[whatwg] Adoption Agency Algorithm

Fri Jan 27 18:09:08 PST 2006

On Sat, 28 Jan 2006, Lachlan Hunt wrote:
>
> 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.

Not if there's a script on the page playing with the disabled attributes. 
Suddenly they have more stylesheets than they were expecting.

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

It could change the favicon, e.g.

> <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 requires UAs to have a concept of "is this script being inserted into 
a <noframes> context". This isn't necessarily a problem, but it's a change 
from what happens now.

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

<base> is used more than <embed>, more than <h4>, more than <pre>, more, 
in fact, than <frameset> and <noframes>. I don't think it's safe to say 
that "very few pages use base".

It's possible that it is rare to see <base> inside <noframes>, though I'd 
feel better after having checked for that. However, in the case of 
<noscript>, I'm sure I've actually seen cases like:

   <noscript>
     <base href="foo">
   </noscript>
   <script>
     document.write('<base href="bar">');
   </script>

...or similar. I've definitely seen things like:

   <noscript>
     <div class="foo">
   </noscript>
   <script>
     document.write('<div class="bar">');
   </script>

...to change what is open and what is not on the fly.

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

But if you ignore it, then your DOM is going to be different if you have 
frames or if you don't. Which is what I thought you were trying to avoid. 
(This argument applies to several other cases where you suggested ignoring 
a tag.)

> Form Controls (input, select, etc.)
>   These do not become associated with any form element outside of the
>   noframes and are thus, not submitted.

How do you prevent the association? Consider form="" pointing at a <form> 
in a <noscript> section.

> 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!?

If it only breaks one in a million pages and that page is CNN.com?

There are billions of pages out there. One in a million is several 
tens or hundrends of thousands of pages.

Another problem (which I just noticed on CNN.com) is that if we say that 
<noframes> creates nodes, browsers will be creating nodes for <img> 
elements that previously they were not creating, which will cause a 
different set of images to be fetched from the server.

Also, if there are links in <noscript> blocks, they will now start being 
added to the document.links array. This might affect scripts that know 
what is in that list.

Also, your suggestion was that <noscript>/<noframes> close all inlines 
that were opened inside them. That would break cases like:

   <noscript><a ...></noscript>
    ...
   <noscript></a></noscript>

...in non-script UAs (assuming that the UAs should have the same DOM 
whether scripts are enabled or not).

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

What is the problem you are trying to solve? You are dismissing many 
backwards compatibility concerns as being minor; the cumulative risk of 
all these minor concerns actually being major has to be outweighed by the 
advantages of your approach. What are they?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'