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


From: Jeni Tennison <jeni@jenitennison.com>
Date: Tue, 15 Nov 2011 09:01:18 +0000
Cc: public-html-data-tf@w3.org
Message-Id: <03DB2976-0D3E-43F0-9A49-4FE302223667@jenitennison.com>
To: Henri Sivonen <hsivonen@iki.fi>

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?

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?

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

>> It looks as though this is something that hits microdata too. If you have:
>>  <div itemscope itemid="#foo" itemtype="http://schema.org/CreativeWork">
>>    <table itemscope itemid="#bar" itemtype="http://schema.org/CreativeWork">
>>      <p itemprop="title">Hello World</p>
>>    </table>
>>  </div>
> Regarding movement of <link> and <meta>, they'd be hoisted above the
> table, too, if you did
> <table><link><meta></table>

Ah, that's important. I've added that specifically to the text at [1].

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

>>  <!DOCTYPE html>
>>  <html>
>>  <head><title></title></head>
>>  <h1>Hello World</h1>
>>  <p>A global greeting for all.</p>
>>  </html>
>> as a valid HTML5 document despite it not having a <body> element, but perhaps that's a validator.nu bug…)
> It is not a bug. The document has a body *element* it just doesn't
> have a <body> *tag* which is optional in this case. See
> http://www.whatwg.org/specs/web-apps/current-work/#optional-tags for
> the cases where tags are optional. Most of the optional tags have been
> inherited from HTML4, except </rp> and </rt> being optional is legacy
> from IE5.

Toby pointed that out, thanks :) I should have known better than to think that validatur.nu would have had a bug!!



[1] http://www.w3.org/wiki/Choosing_an_HTML_Data_Format#Good_Publishing_Practice
Jeni Tennison
Received on Tuesday, 15 November 2011 09:01:45 UTC

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