Closed Bug 242298 Opened 20 years ago Closed 13 years ago

Need to decide how to handle content that "is not rendered" (in HTML)

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: bzbarsky, Unassigned)

References

Details

We need to decide once and for all how to handle content that should somehow
"not exist" per what there is of a spec for HTML.  We need to decide exactly how
such content behaves -- do scripts execute, do stylesheets load, can the DOM see it?

Once we decide that, we need to consistently implement it and apply it to
<iframe>, <noframes>, <object>, <noscript>, <applet>, etc.

At the moment, scripts and stylesheets inside <object> apply to the document. 
<iframe>, <noframes>, and <noscript> are handled in the parser and those nodes
don't even appear in the DOM.

We have a bunch of bug reports on various aspects of this; marking some dependent.

Thoughts?  How best to achieve this with minimal pain, especially for <object>
becoming replaced by its content?
The question is basically: Given:

   <script> ...1... </>
   <one-of-the-elements-mentioned-above>
    <script> ...2... </>
   </one-of-the-elements-mentioned-above>
   <script> ...3... </>

...what order do the script blocks execute in, in these scenarios:

  a. the element is disabled, and stays disabled
  b. the element is enabled, the content is available
  c. the element is enabled, the content is not yet available but will be soon
  d. the element is enabled, the content is not available
  e. the element is enabled, the content is not available but we don't know yet
  f. the element is disabled, but is later enabled triggering case b
  g. the element is disabled, but is later enabled triggering case c
  h. the element is disabled, but is later enabled triggering case d
  i. the element is disabled, but is later enabled triggering case e
  j. the element is enabled and content is known available but is then disabled
  k. the element is enabled and content is known unavailable and then disabled
  l. the element is enabled but is disabled while content is being loaded
  m. the element is disabled and its contents manipulated through the DOM

This is especially important given document.write() calls in those scripts.

Then there are specific pper-element questions:

   <noframes>
     Should toggling frames on/off be dynamic, affecting already-loaded pages?

   <noscript>
     Should toggling script on/off be dynamic, affecting already-loaded pages?

   <input>
   <img>
     Should we do anything with what are basically replaced elements, or should
     their contents go ahead and execute happily?

   <iframe>
   <object>
   <applet>
   xlink:show="embed"
     Should we show the alternative content while the document is loading?
     (how about if there is an <object standby=""> attribute)

...and finally: Do we want all these elements to act the same? Or does it make
sense for some to be different?
Oh, and, should setting *{display:block!important} override this logic?
...and should it differ for XML than for HTML?
I've started writing some tests:
   http://www.hixie.ch/tests/evil/page-loading/alternative-content/investigation/

So far I've tested <noframes> in various situations. Results of browsers I was
able to test (or have someone test for me) are mentioned in the tests.
By the way, types of "active content" we have (things that would need disabling
when "not rendered" or something):

<style>
<link>
<meta http-equiv="link">
<script>
<img> (since it'd fire onload/onerror events)
<object> (same reason)
<embed> (same)
<iframe> (since it can include a document with scripts or whatever)
<frame> (same reason)
<meta http-equiv="refresh">
auto xlinks
<base>
maybe <meta http-equiv="content-type">.

I may have missed a few....
Incidentally, while testing this I ran into an interesting side-effect of the
content sniffing nonsense that IE does. If you have:

   <object data="test.txt">

...then it works roughly as expected but if you have:

   <object data="test.tst">

...the object element does not appear in the resulting DOM. Isn't IE great?
Ok. I made some tests and got results for Opera, Mozilla, IE6 and Safari. Let me
know what else you want me to test.

The results for IE are so totally insane that I can't really see much point in
trying to follow it.

The results for other browsers suggest that <noframes> has the
disable-the-contents magic, but <object> doesn't. Which makes sense given the
model of <noframes> being like an #ifdef and <object> being just presentational.
What does the DOM look like?  In Mozilla, the contents of <noframes>, say, are
actually parsed as CDATA.... what do the other browsers do?
In the results, "DOM broken" means that the <div> wasn't a child of the
<noframes> or <object>, "DOM ok" means the <div> _was_ a child of the <noframes>
or <object>, "no DOM1" and "no DOM2" means that the support for DOM1 or DOM2 was
not good enough to be able to run the test, and "not in DOM" means the element
could not be found in the DOM. (In particular, IE seems to handle <object>
fallback by removing the element from the DOM altogether.)

Does that help?
Yeah; I hadn't thought to look at the tests themselves for the results....  So
Safari removes noframes from the DOM altogether, eh?

Also, how do the various browsers handle things like:  

  <noscript> <noscript> aa </noscript> </noscript>

and similarly for noframes?
Sorry, forgot to mention I'd put the results in the tests.


> Also, how do the various browsers handle things like:  
> 
>   <noscript> <noscript> aa </noscript> </noscript>
> 
> and similarly for noframes?

Are you sure you want to know? Tested Mozilla, Opera and IE6:

http://www.hixie.ch/tests/evil/page-loading/alternative-content/investigation/010.html

Of particular note: IE's concept of elements with tag names starting with a "/"
to represent end tags that it couldn't associate with a start tag.
> Are you sure you want to know?

I thought I was.  Now that I saw what happens, I don't anymore... ;) 
Interesting that IE doesn't allow noscript to nest; that makes it impossible to
implement the (really moronic, as specified) letter of the HTML4 spec.  I'm sure
they spend nights worrying about it.
Another example is SVG's switch element.  I suspect the patch in bug 216563
isn't the right approach, especially considering interaction with XBL.  My gut
feeling is that these content-based mechanisms for ignoring things should set a
bit on the content that both content and layout can look at to determine that it
should be ignored.
Blocks: 216563
No longer blocks: 216563
Blocks: 171254
Blocks: 147070
Blocks: 256624
Blocks: 276865
Note that if this fix causes content in unrendered content not to load images,
we might need to cause the object-replacement process (which uses a restyle
event) to block onload firing, since it could cause a load to start on the next
inner object / embed / img.
HTML5 basically defines this now; for some elements, the parser does the CDATA thing, for other elements, the contents aren't shown but still execute. There's very little in the way of magic involved.
Assignee: general → nobody
QA Contact: ian → general
Is there still something left to fix here?
I'd be fine with closing this bug.
The current setup is terrible for <audio> containing <object> that plays audio, but that's life, I guess...
Let's close it.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.