Re: [uf-discuss] Re: Precise Expansion Patterns

[Benjamin Hawkes-Lewis]

Michael MD wrote:

This would be acceptable:
span class=durationspan class=seconds3/span seconds/span

Or if we wanted to use the hMeasurement approach:
span class=duration title=3sthree seconds/span
span class=duration title=2min 3stwo minutes, three
seconds/span
span class=duration title=2y 35htwo years, 35 hours/span
span class=duration title=3sthree seconds/span



this kind of thing would:

1. add complexity to parsers


Doubtless, but the questions we need to ask are:

1. Can it be done?

2. Is it worth it?

2. require people to be very precise in the choice of allowed strings 
... eg: year  or y , second or seconds otherwise dates and times 
may very quickly degenerate into something not much better than garbled 
freeform text dates.


Yes, like /any/ exact syntax including standardized class names and ISO 
8601, it requires people to be precise.


It would also mean a lot more rules for authors to remember which could 
result in a lot of invalid markup being published.


That's a good argument for keeping the names of recognized units 
consistent and verbose: perhaps always seconds not year or m.


If dates/times are no longer machine-readable I would see no longer see 
much practical use for any of this!


Well, strings conforming to any unambiguous syntax parsed with an 
algorithm we define are machine-readable.



I am very wary of straying too far from ISO for dates and times
(or at least something that can easily be parsed by 
javascript/php/perl/ruby/whatever built-in date functions or commonly 
used date libraries)


JavaScript can parse date times, but has no native support for parsing 
ISO-formatted ones:


http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Date:parse

http://delete.me.uk/2005/03/iso8601.html

PHP and Ruby have functionality for parsing non-ISO date times:

http://uk.php.net/manual/en/function.strtotime.php

http://www.ruby-doc.org/core/classes/Time.html

Perl has no built-in functionality for parsing date times at all 
(although naturally you can find such functionality on CPAN):


http://perldoc.perl.org/perlfaq4.html#How-can-I-take-a-string-and-turn-it-into-epoch-seconds%3f

But in any case Manu's examples featured measurements, durations 
specifically, not dates or times. AFAIK none of these languages have 
in-built support for parsing durations or other measurements at all.


Does anyone have any evidence on what libraries capable of parsing 
durations or other measurements are commonly used?


--
Benjamin Hawkes-Lewis
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Benjamin Hawkes-Lewis]

Manu Sporny wrote:

If we're going to put s and ms in @class, then I don't think that
would be a good idea.


Can you elaborate why?

One argument might be that consistency of naming across all units can 
help authors remember syntax.


But my thinking in suggesting symbols as an exception for SI units was 
that symbols are not subject to spelling variations. It's always m but 
may be metre or meter for example:


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

In other words, I think enforcing symbols for SI units would produce 
fewer errors by authors.



Or if we wanted to use the hMeasurement approach:
span class=duration title=3sthree seconds/span
span class=duration title=2min 3stwo minutes, three
 seconds/span
span class=duration title=2y 35htwo years, 35 hours/span
span class=duration title=3sthree seconds/span


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


Take a look at the hMeasurement strawman... there's been a great deal of
thought put into the issues that you describe:

http://microformats.org/wiki/measure-brainstorming#Straw_man


/If/ it does not over-complicate the task for parsers or authors, I have 
no objection to the contents of elements being parsed as values. But I 
suspect this would only help in a small subset of cases (English content 
where digits and common units are supplied).



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


Then they will need to convert it to SI units:

span class=weight title=95.2543977 kg15 stones/span


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).


We can already do this in hMeasurement:

span class=duration title=10^26s10^26 seconds/span

Or, alternatively they could convert it to another representation format:

span class=duration title=100Ys10^26 seconds/span



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


Like this (in the current hMeasurement proposal):

span class=length title=4ft 4infour feet, four inches/span 


Yes, my problem with this is that I think TITLE is being misused.


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


I think addressing this was outlined above.


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


There is room for error metrics in hMeasurement too, although, it hasn't
been worked out quite how we do that.


I'm not talking about a margin of error in the measurement, but about a 
loose human representation used in extended prose being annotated with a 
more precise representation purely for machine consumption. For example, 
we know it's exactly 3.214 miles and want microformat parsers to know 
that, but we say about three miles in the prose.



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.


Do SI measurements constitute tortured data?


It's not the data I was calling tortured. I was referring to the 
impossibility of going in two directions simultaneously:


1. Microformat data must be human-readable and visible to be maintained.

2. Some microformat data is so human-hostile we need to allow it to be 
replaced by human-friendly content.


Hiding data in a tooltip is a sort of half-way house that doesn't really 
satisfy either of these principles.



Is displaying 2min 23s,
or 2 minutes 23 seconds better than displaying PT2M23S?


Not really. min, minutes and seconds might be just as 
incomprehensible when content is in a non-English language or a 
non-Latin script.



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


Let's address the actual problem of precise expansion patterns for
measurements.

So we could do one of the following:

1. Use hMeasurement and add h for hours and y for years.
2. Define second, minute, hour, year classes.
3. Create second, minute, hour, and year aliases in to the
   hMeasurement units s, min, h, and y, respectively. Use
   hMeasurement.

I suggest doing the 3rd thing, which would give us all of the following,
valid, markup:

span class=duration2 minutes 23 seconds/span
span class=duration title=2 minutes 23 seconds2:23/span
span class=duration title=2 min 23 s2 minutes, 23 seconds/span
span class=duration title=2 min 23 s2:23/span

This approach is more of a measurement design-pattern, but solves the
accessibility and usability issues surrounding using ISO8601 and a
variety of the other ISO formats for measurement.


Defining s, minutes, hours, and years classes would handle all 
four 

Re: [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/abbr2: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=PT2M23S2: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=minutes2/span:span class=s25/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=minutetwo/spanminutes and
   span class=second43/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=second2 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=1Januaryspan
   span class=day15spanth,
   span class=year2008/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=durationspan class=milliseconds2/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 

Re: [uf-discuss] Re: Precise Expansion Patterns

[Manu Sporny]

Benjamin Hawkes-Lewis wrote:
 
 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?

We could argue it both ways based on how we define advisory and the
pattern recognition and cognitive abilities of the general Internet
population. Since we have a potentially better solution on the table,
let's not go down this path yet.

 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.

Agreed.

 So, to adopt your milliseconds example, we could avoid TITLE and just use:
 
 span class=durationspan class=milliseconds2/span
 milliseconds/span

Sure, we could do that... although, we should be careful to address all
of the problems... we would still need to address some of the
non-standard cases that you outline below.

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

If we're going to put s and ms in @class, then I don't think that
would be a good idea. If we were to, however, place that information in
title... that would be fine, IMHO. To illustrate:

This would be a bad idea:
span class=durationspan class=s3/span seconds/duration

This would be acceptable:
span class=durationspan class=seconds3/span seconds/span

Or if we wanted to use the hMeasurement approach:
span class=duration title=3sthree seconds/span
span class=duration title=2min 3stwo minutes, three
 seconds/span
span class=duration title=2y 35htwo years, 35 hours/span
span class=duration title=3sthree seconds/span

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

Take a look at the hMeasurement strawman... there's been a great deal of
thought put into the issues that you describe:

http://microformats.org/wiki/measure-brainstorming#Straw_man

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

We can do this if we use hMeasurement:

span class=duration10^26 s/spaneconds.

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

Then they will need to convert it to SI units:

span class=weight title=95.2543977 kg15 stones/span

 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).

We can already do this in hMeasurement:

span class=duration title=10^26s10^26 seconds/span

Or, alternatively they could convert it to another representation format:

span class=duration title=100Ys10^26 seconds/span

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

Like this (in the current hMeasurement proposal):

span class=length title=4ft 4infour feet, four inches/span

 1. Obscure units (5 chains wide)

Boiling the oceans - we should make them convert it into a more popular
measurement.

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

Boiling the oceans - make them convert it into a more popular measurement.

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

I think addressing this was outlined above.

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

There is room for error metrics in hMeasurement too, although, it hasn't
been worked out quite how we do that.

 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.

Do SI measurements constitute tortured data? Is displaying 2min 23s,
or 2 minutes 23 seconds better than displaying PT2M23S?

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

Let's address the actual problem of precise expansion patterns for
measurements.

So we could do one of the following:

1. Use hMeasurement and add h for hours and y for years.
2. Define second, minute, hour, year classes.
3. Create second, minute, hour, and year aliases in to the
   hMeasurement units s, min, h, and y, respectively. Use
   hMeasurement.

I suggest doing the 3rd thing, which would give us all of the following,
valid, markup:

Re: [uf-discuss] Re: Precise Expansion Patterns

[Michael MD]

This would be acceptable:
span class=durationspan class=seconds3/span seconds/span

Or if we wanted to use the hMeasurement approach:
span class=duration title=3sthree seconds/span
span class=duration title=2min 3stwo minutes, three
seconds/span
span class=duration title=2y 35htwo years, 35 hours/span
span class=duration title=3sthree seconds/span



this kind of thing would:

1. add complexity to parsers
2. require people to be very precise in the choice of allowed strings ... 
eg: year  or y , second or seconds otherwise dates and times may 
very quickly degenerate into something not much better than garbled freeform 
text dates.
It would also mean a lot more rules for authors to remember which could 
result in a lot of invalid markup being published.
If dates/times are no longer machine-readable I would see no longer see much 
practical use for any of this!


I am very wary of straying too far from ISO for dates and times
(or at least something that can easily be parsed by 
javascript/php/perl/ruby/whatever built-in date functions or commonly used 
date libraries)


keep it simple !





___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Andy Mabbett]

In message [EMAIL PROTECTED], Tantek Çelik
[EMAIL PROTECTED] writes

I've drafted this wiki page

http://microformats.org/wiki/anti-patterns

That page, and the glossary

http://microformats.org/wiki/glossary

would benefit from a definition of anti-pattern.

-- 
Andy Mabbett

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[James O'Donnell]

On 16 Dec 2007, at 04:28, Paul Wilkins wrote:


span class=duration title=PT2M23S2:23/span

With this it is not possible to prevent the title from being used by
screen readers and other people who hover their mouse over the time
value. The title is purely to provide machine readable information
that is not humanly presented.


Hi,

JAWS (and, I think, WindowEyes also) reads titles on links,  
abbreviations and form controls. span should be safe if you want to  
hide the contents of the title attribute from a screenreader.


Span seems a more pragmatic choice to me, since title on span  
supplements the enclosed text, whereas title on abbr replaces the  
enclosed text. As someone else mentioned, for a lot of these cases we  
want to annotate a piece of text with computer-parsable information.


Jim

Jim O'Donnell
[EMAIL PROTECTED]
http://eatyourgreens.org.uk
http://flickr.com/photos/eatyourgreens



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Andy Mabbett]

In message [EMAIL PROTECTED],
James O'Donnell [EMAIL PROTECTED] writes


On 16 Dec 2007, at 04:28, Paul Wilkins wrote:

 span class=duration title=PT2M23S2:23/span

 With this it is not possible to prevent the title from being used by
 screen readers and other people who hover their mouse over the time
 value. The title is purely to provide machine readable information
 that is not humanly presented.

Hi,

JAWS (and, I think, WindowEyes also) reads titles on links,
abbreviations and form controls. span should be safe if you want to
hide the contents of the title attribute from a screenreader.

Span seems a more pragmatic choice to me, since title on span
supplements the enclosed text, whereas title on abbr replaces the
enclosed text. As someone else mentioned, for a lot of these cases we
want to annotate a piece of text with computer-parsable information.

While I understand the desire to avoid namespacing per se, in this case,
using:

span class=duration title=value:PT2M23S2:23/span

or
span class=dtstart
  title=value:20070912T16:03:00+01:00
  4.03pm
/span

would render the title both more semantically accurate and
human-readable. It would also enable the users of assistive technologies
to hit the next button as soon as they hear value colon read out,
bypassing the machine-readable fragment.

Parsers MUST ignore titles not starting with value;, thereby
ensuring compatibility with titles used on spans, for other purposes.

In the above value: is just as suggestion; the label could be
machine-value:, data-equivalent:, or some other such word or phrase.

This suggestion may case problems for non-English speakers, though.
Perhaps data: would be more internationally recognised?

-- 
Andy Mabbett
*  Say NO! to compulsory UK ID Cards:  http://www.no2id.net/
*  Free Our Data:  http://www.freeourdata.org.uk
*  Are you using Microformats, yet: http://microformats.org/ ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Martin McEvoy]

On Sun, 2007-12-16 at 00:30 -0500, Sarven Capadisli wrote:
 This is to address SEO and anchors (a) in documents.
 
 Fortunately, good SEO is more complex then boiling down well-ranking
 in SERPs into how the anchors are set in a document.
 
 Regarding: http://microformats.org/wiki/anti-patterns#empty_hyperlinks
 
 point A) if there is no href attribute and value set then the current
 document is not pointing to any resource, therefore there is no impact
 on PR as there is no weight to distribute between documents.

the suggestion was we do this:

a class=duration title=PT2M23S2:23/a

or

a class=duration title=PT2M23S/a2:23

now unfortunatly on both occasions the a is NOT empty @title has a
value and thus robots crawling your site will be expecting a href
attribute for which there is NONE.

 
 point B) Google or any other search engine will not simply ban a Web
 site from the left-field if there are no obvious indicators (bad
 intentions) to be delisted from SERPs. Needless to say, getting
 banned is not a quick automated action and spamming goes much
 further then that.

No you are probably right average joe probably wont get banned it would
depend on if an unscrupulus SEO decided to exploit this pattern
(stuffing the @title with keywords springs to mind), that would be a
worse case scenario, but even so the consequences of doing such things
are way to risky and have little or no benefit to the web itself. As
Tantek says we should avoid promoting such Anti patterns.

 
 Moreover this is like suggesting using URL fragments (internal link
 anchors) in href is bad for SEO.

No Im not links that go somewhere:

a id=here href=#here class=duration title=PT2M23S2:23/a

Is acceptable because there is an href value and it goes somewhere, no
confusing the bots

 
 In addition to all this, I do not think that microformats should be
 concerned with the SEO practices as there are many guidelines out
 there and which method works well for one site today on a particular
 engine may not necessarily work tomorrow. Therefore, I strongly think
 that we move away from these sort of practices.

Microformats are on page SEO they are good for the web, and good for
users, lets not spoil things for our respected community by presenting
half baked solutions that are at best a hack.

Thanks

Martin

 
 I've written about good SEO practices (read: good Web development
 practices) if anyone would like to give it a read:
 http://www.csarven.ca/internal-seo-guidelines
 
 By mentioning all this I am not suggesting the usage of empty anchors
 (no href attribute/value).
 
 -Sarven
 ___
 microformats-discuss mailing list
 microformats-discuss@microformats.org
 http://microformats.org/mailman/listinfo/microformats-discuss

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Andy Mabbett]

In message [EMAIL PROTECTED], Martin 
McEvoy [EMAIL PROTECTED] writes



Moreover this is like suggesting using URL fragments (internal link
anchors) in href is bad for SEO.


No Im not links that go somewhere:

a id=here href=#here class=duration title=PT2M23S2:23/a

Is acceptable because there is an href value and it goes somewhere, no 
confusing the bots


...just the users.

Do we really want to present people with hyperlinks that link to the 
place they're already at?


--
Andy Mabbett
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Martin McEvoy]

On Sun, 2007-12-16 at 13:48 +, Andy Mabbett wrote:
 In message [EMAIL PROTECTED], Martin 
 McEvoy [EMAIL PROTECTED] writes
 
  Moreover this is like suggesting using URL fragments (internal link
  anchors) in href is bad for SEO.
 
 No Im not links that go somewhere:
 
 a id=here href=#here class=duration title=PT2M23S2:23/a
 
 Is acceptable because there is an href value and it goes somewhere, no 
 confusing the bots
 
 ...just the users.
 
 Do we really want to present people with hyperlinks that link to the 
 place they're already at?

no not really just presenting an example, and people already do create
hyperlinks to the content they are already at, named anchors are a
useful feature in long pages of content.

I also am not supporting any such usage (just for the record) ;)

Thanks

Martin 
 

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Martin McEvoy]

On Sun, 2007-12-16 at 15:42 +, Martin McEvoy wrote:
 On Sun, 2007-12-16 at 13:48 +, Andy Mabbett wrote:
  In message [EMAIL PROTECTED], Martin 
  McEvoy [EMAIL PROTECTED] writes
  
   Moreover this is like suggesting using URL fragments (internal link
   anchors) in href is bad for SEO.
  
  No Im not links that go somewhere:
  
  a id=here href=#here class=duration title=PT2M23S2:23/a
  
  Is acceptable because there is an href value and it goes somewhere, no 
  confusing the bots
  
  ...just the users.
  
  Do we really want to present people with hyperlinks that link to the 
  place they're already at?
 
 no not really just presenting an example, and people already do create
 hyperlinks to the content they are already at, named anchors are a
 useful feature in long pages of content.
 
 I also am not supporting any such usage (just for the record) ;)

The crux of what I am trying to explain is that at the moment empty
anchor text links mean nothing as far as SEO is concerned, bots will
either ignore or simply erase them from there index.

If we as a respected community say that empty anchor text DO mean
something, then bots and other applications that crawl the web will have
to take this into account in order to correctly represent their indexes.

Black Hat SEO's will undoubtedly exploit this to their own means
rel=nofollow is a classic example of where a microformat has been
exploited by SEO's to do something its not meant for and thus may be
regarded as an Anti design pattern.

I do not wish (although the intentions are good) to be responsible for
opening the floodgates on any such behavior, and as a community we have
a responsibility to steer well clear of hacks, and half hearted
solutions that may end up causing more damage than good. 

Thanks

martin
 
 Thanks
 
 Martin 
  

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Jeremy Keith]

Jim wrote:
Span seems a more pragmatic choice to me, since title on span  
supplements the enclosed text, whereas title on abbr replaces the  
enclosed text. As someone else mentioned, for a lot of these cases  
we want to annotate a piece of text with computer-parsable  
information.


I agree that there are problems (both semantic and—from the angle of  
assistive technology—possibly practical) associated with using ABBR.  
But I really don't understand this obsession with SPAN. Why would  
SPAN be any more or less preferable to any other element?


I think the crux of this matter is that the ABBR design pattern is  
one of the few times when using a microformat mandates what element  
an author should use.


In hCard, for example, all of the following are fine:

span class=fnJeremy Keith/span

em class=fnJeremy Keith/em

div class=fnJeremy Keith/div

cite class=fnJeremy Keith/cite

...and so on. You get the picture. The author gets to decide which  
element to use based on the context. A good author will choose the  
best (most semantically meaningful) element for the task at hand.  
Sometimes that might be SPAN but not always.


For datetimes, this semantic decision is only in the hands of the  
author if they choose to display the datetimes as text contained by  
opening and closing tags. All of these are, from the perspective of  
the hCalendar spec, fine:


span class=dtstart2007-12-16T16:20:00/span

em class=dtstart2007-12-16T16:20:00/em

div class=dtstart2007-12-16T16:20:00/div

The problem is that, if the author wants to use a design pattern that  
doesn't display this data between tags, the only option is to use the  
ABBR design pattern:


abbr class=dtstart title=2007-12-16T16:20:00

...and that's when you run into all the problems we've been  
discussing. There are potentially problems with screenreaders (test  
results are still needed firm up these issues) but, more  
fundamentally, there's the semantic issue, as Ben said:


This doesn't actually need to have any concern with accessibility,  
or assistive technology tools. Frankly, the difficulty in getting  
solid tests from such tools makes that line of argument less  
attractive in itself. But what has to be a fundamental baseline in  
our implementation of optimisation patterns in microformats is the  
HTML specification we are building on top of.


If a design pattern is going to *mandate* that authors must use a  
particular element, then the semantic meaning of that element needs  
to be pretty solid. That doesn't seem to be the case with the ABBR  
design pattern, as evidenced by the discussion here and, more  
importantly, as is outlined in the HTML spec.


In my opinion, this matter might be best resolved by giving the  
choice back to the author. Allow the author to decide what element is  
semantically best suited for the datetime pattern, just as the author  
is allowed to decide what element is semantically best suited for any  
other microformat class name.


But...

If we just swap out ABBR for SPAN, we're not solving anything. The  
SPAN element *might* be the right element to use for a datetime, or  
another element might be better... it all depends on the context— 
something that only the author will be aware of.


So when we're talking about alternatives to the ABBR design pattern,  
can we please stop just talking about SPAN? Surely what we're really  
talking about is allowing the design pattern to be expanded to any  
element (not just ABBR), at the author's discretion.


There's already confusion out there: some people have looked at the  
wiki and mistakenly jumped to the conclusion that authors must use  
SPANs and DIVs to create microformats because those are the elements  
used in the examples. Let's not turn those fears into reality by  
seriously suggesting that authors must use the SPAN element if they  
want to employ the datetime design pattern.


Can we agree that what we are discussing is opening up the datetime  
pattern to elements other than ABBR, not simply swapping ABBR for SPAN?


I'd be willing to consider a SPAN design pattern if it had any  
semantic merit but considering that SPAN is effectively lacking in  
any semantic value, I don't see how a SPAN design pattern would be  
any better than a DIV design pattern, a P design pattern, a Q design  
pattern or a CITE design pattern.


In short, I don't think we should be telling authors what elements to  
use. That's what got us into hot water with ABBR; I don't want to see  
the same mistake repeated again. The fact that microformats allow  
authors to choose the most semantically meaningful elements  
(according to context) is one of the great strengths of microformats,  
in my opinion.


Bye,

Jeremy

--
Jeremy Keith

a d a c t i o

http://adactio.com/



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Benjamin Hawkes-Lewis]

Martin McEvoy wrote:


The crux of what I am trying to explain is that at the moment empty
anchor text links mean nothing as far as SEO is concerned, bots will
either ignore or simply erase them from there index.

If we as a respected community say that empty anchor text DO mean
something, then bots and other applications that crawl the web will have
to take this into account in order to correctly represent their indexes.

Black Hat SEO's will undoubtedly exploit this to their own means
rel=nofollow is a classic example of where a microformat has been
exploited by SEO's to do something its not meant for and thus may be
regarded as an Anti design pattern.

I do not wish (although the intentions are good) to be responsible for
opening the floodgates on any such behavior, and as a community we have
a responsibility to steer well clear of hacks, and half hearted
solutions that may end up causing more damage than good.


Let me go through Martin's argument, as I understand it, to explain why 
I don't find it persuasive. My comments are in parentheses.


1. Search engines currently ignore TITLE on non-linking A. (Does 
anyone has any clear evidence to confirm this? Does that evidence hold 
for all major engines, or only for Google? I can't find anything solid.)


2. If microformats made use of TITLE on non-linking A for 
machine-readable data, search engines would want to use it. (This seems 
plausible.)


3. Black hat SEOs would then keyword-stuff TITLE on non-linking A. 
(Given the above premises, this seems plausible).


4. Search engines would not be able to distinguish keyword-stuffed TITLE 
attributes on non-linking A from microformat data. (rel=nofollow is a 
standalone pattern and it would be difficult to tell correct from 
incorrect use without human inspection. But these data-hiding patterns 
are intended for use within super-patterns like hAudio that tell parsers 
what to expect. Distinguishing data-hiding patterns of this sort from 
keyword stuffing sounds like a trivial programming task, so I think 
search engines surely would be able to distinguish between them.)


5. This problem only occurs with non-linking A. (But by its very nature, 
markup that hides content from most users, most of the time — and that 
includes /all/ patterns that hide data in TITLE attributes — is 
susceptible to keyword stuffing. Indeed, I would bet that each and every 
one of these patterns is already being abused by black-hat SEOs, 
effectually or not.)


NB: This email isn't intended as a general endorsement of TITLE on 
non-linking A. I'm deeply sceptical about misusing the TITLE attribute 
for human-unfriendly data, especially on anything other than an empty 
SPAN. I'm just saying I don't buy Martin's SEO-based argument against 
non-linking A in particular.


--
Benjamin Hawkes-Lewis
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Martin McEvoy]

On Sun, 2007-12-16 at 18:01 +, Benjamin Hawkes-Lewis wrote:
 1. Search engines currently ignore TITLE on non-linking A. (Does 
 anyone has any clear evidence to confirm this? Does that evidence
 hold 
 for all major engines, or only for Google? I can't find anything
 solid.) 

this may help:
go here http://www.webconfs.com/search-engine-spider-simulator.php
copy and paste this url 
http://weborganics.co.uk/files/test.html

the test consists of four anchor texts two with href attributes two
without

It isnt the definitive answer but I would say pretty accurate ;)

Martin

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Paul Wilkins]

On Dec 17, 2007 7:01 AM, Benjamin Hawkes-Lewis
[EMAIL PROTECTED] wrote:
 NB: This email isn't intended as a general endorsement of TITLE on
 non-linking A. I'm deeply sceptical about misusing the TITLE attribute
 for human-unfriendly data, especially on anything other than an empty
 SPAN. I'm just saying I don't buy Martin's SEO-based argument against
 non-linking A in particular.

Thanks for going through this.

Because the HTML spec doesn't allow for what we're trying to achieve,
one possibility was to use non-linking anchors, but there are several
issues with that.

I still prefer the abbr include pattern though.

The PT2M23S is to indicate a duration of time, but using such a format
meets resistance in that it's not easy for people to correctly markup
in such a manner.

Another option is to use hh:mm:ss instead. This is indicating an
actual moment in time.

Is it viable to consider that if we play a track from midnight, that
we can specify that moment in time when it ends?

abbr title=00:02:232:23/abbr

-- 
Paul Wilkins
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Benjamin Hawkes-Lewis]

Martin McEvoy wrote:

On Sun, 2007-12-16 at 18:01 +, Benjamin Hawkes-Lewis wrote:
1. Search engines currently ignore TITLE on non-linking A. (Does 
anyone has any clear evidence to confirm this? Does that evidence
hold 
for all major engines, or only for Google? I can't find anything
solid.) 


this may help:
go here http://www.webconfs.com/search-engine-spider-simulator.php
copy and paste this url 
http://weborganics.co.uk/files/test.html


the test consists of four anchor texts two with href attributes two
without

It isnt the definitive answer but I would say pretty accurate ;)


That's a cute tool, but I certainly wouldn't rely on a search engine 
simulator to be an accurate guide to the details of how real search 
engines like Google and Yahoo! Search index and weight content.


--
Benjamin Hawkes-Lewis
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Manu Sporny]

Paul Wilkins wrote:
 Another possible solution is to provide greater detail for the time itself.
 
 abbr title=00:23:002:23/abbr
 
 This I understand is an acceptable title for screen readers, it
 expands suitably on 2:23 (which could be 2 hours 23 minutes or 2
 minutes 23 seconds) and it's computer understandable in an ISO 8601
 manner.

If you are suggesting that we use the hh:mm:ss time format for
expressing duration, we cannot. That would be an abuse of the ISO 8601
standard. The standard is very specific about specifying TIME and about
specifying DURATION. Duration MUST be in one of the following formats,
where 0-values can be omitted:

PnnYnnMnnDTnnHnnMnnS
PnnYnnWnnDTnnHnnMnnS
PdateTtime

This is correct for a duration of 2 minutes, 23 seconds: PT2M23S
This is not: 00:02:23

Here's what the various approaches thus far look like when you put them
on an HTML page:

http://uf.digitalbazaar.com/unit-tests/sandbox/isodata.html

There are really two questions that we're attempting to answer here:

1. Can we make screen readers not read the @title, of whatever element
   we choose, out loud?
2. Do we care that PT2M23S will appear if the person browsing hovers
   their cursor over the text denoting the duration, if that is the only
   way we can successfully utilize ISO standards in the Microformats
   community?

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Martin McEvoy]

