[whatwg] Adoption Agency Algorithm
lachlan.hunt at lachy.id.au
Fri Jan 27 17:49:14 PST 2006
I'm Putting this back on the list, my last reply was sent off-list by
Ian Hickson wrote:
> On Sat, 28 Jan 2006, Lachlan Hunt wrote:
>>> <i> Foo
>>> ...the "Bar" musn't be in italics, the <style> block musn't be used, etc.
>> In a frameset document, where all the content is displayed within frames using
>> external documents, when would "Bar" ever be displayed anyway (unless the UA
>> doesn't support frames and was rendering the noframes content).
> <noframes> works in normal docs too.
OK, I didn't realise that. I thought the tags would just be ignored and
the content rendered in non-frameset documents, but this is apparently
not the case.
>> In which case, why does it matter whether or not "Bar" ends up within
>> the I element or not? It should be treated exactly the same way as this
>> would be for a non-frameset document:
> ...that is treated exactly the same as:
> <i>Foo Bar
> ...so probably not what you wanted. :-)
Actually, that is what I intended. I just didn't think of the case with
noframes in a regular document.
>> Besides, if that was a real problem, could it not be defined as a
>> special case so that upon encountering </noframes>, all unclosed child
>> elements are then closed and not reopened?
> We could, which would solve some of the problems, I guess.
>> I'm not sure what the style element in your example is supposed to show,
>> but I'm sure it could be ignored just like scripts, although it would
>> have no effect on the documents within the frames anyway.
> It didn't have to be a frameset document. My point was that there were a
> LOT of things to worry about. Any <head>-level element, form controls,
> image maps, there are a lot of things to worry about if we care about
> back compat while still wanting the DOM to be a real DOM for <noframes>
> and company.
Ok, I think the noframes case can be handled something like this and the
noscript can probably be handled in a similar way.
<link> and <style>
Moved to the document head (just like normal erroneous link element
in the <body>).
If frames are supported/enabled then
the DOM disabled attribute is set to true.
else frames are unsupported/disabled
They are applied as normal (if styles are supported).
Setting the disabled attribute allows them to be present in the DOM, but
stops them having any effect on the document and so backwards
compatibility is retained. <link>s for anything other than stylesheets
isn't much of a backwards compatibility concern, it doesn't matter if
they're left enabled or disabled.
If frames are supported/enabled then
The script is not executed
else if scripts are supported
The script is executed (if scripts are supported).
This should also be the case if script elements are dynamically appended
to noframes/noscript elements like this:
In Mozilla this does not execute the script when it's appended to the
noframes element, but it does in Opera. Both will current execute if
you substitue noframes with noscript. IE fails with script errors.
Apparently it doesn't like using innerHTML on script elements, nor
appending children to a noframes element.
This is appended to the head element (just like a normal erroneous
meta element in the <body>)
Since a new meta element in the DOM will have no effect whatsoever
upon the document for backwards compatibility, it needs nothing
special done. It could even be completely ignored and not added to
the DOM at all, if you'd prefer.
This one may be a problem, but very few pages use base anyway, let
alone within a noframes or noscript element. It could probably just
be completely ignored.
If there is already a page title, this should be ignored. If there
isn't, use this and the page will gain a title, which is hardly much
of a backwards compatibility concern.
Form Controls (input, select, etc.)
These do not become associated with any form element outside of the
noframes and are thus, not submitted.
<p><input type="submit" value="Go 2">
<p><input type="submit" value="Go 1">
Activating button "Go 1" will submit ?foo=X.
In a browser that doesn't support frames (or scripts in the case of
noscript), activating "Go 2" will submit ?baz=X as defined for nested
forms in WF2.
?bar=X will never be submitted, it's not associated with any form.
There is one case I can think of that may cause problems.
var foo = document.getElementById("foo");
If it were parsed as markup instead of CDATA, calling getElementById()
would return the one within the noframes element, but I can't imagine
this case being very common at all and if it only breaks 1 in a million
pages who really cares!?
I'm not sure what you meant about problems with image maps, unless you
were talking about a case like this:
<img ... usemap="foo">
Which is somewhat like the getElementById example above in that the
reference to the map element is now ambiguous, but again, I don't think
this is a major backwards compatibility concern.
More information about the whatwg