[whatwg] Adoption Agency Algorithm

I'm Putting this back on the list, my last reply was sent off-list by 
mistake.

Ian Hickson wrote:
> On Sat, 28 Jan 2006, Lachlan Hunt wrote:
>>> e.g.
>>>
>>>    <noframes>
>>>      <style>...</style>
>>>      <i> Foo
>>>    </noframes>
>>>    Bar
>>>
>>> ...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:
>>
>> <body>
>>   <i>Foo
>> </body>
>> Bar
> 
> ...that is treated exactly the same as:
> 
>    <body>
>      <i>Foo Bar
>    </body>
> 
> ...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.

<script>
   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:

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cnoframes%20id%3D%22nf%22%3E%0D%0A%3Cp%3EFoo%3C/p%3E%0D%0A%3C/noframes%3E%0D%0A%3Cscript%3E%0D%0Avar%20s%20%3D%20document.createElement%28%22script%22%29%3B%0D%0As.innerHTML%20%3D%20%22alert%28%27Hello%20World%27%29%3B%22%0D%0Avar%20nf%20%3D%20document.getElementById%28%22nf%22%29%3B%0D%0Anf.appendChild%28s%29%3B%0D%0A%3C/script%3E

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.

<meta>
   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.

<base>
   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.

<title>
   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.

<form>
   <p><input name="foo">
   <noframes>
     <p><input name="bar">

     <form>
       <p><input name="baz">
       <p><input type="submit" value="Go 2">
     </form>
   </noframes>
   <p><input type="submit" value="Go 1">
</form>

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.

<body>
   <noframes>
     <p id="foo">Foo</p>
   </noframes>
   <p id="foo">Bar</p>
   <script>
   var foo = document.getElementById("foo");
   ...
   </script>
</body>

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:

<noscript>
   <map name="foo">...</map>
</noscript>
<map name="foo">...</map>
<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.

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Friday, 27 January 2006 17:49:14 UTC