22260 - Mozilla must ignore attribute values for unknown elements (esp. STYLE for I/NO/LAYER) [LAYER]

Status: RESOLVED DUPLICATE of bug 111103

(Core :: CSS Parsing and Computation, defect, P3)

Description

[John Morrison]

Hi Eric,

 I was reading your note at http://sites.netscape.net/ekrock/standards.html
and I came across the following statement:

   Navigator 5 will silently ignore the <LAYER>, </LAYER>, <ILAYER>,
   </ILAYER>, <NOLAYER>, and </NOLAYER> tags and render the HTML page as if
   those 6 tags were not present. (i.e. as if the file had been edited to
   remove those 6 tags only)

OK. I admit that I'm confused, but take a look at the attachment (to follow).
I'm still not sure what's in or out, and perhaps this is something that is
scheduled to be cut. But, as it stands, the attachment doesn't jibe with the
above statement. Yes, the contents of LAYER, ILAYER and NOLAYER are all
displayed, but they can still be absolutely or relatively positioned (which
is not quite 'as if [they] were not present'.

John 'Scratching-my-head' Morrison

 [using WinNT SP4 1999122008]

Comment 1

[John Morrison]

Attachment: example; absolutely postioned LAYER in Gecko (1999122008)

Comment 2

[ekrock's old account (dead)]

John -- We put in some fixes right around the 20th of December or so (sorry,
can't locate the bug report); could you quickly reopen the file in M12 and see
if the problem still exists?

Vidur -- Assigning to you in case there's a remaining issue.

Comment 3

[John Morrison]

Well, vidur : the layer, ilayer, and nolayer can be absolutely or relatively
positioned using WinNT 1999122208 (see the test case). [I really filed this
because I thought it was a documentation issue with Eric's tech note.]

The question for you : Is the positioning behaviour demonstrated in the
attached test case the correct behaviour (i.e., what will ship). I have no
opinion, really, but I think this is the intended final behaviour (in which
case, this should be noted in Eric's article).

Reassign to me or Eric when you have a moment to answer. Thanks, John.

Comment 4

[ekrock's old account (dead)]

[Finally downloaded M12 Commercial over dialup on vacation and confirmed bug
report on 1999122023 WinNT 4.0 SP3.] Good catch, John. Actually, since we've
decided that Mozilla will treat I/LAYER and NOLAYER as unknown elements, ignore
them (and their attributes!), and render their contents, you've caught a bug.

Vidur--We should definitely ignore all attributes of LAYER/ILAYER/NOLAYER;
otherwise cross-browser design would be a nightmare, with attributes on
LAYER/ILAYER/NOLAYER that were intended to be Nav4-specific interfering with
style settings on enclosed DIVs or IFRAMES that were supposed to be heeded for
Mozilla.

Also, shouldn't attributes of unknown elements like FOOBAR be ignored when
rendering HTML documents? Tell me if you want me to open a separate bug on that.
But really, Mozilla should handle ILAYER, LAYER, NOLAYER, and FOOBAR all the
same, right?

Comment 5

[John Morrison]

Commenting only re: '<FOOBAR>' -- Mozilla is not recognizing this element and
its attributes, which is _correct_ (it must be ignored in HTML and it is
ignored).

[However, Nav4.x does handle the ILAYER/FOOBAR combination differently
than Mozilla, but I believe that Nav4.x is wrong -- the _contents_ of <FOOBAR>
appear positioned relative to the absolutely positioned <ILAYER>, but the
abs. pos ILAYER is 'out-of-flow' -- hence FOOBAR should not be relative to
it. But that's a 4.x bug, no?]

Comment 6

[ekrock's old account (dead)]

re: FOOBAR: Sorry, my bad. John's right. Mozilla is ignoring the FOOBAR element
and its attributes (as it should) and just rendering the contents (as it
should). So M12's handling of FOOBAR is not an issue.

The issue in this bug, then, is that STYLE attributes on LAYER, ILAYER, and
NOLAYER *should* be ignored but *are not* being ignored. I've revised the
Summary to reflect this. Vidur?

Comment 7

[Jan Bartko]

Attachment: original example with the quotes removed from the STYLE tag

Comment 8

[John Morrison]

Umm, I don't get the point of the previous attachment. The quotes are
*required* around an attribute value that contains whitespace. Obviously, the
parser must interpret the unquoted string as STYLE='position:' and treat the
rest of the string as unknown attributes of the element. [This isn't AI yet :-]

Comment 9

[vidur (gone)]

Turns out that the parser isn't dealing with unknown tags as I thought it did
(and should). Currently, it's throwing them out rather than passing them along
to the content sink. Since I didn't remove parser support for layer/ilayer (I
just changed the sink's handling of them), we're dealing with unknown tags and
layer/ilayer inconsistently.

Passing this along to harish so that he can get the parser to pass along unknown
tags to the sink. Following that, he or I will make sure that the STYLE
attribute isn't processed for the resultant content.

Comment 10

[ekrock's old account (dead)]

We want to fix this as early as possible during M14 so we've got some time to
make sure our handling of I/LAYER is exactly as we intend for beta.

Vidur, Harish, and I checked the first attachment test case in IE4.0 and IE5.5
beta 1 on Windows and confirmed that IE ignores STYLE attribute settings for
unknown elements (FOOBAR and NO/I/LAYER alike).

The HTML 4.0 specification is vague. It does not explicitly say that for unknown
elements, attribute settings should be ignored. However, we agreed that Mozilla
should ignore attribute values for unknown elements for two reasons:

1) compatibility with behavior of IE
2) making it easy for people to create cross-browser pages for Nav4 and Moz/Nav5
that position content using I/LAYER on Nav4 and HTML 4.0/CSS on Nav5, without
having the STYLE attribute settings of I/LAYER that were *intended* for Nav4's
use only start interfering with the layout of the standard content on Nav5

Changing bug summary to generalize it. Also Accepting for harish to move out of
NEW state. Harish will checkin parser changes and reassign bug to Vidur.

Comment 11

[harishd]

Enabled userdefine tags ( partial fix for this bug ).  Assigning bug to vidur to
fix the rest:)

Comment 12

[ekrock's old account (dead)]

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

Comment 13

[leger]

Updating QA Contact.  adding docs folks to cc list

Comment 14

[John Morrison]

Remove comment 'Without the quotes (single or double) around the STYLE 
attribute, the LAYER, ILAYER tags are ignored' from the whiteboard. The 
testcase http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3902 is 
not valid (please ignore, doc/qa folks). The original testcase
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3683 still stands
as the test for 'Mozilla must ignore attribute values for unknown elements 
(esp. STYLE for I/NO/LAYER)'.

While I'm here, I also respond to ekrock's statement of jan 13 "The HTML 4.0 
specification is vague. It does not explicitly say that for unknown
elements, attribute settings should be ignored." I think the answer is in the 
SGML usage of <!ATTLIST el ... > which 'binds' attributes to elements.
(see, e.g., http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.3.4) 

Comment 15

[vidur (gone)]

Need to create a nsHTMLUnknownElement class for all unknown tags (including 
LAYER/ILAYER) and ignore all attribute processing in the class. Aiming for M15.

Comment 16

[Johnny Stenback (:jst)]

I just checked in a nsHTMLUnknownElement class that is basically a normal
element but it doesn't do any inline style processing. The checkin fixes both
testcases in this bug, makrkin this FIXED.

Comment 17

[John Morrison]

"... doesn't do any inline style processing ..." -- did you mean _inline_ or 
_any_ style processing?

Comment 18

[John Morrison]

Attachment: testcase; same as attach #1, but style is spec'd in the head

Comment 19

[Johnny Stenback (:jst)]

I meant _inline_, and that's the only thing that has changed here. FYI, the
HTMLUnknownElement does indeed (in both mozilla and IE) get all the attributes
you set on it, but the style processing is disabled for unknown elements. IOW
document.getElementById('bar') will find <foo id="bar">, just like it does in
IE.

Comment 20

[Johnny Stenback (:jst)]

I now realize that if we want to do what IE does we should also completely
ignore style processing for unknown HTML elements. I think this is something
that needs to be done in the style system (frame constructor?). I tested some
more how IE deal with unknown elements and, if I define the following in a
stylesheet:

.bar {
  color: red;
}

IE ignores this style on <foo class="bar">, but interestingly enough if you
query the element for it's color property (element.style.color) you get "red",
but the color of the element on the page is black?


Reassigning to pierre. Pierre, could we make the CSS frame constructor always
generate an inline frame without any style info (?) for unknown HTML elements,
or do you have other ideas on how this could be solved?

Comment 21

[Hixie (not reading bugmail)]

Since we've decided the docs are correct but our behaviour is wrong, should 
this be moved over to the Browser product?

Comment 22

[John Morrison]

Yes, it could move. (If you change the component, also set qa to 
[e-mail]).

Comment 23

[moshev]

How come this is still M15? M15 is already out!

Comment 24

[ekrock's old account (dead)]

Moving to Browser product. This is a core Gecko Layout bug.

Comment 25

[Pierre Saslawsky]

Pushing to M17 for more investigation, especially on how IE works and check 
whether it cascades the style.

Comment 26

[ekrock's old account (dead)]

nsbeta2 6/1-. Need to get this fixed to enable developers who are upgrading 
Nav4-specific pages that use LAYER to provide easy cross-browser compatibility 
(using LAYER in the page for Nav4, and using IFRAME in the page for N6 and 
having it gracefully ignore LAYER).

Comment 27

[rudman]

Setting qa contact to [e-mail].

Comment 28

[Peter Trudelle]

[nsbeta2+] [6/1] will take fix landing by 6/1

Comment 29

[[e-mail]]

Since unknown tags cannot be containers, they cannot affect layout, can they?

Comment 30

[leger]

Updating from [6/1] to [6/15]

Comment 31

[Jim Roskind]

Cleaning up status whiteboard by changing to beta2 minus (6/15 has passed)

Comment 32

[ekrock's old account (dead)]

Nom. nsbeta3. Final closure on this issue is without question nsbeta3 stopper. 
Since we're forcing developers to upgrade their DHTML content, it's mandatory 
that we make it possible for them to do cross-browser DHTML for Nav4 and 
Moz/Nav6 within a single page when they need to. When we break folks' code, we 
have to provide them with a transition and upgrade path.

Fortunately, it appears that we're really close to resolution on this anyway and 
just need a bit more investigation and (possibly) some tweaking to make sure we 
ignore/inherit things in the right way.

Comment 33

[ekrock's old account (dead)]

Note this comment in bug 42781: "I just today checked in a fix for
bug 38154, which fixes the output system so that if we get an unknown tag like
<foo></foo>, we'll preserve it into the output (and strip off the _moz-unknown
attribute that got added somewhere along the line)."

[nsbeta3-] and FUTURE. Workaround for content providers if they wish to provide
xbrowser compat in a single page with Nav4 and N6 is to pull out the STYLE
attribute, give LAYER a unique ID, and select on that.

Comment 34

[ekrock's old account (dead)]

Moving all [LAYER] bugs to Evangelism component for tracking and open-source
evangelism by mozilla community members of sites that need to upgrade to support 
web standards such as HTML 4.0 (instead of LAYER/ILAYER) and the W3C DOM
(instead of Nav4 document.layers[] or IE document.all()). Sites should be
lobbied to do the upgrade using the email templates that are linked to from
http://www.mozilla.org/newlayout/bugathon.html#layerbugs . When a site's owner
has confirmed receipt of the message requesting an upgrade, the bug should be
marked with the keyword evangelized to indicate that evangelism for that bug is
complete. When the site finishes the upgrade and supports standards, the bug
should be closed.

Comment 35

[ekrock's old account (dead)]

Oops, this bug got caught in the Evangelism moveover by mistake. Sorry about 
that! Changing component back to Style System, restoring Future, reassigning to 
[e-mail] who was the owner. Restoring QA contact to 
[e-mail].

Comment 36

[Boris Zbarsky [:bzbarsky]]

I no longer see this bug on linux build 2001-01-16-08.  There 4 lines of text
appear as just that -- four lines.  No positioning, no borders.

Has this been fixed?

Comment 37

[John Morrison]

See jst's comments from 04/2000, and the attach_id=7248 04/04/2000. Styles
specified in a stylesheet are still applied to unknown elements.

Comment 38

[Doron Rosenberg (IBM)]

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

Comment 39

[Christopher Hoess (gone)]

*** This bug has been marked as a duplicate of 111103 ***