On Wed, 14 Oct 2009 13:53:46 +0200, Ian Hickson <[email protected]> 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
