Closed Bug 63458 Opened 19 years ago Closed 19 years ago

<blink> tag supported in standards mode

Categories

(Core :: Layout, defect)

defect
Not set

Tracking

()

VERIFIED WONTFIX

People

(Reporter: bzbarsky, Assigned: ian)

References

Details

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

Attachments

(3 files)

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
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.9mozilla0.8
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.
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
Closed: 19 years ago
Resolution: --- → WONTFIX
VERIFIED WONTFIX, reopen if you can answer the questions above. Thanks!
Status: RESOLVED → VERIFIED
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 → ---
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
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.
Status: NEW → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → WONTFIX
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.
There is no spec that says we MUST NOT support this.
*** Bug 150855 has been marked as a duplicate of this bug. ***
QA Contact: bugzilla → gerardok
You need to log in before you can comment on or make changes to this bug.