W3C home > Mailing lists > Public > public-html@w3.org > November 2011

Re: noted 3 issues re: time/data (was Re: minutes for HTML WG f2f, 2011-11-04, part 1)

From: Marat Tanalin | tanalin.com <mtanalin@yandex.ru>
Date: Mon, 14 Nov 2011 12:09:04 +0400
To: Tantek Çelik <tantek@cs.stanford.edu>
Cc: Sam Ruby <rubys@intertwingly.net>,public-html@w3.org
Message-Id: <138161321258144@web126.yandex.ru>
13.11.2011, 04:51, "Tantek Çelik" <tantek@cs.stanford.edu>:
>>  and questioning the need to add
>>  an element that has zero semantics and complete overlap with the span
>>  element).
>
> I've noted some reasons for preferring a new element over a new global
> attribute or enhancing the span element.

> Note that the use of machine-readable data that is separate from human
> readable data should be an exception and not the rule (see below about
> DRY violation risk), thus it is advantageous to provide an explicit
> element "<data>" for this purpose to make it obvious when such
> exceptions are being made (rather than a global attribute or enhancing
> the <span> element).

Looks like an equation with key thing missing -- a variable. It's still unclear what is advantage of a dedicated DATA element over an attribute for existing one (like SPAN in simplest case).

Let's consider an example:
<data itemprop="foo" value="bar">ipsum</data>

It's unclear why this is not sufficient instead:
<span itemprop="foo" value="bar">ipsum</span>

I would propose even more laconic CSS-like syntax for itemprop to contain both property name _and_ value if needed:
<span itemprop="foo: bar">ipsum</span>

Here, ': bar' part of itemprop-attribute value is provided only if machine-readable value is different from human-readable content of the element.

For marking-up non-microdata, there are no reasons to use new semanticless element too. Considering Ian's description of DATA element from whatwg.org,

> A script loaded by the page (and thus privy to the page's internal convention
> of marking up dates and times using the data element) could scan through the
> page and look at all the data elements therein to create an index of dates
> and times.

But, if script is privy to the page's internal convention of marking up some data, then just any element with regular data-value (even not newly-invented 'value') attribute can be used. For example, we could have DT/DD pair and use attribute of existing DD element to store machine-readable data:

<dt>Myfoo:</dt>
<dd data-value="bar">ipsum</dd>

Using extra DATA-element instead would be absolutely redundant, verbose, and littering:

<dt>Myfoo:</dt>
<dd><data value="bar">ipsum</data></dd>

Therefore, dedicated DATA element is completely unneeded in the spec.

Thanks.
Received on Monday, 14 November 2011 08:09:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:41 GMT