[whatwg] Microdata feedback

Philip Jägenstedt philipj at opera.com
Thu Oct 15 00:32:30 PDT 2009

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

More information about the whatwg mailing list