10512 - Doesn't parse marked sections

Status: RESOLVED WONTFIX

(Core :: DOM: HTML Parser, defect, P3)

Description

[russell]

Marked sections are indicated by <![keyword[ ... ]]>, where keyword can be one of the following: INCLUDE, IGNORE, TEMP, CDATA, RCDATA. See http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.3.5 (note that lynx handles this vaguely correctly).

Comment 1

[rickg]

It appears as though nav has never dealt with these, and that IE simply ignores
them. I'll decide whether to deal with them later.

Comment 2

[Blake Ross]

reopening and marking Future...

Comment 3

[bsharma]

updated qa contact.

Comment 4

[Koike Kazuhiko]

Mozilla stopped rendering at <![endif]-->.

<!--[if gte IE 5 ]>
for IE
<![endif]-->

<http://www.rescue.ne.jp/> is a serious example. Mozilla shows a blank page.

Comment 5

[russell]

<!--[if gte IE 5 ]>

isn't a marked section, and isn't part of any HTML standard that I know of.
The syntax is different from that of a marked section.

I don't think this issue should be addressed in this bug.
(Personally I don't think it sould be addressed at all.)

Comment 6

[Christopher Hoess (gone)]

Attachment: Testcase with different types of marked sections

Comment 7

[Christopher Hoess (gone)]

Okay, with Clarence's patch 0.9 for bug 57724, we handle CDATA correctly and
ignore the rest. That can probably be hacked up for RCDATA, too.

Comment 8

[Christopher Hoess (gone)]

Attachment: More good clean fun

Comment 9

[Russell O'Connor]

According to <http://www.sgml.u-net.com/book/sgml-8.htm#Using>:

No keywords are equivalent to the INCLUDE keyword
<![[I can read this]]>

Marked sections can be nested, and more that one keyword can be used in a marked
section.  The precidence is as follows

INGORE
CDATA
RCDATA
INCLUDE

<![ IGNORE TEMP [I can't read this]]>

Of course IGNORE and INCLUDE sections can't be nested instide CDATA and RCDATA
sections because <! will not be recongized by the parser.

(Time for another test suite I guess)

Comment 10

[Christopher Hoess (gone)]

->harishd

Comment 11

[Christopher Hoess (gone)]

Attachment: Really immense testcase.

Comment 12

[Hixie (not reading bugmail)]

we should WONTFIX this. You can do marked sections in XML if you really want
them, and at least that is not an obsolete standard. There's zero chance that
any other browser will ever do marked sections in text/html, while many have
already implemented them in XML.

Comment 13

[Christopher Hoess (gone)]

Hixie: no, you can't. Look at the testcases. I agree that this should be at more
or less the bottom of harishd's priority stack (I expect this to be solved by a
non-NS patch, if ever), but that doesn't mean WONTFIX.

Comment 14

[Hixie (not reading bugmail)]

Ok, I've looked at the testcases, they were what I expected. So what?

Why should we add yet another possible source of bugs for a feature which has
zero demand and which is in a spec which has been end-of-lined?

Comment 15

[Christopher Hoess (gone)]

Why do we support stylesheets-through-link-headers-created-by-meta-tags? Why do
we support head {display: inline}? Why do we support text-decoration: blink?

If this ever gets patched, the module owner and peers are perfectly capable of
assessing whether or not it's too risky or too pointless, and it doesn't violate
any standard. Stop kvetching and let them do their job when the time comes
(which may well be never, after all).

Comment 16

[Hixie (not reading bugmail)]

> Why do we support stylesheets-through-link-headers-created-by-meta-tags?

Because Link: headers were removed from HTTP because of lack of implementations,
and we thus want to support them to add weight to the argument of adding them
back in a future verison of HTTP, and there is no equivalent in modern specs.
The http-equiv META tag should be taken out back and shot, but since it exists
in the most recent version of the specs, we support it.


> Why do we support head {display: inline}?

Because the current (non-obsolete) spec says to.


> Why do we support text-decoration: blink?

Because text-decoration: blink could get us into a StarGate SG-1 movie.


> If this ever gets patched, the module owner and peers are perfectly capable of
> assessing whether or not it's too risky or too pointless, and it doesn't 
> violate any standard. Stop kvetching and let them do their job when the time 
> comes (which may well be never, after all).

I'm not whining, I am asking that we spend time on useful features instead of
bloating our already bloated product with features that have no demand, and
which have been obsoleted by more recent developments in web standards.

Comment 17

[Christopher Hoess (gone)]

>> Why do we support stylesheets-through-link-headers-created-by-meta-tags?

>Because Link: headers were removed from HTTP because of lack of 
>implementations,

i.e., a feature that has no demand, and obsoleted by more recent developments 
in web standards.

> and we thus want to support them to add weight to the argument of adding them
> back in a future verison of HTTP, and there is no equivalent in modern specs.

Not at the HTTP level; but <link> seems to be working quite well for those 
people who need to use it. (Also, this would be more convincing if I found 
evidence that the HTTP WG knew this was being argued for.)

>> Why do we support text-decoration: blink?

> Because text-decoration: blink could get us into a StarGate SG-1 movie.

i.e., someone thought this particular piece of bloat was cute. (Don't forget 
that for accessibility purposes, we need a pref to turn it off--and the 
implementation is evidently rather delicate, it's broken twice, I think.)

As for "obsolete", you said in the middle of June that it will be about four 
years (and probably longer) before we can start using the next recommendation 
up. That's plenty of time for Gecko to gain marketshare and let people make use 
of things that haven't been used before, because they've never been implemented.
(<pre><![RCDATA[...lots of markup here...]]></pre> comes to mind, for instance).
From my knowledge of parser, this isn't particularly high-risk (at least in 
comparison to the quirks changes that harishd implements pretty regularly), and 
it isn't terribly bloaty, either (I think the changes can even be limited to 
the parser and kept from content-sink). But based on historical precedent, I 
won't convince you, and you won't convince me; so let's drop the argument, stop 
spamming the rest of the cc list, and let harishd decide whether or not he 
wants this WONTFIXed.

Comment 18

[Russell O'Connor]

My current understanding is that handling marked sections is a requirement of
the ISO_HTML (ISO/IEC 15445:2000).  This international standard should be good
till 2005.

I don't know where one would get the idea that this standard is end-of-lined.

Maybe one day inside Help:About Mozilla it will say ``An HTML system conforming
to International Standard ISO/IEC 15445—HyperText Markup Language.''

Comment 19

[Hixie (not reading bugmail)]

>>> Why do we support stylesheets-through-link-headers-created-by- meta-tags?
>> Because Link: headers were removed from HTTP because of lack of
>> implementations,
> i.e., a feature that has no demand, and obsoleted by more recent developments
> in web standards.

No, quite the opposite.

Link: headers have quite a lot of demand, especially in the semantic web world.
It has not been obsoleted -- there is no other way to associate stylesheet,
hyperlink, or other metadata information with a document without modifying the
document itself.

Link: headers in <meta> tags have little to no demand, though. As I said, that
feature was basically only added for completeness.


>> and we thus want to support them to add weight to the argument of adding them
>> back in a future verison of HTTP, and there is no equivalent in modern specs.
> 
> Not at the HTTP level

That's the level which matters.


> but <link> seems to be working quite well

<link> is a different beast, as it modifies the source document.


> for those people who need to use it. (Also, this would be more convincing if I
> found evidence that the HTTP WG knew this was being argued for.)

http://ftp.ics.uci.edu/pub/ietf/http/hypermail/1999/0084.html

Dan Connolly and I may, once we have two client-side implementations, repropose
this feature to the HTTP working group. Draft spec:
   http://www.hixie.ch/specs/http/link/proposal
Comments welcome.


>>> Why do we support text-decoration: blink?
>> Because text-decoration: blink could get us into a StarGate SG-1 movie.
> i.e., someone thought this particular piece of bloat was cute.

...and might get us measurably more market share through media exposure.


> As for "obsolete", you said in the middle of June that it will be about four
> years (and probably longer) before we can start using the next recommendation
> up.

That's the time from the spec becoming CR to it being implemented in many
browsers. Since I doubt marked sections are likely to be implemented in many
browsers, the same argument applies to this.

In fact, since the modern alternative has _already_ been implemented, the
argument is in reverse here: anyone who will be able to use the results of
implementing this can *already* use the modern equivalent that superseded it.


> That's plenty of time for Gecko to gain marketshare and let people make use of
> things that haven't been used before, because they've never been implemented.
> (<pre><![RCDATA[...lots of markup here...]]></pre> comes to mind, for
> instance).

But by the time that happens, they'll also be able to use XML's much simpler and
better understood <![CDATA[ ]]> construct, and that construct will have better
support across browsers.


> From my knowledge of parser, this isn't particularly high-risk (at least in
> comparison to the quirks changes that harishd implements pretty regularly),
> and it isn't terribly bloaty, either (I think the changes can even be limited
> to the parser and kept from content-sink).

I could see that that could be the case. I withdraw my objections that this be
checked in, if someone takes the time to write it. However, I implore anyone who
is considering implementing this to spend their time on any of the much, much
more important bugs in Mozilla, instead of a redundant feature from which few if
any users will benefit.

Note, however, that there is still a concern that this feature is risky. Has
anyone examined whether <!...> style comments (which look remarkably like marked
sections) are in common use? i.e. Would this break many pages?

BTW: Never change someone else's status whiteboard markings.


> My current understanding is that handling marked sections is a requirement of
> the ISO_HTML (ISO/IEC 15445:2000). This international standard should be good
> till 2005.
> 
> I don't know where one would get the idea that this standard is end-of-lined.

Mozilla's isn't an ISO HTML UA, it's a W3C HTML UA. W3C HTML has definitely been
end-of-lined.

(In any case, I was under the impression that the ISO HTML WG had decided to
stop developing HTML and had dissolved. Is this not the case? If it is, then
that means that ISO HTML has also been EOLed.)

Comment 20

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

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

Comment 21

[Henri Sivonen (:hsivonen) (not reading bugmail until 2025-02-06)]

I think this should be WONTFIX per HTML5.

Comment 22

[Henri Sivonen (:hsivonen) (not reading bugmail until 2025-02-06)]

Tracking HTML5 now. Not SGML.