- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 2 Jul 2009 05:37:22 +0000 (UTC)
On Tue, 9 Jun 2009, Jonas Sicking wrote:
> >>
> >> Some of the improvement suggestions that I have heard that sounds
> >> interesting, though possibly for the next version of microdata.
> >>
> >> * Support for specifying a machine-readable value, such as for dates,
> >> colors, numbers, etc.
> >
> > I expect we will add support for these based on demand, the same way
> > we added <time> in the first place.
>
> Using dedicated elements for each data type seems like it will
> eventually bloat the language.
Only if people don't show restraint in extending the language.
> For example what use would a <color> element or a <number> element do?
It would allow conformance checkers to do type checking for the most
commonly used types, and might allow (for number, anyway) localised
formatting.
> If instead mashine readable values could be added using a generic
> method, such as a 'itemvalue' or 'propvalue' attribute, each microdata
> format can define how to interpret the values, be they numbers, dates,
> body parts, or chemical formulas.
You can do that now with <meta itemprop=... content=...>.
> >> I even wonder it would allow replacing the <time> element with a
> >> standardized microformat, such as:
> >>
> >> Christmas is going down on <span item="w3c.time"
> >> itemvalue="12-25-2009">The 25th day of December<span>!
> >
> > I don't really understand how that would be better than dedicated
> > elements.
>
> The idea would be to reduce the size of the language. I.e. if a feature
> isn't heavily used, it might be better expressed as a microdata format.
Well, you can do it today as:
Christmas is going down on <meta itemprop="w3c.time"
content="12-25-2009">The 25th day of December!
...which (assuming that in your example you meant "itemprop" and not
"item", and assuming that you didn't mean the contents of the <span> to
have any effect on the microdata processing model) would result in exactly
the same name/value pair being generated into the relevant item.
On the other hand, if you really meant item="", which I guess you might
have meant... you could do that today as:
Christmas is going down on <span item="w3c.time"><meta itemprop="value"
content="12-25-2009">The 25th day of December</span>!
...or some such (it doesn't matter what the textual contents of the <span>
are in this example). However, this is going to result in much more
painful structures, and you'd still need to link the item with a parent
item (assuming there is one), as in:
<div item="com.example.somethingorother">
Christmas is going down on <span itemprop="com.example.startdate"
item="w3c.time"><meta itemprop="value" content="12-25-2009">The 25th
day of December</span>!
</div>
...which is really getting complicated compared to just:
<div item="com.example.somethingorother">
Christmas is going down on <meta itemprop="w3c.time"
content="12-25-2009">The 25th day of December!
</div>
...or (preferred today):
<div item="com.example.somethingorother">
Christmas is going down on <time itemprop="w3c.time"
datetime="12-25-2009">The 25th day of December</time>!
</div>
> For example, why didn't you add elements for bibtex or vCard, but
> instead used microdata?
New elements didn't really fit the use cases as well.
> Another reason is as a test of the microdata feature itself. Microdata
> is a sort of extension mechanism to HTML 5. In software development, it
> is common to test your extension system by developing parts of the
> product using the extension system. This way you can both keep the core
> code small, and you get a good test bed for your extension system.
Indeed.
> You have already done this with the "predefined vocabularies"
Right.
> and apparently the lack of ability to define a mashine readable value
> separate from the human readable one was not a problem. However it would
> seem that the same does not hold true for <time>.
Right, that's why I adapted <time> into the microdata model.
> >> * Support for tabular data.
> >
> > This would be nice if we can find a way to do it that doesn't put
> > undue burdens on simple implementations. (e.g. I would imagine that
> > while a microdata implementation today can be a few hundred lines
> > total, adding support for the table model could easily double that.)
>
> Quite possibly.
>
> In both these cases I'm perfectly happy to wait with adding more
> features to microdata for now and see if what we have is successful,
> before we start over engineering it to cover every imaginable case.
Agreed.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 1 July 2009 22:37:22 UTC