63458 - <blink> tag supported in standards mode

Status: VERIFIED WONTFIX

(Core :: Layout, defect)

Description

[Boris Zbarsky [:bzbarsky]]

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;
}

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: testcase with xhtml 1.0 strict doctype

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: proposed patch

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

Comment 5

[Hixie (not reading bugmail)]

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: patch with (b=63458) added

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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...

Comment 8

[Hixie (not reading bugmail)]

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

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 10

[Hixie (not reading bugmail)]

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

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

Comment 12

[Gervase Markham [:gerv]]

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

Comment 13

[Hixie (not reading bugmail)]

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>.

Comment 14

[Gervase Markham [:gerv]]

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

Comment 15

[Loco]

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.

Comment 16

[Hixie (not reading bugmail)]

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?

Comment 17

[Gervase Markham [:gerv]]

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

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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).

Comment 19

[Loco]

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?

Comment 20

[Hixie (not reading bugmail)]

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.

Comment 21

[Loco]

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.

Comment 22

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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

Comment 23

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Come on Bugzilla, you can do it...

Comment 24

[Kai Lahmann (is there, where MNG is)]

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.

Comment 25

[Hixie (not reading bugmail)]

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

Comment 26

[Robert Wall]

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