Closed Bug 124699 Opened 23 years ago Closed 22 years ago

Kill <blink>

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect
Priority:
Not set
Severity:
trivial

Tracking

()

Status:
VERIFIED DUPLICATE of bug 857820

People

(Reporter: jonasj, Assigned: attinasi)

References

(
URL
)

Details

(Whiteboard: VERIFIED WONTFIX)

Attachments

(1 file)

die, <blink>, die!!!
278 bytes, patch
Details | Diff | Splinter Review 
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.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → 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.
Status: RESOLVED → VERIFIED
Component: Layout → Style System
QA Contact: petersen → ian
> > 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.
Whiteboard: 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.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → 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.
Status: RESOLVED → VERIFIED
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.
Resolution: WONTFIX → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: