- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 15 Oct 2009 09:32:30 +0200
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
Received on Thursday, 15 October 2009 00:32:30 UTC