[whatwg] Microdata feedback

[Philip Jägenstedt]

On Wed, 14 Oct 2009 13:53:46 +0200, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 21 Aug 2009, Philip Jägenstedt wrote:
>>
>> Shouldn't namedItem [6] be namedItems? Code like .namedItem().item(0)
>> would be quite confusing.
>> [6]  
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#dom-htmlpropertycollection-nameditem
>
> I don't understand what this is referring to.

I was incorrectly under the impressions that .namedItem on other  
collections always returned a single element and arguing that since  
HTMLPropertyCollection.namedItem always returns a PropertyNodeList  
namedItems in plural would make more sense. Now I see that some other  
namedItem methods aren't as simple as I'd thought, so I'm not sure what to  
make of it. Is there a reason why HTMLPropertyCollection.namedItem unlike  
some other collections' .namedItem don't return an element if there is  
only 1 element in the collection at the time the method is called? Perhaps  
this is legacy quirks that we don't want to replicate?

> On Tue, 25 Aug 2009, Philip Jägenstedt wrote:
>>
>> There's something like an inverse relationship between simplicity of the
>> syntax and complexity of the resulting markup, the best balance point
>> isn't clear (to me at least). Perhaps option 3 is better, never allowing
>> item+itemprop on the same element.
>
> That would preclude being able to make trees.
>
>
>> > > Given that flat items like vcard/vevent are likely to be the most
>> > > common use case I think we should optimize for that. Child items can
>> > > be created by using a predefined item property:
>> > > itemprop="com.example.childtype item". The value of that property
>> > > would then be the first item in tree-order (or all items in the
>> > > subtree, not sure). This way, items would have better copy-paste
>> > > resilience as the whole item element could be made into a top-level
>> > > item simply by moving it, without meddling with the itemprop.
>> >
>> > That sounds kinda confusing...
>>
>> More confusing than item+itemprop on the same element? In many cases the
>> property value is the contained text, having it be the contained item
>> node(s) doesn't seem much stranger.
>
> Based on the studies Google did, I'm not convinced that people will find
> the nesting that complicated. IMHO the proposal above is more confusing,
> too. I'm not sure this is solving a problem that needs solving.
>
>
>> > > If the parent-item (com.example.blog) doesn't know what the
>> > > child-items are, it would simply use itemprop="item".
>> >
>> > I don't understand this at all.
>>
>> This was an attempt to have anonymous sub-items. Re-thinking this,
>> perhaps a better solution would be to have each item behave in much the
>> same way that the document itself does. That is, simply add items in the
>> subtree without using itemprop and access them with .getItems(itemType)
>> on the outer item.
>
> How would you do things like "agent" in the vEvent vocabulary?
>
>
>> Comparing the current model with a DOM tree, it seems odd in that a
>> property could be an item. It would be like an element attribute being
>> another element: <outer foo="<inner/>"/>. That kind of thing could just
>> as well be <outer><foo><inner/></foo></outer>, <outer><inner
>> type="foo"/></outer> or even <outer><inner/></outer> if the relationship
>> between the elements is clear just from the fact that they have a
>> parent-child relationship (usually the case).
>
> Microdata's datamodel is more similar to JSON's than XML's.
>
>
>> It's only in the case where both itemprop and item have a type that an
>> extra level of nesting will be needed and I expect that to be the
>> exception. Changing the model to something more DOM-tree-like is
>> probably going to be easier to understand for many web developers.
>
> I dunno. People didn't seem to have much trouble getting it once we used
> itemscope="" rather than just item="". People understand the JSON
> datamodel pretty well, why would this be different?

After <http://blog.whatwg.org/usability-testing-html5>, the recent syntax  
changes, the improved DOM API and the passage of time I'm not very worried  
about the things I was worrying about above. If there's any specific point  
that seems valid after another review I'll send separate feedback on it.  
Thanks for all the other fixes!

-- 
Philip Jägenstedt
Opera Software