W3C home > Mailing lists > Public > public-html-data-tf@w3.org > November 2011


From: Henri Sivonen <hsivonen@iki.fi>
Date: Tue, 15 Nov 2011 12:36:47 +0200
Message-ID: <CAJQvAufqzh1PLmSAuTgq0Y4tybAthB02-H=1mCL7gGBn02ctjw@mail.gmail.com>
To: Jeni Tennison <jeni@jenitennison.com>
Cc: public-html-data-tf@w3.org
On Tue, Nov 15, 2011 at 11:01 AM, Jeni Tennison <jeni@jenitennison.com> wrote:
> On 15 Nov 2011, at 08:46, Henri Sivonen wrote:
>> On Sat, Nov 12, 2011 at 10:45 PM, Jeni Tennison <jeni@jenitennison.com> wrote:
>>> (Henri, question for you embedded in here: aside from the movement of <link> and <meta> which we know about,
>> What movement are you referring to? In HTML5 once the </head> end tag
>> has been seen but before the <body> start tag has been seen, <link>
>> and <meta> move to the head. Rumors about other <link> or
>> <meta>-specific movements while true of some legacy browsers are
>> untrue of the HTML(5) parsing algorithm.
> Yes, it was the movement in the legacy browsers that I was talking about. Can you take a look at the text at [1] and see whether that's accurate?

It says "Older browsers move meta and link elements in the body of an
HTML document to after the head element". I'm not aware of old browser
moving them after the head element but into the head element (as
children of head, that is).

> Also, I couldn't locate any caniuse.com-type resource that indicated which versions of which browsers stop doing this. Do you happen to know of one?

I don't. You need to test old browsers if you want that data:

I tested Firefox 3.5 and 3.6. They move <meta> to head but (to my
surprise) <link> isn't moved. Firefox 4 and later don't move either.
IE6 doesn't move either of them.

>>> is being a valid HTML5 document enough to avoid unanticipated movement of elements that might result in changes to a publisher's intended microdata/RDFa/microformats?)
>> Yes. In fact, it is enough for the document to be free of Parse
>> Errors. Even better, it's enough for the document to be free of the
>> kind of Parse Errors that Firefox Nightly happens to report, so if you
>> View Source in a build from the Firefox Nightly channel and View
>> Source, there are no unanticipated element movements if you see no red
>> text when viewing source (there may be unanticipated text movement,
>> though, due to limitations in the current reporting capabilities of
>> View Source).
> Cool. When is that likely to become part of regular Firefox?

Probably on 2012-03-13. If things go really well, on 2012-01-31.

>> Additionally, if you want to use Microdata or RDFa, you really want to
>> avoid triggering element cloning and reparenting by the Adoption
>> Agency Algorithm.
> Can you expand on this? I searched for 'Adoption Agency Algorithm', 'adoption' and 'adopt' in the spec and didn't come up with anything.


The name of the algorithm is in the green note after the algorithm.
The other possible algorithm's mentioned in that paragraph refer to
legacy IE (tree is not a tree), legacy Opera (layout results are not
explained by the observable tree shape) and legacy Firefox (trying to
observe the algorithm changes the results)--in that order.

Henri Sivonen
Received on Tuesday, 15 November 2011 10:37:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:08:25 UTC