<blink> tag supported in standards mode

VERIFIED WONTFIX

Status

()

Core
Layout
VERIFIED WONTFIX
17 years ago
15 years ago

People

(Reporter: bz, Assigned: Hixie (not reading bugmail))

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: WONTFIX ? -- fix doesn't accomplish anything useful)

Attachments

(3 attachments)

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;
}
Created attachment 21098 [details]
testcase with xhtml 1.0 strict doctype
Created attachment 21101 [details] [diff] [review]
proposed patch
adding keywords, os -> all, platform -> all, nominating for mozilla0.9
Keywords: mozilla0.9, patch, review, testcase
OS: Linux → All
Hardware: PC → All
actually, nominating for mozilla0.8 since this is a simple low-risk fix and we
have a patch
Keywords: mozilla0.9 → mozilla0.8
(Assignee)

Comment 5

17 years ago
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.
Created attachment 21106 [details] [diff] [review]
patch with (b=63458) added
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...
(Assignee)

Comment 8

17 years ago
I retract my r= unless someone can give a good reason _not_ to support <blink>
in standards mode.
Whiteboard: WONTFIX?
Since Ian and I seem to agree and for lack of any response, marking WONTFIX.
Please comment or reopen if you disagree.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
(Assignee)

Comment 10

17 years ago
VERIFIED WONTFIX, reopen if you can answer the questions above. Thanks!
Status: RESOLVED → VERIFIED

Updated

17 years ago
Keywords: mozilla0.8
*** 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
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
(Assignee)

Comment 13

17 years ago
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>.
Assignee: clayton → ian
Status: REOPENED → NEW
Whiteboard: WONTFIX? → WONTFIX ? -- fix doesn't accomplish anything useful
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

17 years ago
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.
(Assignee)

Comment 16

17 years ago
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).

Comment 19

17 years ago
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?
(Assignee)

Comment 20

17 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → WONTFIX

Comment 21

17 years ago
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.
Status: RESOLVED → VERIFIED
SPAM. HTML Element component is deprecated, changing to Layout component. See
bug 88132 for details.
Come on Bugzilla, you can do it...
Component: HTML Element → Layout
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.
(Assignee)

Comment 25

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

Comment 26

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

Updated

15 years ago
QA Contact: bugzilla → gerardok
You need to log in before you can comment on or make changes to this bug.