[whatwg] Microdata - Handling the case where a string is upgraded to an object

[Ian Hickson]

On Thu, 14 Jul 2011, Tab Atkins Jr. wrote:
>
> It seems that this may be a useful problem to solve in Microdata.  We 
> can expose either an attribute or a privileged property name for the 
> object's "name"/"title"/"string representation".  Then, when using the 
> .items accessor, objects can be returned with a custom .toString that 
> returns that value, so they can be used as strings in legacy code.

So "complex" properties would need to state the data in two forms, or pick 
one of subproperties and annoint it as being the special fallback?


On Mon, 18 Jul 2011, Philip Jägenstedt wrote:
> 
> I take it the problem is with code like this:
> 
> <div itemscope itemtype="person"><span itemprop="name">Foo
> Barsson</span></div>
> <script>
> var p = document.getItems("person")[0];
> alert(p.properties.namedItem("name")[0].itemValue);
> </script>
> 
> If the HTML changes to
> 
> <div itemscope itemtype="person"><span itemprop="name" itemscope><span
> itemprop="givenName">Foo</span> <span
> itemprop="familyName">Barsson</span></span></div>
> 
> then the script would be alerting "[object HTMLElement]" instead of "Foo 
> Barsson".

Indeed. It's not clear to me what else we would return, especially 
considering itemref="".


On Mon, 18 Jul 2011, Tab Atkins Jr. wrote:
> 
> Yeah.  I suspect this kind of API change is relatively common, and it's 
> the sort of thing that would *always* be painful.

In some of the sample vocabularies, there are properties that can either 
take a string or a structured item as a value. In the latter cases, 
there's no trivial way to provide a string alternative.


> > As for the solution, are you suggesting that .itemValue return a 
> > special object which is like HTMLElement in all regards except for how 
> > it toString()s?
> 
> Yes.

Some HTMLElement objects already have a custom toString().


On Tue, 19 Jul 2011, Philip Jägenstedt wrote:
> 
> Currently, it's spec'd as returning the element itself. This isn't 
> terribly useful, at least I've just checked e.itemScope and then 
> accessed e.properties directly rather than going through 
> e.itemValue.properties.

Yeah, it's mostly just so that people can take the itemValue into a local 
variable, and then manipulate it without having to worry about what type 
it is until later.


> Given this, a simpler fix would be to let .itemValue act like 
> .textContent when an itemscope attribute is present.

.textContent doesn't necessarily have anything to do with the modelled 
data. I'm not sure that really makes sense.


> Still, I'm not sure if it's a good idea. It makes the Microdata model 
> kind of odd if a property is both an item and has a fallback text 
> representation. It will also mask the fact that a text property has been 
> upgraded to an item, somewhat decreasing the chance that the consuming 
> code will be updated.

Yeah. And authors would have to make sure the textContent is usable as 
fallback, which isn't at all a given, IMHO.

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