Re: Microdata: The Itemref element

On Mon, 19 Oct 2009, Jonas Sicking wrote:
> On Mon, Oct 19, 2009 at 1:35 AM, Anne van Kesteren <annevk@opera.com> wrote:
> > On Sun, 18 Oct 2009 23:59:01 +0200, Ian Hickson <ian@hixie.ch> wrote:
> >> On Sun, 18 Oct 2009, Nicholas Stimpson wrote:
> >>>
> >>> Instead, would it be possible for the element with the "itemscope" 
> >>> attribute to have an itemref attribute that was a space separated 
> >>> list of ids?
> >>
> >> It'd certainly be possible, but I'm not sure it's desireable, given 
> >> how easy it is to work around.
> >
> > FWIW, that design sounds much nicer to me than having an <itemref> 
> > element somewhere as a descendant do the trick. It is more clear what 
> > the relationship is, does not have legacy parser issues, is easier to 
> > implement using scripting, and more consistent with other such 
> > structures (usemap, for).
> 
> Agreed. I also like the idea of microdata being purely a set of 
> attributes. Mostly because it keeps the markup more readable IMHO. An 
> element attracts a lot more attention when skimming over markup than an 
> attribute does. Especially if the markup is written for readability 
> like:
> 
> <foo>
>   <voidelementbar>
>   <baz>text</baz>
> </foo>
> 
> And I think it's better that the main document structure is what 
> attracts attention, rather than being distracted by microdata markup.
> 
> Further, not having to change the element structure of the document in 
> order to add microdata makes it somewhat safer to add since there's much 
> less reason to worry about scripts that expects a certain DOM structure 
> breaking.
> 
> Neither of the two suggested workarounds are particularly nice:
> 
> 1. Wrapping a <span> around the <itemref> means that microdata attracts 
> even more attention when writing the markup.
>
> 2. Putting the <itemref>s last in an element seems opposite from where 
> you'd intuitively put them. It seems to me more intuitive to put them 
> close to where the item is declared, i.e. the 'itemscope' attribute.

These workarounds are only short-term workarounds, and the same applies 
to, e.g., <source> in <video>, or <command>, so I don't think it's a big 
problem. It's not like <itemref> will appear that much anyway.

Regarding complexity, I don't think it's a big deal. We explicitly tested 
<itemref> in the lab, and it fared much better than itemfor="" did.


On Mon, 19 Oct 2009, Philip Jägenstedt wrote:
> 
> Thanks Nicholas for bringing this up. I'm also not a big fan of the 
> itemref element, for two reasons. First, it's a new void element, which 
> is always problematic, especially when we expect it to be sprinkled all 
> over existing markup (unlike <source> which will be inside <video>).
> 
> Second, it makes HTMLPropertyCollection a more difficult to implement, 
> see yesterdays bug [1] and the IRC discussion [2] for some details. 
> Because <itemref> allows looped references, the algorithm for 
> determining the properties of an item is complicated by keeping a list 
> of visited nodes. This will be added complexity for browser 
> implementations and external parsers alike.
> 
> Using an attribute avoids both of these issues. It would simplify the 
> algorithm as the only possibility of loops is if there's a reference to 
> the @itemscope'd element or an ancestor of it, which is much easier to 
> check (just one node instead of a list of all visited nodes).

Yeah, that's probably a reasonable point.

Ok, done. <itemref> is dead, long live itemref="".

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'