[uf-discuss] Re: Precise Expansion Patterns

[Benjamin Hawkes-Lewis]

Manu Sporny wrote:
> Paul Wilkins wrote:

[snip]

>> I consider the following to be bad
>>     <abbr class="duration" title="PT2M23S"></abbr>2:23
> 
> Agreed. This is hiding data.

So is putting anything in the TITLE attribute on a non-empty element. 
Sure you can get some UAs to show it by hovering over it (although it's 
generally hard to trigger such tooltips with the keyboard alone). But 
then you could also get your browser to show the data in the ABBR 
example above by viewing source (or using a tool to show all TITLE 
attributes, or indeed all microformatted data).

>> Then there's the SPAN element. This one too has issues with the title
>> text, in that anybody seeing it isn't likely to understand its
>> meaning.
>>     <span class="duration" title="PT2M23S">2:23</span>
>> It appears that when the title text is used on content, it must must
>> remain as a human-understandable construct.
> 
> Agree with the first part, readers are probably not going to understand
> PT2M23S. Disagree with the last statement, this is not in violation of
> the HTML spec, IMHO:
> 
> --------------------------------------------------------------------
> http://www.w3.org/TR/html401/struct/global.html#adef-title
> 
> title = text [CS]
>     This attribute offers advisory information about the element for
>     which it is set.
> --------------------------------------------------------------------
> 
> However, I do agree that "PT2M23S" is stretching the rules a bit.

Can information that "readers are probably not going to understand" be 
classed as "advisory"?

> Just to go back to a previous e-mail in the day... I don't think I fully
> understood what Benjamin was proposing with the following:
> 
> <span class="duration">
>    <span class="minutes">2</span>:<span class="s">25</span>
> </span>
> 
> After looking at it again and running it through a variety of tests,
> it's looking like a fairly good solution to the issue... very verbose,
> but it doesn't have any of the previously stated problems
> (accessibility, usability, or tag abuse), and there are several more
> benefits that it brings. For example, you can do this:
> 
> <span class="duration">
>    <span title="2" class="minute">two</span>minutes and
>    <span class="second">43</span> seconds
> </span>
> 
> For an example of how this looks, check out #6 on the following page:
> 
> http://uf.digitalbazaar.com/unit-tests/sandbox/isodata.html
> 
> You can also do stuff like this, for fractional elements:
> 
> <span class="duration">
>    <span title="0.002" class="second">2 milliseconds</span>
> </span>
> 
> In fact, if we had the following Microformat:
> 
> duration
>   year
>   month
>   day
>   hour
>   minute
>   second
> 
> We could address not only duration, but also specify time (January 15th,
> 2008):
> 
> <span class="dtstart">
>    <span class="month" title="1">January<span>
>    <span class="day">15<span>th,
>    <span class="year">2008</span>
> </span>
> 
> This line of reasoning follows what we've been doing with hMeasure:
> 
> http://microformats.org/wiki/measure-brainstorming#Straw_man
> 
> Was this what you were getting at, Benjamin?

Sort of.

What I was proposing was this. When all the information required is 
available in the content of the element in Arabic numeral form, and all 
a parser would need to know is what units are being used, we should 
prefer to mark up the units rather than attempt hide an ISO format of 
the same data with the TITLE hack.

So, to adopt your milliseconds example, we could avoid TITLE and just use:

<span class="duration"><span class="milliseconds">2</span> 
milliseconds</span>

Units we might want to specify for duration would include:

years
months
days
hours
minutes
seconds

Second is the SI unit for time. As such, you can append the 20 standard 
SI prefixes: from yotta- (10^24) to yocto- (10^-24):

http://en.wikipedia.org/wiki/SI

We might prefer to specify abbreviations like s and ms, I'm not sure.

This makes for simple implementations in the case of durations, since 
these units seem to be in global use.

Obviously, if this principle were to be extended to other sorts of 
measurements, it could get more complicated for two reasons:

1. People might want to use variations on the SI units that cannot be 
expressed with the SI prefixes e.g. 10^26 s.

2. People might want to use non-SI, non-global units like inches and quarts.

Now, it might be that we could adapt the principle to serve in some of 
those situations too:

1. Perhaps we could allow class names like "seconds/10^26" (it's ugly 
but legible and conforming).

2. Perhaps we could think about specifying class names for widely-used, 
non-SI units like inches.

So cases that could not be covered by this principle include:

1. Obscure units ("5 chains wide")

2. Use of non-Arabic numerals ("III HORA")

3. Use of words instead of digits ("three seconds long")

4. Fuzzy representations where not all the information required is 
implicit in the human-friendly content ("about three miles")

For these cases, we would /still/ need an expansion pattern. I wasn't 
particularly thinking of the expansion pattern you suggest, since it's 
still attempting to put tortured data-showing requirements over the 
needs of human end-users.

The point of my suggestion is to reduce the number of cases where we 
need an expansion pattern, since expansion patterns are proving problematic.

--
Benjamin Hawkes-Lewis