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

RESOLVED DUPLICATE of bug 111103

Status

()

Core
CSS Parsing and Computation
P3
normal
RESOLVED DUPLICATE of bug 111103
18 years ago
16 years ago

People

(Reporter: John Morrison, Assigned: Pierre Saslawsky)

Tracking

({testcase})

Trunk
Future
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2-][nsbeta3-], URL)

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
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]
(Reporter)

Comment 1

18 years ago
Created attachment 3683 [details]
example; absolutely postioned LAYER in Gecko (1999122008)
Assignee: ekrock → vidur
Summary: Your article "Transitioning from ..." & Positioning LAYERs → [LAYER] Your article "Transitioning from ..." & Positioning LAYERs
Target Milestone: M13
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.
(Reporter)

Comment 3

18 years ago
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.
Summary: [LAYER] Your article "Transitioning from ..." & Positioning LAYERs → [LAYER] Mozilla not ignoring STYLE attribute of LAYER, ILAYER, NOLAYER (and bogus FOOBAR elements)
[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?
(Reporter)

Comment 5

18 years ago
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?]
Summary: [LAYER] Mozilla not ignoring STYLE attribute of LAYER, ILAYER, NOLAYER (and bogus FOOBAR elements) → [LAYER] Mozilla not ignoring STYLE attribute of LAYER, ILAYER, NOLAYER
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

18 years ago
Created attachment 3902 [details]
original example with the quotes removed from the STYLE tag

Updated

18 years ago
Whiteboard: [TESTCASE] Without the quotes (single or double) around the STYLE attribute, the LAYER, ILAYER tags are ignoredthe
(Reporter)

Comment 8

18 years ago
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 :-]

Updated

18 years ago
Assignee: vidur → harishd

Comment 9

18 years ago
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.

Updated

18 years ago
Target Milestone: M13 → M14
Status: NEW → ASSIGNED
Summary: [LAYER] Mozilla not ignoring STYLE attribute of LAYER, ILAYER, NOLAYER → [LAYER] Mozilla must ignore attribute values for unknown elements (esp. STYLE for I/NO/LAYER)
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.
Blocks: 23722

Updated

18 years ago
Assignee: harishd → vidur
Status: ASSIGNED → NEW

Comment 11

18 years ago
Enabled userdefine tags ( partial fix for this bug ).  Assigning bug to vidur to
fix the rest:)
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase

Comment 13

18 years ago
Updating QA Contact.  adding docs folks to cc list
QA Contact: nobody → rudman
(Reporter)

Comment 14

18 years ago
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) 
Whiteboard: [TESTCASE] Without the quotes (single or double) around the STYLE attribute, the LAYER, ILAYER tags are ignoredthe → [TESTCASE]

Comment 15

18 years ago
Need to create a nsHTMLUnknownElement class for all unknown tags (including 
LAYER/ILAYER) and ignore all attribute processing in the class. Aiming for M15.
Status: NEW → ASSIGNED
Target Milestone: M14 → M15
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 17

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

Comment 18

18 years ago
Created attachment 7248 [details]
testcase; same as attach #1, but style is spec'd in the head
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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?
Assignee: vidur → pierre
Status: REOPENED → NEW
Since we've decided the docs are correct but our behaviour is wrong, should 
this be moved over to the Browser product?
Keywords: 4xp
Summary: [LAYER] Mozilla must ignore attribute values for unknown elements (esp. STYLE for I/NO/LAYER) → Mozilla must ignore attribute values for unknown elements (esp. STYLE for I/NO/LAYER) [LAYER]
Whiteboard: [TESTCASE]

Comment 22

18 years ago
Yes, it could move. (If you change the component, also set qa to 
desale@netscape.com).

Comment 23

18 years ago
How come this is still M15? M15 is already out!
Moving to Browser product. This is a core Gecko Layout bug.
Component: Web Developer → Layout
Product: Documentation → Browser
Target Milestone: M15 → M16
Version: unspecified → other
(Assignee)

Comment 25

18 years ago
Pushing to M17 for more investigation, especially on how IE works and check 
whether it cascades the style.
Status: NEW → ASSIGNED
Target Milestone: M16 → M17
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).
Keywords: nsbeta2

Comment 27

18 years ago
Setting qa contact to desale@netscape.com.
QA Contact: rudman → desale

Comment 28

18 years ago
[nsbeta2+] [6/1] will take fix landing by 6/1
Whiteboard: [nsbeta2+] [6/1]

Comment 29

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

Comment 30

18 years ago
Updating from [6/1] to [6/15]
Whiteboard: [nsbeta2+] [6/1] → [nsbeta2+][6/15]

Comment 31

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

Whiteboard: [nsbeta2+][6/15] → [nsbeta2-]
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.
Keywords: nsbeta3
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.
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Target Milestone: M17 → Future
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.
Assignee: pierre → nobody
Status: ASSIGNED → NEW
Component: Layout → Evangelism
Keywords: evangwanted
QA Contact: desale → nobody
Target Milestone: Future → ---
Oops, this bug got caught in the Evangelism moveover by mistake. Sorry about 
that! Changing component back to Style System, restoring Future, reassigning to 
pierre@netscape.com who was the owner. Restoring QA contact to 
desale@netscape.com.
Assignee: nobody → pierre
Component: Evangelism → Style System
Keywords: evangwanted
QA Contact: nobody → desale
Target Milestone: --- → Future
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

17 years ago
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.
*** Bug 23722 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 111103 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.