The <blink> tag is recognized by mozilla and causes text to blink both in quirks mode and in standards mode. The culprit is the following style rule in html.css (which should probably be moved to quirks.css): blink { text-decoration: blink; }

adding keywords, os -> all, platform -> all, nominating for mozilla0.9

actually, nominating for mozilla0.8 since this is a simple low-risk fix and we have a patch

Could you add a reference to this bug (b=63458) in the same syntax as is used for the rest of quirk.css? If you do that, r=hixie.

What does this patch accomplish? It means that if someone wants to use BLINK, they'll have to make their pages trigger quirks mode. Is that what we want? I'd really rather keep quirks mode/standards mode differences to things where existing pages will break if we support the standards. I don't think the standards say we shouldn't support blink...

I retract my r= unless someone can give a good reason _not_ to support <blink> in standards mode.

Since Ian and I seem to agree and for lack of any response, marking WONTFIX. Please comment or reopen if you disagree.

VERIFIED WONTFIX, reopen if you can answer the questions above. Thanks!

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

Grr. Reopening. Answer to Hixie's question: _Because_ it's _not_ in the standard! Are there any other HTML tags we support in standards mode which aren't in the standard (HTML 4)? If not, why is blink, the most annoying tag on the planet, an exception? If I lose this argument, we should add a comment to html.css giving the reasoning - then there won't be lots of dupes :-) Gerv

There are lots -- signed scripts is one that comes to mind. '-moz-opacity' and '-moz-border-radius' are two others. The question you have to answer is not "why fix this", but: > What does this patch accomplish? It means that if someone wants to use BLINK, > they'll have to make their pages trigger quirks mode. Is that what we want? Like David, I'd really rather keep quirks mode/standards mode differences to things where *existing* pages will *break* if we support the standards. If you write valid markup, then our support of <blink> is irrelevant. Per the specs, if you write invalid markup then behaviour is undefined -- and thus we can do what we like, including supporting <blink>.

Maybe I should have phrased my question differently. "Are there any other obsolete/proprietary HTML tags that we support in standards mode that are not in the standard?" If we can do whatever we want in standards mode, then surely ignoring <BLINK> would get the popular vote over supporting it "just because we can". Gerv

Perhaps the question may be rephrased: How much time and effort do we want to invest in tags such as <blink> that offer no functionality (aside from annoyance) in the most standards-compliant browser in the market? Frankly, if taking thinks like this out will a) speed up the browser, b) speed up getting to version 1.0, or c) make it more stable and less likely to get funky I'm all for the process of elimination. <soapbox> I don't know how many of these things abound around here, but this is the quintessential "feature bloat" question. It all adds up in the end to .jar files that are humungous and cause loading times for moz to be something shy of an eternity. </soapbox> Glad that's out of my system. I think.

Gerv: <xmp> and <plaintext> to name but two. I can see the argument to remove the support for <blink>, but I believe it is far outweighed by the fact that if an author wants to not use it, they need merely not use it. There is no case when an author would "accidentally" run into <html:blink>. Just treat it as an easter egg if that makes it easier to swallow. Loco: To make <blink> work takes one line of CSS. That's it. Nothing else. Time required: none. It's done. Effort required: none. It's done. a. It won't speed up the browser. b. It won't speed up getting to 1.0, in fact it will slow us down because to remove support requires a check-in and a round of QA. c. It won't touch stability because there is no C++ or JS code involved. One line of CSS -- hardly 50 bytes before compression -- and we support an element that *some* people want. Why remove it?

OK, let me try a different tack. :-) We need to be able to turn blinking off (epilepsy and so on.) Until there's a pref for that, why can't we take it out? And another tack: both you and I know that <blink> is the most hated tag on the entire web. So why support it when we don't have to? No-one gives a monkeys about <plaintext>, but <blink> starts wars. Gerv

Being able to turn blink off is a totally different issue from not supporting it in standard mode. It should be a separate bug, and is quite valid. I'm still strongly against doing anything to fix this one (see my previous comment).

Hixie: I see your points and agree completely. However, my main point was "How many of these 50 byte pieces do we have lying around that add to the bottom line?" I guess its more of a curiosity...I'm a big fan of small & fast, although I may have arrived at this crime scene too late to really raise much of a fuss. As for why not leave it in, I think (like the next guy) <blink> is annoying:). Oh, well. Gerv: I'm with dbaron on this one-turning blink on/off is useful but belongs in another bug.-I'd recommend opening one and even tagging it with the access KW...no?

Gerv: we support 'blink' as _part_ of our standards support (indeed, <blink> is implemented just by 'mapping' it in CSS to text-decoration: blink). Loco: probably very few. But even if we had a dozen of these 80 byte things, that's still on 1kb!!! The splash screen is 10 times that at least! :-) Ok. WONTFIXing again.

Here we go again. Marking VERIFIED. Hixie: On the note of the splash screen...I wish I didn't have to see it for quite soooo long:/. Gerv: See you in the new bug.

SPAM. HTML Element component is deprecated, changing to Layout component. See bug 88132 for details.

Come on Bugzilla, you can do it...

David: no, if someone wants brinking text in Standards-mode he has to use valid markup and so use text-decoration:blink; on CSS. currently Mozilla makes no difference between text-decoration:blink; which is valid and should be supported and <blink> which is invalid and MUST NOT be supported.

There is no spec that says we MUST NOT support this.

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