Re: noted 3 issues re: time/data (was Re: minutes for HTML WG f2f, 2011-11-04, part 1)

18.11.2011, 21:51, "Tab Atkins Jr." <jackalmage@gmail.com>:
> On Fri, Nov 18, 2011 at 9:22 AM, Marat Tanalin | tanalin.com
> <mtanalin@yandex.ru> wrote:
>
>>  18.11.2011, 19:59, "Philip Jägenstedt" <philipj@opera.com>:
>>>  We cannot provide equivalent markup for itempropvalue unless we know how
>>>  itempropvalue is intended to work:
>>>
>>>  1. When itempropvalue appears on an URL property elements [1], is it (1)
>>>  ignored (2) resolved as a URL or (3) a plain text property?
>>  For URL property elements, @itempropvalue attribute should probably be ignored since such elements have their own dedicated attributes to store a value.
>
> That's even worse, imo.
> @itemscope already "wins" over special
> attributes when they're specified together (in other words, in <a
> itemprop=foo href=bar itemscope>, the value of "foo" is the nested
> item, not the url).  If @itempropvalue instead lost to the special
> attributes, that would be all kinds of confusing.

Then this part of spec probably should be changed. In my opinion, @itemscope should always relate to nested elements of its owner element, not to the element itself. This way would be quite intuitive and expected in general, and @itempropvalue could be consistently and intuitively used in particular.

For example, for:

<div itemscope>
    <a itemprop="foo" href="bar" itemscope>
        <span itemprop="lorem">ipsum</span>
    </a>
</div>

we would have following data hierarchy:

foo=bar (property of DIV's itemscope)
    lorem=ipsum (property of A's itemscope)

>>>  2. When itempropvalue appears together with itemscope, is it (1) ignored
>>>  or (2) a plain text property?
>>  @itempropvalue should be treated according to @itemtype. If @itemtype defines that item value should consist of several values specified by child elements, then @itempropvalue for element with @itemscope attribute should probably be ignored.
>
> The Microdata extraction algorithm doesn't pay attention to the
> itemtype when extracting.  It *can't*, because there's no schema for
> indicating such a structure in a machine-readable way, there's no way
> to link the itemtype to a schema in a machine-followable way, we know
> from long experience that adding such a mechanism (see DOCTYPEs) is an
> invitation to DDOS the provider, and finally, if the resource is ever
> unavailable, either temporarily (site overwhelmed) or permanently
> (domain registration expired), the extraction algorithm would have no
> way to know what to do.
>
> Now, *after* the data's been extracted, a type-aware consumer can
> interpret the data however they like.  They've got the schema
> built-in, so none of the above problems affect them.

Well, then, so much the more, @itemscope should always relate to element's descendants, not the element itself. (See above.)

Received on Friday, 18 November 2011 19:57:47 UTC