On Sun, 2007-12-16 at 19:16 +, Benjamin Hawkes-Lewis wrote:
 Martin McEvoy wrote:
  On Sun, 2007-12-16 at 18:01 +, Benjamin Hawkes-Lewis wrote:
  1. Search engines currently ignore TITLE on non-linking A. (Does 
  anyone has any clear evidence to confirm this? Does that evidence
  hold 
  for all major engines, or only for Google? I can't find anything
  solid.) 
  
  this may help:
  go here http://www.webconfs.com/search-engine-spider-simulator.php
  copy and paste this url 
  http://weborganics.co.uk/files/test.html
  
  the test consists of four anchor texts two with href attributes two
  without
  
  It isnt the definitive answer but I would say pretty accurate ;)
 
 That's a cute tool, but I certainly wouldn't rely on a search engine 
 simulator to be an accurate guide to the details of how real search 
 engines like Google and Yahoo! Search index and weight content.

No neither would I but I as you cannot find any definitive answer to
this.

still searching...


Martin
 
 --
 Benjamin Hawkes-Lewis

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Sarven Capadisli]

On Dec 16, 2007 2:16 PM, Benjamin Hawkes-Lewis
[EMAIL PROTECTED] wrote:
 Martin McEvoy wrote:
  On Sun, 2007-12-16 at 18:01 +, Benjamin Hawkes-Lewis wrote:
  1. Search engines currently ignore TITLE on non-linking A. (Does
  anyone has any clear evidence to confirm this? Does that evidence
  hold
  for all major engines, or only for Google? I can't find anything
  solid.)
 
  this may help:
  go here http://www.webconfs.com/search-engine-spider-simulator.php
  copy and paste this url
  http://weborganics.co.uk/files/test.html
 
  the test consists of four anchor texts two with href attributes two
  without
 
  It isnt the definitive answer but I would say pretty accurate ;)

 That's a cute tool, but I certainly wouldn't rely on a search engine
 simulator to be an accurate guide to the details of how real search
 engines like Google and Yahoo! Search index and weight content.

 --
 Benjamin Hawkes-Lewis

 ___
 microformats-discuss mailing list
 microformats-discuss@microformats.org
 http://microformats.org/mailman/listinfo/microformats-discuss



This is one of the reasons not to rely on what some of the agents are
doing with the documents. Not only is it not reliable (because they
all take a guess) but also there is no guarantee how the information
will be extracted/perceived in the future with the actual search
engines.

As I mentioned before, the formats should steer clear from what these
agents may be doing and instead focus on deriving solutions that is
sound within the document.


Jeremy Keith wrote:
 If a design pattern is going to *mandate* that authors must use a
 particular element, then the semantic meaning of that element needs
 to be pretty solid.

I totally agree with this.

-Sarven
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Manu Sporny]

Paul Wilkins wrote:
 span class=duration title=PT2M23S2:23/span
 
 With this it is not possible to prevent the title from being used by
 screen readers and other people who hover their mouse over the time
 value.

This is not true. You can set several, of not all, screen readers to not
read titles of SPAN elements.

It is important for us to focus on the reason this discussion started in
the first place:

http://microformats.org/discuss/mail/microformats-discuss/2007-December/011035.html

The issue was accessibility, specifically, how accessible is the ABBR
design pattern for those that use screen readers.

At this point, it's really just a matter of testing the examples we have
so far:

http://uf.digitalbazaar.com/unit-tests/sandbox/isodata.html

Against the list of screen reader packages on the market:

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

I'll volunteer to check out Orca and JAWS and report the findings to the
list, and document them in the wiki.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Paul Wilkins]

On Dec 17, 2007 8:14 AM, Manu Sporny [EMAIL PROTECTED] wrote:
 There are really two questions that we're attempting to answer here:

 1. Can we make screen readers not read the @title, of whatever element
we choose, out loud?

Yes, by enclosing no text inside the element.

 2. Do we care that PT2M23S will appear if the person browsing hovers
their cursor over the text denoting the duration, if that is the only
way we can successfully utilize ISO standards in the Microformats
community?

Yes we should care about that. Humans first - if the abbr title isn't
useful to humans, then it needs to be fixed.

The following we should not do:
abbr class=duration title=PT2M23S/abbr2:23

But we can do something like this:
span class=duration title=PT2M23S/span2:23

I don't think that we will find a completely acceptable solution, so
it's a matter of working out what needs are the least important in
maintaining.

-- 
Paul Wilkins
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Ben Ward]

On 16 Dec 2007, at 20:09, Manu Sporny wrote:
It is important for us to focus on the reason this discussion  
started in

the first place:

http://microformats.org/discuss/mail/microformats-discuss/2007- 
December/011035.html


The issue was accessibility, specifically, how accessible is the ABBR
design pattern for those that use screen readers.


No, Manu, that was not the reason this most recent discussion started.

In fact, the catalyst for this most recent iteration concerns not  
accessibility — I deliberately avoided that as finding precise data  
is too difficult. The issue at hand is that more recent  
specifications such as GEO (albeit brainstorming) and hAudio are  
mandating the use of the ABBR pattern in a way which is not  
compatible with the HTML specification.


Yes, there are many here who care a great deal about the implications  
of microformats on users of assistive technology, but it is clear  
that most contributions here are unable to find sources or recorded  
evidence to support or refute any claim. Unfortunately, gaining such  
evidence from people who really use AT daily is neither easy nor  
inexpensive. You or I downloading a trial of JAWS and running it will  
not useful test results.


This is not true. You can set several, of not all, screen readers  
to not

read titles of SPAN elements.


The issue is not whether you _can_ set a screen reader to read or  
ignore @title attributes, it is whether users actually do or not. The  
limited experience I have from inside Yahoo!, where I have been able  
to ask some very generous people to assist in accessibility testing  
on another issue, is that people who depend upon AT tools are far  
more inclined to customise their tool to improve their experience. As  
such, there are a plethora of combinations of tools and  
configurations consuming pages.


One can presume on the basis that these users are more inclined to  
configure their tool, that such a user will configure their tool  
optimally for their usage, depending on the kind of content they  
interact with the most. As such, we cannot ever work on the basis  
that upon discovering machine data in the @title attribute of a  
microformat property that they will simply reconfigure their tool;  
their choice to enable reading of titles will be useful for some  
kinds of content.


It is the quantity of variables in the field of AT and the expense of  
testing them which makes it hard for a community of our limited  
resources to make decisions based on AT performance. But whether  
criticising or supporting a pattern, vague statements about the  
behaviour of AT help nobody.


I think this discussion would progress better if people stay focused  
on the data requirement and the semantics of the output first, and  
the implementation second. So far, we're getting very sidetracked by  
a series of new proposed hacks, rather than identification of which  
problems need solving by a precision/expansion pattern.


Thanks,

Ben
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Martin McEvoy]

On Sun, 2007-12-16 at 15:09 -0500, Manu Sporny wrote:
 I'll volunteer to check out Orca and JAWS and report the findings to
 the
 list, and document them in the wiki. 

Thank you manu :)

can you please test:

