On the W3C Style page, where it talks about being able to "influence the presentation of documents without sacrificing device-independence or adding new HTML tags", the last few words are inside a <blink>. The custom DTD of that page explains that the <blink> is just a joke. The W3C is making fun of us! text-decoration: blink; is valid. <blink> is NOT valid. It must be killed. (Note that none of them will currently make text blink due to bug 89065.)

BTW, this is not a dup of bug 63458. That bug was about moving <blink> support to quirks mode, this one is about removing it completely.

You sure we should remove it? We didn't remove <font> either, for example. It should be supported in quirks mode.

> You sure we should remove it? Yes. > We didn't remove <font> either, for example. <font> is bad, but it is a valid HTML tag according to the W3C recommendations. <blink> is not. > It should be supported in quirks mode As I understand it, quirks mode isn't supposed to be an IE/NS4 emulation mode but rather the same as standards mode with only the changes that are absolutely required for not breaking pages written for old browsers.

hmmmm >As I understand it, quirks mode isn't supposed to be an IE/NS4 emulation mode As I understand it, quirks mode is exactly supposed to be an IE/NS4 emulation mode.

Mielke: Then it should (would need to) have document.all and document.layers too. Do we really want that?

<blink> isn't and was never part of any W3C Spec, so it should ge killed. Only textdecoration:blink; is allowed in there.

I still fail to see how this is different from bug 63458. All the same arguments apply to both bugs.... If you don't like blink, disable it in your build. We have a pref for that.

I thought the whole point of Mozilla was to have a browser that did not add proprietary extensions to HTML? <sarcasm>Why don't we just implement document.layers and document.all and tell people to turn them off in their buils?</sarcasm> Yes, there's a pref for disabling blinking text. So what? This bug is not about preventing blinking text. I'm not saying we should rip out text-decoration: blink. I'm just saying we should kill <blink>, since it's not part of any W3C recommendation and thus has no place in a web browser. Unless, of course, we rename it to <-moz-blink>...

> Why don't we just implement document.layers and document.all I know this was sarcasm, but that's a real question that has a real answer. Quite simply, they would take too much effort to do. So we don't do them. <blink> takes no effort.

You mean that if someone wrote a patch that enabled document.all and .layers in Mozilla, it would get checked in? So that, once Mozilla was the market leader, every other browser would have to implement them as well?? And we'd start seeing Best Viewed With Mozilla banners?!? Oh, please, God, no. What I'd like to see is a browser that supports the W3C standards 100%, and nothing, nothing, *nothing*, nada, zilch, zip else, unless it had a -vendor- prefix. And it shouldn't support window.open either. That is the only way we can get a web where all pages look the same in all browsers, no matter what. Yes, I'd like to see .innerHTML removed from Mozilla as well. Oh, and that weird <font point-size=...> thing that the 4.x composer sometimes generates.

Please don't be silly... If we did that we'd be unable to render the web and would have no market share and thus no effect on the world. There's no reason to do this. INVALID.

> You mean that if someone wrote a patch that enabled document.all and .layers in > Mozilla, it would get checked in? If it worked and worked correctly and did not cause problems, than probably. Verified INVALID.

> > You mean that if someone wrote a patch that enabled document.all and .layers in > > Mozilla, it would get checked in? > > If it worked and worked correctly and did not cause problems, than probably. Say WHAT? You must be joking! I can't believe it :-/

> Please don't be silly... If we did that we'd be unable to render the web and > would have no market share and thus no effect on the world. Now, yes. When Moz has 75% market share, it would be possible. Please remind me to file a bug called "back out quirks mode" when Moz reaches 75% market share. > There's no reason to do this. INVALID. I can see how this could be WONTFIX, but how can it be INVALID? > > > You mean that if someone wrote a patch that enabled document.all and > > > .layers in Mozilla, it would get checked in? > > > > If it worked and worked correctly and did not cause problems, than probably. > > Say WHAT? You must be joking! I can't believe it :-/ Me neither. :-( <slightly-offtopic>Ben Bucksch: Just out of curiousity, what is Beonex's official opinion on adding document.all/document.layers support to Mozilla? (Not that it would ever happen -- thank god for that -- but just theoretically.)</slightly-offtopic>

> Ben Bucksch: Just out of curiousity, what is Beonex's > official opinion on adding document.all/document.layers support to Mozilla Generally, Beonex supports standards, not proprietary extensions, whereever possible. What "possible" is is the tough question. I guess, we now have the chance to make the world create documents that at least somewhat comply to the w3c specs. If we support document.all now, we'll forever be stuck with it. But I don't know about the crap on the web out there to make informed decisions. I rely on the people in the HTML rendering group to decide that. > What I'd like to see is a browser that supports the W3C standards 100%, and > nothing, nothing, *nothing*, nada, zilch, zip else This is indeed silly, unfortunately. Hixie is right - we'd be unable to render 95+% (number take out of the air) of the web and be useless. As for this bug, I see no reason to support the <blink> tag. The quirks mode does not emulate NS4 exactly anyways, so do what the user wants. I have yet to see a user who likes text blinking. I'd vote fixing this bug, and probably will do so in Beonex Communicator. And, such a bug is at most WONTFIX, not INVALID.

Cool. Beonex rocks :-) I don't think the number is as high as 95%, but it's definitely high enough to keep support for most of the proprietary elements currently supported. I hope support for them can be removed gradually as Moz gains market share. Leaving resolution as INVALID to avoid creating three meaningless mail notifications, but I consider this bug to be VERIFIED WONTFIX.

I found this by coincidence on <http://www.mozilla.org/community.html>: Wishlist This forum is for discussions of future ideas, ranging from the practical to the far out. Read the wishlist FAQ to see if your wish has already been discussed. (Note that ``turn off the <blink> tag'' has already been discussed to death.) :-)

*** Bug 148365 has been marked as a duplicate of this bug. ***

the bug to remove an _invalid propietary_ HTML Tag get's invalid? text-decoration:blink is valid CSS1. <blink> is a proprietary Extension from Netscape 2 or 3 and never got into HTML spec. It makes Mozilla Advocacy more or less hopeless, if Mozilla still has such trash, I get quite often a "Mozilla extents HTML in bad old Netscape tradition" on this.

So.. do you suggest that we remove support for backgrounds on <td> via the "background" attribute as well? That's also an invalid extension to HTML....

to be strict we should, but as this could render many pages unreadable and it's supported by many browsers. <blink> neighter makes problems if it's not there, nor is it supported by many browsers.

Kai Lahmann, if you want to have this REOPENed, please point to the previous discussion (preferably a summary of it), which obviously exists, considering the wishlist charter quoted above.

The interesting thing about http://www.w3.org/Style/ is that its doctype is <!DOCTYPE html SYSTEM "http://www.w3.org/Style/HTML40-plus-blink.dtd">. The funny thing is that the page (http://www.w3.org/Style/) is validated with http://validator.w3.org/ ;-) The actual validator text is: "Congratulations, this document validates as the document type specified! (I don't have an icon for this one yet, sorry.)" Does it mean that W3C supports <blink>, after all? Well not quite. The DTD file has the following comment: "This is basically just HTML40, but with BLINK added. This will make /Style/Overview.html validate, but it doesn't make it valid HTML40. The BLINK is merely added as a joke."

There is bug 106462 about providing a UI for this. The discussion was in bug 19258. I can't see why this bug is reopened. If the defaults are undersired, file an RFE about having it disabled by default, or rather comment about it in the valid bugs dealing with this.

Bug 106462 is not about providing a UI for enabling/disabling <blink>. It is about providing a UI for enabling/disabling <blink> *and* text-decoration:blink. It is not at all relevant to this bug, and neither is the default value of that pref, since this bug asks for removing support for the <blink> tag while keeping support for text-decoration:blink. > So.. do you suggest that we remove support for backgrounds on <td> via > the "background" attribute as well? Is it supported in both layout modes? IMO it should only be supported in quirks mode.

dbaron (Style System module owner) and I (Style System QA) agree that Quirks mode should only be for things that break standards compliant pages, such as the quirky inline box model. Since <blink> is not such a feature, we will not be removing it from our standards compliant mode. WONTFIX.

> Quirks mode should only be for things that break standards compliant pages That isn't really relevant since this bug asks for <blink> to be removed from both quirks and standards mode (my comment 25 was about td background, not blink). Nevertheless, marking VERIFIED since the module owner has made the call that he doesn't want this to be fixed.

Oh, I didn't realise this was for removing <blink> completely. I don't see the point of removing <blink>. Think of it as an easter egg...

*** Bug 162300 has been marked as a duplicate of this bug. ***

Blink should be more BEARABLE. Bug 173540 has the solution.

Duping forward to bug 857820, where we did end up fixing this and killing the <blink> tag after all.