Re: [whatwg] Microdata - Handling the case where a string is upgraded to an object
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:
>
> Foo
> Barsson
>
> var p = document.getItems("person")[0];
> alert(p.properties.namedItem("name")[0].itemValue);
>
>
> If the HTML changes to
>
> itemprop="givenName">Foo itemprop="familyName">Barsson
>
> 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Microdata - Handling the case where a string is upgraded to an object
On Mon, 18 Jul 2011 22:01:37 +0200, Tab Atkins Jr. wrote: On Mon, Jul 18, 2011 at 4:20 AM, Philip Jägenstedt 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. 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. Given this, a simpler fix would be to let .itemValue act like .textContent when an itemscope attribute is present. 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. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Microdata - Handling the case where a string is upgraded to an object
On Mon, Jul 18, 2011 at 4:20 AM, Philip Jägenstedt wrote:
> There is no items IDL attribute, do you mean getItems() or .itemValue
> perhaps?
Yes, sorry.
> I take it the problem is with code like this:
>
> Foo
> Barsson
>
> var p = document.getItems("person")[0];
> alert(p.properties.namedItem("name")[0].itemValue);
>
>
> If the HTML changes to
>
> itemprop="givenName">Foo itemprop="familyName">Barsson
>
> then the script would be alerting "[object HTMLElement]" instead of "Foo
> Barsson".
>
> I'm not sure why this would be a problem. If someone changes the page, then
> can't they adjust the script to match?
That only works if the page is using its own Microdata, not if someone
else is consuming the Microdata.
> Is it extensions and libraries that
> you're worried about?
Yeah. I suspect this kind of API change is relatively common, and
it's the sort of thing that would *always* be painful.
> 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.
~TJ
Re: [whatwg] Microdata - Handling the case where a string is upgraded to an object
On Thu, 14 Jul 2011 20:49:44 +0200, Tab Atkins Jr.
wrote:
Some IRC discussion this morning concerned the scenario where an API
starts by exposing a property as a string, but later wants to change
it to be a complex object.
This appears to be a reasonably common scenario. For example, a
vocabulary with a "name" property may start with it being a string,
and then later change to an object exposing "firstname"/"lastname"/etc
properties. A vocabulary for a music library may start by having
"track" as a string, then later expanding it to expose the track
title, the individual artist, the running time, etc.
In a very similar vein, the CSSOM is currently defined to always
return property values as strings. We want to instead return complex
objects that expose useful information and interfaces specialized on
the value's type, however. For compat reasons, we have to use an
entirely different accessor in order to expose this type of thing.
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.
Thoughts?
There is no items IDL attribute, do you mean getItems() or .itemValue
perhaps?
I take it the problem is with code like this:
Foo
Barsson
var p = document.getItems("person")[0];
alert(p.properties.namedItem("name")[0].itemValue);
If the HTML changes to
itemprop="givenName">Foo itemprop="familyName">Barsson
then the script would be alerting "[object HTMLElement]" instead of "Foo
Barsson".
I'm not sure why this would be a problem. If someone changes the page,
then can't they adjust the script to match? Is it extensions and libraries
that you're worried about?
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?
--
Philip Jägenstedt
Core Developer
Opera Software
[whatwg] Microdata - Handling the case where a string is upgraded to an object
Some IRC discussion this morning concerned the scenario where an API starts by exposing a property as a string, but later wants to change it to be a complex object. This appears to be a reasonably common scenario. For example, a vocabulary with a "name" property may start with it being a string, and then later change to an object exposing "firstname"/"lastname"/etc properties. A vocabulary for a music library may start by having "track" as a string, then later expanding it to expose the track title, the individual artist, the running time, etc. In a very similar vein, the CSSOM is currently defined to always return property values as strings. We want to instead return complex objects that expose useful information and interfaces specialized on the value's type, however. For compat reasons, we have to use an entirely different accessor in order to expose this type of thing. 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. Thoughts? ~TJ