var class=duration title=PT2M23S2:23/var

I think it would be valuable to know if the @title is read out loud on
uncommon tags like var and dfn or if all @titles are read out loud.

My thought is (after many months of wrestling with this beast) that
instead of trying to hide and change what we are doing (after all its
necessary) it may be worthwhile trying to find a more semantic
equivalent of how we use the abbr tag.

http://www.w3.org/TR/html401/struct/text.html#h-9.2.1

VAR:
Indicates an instance of a variable or program argument.

We are presented with an instance of a variable, when we do this:

abbr class=duration title=PT2M23S2:23/abbr

duration is described in two ways machine data, and human data, this
presents the instance and an argument with two different outcomes, if
you are a machine do this PT2M23S, if you are a person do this 2:23.

*Var* seems wholly suited to what we are trying to achieve.

?

Thanks.

Martin




___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Martin McEvoy]

moved to uf-new
http://microformats.org/discuss/mail/microformats-new/2007-December/001330.html

sorry

Thanks

Martin

On Sun, 2007-12-16 at 21:16 +, Martin McEvoy wrote:
 On Sun, 2007-12-16 at 15:09 -0500, Manu Sporny wrote:
  I'll volunteer to check out Orca and JAWS and report the findings to
  the
  list, and document them in the wiki. 
 
 Thank you manu :)
 
 can you please test:
 
 var class=duration title=PT2M23S2:23/var
 
 I think it would be valuable to know if the @title is read out loud on
 uncommon tags like var and dfn or if all @titles are read out loud.
 
 My thought is (after many months of wrestling with this beast) that
 instead of trying to hide and change what we are doing (after all its
 necessary) it may be worthwhile trying to find a more semantic
 equivalent of how we use the abbr tag.
 
 http://www.w3.org/TR/html401/struct/text.html#h-9.2.1
 
 VAR:
 Indicates an instance of a variable or program argument.
 
 We are presented with an instance of a variable, when we do this:
 
 abbr class=duration title=PT2M23S2:23/abbr
 
 duration is described in two ways machine data, and human data, this
 presents the instance and an argument with two different outcomes, if
 you are a machine do this PT2M23S, if you are a person do this 2:23.
 
 *Var* seems wholly suited to what we are trying to achieve.
 
 ?
 
 Thanks.
 
 Martin
 
 
 

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Re: Precise Expansion Patterns

[Michael MD]

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Benjamin
Hawkes-Lewis
Sent: Monday, 17 December 2007 7:33 AM
To: Microformats Discuss
Subject: Re: [uf-discuss] Re: Precise Expansion Patterns

Manu Sporny wrote:

 There are really two questions that we're attempting to answer here:
 
 1. Can we make screen readers not read the @title, of whatever element
we choose, out loud?
 2. Do we care that PT2M23S will appear if the person browsing hovers
their cursor over the text denoting the duration, if that is the only
way we can successfully utilize ISO standards in the Microformats
community?

I think it's clear that with a bit of testing we can find a markup 
pattern, albeit not necessarily a pretty one, where human-hostile data 
is not read aloud or shown on hover.

I'm a bit concerned that if important machine readable data is completely
hidden, people will forget to update it when they update the page.
I thought that is one of the reasons title was chosen in the first place.
(showing it on hover in many browsers would act as a reminder for authors to
update it)





___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Andy Mabbett]

On Sun, December 16, 2007 19:14, Manu Sporny wrote:
 Paul Wilkins wrote:

 Another possible solution is to provide greater detail for the time
 itself.

 abbr title=00:23:002:23/abbr

 If you are suggesting that we use the hh:mm:ss time format for
 expressing duration, we cannot. That would be an abuse of the ISO 8601
 standard.

We can, becasue we are not mandated to use the ISO 8601 standard.

-- 
Andy Mabbett
** via webmail **

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Paul Wilkins]

On Dec 17, 2007 10:59 AM, Michael MD [EMAIL PROTECTED] wrote:
 I'm a bit concerned that if important machine readable data is completely
 hidden, people will forget to update it when they update the page.
 I thought that is one of the reasons title was chosen in the first place.
 (showing it on hover in many browsers would act as a reminder for authors to
 update it)

How then do we then handle situations where the machine data is
hostile to humans?
If someone is editing the page without seeing the code, they won't
know about the title attributes either. A most likely scenario that
remedies this is when people spot an error in their microformat, and
get in touch to have it corrected.

Is it possible to use a relationship attribute instead?

a class=duration rel=PT2M23S2:23/a

If not my favourite for avoiding the title attribute being expressed
still has to be
span class=duration title=PT2M23S/span2:23

-- 
Paul Wilkins
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Benjamin Hawkes-Lewis]

Paul Wilkins wrote:

Is it possible to use a relationship attribute instead?

a class=duration rel=PT2M23S2:23/a


No, that's not what REL is for.

http://www.w3.org/TR/html401/struct/links.html#adef-rel

Misusing HTML 4.01 attributes to hold machine-readable data is arguably 
worse than (say) inventing new, non-standard attributes to do the same 
thing.


But neither practice is compatible with the microformats philosophy of 
building on existing and widely adopted standards.


--
Benjamin Hawkes-Lewis
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Benjamin Hawkes-Lewis]

Michael MD wrote:

I'm a bit concerned that if important machine readable data is completely
hidden, people will forget to update it when they update the page.
I thought that is one of the reasons title was chosen in the first place.
(showing it on hover in many browsers would act as a reminder for authors to
update it)


There are some drawbacks with using TITLE as a solution to the 
maintenance problem.


1. It turns the author's maintenance problem into everyone else's 
usability problem, and potentially some people's accessibility problem.


2. If people are updating a page and forget to update machine-readable 
data, it hardly seems likely that they would remember to hunt for and 
hover over each bit of data. In fact that seems rather more error-prone 
than just looking for such hidden data in the source.


3. Even if they do check via hovers, human-hostile data is hard for 
humans to read. That means it is also hard for humans to check.


Would it not be a better solution to build tools that display the hidden 
data for all microformats on a page at the click of a single button? 
This would include the following advantages:


1. Only the author would have to deal with it.

2. There's only one button to remember.

3. The hidden data can be revealed in a human-friendly format (e.g. the 
precise date time in the local date time format for that author) or 
flagged as an error if unparseable.


--
Benjamin Hawkes-Lewis

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Jeremy Keith]

Andy wrote:

Span is used as an example of a generic paired element.


Good. That's what I was hoping. Then can we say that instead of  
saying SPAN? Please? :-)


Bye,

Jeremy

--
Jeremy Keith

a d a c t i o

http://adactio.com/


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-new] [Fwd: Re: [uf-discuss] Re: Precise Expansion Patterns]

[Paul Wilkins]

On Dec 17, 2007 2:12 PM, Martin McEvoy [EMAIL PROTECTED] wrote:
  Any misuse of the VAR element will affect how they are to be presented.
  Consider what will happen when proper use of the VAR element is
  intermingled with other use of the the VAR element as a design
  pattern.

 I am not misusing it?

 Paul why do you make me work so much? :) ...

Because these standards are not to be fiddled with.
VAR elements are typically styles in italics, and depending on your
styles it can be anything from virulent green to preformatted text, to
help denote the variables you are referring to.

 Although html 1.0 never really existed as a standard since then
 var is defined as simply A variable name.
 http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt

 As far as I know var hasn't changed since then.

The XHTML2 specs gives the following example:
The parameter varncols/var represents the number of colors to use.

And the HTML5 specs provide the following example:
pIf there are varn/var pipes leading to the ice cream factory
then I expect at emleast/em varn/var flavours of ice cream to
be available for purchase!/p

 var is regarded as a Metasyntactic variable
 http://www.gnu.org/software/texinfo/manual/texinfo/html_node/var.html
 http://www-fs.informatik.uni-tuebingen.de/~hunszing/QuickRef.html

You didn't provide the QuickRef information from HTML 1.0
for a ``metasyntactic'' variable, where the user is to replace the
variable with a specific instance. Typically displayed in italics.

The wikipedia article about metasyntatic variables says
A metasyntactic variable (pronounced /ˌmɛtəsɪnˈtæktɪk ˈvɛəriəbl/)
is a placeholder name, or an alias term, commonly used to denote the
subject matter under discussion

It also says about them
it has been plausibly suggested that the real reason for the term
metasyntactic variable is that it sounds cool

 yes it has proved to be useful in programming but that is not its sole
 purpose, all it means is this is the bit we want to do something
 with...?

In all cases of a variable, the purpose of a variable is to be
replaced with a specific instance.

The Wikipedia article helps to boils this down.

There are three specific domains for variables:
- computers and maths
- physical sciences and engineering
- statistics

It then goes on to state that in general
  Variables are used in open sentences. For instance, in the formula x
+ 1 = 5, x is a variable which represents an unknown number.

2:23 is about as far away as we can get from an unknown number.

You're going to have a very large uphill battle convincing anyone that
the duration of 2 minutes and 23 seconds is a variable.

-- 
Paul Wilkins

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Manu Sporny]

Benjamin Hawkes-Lewis wrote:
 Here's another question that needs asking. How much real-world value
 does the use of the ISO standard for date time representations
 actually add in this /particular/ case (hAudio duration)?
 How often do these reasons apply to hAudio duration?

These questions are dangerously short-sighted, focusing on just hAudio
will hurt the Microformats community in the long run... I'll explain why
below.

 The impression I get is that the majority of cases would be served
 fine by:

 span class=durationspan class=minutes2/span:span
 class=s25/span/span

This would be a giant pain to author, IMHO. Then again, it fixes our
accessibility/usability issues - placing much of the load on the
authors. If we make it this verbose to mark up this sort of information,
do we think authors are going to mark up DURATION?

For sites like ours that are automated, we would have no problem
adopting the approach listed above... but think about the blog author
that has to mark up DURATION. Are they going to take the time, or skip it?

What happens when somebody wants to specify a time duration as
twenty-three minutes? Or a measurement as two stones? Your proposal
above doesn't solve those problems.

Andy Mabbett wrote:
 On Sun, December 16, 2007 19:14, Manu Sporny wrote:
 Paul Wilkins wrote:

 Another possible solution is to provide greater detail for the time
 itself.

 abbr title=00:23:002:23/abbr
 
 If you are suggesting that we use the hh:mm:ss time format for
 expressing duration, we cannot. That would be an abuse of the ISO 8601
 standard.
 
 We can, becasue we are not mandated to use the ISO 8601 standard.

So assume that we do that today...

We're locking in DURATION to have a very specific meaning a length of
time. To denote that length of time, you have hours, minutes and
seconds HH:MM:SS.

Some time further down the line, somebody has another Microformat that
needs to specify a time duration. Their time durations, however, are in
years.

The problem comes in when the second person wants to denote their time
duration in years. We've already said that DURATION is a length of
time and specified a format HH:MM:SS. So now, authors have to translate
years into hours... quite a pain, but it gets worse.

Later yet, in a future Microformat far, far away, somebody comes along
and wants to specify time in fractions of a second.

Once again, they can't use DURATION because there is no space for
fractions of a second (which you can specify in ISO8601).

Remember, this same thing happened with the TITLE tag in Microformats.
TITLE is used to specify a job title in hCard. This meant that we
couldn't use TITLE in hAudio because it meant a job title, not the
title of an object, such as, but not limited to, a book, movie, album,
or person.

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.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Ben Ward]

On 17 Dec 2007, at 00:31, Jeremy Keith wrote:

Andy wrote:

Span is used as an example of a generic paired element.


Good. That's what I was hoping. Then can we say that instead of  
saying SPAN? Please? :-)


Perhaps adopt a convention of using FOO or a more English friendly  
ANYELEMENT ‘element’ when writing such examples in this discussion?  
I think it might assist the wider thought process and keep people  
thinking generically, rather in terms of SPAN.


Ben



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Paul Wilkins]

On Dec 17, 2007 11:18 AM, Andy Mabbett [EMAIL PROTECTED] wrote:
 On Sun, December 16, 2007 19:14, Manu Sporny wrote:
  Paul Wilkins wrote:
  abbr title=00:23:002:23/abbr
  If you are suggesting that we use the hh:mm:ss time format for
  expressing duration, we cannot. That would be an abuse of the ISO 8601
  standard.

 We can, becasue we are not mandated to use the ISO 8601 standard.

It is a nice solution, and I notice an error, another positive aspect
of this notation.
It should be:
abbr title=00:02:232:23/abbr
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Jason Karns]

I realize that the OBJECT element has lost favor in the
include-pattern due to browser issues.  But it provides a @data
attribute which, can be used to specify the location of the object's
data, for instance image data for objects defining images, or more
generally, a serialized form of an object which can be used to
recreate it. [http://www.w3.org/TR/html401/struct/objects.html#adef-data]

Given the browser issues, this won't work for everyone all the time
but, truth be told, nothing ever does.  Could the object/@data pair be
considered as an option to be used at the author's discretion (perhaps
as an alternative to the empty anchor proposed earlier.)

~Jason
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Michael MD]

what about html5's datetime attribute?
(would only be of use in html5 though)


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Paul Wilkins]

On 12/16/07, Michael MD [EMAIL PROTECTED] wrote:
 what about html5's datetime attribute?
 (would only be of use in html5 though)

There is a datetime attribute (on a very select few elements) in HTML4.

The trouble is that you are required to specify a full date/time, of
which only one type for format is accepted, which is too narrow for
our needs.

I presume that there are similar issues with the HTML5 standard too.

-- 
Paul Wilkins
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Paul Wilkins]

On Dec 16, 2007 8:00 AM, Manu Sporny [EMAIL PROTECTED] wrote:
 What was the problem with the SPAN approach, again?

 span class=duration title=PT3M23S3:23/span

 - You can set most, if not all, screen readers to not verbalize @title
   in SPAN.
 - We're not abusing ABBR.

I've been looking carefully through the HTML 4.01 specs and realised
that there is no actual mechanism provided for what we are wanting to
achieve. This is why there has been so much debate about this and it's
why compromises will have to be made if we're to achieve our end
result.

