Re: Re: Precise Expansion Patterns

Paul Wilkins wrote:
> On Dec 17, 2007 2:38 PM, Manu Sporny <mspornydigitalbazaar.com> wrote:
>> By constricting DURATION to have a restrictive
format, HH:MM:SS, we are
>> being short-sighted and are not thinking about the
other Microformats
>> that are still to come that will need to specify
DURATION.
>>
>> "00:02:23" is being shortsighted. Let's
learn from our past and not make
>> the same mistake again... let's not be
short-sighted about this decision.
> 
> If we stay with "PT2M23S" then how are we
going to deal with the title
> attribute issues.

We have some suitable candidates for replacement... all of
them are not
ideal, so we are going to have to compromise. We know the
following:

1. Using DURATION with ABBR was a compromise, so it's not
like we're
   replacing something that is perfect.
2. Hidden data is considered harmful by the Microformats
   community. <span class="foo"
title="blah"></span> == bad
3. Semantically abusing tags is considered bad by the
community.

> I consider the following to be bad
>     <abbr class="duration"
title="PT2M23S"></abbr>2:23

Agreed. This is hiding data.

> Next we have the classical abbr-include-pattern.
> 
> This has issues in that the title is not an acceptable
abbreviation of
> 2:23. The title text must be sensible to the human
viewer.
>     <abbr class="duration"
title="PT2M23S">2:23</abbr>

Agreed. This is abusing the semantic meaning of ABBR.

> 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-t
itle

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.

> The SPAN element however has classically been allowed
to be empty, as
> a placeholder for the likes of css images.
> This situation can be leveraged to provide computer
data, without
> interfering with the content itself.
> 
> I consider the following to be less bad than the others
above.
>     <span class="duration"
title="PT2M23S"></span>2:23

Agreed. I personally don't have a problem with hidden data
like this,
especially when there are tools like Operator that can be
used to check
your work. However, there are others in the community that
will fight
you (and me) on this.

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/isodat
a.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#S
traw_man

Was this what you were getting at, Benjamin?

-- manu
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

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-t
itle
> 
> 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/isodat
a.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#S
traw_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.o
rg/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
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss