Do not create text-content for tags that contain alternate content

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
16 years ago
9 years ago

People

(Reporter: harishd, Unassigned)

Tracking

({memory-footprint})

Trunk
x86
Windows 2000
memory-footprint
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
Currently, the contents of noscript, noframes, iframe...etc., ( tags that
contain alertnate content ) are collected as string since the content should not
be processed when script/frames are enabled. However, the collected content is
never used, in the browser mode, and hence does not have to be in the content
model. That is, the parser can dispose the alternate content in the browser mode
( but should retain it for editor ).
But if someone turns off Javascript, shouldn't we display the content of 
"noscript"? (I think there's also a bug asking for the ability to turn off 
frames, but I'm not sure.)
(Reporter)

Comment 2

16 years ago
Yes if script is turned off then we treat the alternate content as regular
content and will become a part of the content model.

Updated

16 years ago
Blocks: 92580
Keywords: footprint
Does this seem reasonable from a compat point of view?  Are there sites that
depend on this being in the DOM?
It would always be in the content model for XHTML... I'd rather leave it in for
HTML too, the fewer differences between the two the better.
Actually, for XHTML we insert 'real' DOM, i.e. elements etc so we are already
not doing the same thing between the two. I.e. for the following markup:

<noscript>
  <span>error</span>
</noscript>

In HTML create just a big textnode with .value = "<span>error</span>"
In XHTML we create an actual <span> with a child-textnode with .value = "error".

Actually, i'm not even sure that that is what we do for HTML, i have a
recollection that we actually did drop that content. It could differ from
alternate-content-element to alternate-content-element.

However, I do think that we should move more towards what XHTML is doing, not
towards what HTML is doing. Partly because of what hixie said; differences are
good to avoid. But mostly because in many cases things don't work as they should
in XHTML. Elements expect to be removed from the DOM when they are inside an
alternate-content-element, if they are inserted they execute happily without
checking if they actually should.

The reason we don't find this is simply that people aren't using XHTML very
much. But when they do they run into bugs like this (which makes them switch
back to HTML many times i would guess).
Assignee: harishd → nobody
QA Contact: moied → parser
This should be WONTFIX per HTML5.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.