One of the things I came across is that the INS element accepts a
datetime attribute, but it has to be fully specified as a moment in
time. That might be useful for other applications like the calendar.

The A element is the other one that I came across. We appear to have
been completely ignoring this one, even though it looks to be a very
suitable candidate.
The specs say that it doesn't have to link to anything, and can
contain the class and title of what we require.
Authors may also create an A element that specifies no anchors,
i.e., that doesn't specify href, name, or id.

a class=duration title=PT3M23S3:23/a

And if you don't want the title to appear when you hover over the
text, you can leave the A element empty.

a class=duration title=PT3M23S/a3:23

In both situations the A element is not included in the tabbed flow of
the document, because there is no anchor involved.

With this technique we are able to embed machine-only information
around or near-to the human readable text.

-- 
Paul Wilkins
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Martin McEvoy]

On Sun, 2007-12-16 at 12:28 +1300, Paul Wilkins wrote:
 On Dec 16, 2007 11:52 AM, Martin McEvoy [EMAIL PROTECTED] wrote:
  The empty a/a although valid, seems nasty to me and a little anti!,
  microformats are supposed to represent the data they contain...are they?
 
 
 As I was saying, this is why there has been so much debate about this
 and it's why compromises will have to be made if we're to achieve our
 end result.
 
 The elements haven't been designed for what we are trying to use them
 for. As such, there will be situations where the only other solutions
 have differing levels of tradeoffs.
 
 For example, you can use the following which gives no title display in
 both Firefox and IE, but it's largely a hack.
 span title=a title=PT3M23Sspan title=3:23/span/a/span
 
 A simple statement of fact is, if you don't want titles to be
 displayed then don't wrap them around content.
 Humans first and machines second. The empty anchor before the content
 appears to fulfil that nicely, more-so than other attempts.

OK Paul, lets try and put that in the real world, My client has a music
store with around 500 pages of content and around 10 to 20 items of
hAudio on each page, My client want's their pages to validate and be
accessible.. no problem i say, semantic markup... and SEO,  semantic
markup... we can sprinkle some hAudio magic in there I say .. great my
client says because they trust me im good at my job, I do the job, my
boss looks at my work and says what are all these empty anchors
about... pause right there... any SEO worth his salt will know anchor
text links that go nowhere, will A, reduce the quality of out going
links from your site so reducing PR (Page Rank) and B, more than likley
get you banned from google because it will think you are trying to spam
it you know what my boss will sayyou are sacked.

so no thank you Paul although your idea is workable, its still a hack,
and in the real world never likely to be used.

Thanks

Martin
 

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Tantek Çelik]

On 12/15/07 4:39 PM, Martin McEvoy [EMAIL PROTECTED] wrote:

 OK Paul, lets try and put that in the real world, My client has a music
 store with around 500 pages of content and around 10 to 20 items of
 hAudio on each page, My client want's their pages to validate and be
 accessible.. no problem i say, semantic markup... and SEO,  semantic
 markup... we can sprinkle some hAudio magic in there I say .. great my
 client says because they trust me im good at my job, I do the job, my
 boss looks at my work and says what are all these empty anchors
 about... pause right there... any SEO worth his salt will know anchor
 text links that go nowhere, will A, reduce the quality of out going
 links from your site so reducing PR (Page Rank) and B, more than likley
 get you banned from google because it will think you are trying to spam
 it you know what my boss will sayyou are sacked.
 
 so no thank you Paul although your idea is workable, its still a hack,
 and in the real world never likely to be used.

Martin, thanks for this reality-check.  You've provided some good reasons
for why empty hyperlinks are an anti-pattern, and given that that's two this
week, and that we have a few existing anti-patterns documented on the wiki,
I've drafted this wiki page accordingly.

http://microformats.org/wiki/anti-patterns

In particular I've documented part of what you noted above in this section:

http://microformats.org/wiki/anti-patterns#empty_hyperlinks

I encourage you to expand upon it with any additional details / references.

Thanks,

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Paul Wilkins]

On Dec 16, 2007 1:39 PM, Martin McEvoy [EMAIL PROTECTED] wrote:
 snip my
 boss looks at my work and says what are all these empty anchors
 about... pause right there... any SEO worth his salt will know anchor
 text links that go nowhere, will A, reduce the quality of out going
 links from your site so reducing PR (Page Rank) and B, more than likley
 get you banned from google because it will think you are trying to spam
 it you know what my boss will sayyou are sacked.

First an apology to Martin, my reply went direct to him when it should
have come to the group.

The A elements are not empty-anchors, and they are not text links that
go nowhere.
There is no text being linked, and there is no href, no name and no id
to anchor them to anything.
If they don't anchor to anything they can't be anchors, and are
perfectly valid from the HTML spec and
google perspective.

Regardless of that though, they don't have to be anchors. For the sake
of simplifying things they can just as easily be SPAN elements.

span class=duration title=PT2M23S2:23/span

With this it is not possible to prevent the title from being used by
screen readers and other people who hover their mouse over the time
value. The title is purely to provide machine readable information
that is not humanly presented.

If the title is to not to be presented as human readable information,
then the title must be wrapped around no text.

span class=duration title=PT2M23S/span2:23

It may even be possible to use a special class to designate that the
title has special meaning.

span class=include-title duration title=PT2M23S/span2:23

Remember, the HTML 4 specs are not designed for what we're trying to
do here. We are looking for how to provide computer understandable
information without interfering with the use of human readable text.

Another possible solution is to provide greater detail for the time itself.

abbr title=00:23:002:23/abbr

This I understand is an acceptable title for screen readers, it
expands suitably on 2:23 (which could be 2 hours 23 minutes or 2
minutes 23 seconds) and it's computer understandable in an ISO 8601
manner.

I will gratefully hear from anyone else who has an include pattern
where computer understandable information does not interfere with
human readable information.

--
Paul Wilkins
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Sarven Capadisli]

This is to address SEO and anchors (a) in documents.

Fortunately, good SEO is more complex then boiling down well-ranking
in SERPs into how the anchors are set in a document.

Regarding: http://microformats.org/wiki/anti-patterns#empty_hyperlinks

point A) if there is no href attribute and value set then the current
document is not pointing to any resource, therefore there is no impact
on PR as there is no weight to distribute between documents.

point B) Google or any other search engine will not simply ban a Web
site from the left-field if there are no obvious indicators (bad
intentions) to be delisted from SERPs. Needless to say, getting
banned is not a quick automated action and spamming goes much
further then that.

Moreover this is like suggesting using URL fragments (internal link
anchors) in href is bad for SEO.

In addition to all this, I do not think that microformats should be
concerned with the SEO practices as there are many guidelines out
there and which method works well for one site today on a particular
engine may not necessarily work tomorrow. Therefore, I strongly think
that we move away from these sort of practices.

I've written about good SEO practices (read: good Web development
practices) if anyone would like to give it a read:
http://www.csarven.ca/internal-seo-guidelines

By mentioning all this I am not suggesting the usage of empty anchors
(no href attribute/value).

-Sarven
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss