[uf-discuss] Tutorial on AHAH (such a cool technology!)

[Paul Wilkins]

Mike Schinkel wrote:

Printable version please! Ane that doesn't take 12 pages to print...  (He
also grumbles about lack of back button in presentation but glad the
presentation was not 96 pages...)


The slideshow was built using S5, A Simple Standards-Based Slide Show
System from Eric Meyer.
http://meyerweb.com/eric/tools/s5/

Eric built S5 to scratch an itch, and now many others have taken to using it 
too.


There are several ways to go back, arrow keys, page up, or mouse down to the 
info back and click on the arrows.


Keyboard controls for it can be found at
http://meyerweb.com/eric/tools/s5/features.html#controlchart

The keyboard controls aren't easily discoverable, especially for people 
viewing the slideshows and perhaps that's an improvement that can be 
suggested.


You're right about the printing issue. a page per screen is too much. I 
wonder if there's a way to print on a virtual a5, and have two of those a5's 
appear on a single a4 page.





Lastly, photo
hides the content from search engines, which is not good.



Another alternative that seems cleaner to me would be to code it like this
and let your ahah.js annotate the link for you:

photo
Oh course this last suggestion will probably run me afoul of the
microformat
police since rel="ahah" hasn't even been officially proposed yet and I
didn't bring it up on [uf-new]... ;-P


Give it an id and the script can be robust while you're at it.

I don't like the idea of javascript scraping the page for class names.
Dustin Diaz covers this particular issue very well in
http://www.dustindiaz.com/class-name-widget-philosophy/

While it's convenient, it's slow, demanding, and at high risk of breaking.

If we're going to try to not use the class tag as an identifier for 
javascript functions, the trouble comes in making it easy for people to add 
the script to their page and use it.


The following seems to do the trick.

photo

 

Then the script can get only what it needs, like the anchors, filter through 
them much more rapidly, perhaps with the wonderful forEach technique from 
http://dean.edwards.name/weblog/2006/07/enum/ and add the behavior to those 
elements with something like addEvent from 
http://www.dustindiaz.com/rock-solid-addevent/

(Yeah, more Dustin, he does great stuff)

And if the script uses object notation, like the searchplay object at
http://www.dustindiaz.com/javascript-searchplay/ then there won't have to be 
a

lot of functions like ahahinit, ahahdoit, ahahdone.

It might start to look something like this

// beware, untested code, dragons may be lurking
ahah = {
 init : function() {
   var els = document.getElementsByTagName('a');
   Array.forEach(els, function(el) {
 if ('ahah' == el.getAttribute('rel')) {
   var href = el.getAttribute('href');
   var id = 'ahah-' + el.getAttribute('id');
   addEvent(el, 'click', 'function(){ahah.get("'+href)+'", 
"'+id+'")}');

 }
   }
 },
 get : function(url, target, delay) {
  // code as per normal
 }
};

How close would something like this get to cleaning things up?

--
Paul Wilkins

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

Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)

[Paul Wilkins]

From: "Paul Wilkins" <[EMAIL PROTECTED]>

It might start to look something like this


// beware, untested code, dragons may be lurking
ahah = {
 init : function() {
   var els = document.getElementsByTagName('a');
   Array.forEach(els, function(el) {
 var href = el.getAttribute('href');
 var id = 'ahah-' + el.getAttribute('id');
 addEvent(el, 'click', '');
   });
 },
 get : function(url, target, delay) {
  // code as per normal
 }
};


How close would something like this get to cleaning things up?


--
Paul Wilkins

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

Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)

[Paul Wilkins]

From: "Paul Wilkins" <[EMAIL PROTECTED]>

It might start to look something like this


Note to self, don't post when rushed for time.

// beware, untested code, dragons may be lurking
ahah = {
 init : function() {
   var els = document.getElementsByTagName('a');
   Array.forEach(els, function(el) {
 var href = el.getAttribute('href');
 var id = 'ahah-' + el.getAttribute('id');
 addEvent(el, 'click', 'function(){ahah.get("'+href+'", "'+id+'")');
   });
 },
 get : function(url, target, delay) {
  // code as per normal
 }
};


How close would something like this get to cleaning things up?


--
Paul Wilkins

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

Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)

[Paul Wilkins]

From: "Paul Wilkins" <[EMAIL PROTECTED]>

If I have some time I'll get a fully tested version of this fleshed out.

// beware, untested code, dragons may be lurking
ahah = {
 init : function() {
   var els = document.getElementsByTagName('a');
   Array.forEach(els, function(el) {
 if ('ahah' == el.getAttribute('rel')) {
   var href = el.getAttribute('href');
   var id = 'ahah-' + el.getAttribute('id');
   addEvent(el, 'click', 'function(){ahah.get("'+href+'", 
"'+'ahah-'+id+'")');

 }
   });
 },
 get : function(url, target, delay) {
  // code as per normal
 }
};

How close would something like this get to cleaning things up?

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

Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)

[Paul Wilkins]

nd the bits it needs.



I think it would be a heavy burden to place on a
content author to require them to write the Javascript code he talks about
if they had to tag 10 different segments rather than just scan for . I think these may well be two different use-cases that might
deserve two different approaches.


It would be a heavy burden, so I'm suggesting that the javascript code he 
talks about is moved into the function itself, so that the content author 
just has to bring in the code and apply a rel attribute and a few id 
attributes.


On a similar note, one a partner of mine is would on, how do you feel 
about
scraping a document to find heading tags (H1..H3) so as to build a table 
of

contents?


I know what you're on about because Web Developer already has a View 
Document Outline

http://chrispederick.com/work/webdeveloper/

The biggest issue at hand is if this stuff is happening after the page 
finished loading, that the user received feedback on when these things have 
finished and the page is ready for use. When a page appears on the screen 
people expect to be able to use it immediately. If there is some 5 seconds 
of waiting required (without feedback of some kind) before everything is 
ready, that's where the trouble lies.


Anyway, I'm fundamentally not really a Javascript guy, I'm a URL guy.  So 
my
comments were focused on ensuring the URLs were treated right. If you are 
a

Javascript guy that can optimize that stuff so it is still usable for the
content author, it's all yours!


Dead right, for URLs to work properly the href must link to to a usable 
document. If javascript isn't enabled it'll then still work. If javascript 
is enabled then it can fiddle around and perform its magic, just so long as 
it works and doesn't take too long.


--
Paul Wilkins 


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

Re: [uf-discuss] Formatting arbitrary dates, not part of hCalendar

[Paul Wilkins]

Bob Jonkman wrote:
Hi all:  Today I had the urge to mark up an arbitrary date, not one that is part of 
an hCalendar event, eg.


  Use version 7.0.2 from 5 March 2007

This is to provide some standarization in presenting dates, but keep them human-
readable in arbitrary format.

dtstart and dtend aren't appropriate semantic classes in this example.  Is there a 
proper microformat for arbitrary dates?


No, there isn't a proper microformat, it's more of a design pattern.

Datetime Design Pattern
http://microformats.org/wiki/date

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

Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)

[Paul Wilkins]

Mike Schinkel wrote:

Strange; S5's intro[1] DOES print correctly in outline mode, but Roger's
AHAH slideshow does not. 


Now that *is* an interesting problem.
It appears that Roger uses a separate print stylesheet that forces the 
page break after each slide. Naughty Roger.



At least some of them allow you to supply extra info to
help narrow down and pleed up the search, like
http://www.dustindiaz.com/getelementsbyclass


That looks like a good middle ground.


It is a good middle ground. Let's make the code smarter so that the job 
can be performed faster.



I don't know if you are aware, but I made a big deal about that issue on
this list several months ago but it seemed that most people didn't feel like
my concerns were going to be an issue. So rather than beat a dead horse, I
moved on to work in other areas.  I still monitor this list occassionally,
but not in real time.


Well it'll be a shame to lose your voice on this, because often it is 
the pressure of limitations (such as trying to use less class) that give 
rise to the inspiration for a creative solution.



They *are*are at more of a risk of breaking, but it's the
best solution we have at the moment.


Actually, there are solutions I've proposed I think are better, but they
fell on deaf ears on this list. I can dredge them up again if you like.


Oh yes please, do tell.


Sure thing. Take for example the case where some
webmaster decides to specify the relevance of outgoing
links. He may have a script that goes through adding rel
tags to certain known links and domains, and leave empty
those that it doesn't know about.



Well, that would break all of Microformats and sounds like the problem is
the rogue webmaster not realizing that existing rel tags need to be
maintained.  I can see a potential for such a problem, but in the same
context I can see that webmaster creating far greater problems than just
upseting rel="ahah."


That's right. It was a good reminder that the page as coded isn't the 
same page that ends up with the user. Similar issues are where links are 
given class attributes by some script to achieve different effects, but 
this in turn breaks the class="url" attribute that was on it.


That attribute is still needed, but it does mean that the people writing 
these scripts, and those of us using them, will have to be more careful 
in how they're applied.



Here's a thought (more of a Javascript issue than a microformat issue; we
can take offline is anyone objects): would it be possible to pipeline in a
common file with a single scanner that any such widgets could attach to? (I
don't know Javascript well enough to know the answer to that.)


Yes, it is possible. Instead of getElementsByClassName, you could set up 
an array structure with two elements, the names to be looked for and 
some function to be applied to them. A final script after all the others 
would activate the search so that the page can be processed for the 
items in the array, and then acted upon


So yes, it is possible.


It would be a heavy burden, so I'm suggesting that the
javascript code he talks about is moved into the function
itself, so that the content author just has to bring in
the code and apply a rel attribute and a few id
attributes.


I don't see it.  Can you give code examples?


The code he talks about is where the function accepts arguments which 
contain the elements to be worked upon.


The code sample he gives is

...
var parent = document.getElementById('foo');
var elements = parent.getElementsByTagName('a');
var Fantacy = new Fantasticulator(elements);
Fantacy.init();
...


The thing is, we don't want to content author to have to write this 
code. If the content author isnt to write the code, then the code will 
have to try and find the appropriate parts itself, which will be less 
efficient but still workable.


In our AHAH case, we can have an init section that find the elements and 
passes them on to be attached. The ahah attribute may be attached to any 
anchor, so we need to get all of them from the page.

var els = document.getElementsByTagName('a');

Then we find any with the rel="ahah" attribute,
Array.forEach(els, function(el) {
  if ('ahah' == el.getAttribute('rel')) {

and pass those elements on to a function that does the dirty work of 
attaching the event.

this.attach(el);
  }

Here's some similar code from before that demonstrates this.

ahah = {
 init : function() {
var elements = [];
var els = document.getElementsByTagName('a');
Array.forEach(els, function(el) {
  if ('ahah' == el.getAttribute('rel')) {
this.attach(el);
  }
}
  ),
  attach : function(el) {
var href = el.getAttribute('href');
var id = 'ahah-' + el.getAttribute('id');
addEvent(el, 'click', 'function(){ahah.get("'+href+'", 
"'+'ahah-'+id+'")');

  }
);


The biggest issue at hand is if this stuff is happening
after the page finished loading, that the user received
feedback on when these

Re: [uf-discuss] Scraping or parsing?

[Paul Wilkins]

From: "Mike Schinkel" <[EMAIL PROTECTED]>
I have a book in my hands "Definitive XML Schema" written in 2001, 
published

in 2002 and it discussed Namespaces in depth. The recommendation may have
been last year, but it was not last year that the technology was available
for people to use.

And the fact that the major browsers can incorporate technology is an
example of the Herculean effort from vested interests that I discussed. I
don't know any mere mortal content author who can get the logic of XML
Namespaces (after studying them on and off for six months, I gave up on
them, and I'll challenge anyone on this list to be able to author a valid
XML document that contains complex schema right without having to run
through validation to debug it first.)


I may take you up on that challenge, but what do you mean by "complex 
schema"?


My primary understanding of namespaces is that they're to help programmers 
get the information then need.


So we could have an hCard namespace, and attach it to everything that is 
hCard.

   xmlns:xhc="http://www.microformats.org/wiki/hcard";

Which should look something like this.


http://www.w3.org/1999/xhtml";
 xmlns:xhc="http://www.microformats.org/wiki/hcard";>
Ryan's banana fixation


 http://ryancannon.com/"; class="bar">
   Ryan Cannon
   is a Scorpio.




--
Paul Wilkins 


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

Re: [uf-discuss] Formatting arbitrary dates, not part of hCalendar

[Paul Wilkins]

From: "James Craig" <[EMAIL PROTECTED]>
In this case, I think what you are looking for is the 'datetime' 
attribute on INS and DEL elements.


5 March 2007

This has nothing to do with microformats; it's just semantic HTML. It 
specifies the time of the insertion or deletion, so I think it's  quite 
appropriate for specifying when a version was released.


While it specifies the time of insertion or deletion, the semantics of that 
don't match up with what we're wanting to do here. The INS and DEL elements 
are supposed to markup changes to the document, with respect to a different 
version of that document. So for example, INS is marked up with underlines, 
and DEL is marked with a line-through.


Yes it's possible to get around the presentation issues by negating the 
style that INS and DEL are presented with, but this is counterproductive to 
other more correct use of those elements.


Unfortunately here we have a case similar to BLOCKQUOTE, where an element is 
used for a purpose that it's was never intended for, and that new purpose 
eliminates reasonable chances of its actual intended use.


--
Paul Wilkins 


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

Re: [uf-discuss] Formatting arbitrary dates, not part of hCalendar

[Paul Wilkins]

From: "James Craig" <[EMAIL PROTECTED]>
While it specifies the time of insertion or deletion, the semantics  of 
that don't match up with what we're wanting to do here.


Unless you and Bob are working on that project together, the  semantics of 
the use can only be determined by Bob.


The semantics of proper use have already been determined. Would you use 
tables to markup the layout of a webpage, or blockquote to indent text? 
Using ins or del to markup when their content changed (and possibly from 
what) is a similar issue.



The INS and DEL elements are supposed to markup changes to the  document


Yes, and the line in question referred to a specific date when that  copy 
was inserted OR when that line of text became relevant due to  the release 
of the new version of software.


So it's not the date that's the relevant part, it's the software release 
instead.


I disagree. By your logic, use of DL as a data structure in XOXO  would 
also be a misuse because it's key:value data pairs instead of  an actual 
definition term and description.


That falls within the defined use of the element as it doesnt have to be 
term and description. It can also be for marking up dialogues, along with 
other similar applications.


I'll save the list the  semantics argument, but I believe this is well 
within the proper use  of INS.



To use INS just to provide a machine-friendly translation of a date/time, 
that's a no-no.


In the context of what's going on here, as it's not the date that's changed 
but the version of the software itself, marking up the date isn't the right 
approach here. The software release itself should be marked up instead.


The best possible markup for using INS in this case would be
Use title="bugfix">version 7.0.2 from 5 March 2007


--
Paul Wilkins 


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

Re: [uf-discuss] Formatting arbitrary dates, not part of hCalendar

[Paul Wilkins]

From: "James Craig" <[EMAIL PROTECTED]>

Given that, you might also want to specify the URI for version changes.

Use version  7.0.2 
from 5 March 2007.


My apologies James, I see that we're both approaching the same answer from 
different reasons.


I'm wanting to avoid using INS as a datetime design pattern, and instead use 
it properly as you have above to markup a change to the code version.


--
Paul Wilkins 


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

Re: [uf-discuss] hCal issues: organizer=vCard and value concatenation

[Paul Wilkins]

Scott Reynen wrote:
My main problem is the class="vcard organizer".  The hCal spec [1]  says 
"ORGANIZER in iCalendar may be represented by an hCard in  hCalendar," 
so that's what I'm doing.  I want the class="fn org" to  be part of the 
vCard, so I need to wrap the vCard around both the   and the , 
which I can do in the vCard without the date being  included, as the 
date isn't wrapped in any vcard properties.  But the  two hCal->vCal 
parsers I've tried (X2V and a bookmarklet in Safari of  a source I can't 
presently remember) both include "March 6th, 2007  at" as part of the 
organizer, even though it's not part of the  vCard.  Is this behavior 
correct?


It depends on what's meant by correct.
Is it what's supposed to be done given the knowledge we know have 
available? Sure thing! Is it what's being supported by the existing 
tools out there, not a chance.


Attendee and Organizer are currently defined as email addresses. Using a 
vcard as the attendee is still in development and to be discussed.

http://microformats.org/wiki/hcalendar-brainstorming#Undecided_Encodings_of_Certain_Property_Attributes

When X2V interprets the hCalendar, it uses the existing mailto format 
and extracts everything inside of attendee.


ATTENDEE:MAILTO:Valient Thorr at 8:00 pm w/ Fu Manchu Fu Manchu at 8:30 
pm w/ Valient Thorr\, Artimus Pyledriver


We can tidy that part up by moving the organizer and attendee to their 
most appropriate parts, like their website or failing that, their name


ATTENDEE:MAILTO://myspace.com/valientthorr



My second issue is with class="description" and class="value".  I was  
hoping the class="value" would restrict the description to just  
concatenations of those nodes, as the hCard parsing [2] suggests:


But that doesn't happen.  Is there a reason this is only applied to  
hCard and not hCalendar, or even all microformats?  It would also be  
nice to be able to do concatenation using class="value" with the  
dtstart and dtend as well, as my date and time are somewhat distant  in 
this markup.


The trouble comes when the computer tries to work out what property to 
assigen those values to.


hCalendar Parsing hasn't been defined yet, so it's still in flux.
In this case you're wanting to join together the names of both bands and 
have them on the mailto field called attendee. There are many problems 
with this, so the best options are to either provide an actual email 
address, or a link to their webpage.



	March 6th, 2007 at The Black Sheep
	Colorado Springs, class="region">CO



http://myspace.com/valientthorr"; 
class="attendee">Valient Thorr at
title="2007-03-06T20:00:00-08:00">8:00 pm

w/ Fu Manchu


http://myspace.com/fumanchu"; 
class="attendee">Fu Manchu at
8:30 
pm

w/ Valient Thorr, Artimus Pyledriver




The info extracted from this is

BEGIN:VCALENDAR
X-WR-CALNAME;CHARSET=utf-8:Untitled Document
VERSION:2.0
METHOD:PUBLISH
BEGIN:VEVENT
DESCRIPTION;CHARSET=utf-8:Valient Thorr at 8:00 pm \n w/ Fu Manchu \n\n 
\n Fu Manchu at 8:30 pm \n w/ Valient Thorr, Artimus Pyledriver \n\n \n

SUMMARY;CHARSET=utf-8:March 6th\, 2007 at The Black Sheep
DTSTART;VALUE=DATE-TIME:20070307T04Z
DTEND;VALUE=DATE-TIME:20070307T053000Z
ATTENDEE:MAILTO://myspace.com/valientthorr
ATTENDEE:MAILTO://myspace.com/fumanchu
ORGANIZER:MAILTO:The Black Sheep
END:VEVENT
END:VCALENDAR

It's still going to be officially wrong, but it's the best you're likely 
to do for now.



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

Re: [uf-discuss] Formatting arbitrary dates, not part of hCalendar

[Paul Wilkins]

Bob Jonkman wrote:

Erm, neither.  My usage isn't meant to refer to a change in the document in which it appears 
(ruling out the semantic use of  and ), nor is it meant to refer to software 
releases in particular. Let me try again:


 Today I bought an old 
 newspaper from 2 July 2006


These are arbitrary dates, NOT related to the publishing date of the document it appears in, 
not related to any resources such as a software release.  I simply want dates occuring within 
prose to be recognized as machine-readable dates.  This is for both for screen readers and 
disabiguation of dates such as 3/2/2006 or 02-03-06.  It's also useful when quoting text with 
poorly formatted dates, without altering the presentation of the original quote, eg.


 The Constitution of 4/7/76
 



From what James was saying before, screen readers are going to 
misbehave with that kind of design pattern.
For abbr to be used, the information in the title has to be more 
meaningful to the human, than the information contained within.


Andy Mabbett suggested a class of "dtstamp" which comes closer to what I intend, but the 
iCalendar property DTSTAMP is specifically meant to indicate when an iCalendar object was 
created, which is not the case here.


Following the design pattern for dates, I think we need a semantic classname such as 
"datetime" which James Craig pointed out is an attribute for  and 


 March 2, 2006

Does such a classname for an arbitrary date/time already exist?  
 



Not for an arbitrary one. See 
http://microformats.org/wiki/naming-principles#dt_properties


A difficulty that I see here is that the abbr for March 2, 2006 doesn't 
disambiguate. It's perfectly clear what's going on in that particular case.


With the previous example, you might write the date as 4/7/76 and force 
the reader to find and use the abbreviation, but as someone who cares 
enough to create a datetime design pattern, it should be obvious that 
writing the date as July 4, 1776 solves the problem.


Another trouble is that with the arbitrary datetime pattern in use, how 
can the machine benefit from that information. It's not immediately clear.


So I have to ask, if the text can be more easily rewritten to be 
clearer, and the abbr element isn't going to allow the information to be 
processed by some program, then are we just creating a microformat here 
just for the sake of creating one?


Steps one and two of the microformat principles 
http://microformats.org/wiki/microformats#the_microformats_principles are

* Solve a specific problem
* Start as simple as possible

Problem. Date 02-03-06 can be misunderstood.
Solution: Write the date as March 2, 2006 or 2nd of March, 2006


--
Paul Mark Wilkins
New Zealand Tourism Online
[EMAIL PROTECTED] 
109 Tuam Street
Level 1
Christchurch 8011
New Zealand
+64 3 963 5039
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Formatting arbitrary dates, not part of hCalendar

[Paul Wilkins]

Bob Jonkman wrote:

I simply want dates occuring within 
prose to be recognized as machine-readable dates.




Why do you want them to eb recognised as machine readable dates? What 
problem will it solve for the machines?


This is for both for screen readers and 
disabiguation of dates such as 3/2/2006 or 02-03-06.




As I'm to believe, screen readers will read out both parts of the date 
information. As such, having the title as 4 July 1776 will mean the 
screen reader will read

"The Constitution of 4 7 76 4 July 1776"

It's also useful when quoting text with 
poorly formatted dates, without altering the presentation of the original quote, eg.


 The Constitution of 4/7/76
 



That is the one example in which the abbr element could be usefully used.

The abbr element doesn't require a class, because there is no problem 
that having such a format will currently solve. The microformat 
principles mention something similar, in that "Lots of corporate 
inventors working with plenty of experience, over-designing a format for 
what //might// be needed some day."

http://microformats.org/wiki/microformats#the_microformats_principles

As the title is currently for screen readers or to disambiguate the 
date, it should be kept in a human understandable format.

The Constitution of 4/7/76

There is some very useful information from the Manual of Style on the 
formatting of dates and numbers.

http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_%28dates_and_numbers%29

The following is a direct quote of the relevant parts.


 Incorrect date formats

   * Do not use numbers to express a month, except in ISO 8601 format.
 Always express a month as a whole word (e.g. "February" /not/
 "2"). Do not use abbreviations like "Feb" unless the available
 space is extremely limited, such as in a table, infobox, or the like.
   * Do not use two digits to express a year unless at the end of a
 range, e.g., "1970–87" (the same for BC). In all other cases, use
 four digits for years and decades after AD 999 (the same for BC).
 Using the less formal two-digit form for a decade is acceptable
 when not ambiguous; for example, when referring to the decade of
 the 20th century known as "the eighties", use "1980s" or, less
 often, "the '80s", not just "80s".

   * Use consistent date formatting throughout an article, unless there
 is a good reason to vary it.

   * Do not use ordinal suffixes:
 o Incorrect: "February 14th" and "14th February"
 o Correct: "February 14" and "14 February"

   * Do not use articles:
 o Incorrect: "the 14th of February"
 o Correct: "February 14" and "14 February"

   * Do not put a comma or the word "of" between a month and year:
 o Incorrect: "December, 1945" and "December of 1945"
 o Correct: "December 1945"

   * Do not use an apostrophe to indicate a decade:
 o Incorrect: 1970's
 o Correct: 1970s


 Direct quotations

An important exception to these guidelines is that direct quotations—the 
word-for-word reproduction of a written or oral text—should /not/ be 
altered to conform to the Wikipedia "Manual of Style". In other words, a 
paragraph such as this (fictional) quotation from a newspaper report is 
fine as is:


   "Tony Blair, responding to critics in his party, said 'The world has
   totally changed since the 11th of September.' He was echoing earlier
   sentiments by Lord Ronald McDonald, who said that 'nine-eleven' was
   the day that the American public woke up to the reality of terrorism."



--
Paul Mark Wilkins
New Zealand Tourism Online
[EMAIL PROTECTED] 
109 Tuam Street
Level 1
Christchurch 8011
New Zealand
+64 3 963 5039
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] hCite elevator pitch and my bibliography generator

[Paul Wilkins]

Henri Sivonen wrote:

I needed a .bib-based bibliography generator for XHTML, so I wrote  
one with help from a friend who had developed a .bib parser. The  
output of my generator can be seen at

http://hsivonen.iki.fi/thesis/html5-conformance-checker.xhtml#references

I've wrapped the values of .bib fields in elements whose class name  
is the .bib field name. I did it just in case. I don't have any  
consumer use case for those class names. It was just super-easy to  
generate them.


My use case (publishing an academic paper with a bibliography) is not  
mentioned as a use case at
http://microformats.org/wiki/citation-brainstorming . More to the  
point, the wiki has no consumer use case for my publication use case.


Does this mean that hCite is not for me at all?



Not at all. You are using the BibTex format, which is covered in the 
citation formats http://microformats.org/wiki/citation-formats


If hCite is for me, what's the elevator pitch convincing me to put  
more effort into my generator? What benefits should I expect if I do?  
Is hCite mature enough to be implemented yet?



The citation microformat is a work in progress at this stage, so it's 
not mature enough for programs to extract information from it, yet 
examples of current use are being asked for at 
http://microformats.org/wiki/citation-examples so that most popular uses 
will be catered for.


The benefits are that people visitng your content with next generation 
tools wil be able to easily extract and use the information in more 
interesting and useful ways.
Tantek has a recent presentation about the big picture of microformats 
at http://tantek.com/presentations/2007/02/microformats/


Moreover, is it even possible to generate hCite from my source data  
(http://hsivonen.iki.fi/thesis/dippa.bib) without sacrificing the  
presentation that I want and without potentially generating bogus  
markup for personal names?



One of the big ideas behind the use of microformats is that it will 
allow you to markup the content on your page without modifying the 
presentation of it.


For example, my source data does not  encode explicitly the given 
name, the family name and other stuff  that isn't quite neither. As 
far as I can tell, it is impossible to  tell heuristically that the 
middle token in these two names is  semantically different:

Gavin Thomas Nicol
Henrik Frystyk Nielsen



Those issues haven't yet been covered for for the citation microformat.

It may be possible for for a generator to parse through them and extract 
the appropriate information though.
For example, honorific-prefix and honorific-suffix are a rather short 
list. Then after those, the given name, family name and additional name 
could be extracted in that particular order.


--
Paul Mark Wilkins
New Zealand Tourism Online
[EMAIL PROTECTED] 
109 Tuam Street
Level 1
Christchurch 8011
New Zealand
+64 3 963 5039
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] hCard email & type properties

[Paul Wilkins]

Kim Franch wrote:


My confusion comes when trying to impliment email types. I used the
following markup:


 
   Email FooBar
 




The markup appears to be correct, as when your code is added to an hcard 
with a test name, the tool at http://suda.co.uk/projects/X2V/ pulls out 
the correct information.


The type of internet and preferred aren't necessary, as internet is the 
default email type, and as there is only one email address listed for 
them, there is strictly no preferred one to refer to.



From what I've read through, I believed this would be correct, while
keeping markup to a minimum. However, checking my hcard markup using
the Tails & Operator Firefox extensions proved troublesome in the fact
that when exporting the cards 'Email FooBar' showed up as the email
address instead of [EMAIL PROTECTED] Tails would show the correct email
address in the sidebar, but not in the exportation.

I realise that potential issues with these extentions are outside the
scope of this list; I would appreiciate, though, comment or
suggestions on the above markup.



What you may be facing is that some tools aren't as of yet fully complete.
As an example, Operator is an alpha release right now, and doesn't 
appear to support some abbr design patterns.


The most up-to-date one typically being http://suda.co.uk/projects/X2V/



--
Paul Mark Wilkins
New Zealand Tourism Online
[EMAIL PROTECTED] 
109 Tuam Street
Level 1
Christchurch 8011
New Zealand
+64 3 963 5039
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] An Inconvenient hCard

[Paul Wilkins]

From: "Ara Pehlivanian" <[EMAIL PROTECTED]>

I've got a bit of a problem with an hCard that I need to mark up and I
was wondering if anyone could lend me a hand.

I realize the syntax requires that a type be specified for telephone
numbers ("voice", "fax", etc...) and that's where my problem lies.
It's inconvenient to have the word "voice" appear in the markup
because that's not how the convention (at least in this neck of the
woods) is when writing out contact information. The final display
should be:

Tel.: (514) 123-4567
Fax: (514) 123-4568

Yet with the required "voice"/"fax" types it ends up like this:

Voice Tel.: (514) 123-4567
Fax Fax: (514) 123-4568





So, dear Microformats community, please lend me a hand and help me
unravel this conundrum of mine.


Good news, the voice type is the default one, so you don't have to specify 
the voice type at all, and only specify for the fax (in this case).


With that, you can have
Tel: (514) 123-4567
Fax: (514) 
123-4568


--
Paul Wilkins 


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

Re: [uf-discuss] An Inconvenient hCard

[Paul Wilkins]

From: "Paul Wilkins" <[EMAIL PROTECTED]>

With that, you can have
Tel: (514) 123-4567
Fax: (514) 
123-4568


Correction:
Tel: (514) 123-4567
Fax: (514)
123-4568

The good thing about keeping the tel class in the paragraph is that if the 
type and value aren't yet understood by a parser, the appropriate content 
will still make it through.


--
Paul Wilkins 


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

Re: [uf-discuss] An Inconvenient hCard

[Paul Wilkins]

From: "Ara Pehlivanian" <[EMAIL PROTECTED]>

On 3/11/07, Paul Wilkins <[EMAIL PROTECTED]> wrote:
Good news, the voice type is the default one, so you don't have to 
specify

the voice type at all, and only specify for the fax (in this case).

With that, you can have
Tel: (514) 123-4567
Fax: (514)
123-4568


Thanks Paul. That's really helpful.

Any ideas about internationalization? How would I handle "fax" in
French? I doubt that "Télécopieur" would be a valid type, since RFC
2426 doesn't seem to be geared toward types in other languages.


If the word doesn't appear in the expected english (yeah I know, us damned 
english) then you would have to use the abbr design pattern.


With the abbr design pattern, you encode the machine-readable info around 
the human-readable words.
Téléc: class="value">(514) 123-4568


http://microformats.org/wiki/abbr-design-pattern has more details on the 
abbre design pattern.


--
Paul Wilkins 


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

Re: [uf-discuss] hCard email & type properties

[Paul Wilkins]

From: "Mike Kaply" <[EMAIL PROTECTED]>

On 3/11/07, Kim Franch <[EMAIL PROTECTED]> wrote:


  
Email FooBar
  



This markup is incorrect. title can only be used with an abbr - the
title on a span wont work.


Also, if it's email or uri, it will automatically be internet, and if it's 
the only one of its type there, then you have no preferance (pref) as it's 
the only possible choice.



Why aren't you just using a mailto?


I suspect because he wants people to be directed to a page where they can 
get in touch, instead.




  FooBar Webpage



This works for me in the the current operator. I don't understand why
you are using this pattern though? Why not just have a anchor that
points to the web page?


Perhaps he wants to be a sneaky bastard (tm) and take people to a different 
version of the website (perhaps a wrapper) while allowing the real website 
name to be used by people and tools too.


--
Paul Wilkins 


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

Re: [uf-discuss] hCard email & type properties

[Paul Wilkins]

From: "Scott Reynen" <[EMAIL PROTECTED]>

The inital problem I encountered with both propeties stemmed from the
fact that I hook into another Drupal module for link managment and
click-through tracking, the latter using a redirect after logging the
click-through.


So the goal is to have the href attributes point to click-tracking  URLs, 
but have microformat parsers read the original URLs.  Even  though this is 
possible (as others have explained), it seems to  violate the microformat 
principle of designing for humans first,  machines second.  In this case, 
machines are getting more useful  links than humans.


Why not then have the normal URL in the markup then use an onmousedown event 
to update the URL to be what it should with the clickthrough tracking?


--
Paul Wilkins 


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

Re: [uf-discuss] An Inconvenient hCard

[Paul Wilkins]

James Craig wrote:


Paul Wilkins wrote:

With the abbr design pattern, you encode the machine-readable info  
around the human-readable words.
Téléc: class="value">(514) 123-4568


http://microformats.org/wiki/abbr-design-pattern has more details  on 
the abbre design pattern.



This is a misuse of abbr at best.

See: open issue! 2007-01-26
http://microformats.org/wiki/hcard-issues



I also see that you are the author of that open issue, and that it's 
been rejected.


The abbr design pattern is the currently accepted microformat method in 
which to provide machine readable information for human readable content,
as it's defined in the TEL Type Definition at 
http://www.microformats.org/wiki/hcard-examples#3.3.1_TEL_Type_Definition



my 
work 
phone, with 
voicemail:

+1-213-555-1234



While the abbr element isn't being used strictly as it was originally 
intended, there are sufficient grounds to continue using it for the 
purpose of microformats.


The purpose of the abbr design pattern is formally to
- to make text that is human readable also formally machine readable

So in this case, the "Téléc" is readable to (french) humans, while the 
title="fax" is machine readable
Téléc: class="value">(514) 123-4568


The stated situations where the abbr design pattern is to be avoided is 
when it's used

- to re-encode human text or to hide data

Which would make the following an incorrect use, as the type is being 
hidden from view

(514) 123-4568

I have yet to find a succinct example of re-encoding human text.

Other solutions that have been tempting have been the use of namespaces, 
but they have long been considered to be harmful.

So failing that, what else comes even close? The DFN element?

--
Paul Wilkins


--
Paul Mark Wilkins
New Zealand Tourism Online
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
109 Tuam Street
Level 1
Christchurch 8011
New Zealand
+64 3 963 5039
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Geo Elevation Data

[Paul Wilkins]

From: "Jon Clausen" <[EMAIL PROTECTED]>

I apologize if this has been been discussed before.  I browsed through
the wiki and the list archives and couldn't find any relevant threads
or pages.   So I joined the list to ask :-)


Hi Jon, thakns for joining. It's always useful to receive more input on 
these things.



I'm developing an app that makes heavy use of geo-spatial data, both
lines and points.  I'd like to incorporate the geo microformat for
points, at minimum, however the coordinate data also includes the
z-index (elevation) as well.

My first question is whether elevation has been proposed as part of
the geo draft specification?  Adding the third dimension would seem
natural and would add additional precision when adopted.


Unfortunately the third dimension is being rejected at this time. However, 
if the vCard spec is updated to include an altitude component, then it will 
definately become a part of the hCard spec too.

http://microformats.org/wiki/hcard-issues

If it does get decided to add an altitude component,  it'll be explored 
first on the brainstoming section.

http://microformats.org/wiki/hcard-brainstorming#geo_improvements
But at this particular stage, extensions to hCard/vCard are being currently 
rejected.



My second question is whether or not, for line data, it is acceptable
to include multiple latitude and longitude classes, in sequence, which
make up the line in sequence or if there is a better way to do it?


What kind of use do you envisage web tools being able to use that line 
sequence information for?


This may be a case where something greater than the Geo microformat (which 
is point specific) is required.


--
Paul Wilkins 


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

Re: [uf-discuss] An Inconvenient hCard

[Paul Wilkins]

Tim White wrote:


- Original Message 

From Ara


On 3/12/07, James Craig <[EMAIL PROTECTED]> wrote:
 


Paul Wilkins wrote:

   


With the abbr design pattern, you encode the machine-readable info
around the human-readable words.
Téléc: (514) 123-4568
 



 


This is a misuse of abbr at best.

See: open issue! 2007-01-26
http://microformats.org/wiki/hcard-issues
   



 

Okay, so what does a guy do in a case like this then? 
   



What about something along the lines of: 


Telec: (514) 
123-4568

Title is a valid HTML attribute and this avoids abusing the . 
 



The possibility of using the title attribute to hold generic machine 
readable information was considered and rejected.


The title attribute is already commonly used on many elements today. If 
people were to add a microformat to their page, they would have to 
remove all title attributed content except for that which they 
specifically intended to be the machine readable information. This then 
becomes an abuse of the title attribute and as such is not allowed.


Another reason for discarding the idea was that it makes it too easy for 
people then to hide information. If someone is not willing to make the 
information available in plain text, then that information shouldn't be 
used.This is why we people shouldn't be encouraged to store information 
invisibly because that just leads to bad things.


Restricting the title attribute for microformatted information to just 
the abbr element itself was considered and allowed, because that element 
at least, is purpose built to show a different representation of the 
information within it, and that's why it's become so useful with dates 
and other content, to allow human readable content with a machine 
understandable representation.


When it comes to languages other than English though, this is where 
things get tricky, and is covered in the FAQ at 
http://microformats.org/wiki/faq#Q:_How_do_microformats_breach_language_barriers.3F

Effectively, the language barrier is a pre-existing unsolved problem.

While it's fine for class names to be represented in English, what 
happens when the readable content is used as keyword data. We are left 
with one of two options. Either the readable data needs to remain as 
English, or some other way needs to be found to provide a representation 
of that non-english data in an english form.


Currently there hasn't been a more appropriate answer to this than the 
abbr design pattern, and it is possible to justify. The computer is able 
to understand only a very small number of terms, and each of those terms 
can be expressed in a wide number of human readable formats. So what 
we're doing with the abbr design pattern is to take one of these vast 
number of human readable formats and abbreviate all of those 
possibilities down to one common computer understandable term.


Téléc:

The only viable alternatives are either to spell it out in full,

Téléc (Fax):

Or to hide the english form of the word

Téléc Fax:

This is one of those situations where whateveryou do, you're guilty of 
something.


--
Paul Mark Wilkins
New Zealand Tourism Online
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
109 Tuam Street
Level 1
Christchurch 8011
New Zealand
+64 3 963 5039
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] hCard email & type properties

[Paul Wilkins]

From: "Kim Franch" <[EMAIL PROTECTED]>

Point taken. Thank you for the further explaination Scott. Back to the
drawing board for me.


What we've taken to doing is to provide the proper url in the href, so that 
tools can make good use of it, and use the onmousedown event, so that should 
someone click on it, the url is rewritten to incorporate clickthrough data.



function clickthru(this, click) {
   // this.href = whatever rewrite is required
}



--
Paul Wilkins 


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

Re: [uf-discuss] Logging information

[Paul Wilkins]

From: "LuigiG" <[EMAIL PROTECTED]>

is there a microformat specification for
application/server logs? 
Typical structure:


[DTM stamp] [Severity] [Message]

Example:

2007-03-03.13:43:21 INFO Server was started

But then with each element tagged with an appropriate
class.


What is the problem that you require a solution for?

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

Re: [uf-discuss] include pattern : including table data

[Paul Wilkins]

From: "Alwin Blok" <[EMAIL PROTECTED]>

I have a question about the include pattern:
anchor elements are not allowed in all elements: ie using an anchor 
element to include extra table data (rows) will result in invalid  xhtml. 
ie.  is  not valid.


I suppose we could work around this by using the title attribute  along 
with the class="include" on almost all elements.
ie.   is 
valid.


The title attribute set too "#an_id", however does not indicate a 
reference to an other element, which is a problem. Any thoughts/ 
suggestions ?


The include pattern is not going to change how information is presented on 
the screen.
The purpose of the include pattern is to allow you to reuse microformat 
information that's already on the page. The only effect that the include 
pattern has is on parsers looking through the page for microformat 
information.


For example, if you have information that an hcard could use, then later on 
in the page you have address details for them, their first hcard information 
can be reused (when microformat info is extracted) without having to 
redisplay that info on the page again.


Paul Wilkins
... other stuff ...
The place where I 
live is 123 Evergreen 
Terrace.


If you can provide an example of what you're wanting to display on the page, 
we can then help with examples of how to effectively mark it up as a 
microformat.


--
Paul Wilkins 


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

Re: [uf-discuss] Formatting arbitrary dates, not part of hCalendar

[Paul Wilkins]

Andy Mabbett wrote:

Paul Wilkins writes
Our responsibility is to publish valid, semantically-meaningful markup, 
not to pander to the former.


As the title is currently for screen readers or to disambiguate the 
date, it should be kept in a human understandable format.

The Constitution of 4/7/76


Then why doesn't that apply to dtstart and dtend, for example?


If we intend for a microformat to also understand what's going on, we 
should disambiguate the title even further.


The Constitution of 4/7/76

As long as the quotation is left unchanged, the additional information 
is provided in a means that clearly disambiguates for the intended audience.


There is some very useful information from the Manual of Style on the 
formatting of dates and numbers.

http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_%28dates_and_numb
ers%29

The following is a direct quote of the relevant parts.


Incorrect date formats


[...]

That's "incorrect" according to the pretences of Wikipedia's 
administrators; not by any other authority.


There are a number of style guides to pick from. The message I wanted to 
get across is to try to ensure that it's consistant, for whichever style 
you pick. That's what the wikipedia group are wanting to achieve and 
they appear to have a very clear understanding of online writing style.



--
  Paul Mark Wilkins
New Zealand Tourism Online
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
109 Tuam Street
Level 1
Christchurch 8011
New Zealand
+64 3 963 5039
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Formatting arbitrary dates, not part of hCalendar

[Paul Wilkins]

Andy Mabbett wrote:

In message
<[EMAIL PROTECTED]>, Ara
Pehlivanian <[EMAIL PROTECTED]> writes



I've always had trouble with the idea of using  to mark up dates
because semantically, it isn't expressing an abbreviation of any sort.



That's particularly true of:

30 March

which is an abomination (and an accessibility disaster) which I have
vowed ever to use on web pages under my control.


There is a nice way out of this mess though. Provide a time instead of a 
date and dtend can then end on whatever correct day you desire.


30 March

Unfortunately it's not microformats to blame there, as the microformat 
itself is mirroring to as great an accuracy as possible the already 
defined behaviour for internet calendaring and scheduling as set out by 
Apple in RFC 2445.


The "DTEND" property for a "VEVENT" calendar component specifies 
the non-inclusive end of the event.


When a date only is provided, it's assumed that the time is at midnight. 
For events that are specified in terms of days, and not time, the end 
date is the non-inclusive date.


If an event goes for one day, saying they start and stop on the same day 
 uses the presumption of a midnight time, so for an event to last for 
one day, the end *has* to be on the day after.


This is why the RFC for internet calendaring and scheduling defines 
dtend as being a non-inclusive date.


The RFC for internet calendaring and scheduling is at
http://www.ietf.org/rfc/rfc2445.txt

   The "DTSTART" property for a "VEVENT" specifies the inclusive start
   of the event. For recurring events, it also specifies the very first
   instance in the recurrence set. The "DTEND" property for a "VEVENT"
   calendar component specifies the non-inclusive end of the event. For
   cases where a "VEVENT" calendar component specifies a "DTSTART"
   property with a DATE data type but no "DTEND" property, the events
   non-inclusive end is the end of the calendar date specified by the
   "DTSTART" property. For cases where a "VEVENT" calendar component
   specifies a "DTSTART" property with a DATE-TIME data type but no
   "DTEND" property, the event ends on the same calendar date and time
   of day specified by the "DTSTART" property.


--
Paul Mark Wilkins
New Zealand Tourism Online
[EMAIL PROTECTED] 
109 Tuam Street
Level 1
Christchurch 8011
New Zealand
+64 3 963 5039
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] An Inconvenient hCard

[Paul Wilkins]

Andy Mabbett wrote:
Can you cite evidence that it's "currently accepted" for non-English 
content, as in the above example; or clarify those "sufficient grounds" 
for its use in such cases, please?


This would be the first defining instance of such a use.

If there are other currently accepted methods for providing non-english 
content with machine readable information, they can be looked in to as well.


What methods are out there that provide an english term that means the 
same as the non-english word or phrase?


All Ara wants is for his fax number to be accepted when the fax name is 
spelled out in French instead of English.


What tools do we have to provide an english term for the parser to 
understand?


How do we make the following understandable by the microformat system?

Tél: (514) 123-4567
Téléc: (514) 123-4568

--
  Paul Mark Wilkins
New Zealand Tourism Online
[EMAIL PROTECTED] 
109 Tuam Street
Level 1
Christchurch 8011
New Zealand
+64 3 963 5039
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] An Inconvenient hCard

[Paul Wilkins]

Andy Mabbett wrote:

Ara Pehlivanian writes


Voice Tél.: (514) 123-4567
Fax Téléc.: (514) 123-4568



Tél

Téléc

Though there are concerns that that's an abuse of "abbr".


There is a possible alternative, inspired from 
http://microformats.org/wiki/hcard-faq#How_do_you_create_non_English_tooltips


Fax:

If abbr is considered to be too semantically incorrect, it's the only 
other currently viable method where the native language term is revealed 
in a tooltip.


--
Paul Mark Wilkins
New Zealand Tourism Online
[EMAIL PROTECTED] 
109 Tuam Street
Level 1
Christchurch 8011
New Zealand
+64 3 963 5039
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] An Inconvenient hCard

[Paul Wilkins]

From: "Paul Wilkins" <[EMAIL PROTECTED]>

Andy Mabbett wrote:

Ara Pehlivanian writes


Voice Tél.: (514) 123-4567
Fax Téléc.: (514) 123-4568


Tél

Téléc

Though there are concerns that that's an abuse of "abbr".


There is a possible alternative, inspired from 
http://microformats.org/wiki/hcard-faq#How_do_you_create_non_English_tooltips


Fax:


Additionally, there is an existing example of ABBR used for telephones

3.3.1 TEL Type Definition at
http://microformats.org/wiki/hcard-examples#3.3.1_TEL_Type_Definition


my
work
phone, with
voicemail:
+1-213-555-1234


This is an existing microformat example where abbr is used to provide
machine understandable terms for human readable content.

How great is the difference between that and these examples

phone
tel
Tél
Téléc

I say that because of the abbr use in TEL Type Definition, it is acceptable 
use to use abbr to provide microformat terms for non-understandable content.


-- Paul Wilkins

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

Re: [uf-discuss] An Inconvenient hCard

[Paul Wilkins]

Ryan King wrote:
> On Mar 11, 2007, at 6:06 PM, Ara Pehlivanian wrote:
>
>> I've got a bit of a problem with an hCard that I need to mark up and
>> I was wondering if anyone could lend me a hand.
>
> Type is not required.

Thanks for the reality check Ryan.

With you knowledge and experience of microformats, do you have some 
advice for Ara on how to to markup the following example so that the 
appropriate fax numbers can be given the appropriate type as a fax number?


Tél.: (514) 123-4567
Téléc.: (514) 123-4568

--
Paul Wilkins

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

Re: [uf-discuss] An Inconvenient hCard

[Paul Wilkins]

From: "Ara Pehlivanian" <[EMAIL PROTECTED]>
To: "Microformats Discuss" 
Sent: Monday, March 12, 2007 1:06 PM
Subject: [uf-discuss] An Inconvenient hCard



I've got a bit of a problem with an hCard that I need to mark up and I
was wondering if anyone could lend me a hand.

I realize the syntax requires that a type be specified for telephone
numbers ("voice", "fax", etc...) and that's where my problem lies.
It's inconvenient to have the word "voice" appear in the markup
because that's not how the convention (at least in this neck of the
woods) is when writing out contact information. The final display
should be:

Tel.: (514) 123-4567
Fax: (514) 123-4568

Yet with the required "voice"/"fax" types it ends up like this:

Voice Tel.: (514) 123-4567
Fax Fax: (514) 123-4568

or in the French version of the page:

Voice Tél.: (514) 123-4567
Fax Téléc.: (514) 123-4568

I realize that it's simple enough to just hide the types via CSS, but
being the strict standards advocate that I am, I don't like entangling
the structural layer with the presentational one by making it
dependent on it. The idea of superfluous words littering my markup
without proper grammatical consideration doesn't sit well with me.

I thought of doing something like this:

Tel.: (514) 123-4567 (Voice)
Fax: (514) 123-4567 (Fax)

or in the French:

Tél.: (514) 123-4567 (Voice)
Téléc.: (514) 123-4568 (Fax)

But it's redundant in English and nonsensical in French.

So, dear Microformats community, please lend me a hand and help me
unravel this conundrum of mine.


I have a creative solution here for you, inspired from
Fax Téléc.: (514) 123-4568

If the page is in a foriegn language, such as French, you really should mark 
up non-French words with the appropriate language attribute

HTML - lang
XHTML 1.0 - lang and xml:lang
XHTML 1.1 - xml:lang
FaxTéléc.: (514) 123-4568

Then you can use a stylesheet to hide the english word.
span [lang=en] {display: none;}

Let's take this one further. Markup the new code as a telephone microformat.


   Fax
   Téléc.:
   (514) 123-4568


And hide the english text inside the microformat
.tel [lang=en] {display: none;}

--
Paul Wilkins 


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

Re: [uf-discuss] An Inconvenient hCard

[Paul Wilkins]

From: "Ara Pehlivanian" <[EMAIL PROTECTED]>

On 3/20/07, Paul Wilkins <[EMAIL PROTECTED]> wrote:


Fax
Téléc.:
(514) 123-4568


And hide the english text inside the microformat
.tel [lang=en] {display: none;}


Thanks for the work you put into this solution but I've got two
problems with it. The first being what I mentioned in my initial
posting (though I may not have been overly clear about it), but hiding
content in CSS still means that the content is there for unstyled
viewing. Secondly, the attribute selector isn't widely supported
enough to make the solution viable on most browsers (in particular
IE).

Thanks though. :-/


That's all right Ara. Until IE6 becomes less of an impact, there are two 
other options.


One makes use of a slight loosening of the semantics of the abbr element.
Téléc.:
   (514) 123-4568


And the other discards any ability to separate the phone number by its 
appropriate type, but is at least guaranteed to work in a minimal nature.


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

Re: [uf-discuss] An Inconvenient hCard

[Paul Wilkins]

Ara Pehlivanian wrote:

On 3/21/07, Ryan King <[EMAIL PROTECTED]> wrote:

Tél.: (514) 123-4567
Téléc.: (514) 123-4568



Does the following make any sense to you as a potential solution to i18n?

Téléphone: (514)
123-4567
Télécopieur: (514)
123-4568

as opposed to stretching the semantics of the  tag?


Quoted from http://microformats.org/wiki/hcard-issues

REJECTED TRIED ALREADY. Using class names for the "type" of a tel or adr 
was attempted (http://microformats.org/wiki/hcard-parsing#ISSUE_2), and 
failed in many situations. In addition, the "type" information is actual 
data, not just a property name, and thus deserves to be in the visible 
markup. Note that you can use abbreviations, e.g. title="work">W: in order to present the type in a way that may 
better fit in with the rest of your presentation.


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

Re: [uf-discuss] An Inconvenient hCard

[Paul Wilkins]

From: "Andy Mabbett" <[EMAIL PROTECTED]>

In message <[EMAIL PROTECTED]>, Paul Wilkins
<[EMAIL PROTECTED]> writes


a slight loosening of the semantics of the abbr element.
Téléc.:
  (514) 123-4568



This thread is going in circles, On 12 March, I wrote, having suggested
the same possibility, that:

   ...there are concerns that that's an abuse of "abbr".


I think that abuse is too strong a term for what's happening here.

There is historical evidence that in the case of microformats, such a thing 
is allowed.


To markup the following vcard example.

http://microformats.org/wiki/hcard-examples#3.3.1_TEL_Type_Definition

TEL;TYPE=work,voice,pref,msg:+1-213-555-1234


  my
  work
  phone, with
  voicemail:
  +1-213-555-1234


--
Paul Wilkins 


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

Re: [uf-discuss] hCite elevator pitch and my bibliography generator

[Paul Wilkins]

Henri Sivonen wrote:

On Mar 10, 2007, at 23:10, Paul Wilkins wrote:
You are using the BibTex format, which is covered in  the 
citation formats http://microformats.org/wiki/citation-formats


Sure, but considering that I share my .bib, should I expect people to  
want to scrape my (X)HTML-formatted bibliography?


If the .bib is used as the lone source for the XHTML, I suspect it would 
be easier to scrape the .bib file.


The citation microformat is a work in progress at this stage, so  it's 
not mature enough for programs to extract information from it,


I guess this means that I shouldn't try to support hCite on the  
generator side in my thesis considering that the document should go  
final on the first week of April.


Even though it goes final then, does that prevent you from later on 
adding markup which doesn't affect the text, yet makes it easier for 
tools to scrape through the information?


Would it be of any use to anyone if I wrapped the name of each author/ 
editor in a  if I otherwise leave my markup the way  it 
is now?


A formatted name is quite a restricted format, and if the formatted name 
doesn't follow a certain prescribed format, it is considered to be 
invalid and isn't used.


Currently the BibTeX is as follows

@Misc{AXML,
  editor = {Tim Bray and Jean Paoli and C.M. Sperberg-McQueen},
  title = {The Annotated XML 1.0 Specification},
  year = {1998},
  publisher = {O'Reilly Media, Inc.},
  refdate = {2007-03-04},
  url = {http://www.xml.com/pub/a/axml/axmlintro.html}
}

From which you are wanting to create the following kind of data.

[AXML]
The Annotated XML 1.0 Specification. Tim Bray, Jean Paoli and C.M. 
Sperberg-McQueen, editors. O’Reilly Media, Inc., 1998. 
http://www.xml.com/pub/a/axml/axmlintro.html (referenced: 2007-03-04)


The editor section alone will be interesting to markup, because the 
citation will have to allow multiple editors, in which case both the 
BibTeX and the microformat will have to be created from a parent source, 
so that the microformat can gain the name-based information in the 
format required, while still allowing that information through to become 
the BibTeX file.


The benefits are that people visitng your content with next  
generation tools wil be able to easily extract and use the  
information in more interesting and useful ways.


So basically, my effort would not be about catering to specific  
realistic foreseeable use cases. Instead, it would be about putting  
data out there in case someone figures out a use case later on.


It may be more useful to provide the ISBN number for the book. Then the 
problems left to be solved become smaller and easier to handle.


Somehow, I was under the impression that hCite required bibliography  
items as s instead of / pairs (which is what I use and  what 
W3C and WHATWG specs use).


I'm sure that design patterns can be created to accommodate such a scheme.

What I'm trying to say is that I think hCite should allow names to be  
marked up as formatted names tossing the deformatting problem to the  
consumer. After all, one of the most popular bibliography data  format, 
BibTeX, stores formatted names.


Currently the formatted names are accepted in the following formats

given-name (space) family-name
family-name (comma) given-name
family-name (comma) given-name-first-initial
family-name (space) given-name-first-initial (optional period)

How much granularity does BibTeX allow for when storing the formated 
names for Editors?



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

Re: [uf-discuss] hCards in other languages

[Paul Wilkins]

Justin Mclean wrote:

Hi there,

I have a simple site (http://www.classsoftware.com) on which I've  added 
a vCard, the card seems to work fine in Operator (firefox  plugin) but 
in the Japanese version of the page (http:// 
www.classsoftware.com/index.cfm/lang/ja) with exactly the same XHTML  
structure the imported card is missing the org name and my name. Is  
something wrong with the hCard on the page or is it an issue with  
Operator?


Works for me on Operator 0.6.2 and on X2V at http://suda.co.uk/projects/X2V/

Also what is the best way to mark up a hCard when the content of the  
card is in an langauge other than english? Do you need to specify the  
language used in the card (lang attribute on the card's container) or  
is the language of the of HTML page (the lang attribute on the html  
tag) good enough?


Yes, that's good enough. The only difficulty is when english text is 
expected as keywords, and you want them displayed in another language 
instead. Then you'd have to do something like


fakusu

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

Re: [uf-discuss] hCite elevator pitch and my bibliography generator

[Paul Wilkins]

Henri Sivonen wrote:

Rephrasing:
How would I need to change my markup to comply with what hCite is  
currently expected to be? If I do that now, will I pollute the space  of 
future hCite data?


As far as I'm aware, the architectural plans are still being drawn up
for hCite. It is currently still a work-in-progress, with property names 
 not yet created.


The best advice I can give for you is, watch this space.

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

Re: [uf-discuss] hCards in other languages

[Paul Wilkins]

Justin Mclean wrote:

Hi Paul,

Works for me on Operator 0.6.2 and on X2V at http://suda.co.uk/ 
projects/X2V/


Thanks for that, X2V worked for me also so that implies that the  hCard 
on the page is fine. Out of interest what address program are  you using?


Currently I'm using Microsoft Outlook, but I'll be changing that shortly.


fakusu


Yes that's what I'm using in the japanese (and other language)  
versions. The address is still in english so I guess I should tag that 
as lang="en"  (or perhaps en-au) as it's a different language to  the page.


That's right.

If you're using HTML then use lang="en-au"
If you're using XHTML 1.1 then use xml:lang="en-au"
If you're using XHTML 1.0 then use both together.


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

Re: [uf-discuss] Mark-up for vCard in table rows

[Paul Wilkins]

Andy Mabbett wrote:

Given that the only place class="vcard" can go is the , where can I
put class="adr"?


If you have to stick to using tables (ugh), you can nest them together.


Visitor Center

  
  Nepal
  Okhaldhunga (40 km)
  map



My mother always said tables would be bad for my health.

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

Re: [uf-discuss] Mark-up for vCard in table rows

[Paul Wilkins]

From: "Andy Mabbett" <[EMAIL PROTECTED]>
I'm trying to advise someone about marking up an existing table; uFs are 
not supposed to require the re-engineering of valid HTML.


http://microformats.org/wiki/hcard-parsing
Other properties, like "adr", "email", "url", "tel", etc., may (and often 
do) appear more than once, and thus the parser continues to look for each 
occurrence within the contents of the hCard


So you can mark it up properly, with a class="adr" on each appropriate td.

If the tool doesn't correctly take the multiple instances and bring them 
together, that ais a problem that the tool will need to remedy.


--
Paul Wilkins 


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

Re: each "adr" is its own address (was Re: [uf-discuss] Mark-up forvCard in table rows)

[Paul Wilkins]

From: "Tantek Ç elik" <[EMAIL PROTECTED]>
vCards can contain multiple ADR properties for multiple addresses.  Thus 
in

hCard, multiple class="adr" instances are for multiple addresses, not
concatenation into a single address.  Each class="adr" indicates a 
separate

address.


What kind of solution would you propose then for Andy's table layout 
dilemma?


--
Paul Wilkins 


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

Re: [uf-discuss] Mark-up for vCard in table rows

[Paul Wilkins]

From: "Paul Wilkins" <[EMAIL PROTECTED]>

http://microformats.org/wiki/hcard-parsing
Other properties, like "adr", "email", "url", "tel", etc., may (and often 
do) appear more than once, and thus the parser continues to look for each 
occurrence within the contents of the hCard


So you can mark it up properly, with a class="adr" on each appropriate td.


Sorry, correction, thanks Tantek, separate adr sections are for separate 
addresses.


--
Paul Wilkins 


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

Re: [uf-discuss] Mark-up for vCard in table rows

[Paul Wilkins]

From: "Andy Mabbett" <[EMAIL PROTECTED]>
I'm trying to advise someone about marking up an existing table; uFs are 
not supposed to require the re-engineering of valid HTML.


Modern markup techniques can't be expected to work with ancient coding 
troubles.


The only way to group address parts in separate td elements is to group them 
from the tr element.


With the adr class in the tr element, the hcard grouping has to be further 
up, so with the current manner of marking up microformats, the table code 
you're working with isn't able to be marked up without modification.


A way of successfully marking it up is to combine the td elements together, 
and use div and span to adjust the layout with css.



Visitor Center

  class="country-name">Nepal
 Okhaldhunga (40 km) href="...">map




But if you want to mark up the original code with no structural changes, 
because of the structured nature of microformats, that won't be possible.


--
Paul Wilkins 


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

Re: [uf-discuss] Mark-up for vCard in table rows

[Paul Wilkins]

From: "Jason Garber" <[EMAIL PROTECTED]>

Correction: those classes should be "vcard", not "hcard".


yeah, that could work.

Andy - how would you feel with the following sample code for your particular 
trouble.



Visitor Center
 class="country-name">Nepal
Okhaldhunga (40 km) href="...">map



--
Paul Wilkins 


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

Re: [uf-discuss] Real vs. stage names

[Paul Wilkins]

Andy Mabbett wrote:

Tantek Çelik writes

Andy Mabbett wrote:

How would folks mark up an hCard for the singer Alvin Stardust, born
Bernard William Jewry, also known under the stage name Shane Fenton?

What's his passport look like?

Oddly enough, he's never sent it to me.


That would answer the given-name, family-name questions, and perhaps 
even the additional-name and nickname questions.

And otherwise?


And otherwise, like this.

Start with what you know.

singer Alvin Stardust, Bernard William Jewry, also known under the 
stage name Shane Fenton.


Markup what you can, like the persons name
singer Alvin Stardust,
  Bernard William Jewry,
  also known under the stage name Shane Fenton.

Then you move on to nicknames

The cheatsheet on the wiki at 
http://microformats.org/wiki/hcard-cheatsheet says nicknames can match 0 
or more times, and just to make sure, RFC2426 which defined the vCard 
spec says about Nicknames:

Type value: One or more text values separated by a COMMA character

So if multiple nicknames are listed, they'll end up being comma separated.

singer
  Alvin Stardust,
  Bernard William Jewry,
  also known under the stage name
  Shane Fenton.

And finally you can sprinkle other things, like his role and stagename


  singer
  Alvin Stardust,
  Bernard William Jewry,
  also known under the
  stage name
Shane Fenton
  .


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

Re: [uf-discuss] hCard names - n vs. fn

[Paul Wilkins]

For the purposes of discussion, a more generic version of this is



 The Rt Hon
 Tony Blair
 MP



An update may be required, where then fn is looked for first, and parsed out 
into appropriate n fields, then after that the n fields are updated from the 
remaining information.


--
Paul Wilkins 


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

Re: [uf-discuss] hCard names - n vs. fn

[Paul Wilkins]

From: "Andy Mabbett" <[EMAIL PROTECTED]>

On reflection, would it make more sense to reverse the "n" and "fn",
thus:

   
 The Rt Hon 
  
 Tony Blair
  
 MP
   

?


No, for then
- fn is "The Rt Hon Tony Blair MP"
- n is "Tony Blair"

Neither of which are acceptable.

The former code is:

  
The Rt Hon 
 
Tony Blair
 
MP
  

which gives
- fn "Tony Blair"
- n honorific-prefix "The Rt Hon"
- n honorific-suffix "MP"

The rest of the name can be implied by allowing the "FN" property to 
imply "N" property values in typical cases


My question to Brain is, even though we're being more explicit with the use 
of the N property, should that permit us to then totally disregard any FN 
information?


Who's responsibility is it to parse the information in FN.

given-name (space) family-name
family-name (comma) given-name
family-name (comma) given-name-first-initial
family-name (space) given-name-first-initial (optional period)

Is this to rest on the shoulders of people creating templates for their 
pages, or can it be done consistantly and reliably by the tools that 
interpret them.


--
Paul Wilkins 


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

Re: [uf-discuss] hCard names - n vs. fn

[Paul Wilkins]

Drew McLellan wrote:

It's the fn=n optimisation ... from my notes it seems that it was  
created around the same time as a.include.



So if the fn=n optimisation is being used, does that existing spec deny 
the ability to include other n properties? And if not, what wqould the 
code look like?


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

Re: Fwd: [uf-discuss] Legal implications of using Microformats

[Paul Wilkins]

Brian Suda wrote:

I keep going back to how companies like Microsoft and Yahoo have
decided to use microformats, if they thought there were problems, they
would have been the first to complain.

Lets talk about what/if any changes could be made to make things more
clear. I'm certainly up for clarifying things, as an author, i'm not
trying to hide or do something sneaky.


What kind of copyright or licensing things are involved with microformats?

I would have thought that there were none, as microformats are just an 
advisory on how to markup text.


I compare it with, "Hey, here's an idea. Use the address tag so people 
know who to get in touch with to edit the page."


Does the way that geo tags are put together,
. . .
require any form of copyright or license? I would hope not.

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

Re: [uf-discuss] human readable date parsing

[Paul Wilkins]

From: "James Craig" <[EMAIL PROTECTED]>
To: "Microformats Discuss" 
Sent: Thursday, May 03, 2007 8:56 AM
Subject: Re: [uf-discuss] human readable date parsing



Tim Parkin wrote:


With all of the discussion about iso dates being unreadable and  that an
iso date isn't necessarily required when someone enters a date (i.e.
saying 24th June doesn't translate into a single date, neither does
'thursday'). Shouldn't the focus be on trying to standardise date
formats rather than trying to hide the iso date? If we can get a  parser
to recognise 'human readable' dates (which *is* possible, if not  totally
easy, http://labix.org/python-dateutil for a python version).


I disagree. If you try to make other, human readable formats into a 
standard, they will fall short when it comes time to internationaliz (s)e 
it. If you can come up with a better format readable to all  machine and 
all humans in all languages, I'll recant.


I think the ISO 8601 is the best machine data format for the job. I  just 
don't think it should be in abbr.


So as machine-readable information shouldn't be presented in a 
human-readable manner, that rules out having the information in-the-clear, 
and in title tags.


This leads us to having a hidden class for machine-readable information that 
will be hidden by default and not presented to people.


A class with a suitable name would have to be used, something like the 
existing "value" but modified to infer that it's for the computer only and 
isn't to be read.


What if the value class was to be used with a hidden class. Then they would 
serve their purpose, they wouldn't interfere with existing styles and could 
be interpreted correctly.


.hidden {display: hidden}

Then the human-readable and machine-readable can be mashed together. If the 
screen-reading software honor hidden styles this could be the right path to 
take.


Friday the 13th 20070713


--
Paul Wilkins 


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

Re: [uf-discuss] Expanding the abbr pattern

[Paul Wilkins]

From: "Andy Mabbett" <[EMAIL PROTECTED]>

In addition to Patrick's valid concerns about house style; I would again
point out that "dtend" is exclusive; microformats currently (and
wrongly, from a semantic and accessibility PoV) require:

   Q1 '07: 2007-01-01 through 2007-04-01


My understanding here is that the date defaults to a time of midnight, so 
the end date must be exclusive otherwise a one-day event will last for no 
time at all.


You're right to be concerned though. I suspect that it is too much to ask 
people marking up their code to understand such fine points. Not to mention 
the troubles involved with templated or scripted markup.



I have proposed a solution to this problem:


<http://microformats.org/wiki/hcalendar-brainstorming#Simplification_of_date-end>

but it has, so far, been ignored.


You may want to correct the proposition. The following from the proposal I 
suspect is errant.

31 January 2007

Were you after the following?
31 January 2007

--
Paul Wilkins 


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

Re: [uf-discuss] Regarding POSH and misuse of the microformats logo

[Paul Wilkins]

From: "Andy Mabbett" <[EMAIL PROTECTED]>

...which brings us back to the issue, now over a year old, that many of
the pages on the 'wiki' need to be re-written in plain English.


If you can furnish us with several examples perhaps gathered together on a 
wiki page, I'm sure that the uF army will begin to work on them.


--
Paul Wilkins 


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

Re: [uf-discuss] Hidden Locality/Country?

[Paul Wilkins]

From: "kalisti" <[EMAIL PROTECTED]>

The issue I'm having right now is finding a balance between keeping my
site optimized for human reading, and also making it as semantically
robust as possible for machines. The specific issue is that since every
business on the site is found within our county, it makes no sense to
include either locality (California) or country-name (US) in the address
information for the reader to see. This simply takes up space without
adding any information -- the site is manifestly about businesses based in
California, which is therefore in the US.

Now, the spec seems to say I can omit this information if I choose to. At
the same time, it seems like omitting this information would result in a
less robust experience for anyone getting the information down the line
via an aggregator -- humans visiting the site will know it is in
California and in the US, but machines will not, and therefore humans who
see the businesses listed anywhere other than our site won't know what
state they're in.


Just include the information marked up as per normal, and use CSS to adjust
the on-screen presentation of the information so that the state and country
aren't visible.

--
Paul Wilkins

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

Re: [uf-discuss] RFC: sHTML Video Thumbnailing

[Paul Wilkins]

http://www.w3.org/TR/html401/struct/links.html#h-12.1.2

My simplified understanding of the relationship between rel and rev is

With the rel attribute, the relationship that the linked page has to this 
link is "foo".
With the rev attribute, the relationship that this link has from the linked 
page is "foo".


Use "previous" or "next" as the link values and you'll understand what's 
going on.


From: "Patrick H. Lauke" <[EMAIL PROTECTED]>

Charles Iliya Krempeaux wrote:


http://example.com/video";>
   http://example.com/thumbnail.jpg";>



I'm not sure if the "rev" attribute is being used correctly in your 
markup.


Rev defines the reverse link to the current document, not to whatever is 
encapsulated by the link itself...unless I'm reading the spec wrong
"This attribute describes the relationship from the current document to 
the anchor specified by the href attribute"

http://www.w3.org/TR/html401/struct/links.html#edef-A


A rel link from the video page to the thumbnail would be "thumbnail".
So, a rev link on the thumbnail to the video page would also be "thumbnail".

I've got no problem with using rel and rev values myself, but if you're 
going to use a a custom link-type that's not actually defined in 
http://www.w3.org/TR/html401/types.html#type-links then you should use a 
profile to define what's going on.


--
Paul Wilkins 


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

Re: [uf-discuss] Microformats gets strong showing in Firefox 3 UI

[Paul Wilkins]

Charles Iliya Krempeaux wrote:

Why not just restrict the cursor thing to be activated over the actual
"data" of a Microformat.


That sounds like a nice idea, but then you're getting into the realms of 
mystery-meat navigation.

http://www.webpagesthatsuck.com/mysterymeatnavigation.html



For example... consider an hCard.  It's true that the actual hCard
could span the whole page.  But you could make the cursor thing happen
only when the cursor goes over the text of the name... the logo... and
stuff like that.

(Did I explain that well enough?)

So... you would NOT make the cursor thing happen over the span of the
Microformat.  But you would make it happen over the actual "text",
"image", etc, data of the Microformat.


How about if a microformats icon is activated when such content is 
available on the page.


When you click on the logo, you get a dialog box containing all of the 
information, while hovering over the icon makes obvious the locations on 
the page where the microformat information is.


Even if the information is made visible on the page in some manner, 
there are issues with long pages that have most of the microformat 
information off of the visible part of the page.


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

Re: [uf-discuss] Microformats gets strong showing in Firefox 3 UI

[Paul Wilkins]

From: "Charles Iliya Krempeaux" <[EMAIL PROTECTED]>

That sounds like a nice idea, but then you're getting into the realms of
mystery-meat navigation.
http://www.webpagesthatsuck.com/mysterymeatnavigation.html


The cursor thing could be in addition to other ways (that don't
exhibit MMN) of getting at Microformats.


I'm happy as as long as the discovery of information maintains some form of 
usability.


On a tangent, I was thinking about tabbed browsing and how IE7 made it easy 
for people to discover what it was. With microformats, how easy it will be 
for end-users to discover and make use of the information will be a key 
factor in how well it gets taken up.


--
Paul Wilkins 


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

Re: [uf-discuss] Microformats gets strong showing in Firefox 3 UI

[Paul Wilkins]

From: "Alex Faaborg" <[EMAIL PROTECTED]>
Changing the cursor isn't perfect, but it is the only way for the  browser 
to provide a visual cue of contextual action without directly  modifying 
the page itself, which is why this is the best solution I  have heard so 
far.


Will this be able to combine with other existing extensions that change the 
mouse cursor?
If it will interoperate, it shouldn't be the primary means by which the 
imformation is made known.



The cursor thing could be in addition to other ways (that don't
exhibit MMN) of getting at Microformats.


The cursor change isn't technically mystery meat navigation, since  you 
can hopefully see what you are hovering over, and the icon of the 
application that is going to launch is appended to the cursor.


Strictly speaking it isn't MMN because navigation itself isn't involved. The 
problems surrounding the cursor change though are identical. If it is the 
only mechanism to find microformat content, it won't be found until someone 
chances across it if they notice it changing when it crosses such content.


The mouse cursor operation won't be able to survive all by itself. It will 
need other techniques to back it up. I suggest some below.




In a lot of cases it is easier to directly interact with information  in 
the page than it is to find it in a menu somewhere.  For instance,  if you 
want to map a single item in a list of 100 items, you don't  want to do a 
visual scan for the same item in a menu, you just want  to click on it.


My suggestion is:
- A microformats icon appears when such information is available, and a 
dialog box should appear to introduce the microformat logo, with a tick box 
to not show it again
- The microformat content is made visible (dotted border, or some other 
mechanism) temporarily when whe microformat logo is hovered over, or 
permanently (until page refresh) when clicked.
- The microformat logo should have a couple of drop-down options such as 
"Outline Microformat Content" and another option for a modal dialog box 
containing the microformat content information.
- The mouse can indicate the microformat type when it hovers over the 
content, but it should not activate the outlining of the content. That would 
get too messy and distracting.
- The context-menu (right-click) should provide the ability to interact with 
the microformat content


This allows several types of behaviour to take place:
- you can guess at what is microformat content should you desire to
- you can hover briefly on the logo to get an idea of where the microformat 
content is, then use the mouse to interact with the content
- you can turn on the microformat outline for the page then scroll to find 
relevant pieces
- people who don't know they can click the microformat logo can still 
activate it from the drop-down menu


--
Paul Wilkins 


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

Re: [uf-discuss] Microformats gets strong showing in Firefox 3 UI

[Paul Wilkins]

Colin Barrett wrote:

I was thinking about this, and I wonder -- how did people learn the  
behavior that you can click on a blue, underlined piece of text? 
Think  about a pre-web world where nobody knew what hypertext was. 
People  needed to figure out somehow that you could click on links to 
make  them activate.


Enter, the hand cursor. If you think about it, it tells you nothing  
about what's actually going to happen when you click -- instead, it  
looks like someone about to click the mouse, so I suppose it's  
inviting for people to mimic the gesture? This still doesn't answer  
the question of how people would discover this. My guess is that  
people scan the page with their mouse as they read. I know I do that  
sometimes. Anyone have actual evidence?



There's no need to guess.
There were many issues and problems with hyperlinks when they were first 
used, and information about this is fully available in great detail.


The following extract is by Jakob Nielsen from 1988

Architectural Component of Hypertext Systems
http://www.useit.com/papers/hypertext_theory/


Perhaps we don't need to worry about discoverability of microformats  
further than just changing the cursor, after all.



Your proposal for microformats provides no mechanism for people to 
visually distinguish what is microformat content and what is not.


Imaging that you have ten different pages, all from different websites. 
Three of them have microformat information in them and the rest do not.
Are people going to right-click on every piece of content that's of 
interest to them on all of those ten pages and examine the context-menu 
to see if that piece of content lets them use some microformat content? 
No they are not. After a very short while they'll tire of that game.


If there is instead a visual cue of there being microformat content on 
the page (an icon appears, or your hovered mouse shows you something), 
then it becomes much easier to take action on potential information of 
interest.


Idea for developers - for accessibility, there should be a keyboard 
shortcut that enables the outlining of microformat content. Then someone 
can quickly (without the mouse) check to see if there's something of 
interest to them, before moving on.


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

Re: [uf-discuss] Microformats gets strong showing in Firefox 3 UI

[Paul Wilkins]

Colin Barrett wrote:


On Jun 5, 2007, at 11:46 PM, Paul Wilkins wrote:


There's no need to guess.
There were many issues and problems with hyperlinks when they were  
first used, and information about this is fully available in great  
detail.


The following extract is by Jakob Nielsen from 1988



Curses - 1995 is wehen it was published, but it's all good.



Architectural Component of Hypertext Systems
http://www.useit.com/papers/hypertext_theory/



LazyWeb, Go! :) Thanks for the link.


If there is instead a visual cue of there being microformat content  
on the page (an icon appears, or your hovered mouse shows you  
something), then it becomes much easier to take action on potential  
information of interest.



Isn't that what I was advocating? A hover effect for the mouse, like  
Alex proposed (full disclosure, Alex is a co-worker of mine at Mozilla).



We may have different parts of the elephant here.

My opinion is that the "hunt around and discover a mystery logo on some 
content" technique should be secondary and supplemental to aanother 
indicator that the microformat content is there, whether it be a visual 
icon, or an audible fanfare (just kidding), or *something* that alerts 
the user by saying "Hey, wake up!" to its presence.


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

Re: [uf-discuss] Microformats gets strong showing in Firefox 3 UI

[Paul Wilkins]

From: "Andy Mabbett" <[EMAIL PROTECTED]>

Brian Suda <[EMAIL PROTECTED]> writes

It would be best NOT to let others define how microformats work
outside of the microformats community! This is an open community and
they can certainly particate in the development and give their
feedback rather than ignore our process and interpret the specs how
they see fit.


You're right, but that puts the onus (and the moral responsibility) onto
this community, to respond in a timely manner to, and to adequately
resolve, the accessibility concerns about the abuse of "abbr" raised
here a few weeks ago.


Has anyone taken an in-depth look at how the usage of the abbr tag affects 
internet explorer?


As IE doesn't seem to know about the abbr tag, will this affect scripts 
parsing the dom on IE browsers?


--
Paul Wilkins 


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

Re: [uf-discuss] Question about telephone numbers

[Paul Wilkins]

- Original Message - 
From: "Scott Reynen" <[EMAIL PROTECTED]>

You can use the include pattern to remove some of this redundancy:

http://microformats.org/wiki/include-pattern

E.g.:

Staff work phone  
numbers:

...

Person One
class="value">123-4567

...


I presume that the anchor should not be #work-title but #work-type ?
...  ...

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

Re: [uf-discuss] Empty anchor tag-pairs and accessibility (was: Questionabout telephone numbers)

[Paul Wilkins]

From: "Andy Mabbett" <[EMAIL PROTECTED]>
I thought we'd decided that empty anchor tag-pairs were bad, from an 
accessibility PoV?


Is the object tag to be used instead for the include pattern?

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

Re: [uf-discuss] Empty anchor tag-pairs and accessibility (was:Questionabout telephone numbers)

[Paul Wilkins]

From: "James Craig" <[EMAIL PROTECTED]>

Paul Wilkins wrote:

Is the object tag to be used instead for the include pattern?


The  include pattern has some performance problems, it would  be 
best to use the anchor include pattern but include some text  indicated 
the marker that was being included.


So when we have multiple phone numbers of the same type

Staff work phone numbers:
...
Person One
123-4567

How should they be marked up. Something like this?

Staff work phone numbers:
...

   Person One
   
   123-4567
   


This feels wrong, and not the least because fragment identifiers have 
received a hammering in terms of usability.

http://www.useit.com/alertbox/within_page_links.html

It's tempting to change the text (god forbid) to achieve better code.

Person One
Wk: 123-4567


   Person One
   
   Wk:
   123-4567
   


--
Paul Wilkins 


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

Re: [uf-discuss] Question about telephone numbers

[Paul Wilkins]

From: "Rickards, Julian (NDM)" <[EMAIL PROTECTED]>

Last night, I came up with two ideas.

 1.  Using the code, Work, I could
create CSS to hide the contents of the hidden class. It doesn't get me
around needing to add "Work" to every phone number but it does hide it
from sighted users (with CSS-capable browsers).


This first idea is usually considered bad as it's hiding information. 
Personally though I like the idea of using css to adjust the presentation of 
the information.


I wouldn't go with the hidden class though, as that is a presentational 
name, rather than a semantic one.


If you want the type of all of the numbers to be hidden, you could easily 
use

CSS:
.vcard .type {display: hidden}
HTML:


   Work: 
   123-4567




 2.  What about using the title attribute to indicate phone type such
as 1-234-567-8901?


That would normally be a great idea, but IE is too thick to understand 
attribute selectors.
The title attribute isn't workable with mifroformats either, unless it is as 
the abbr tag, as that's the only element in which information is stored from 
the title attribute.


If some of the numbers are work numbers, you could use a class called 
work-number and use css to hide just the type. The class isn't placed with 
the tel class, to allow the possibility of having non-work numbers also 
displayed.

CSS:
.work-number {display: hidden}
HTML:

   Work: 
   123-4567


It's a shame that IE doesn't understand type selectors, because we should be 
using something as simple as this.

CSS:
.type[title=work] {display: hidden}
HTML:

   Work: 
   123-4567


--
Paul Wilkins 


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

Re: [uf-discuss] Question about telephone numbers

[Paul Wilkins]

From: "Rickards, Julian (NDM)" <[EMAIL PROTECTED]>
To: "Microformats Discuss" 
Sent: Tuesday, June 26, 2007 12:10 AM
Subject: RE: [uf-discuss] Question about telephone numbers



Thanks Paul for your reply but I have two issues with your statements at
the bottom.


1. I proposed the title attribute to store the telephone type and you
replied that the "title attribute isn't workable with microformats ...
unless it is [in] the abbr tag". My issue with this is that the title
attribute is a Core attribute and may be used in any tag. Therefore, it
should be possible to store this type of information in the title
attribute without requiring the abbr element. The fact that the hCard
specification doesn't allow or support this is another issue but it
should be possible.


Because something is possible doesn't mean that it's a good idea. 
Microformats are designed to be applied on pre-existing information, and if 
any of that information has title attributes already applied to it, we don't 
want that information to mistakenly flow over into the microformat itself.




2. I have never seen reference to anything in the Microformats
specifications that suggest that styling microformats must be compatible
with all browsers which is the only reason why you might want to
consider attribute selectors. Therefore, I don't think that browser
compatibility for attribute selectors should be a valid reason not to
use the title attribute to store the phone type.



I'm thinking about styles that may want to be applied to the abbr tag. IE 
just won't allow this to occur.




However, as I was thinking about this during this morning, I realized
that microformats do offer an alternative, even if it isn't spelled out
as part of the hCard specification for the telephone component and that
is to use multiple classes. It is perfectly legal (and required in some
instances) to use class="fn n", this pattern could be extended to be
used as class="value work" and class="value home" etc.

For example:


   Toll-free Phone: 1-800-567-7890
   Toll-free Fax: 1-800-567-0987



This technique is in danger of overloading the already crowded class name 
space. The number of class names that are used should be kept to a minimum.




The current format forces us to include "voice" or "fax" in text rather
than in the attributes. In my original case, I didn't want to include
the word "voice" in the text because in the contacts page I was/am
creating, all of the numbers were voice numbers (all of the people in
the contacts page share a single fax number so I didn't need to specify
a fax number for each and use "fax" and "voice" to distinguish them for
each person).

The other problem I will encounter is the fact that because my efforts
are on our government web pages (in Ontario, Canada, all government
pages must be in both English and French), I must use the French
equivalent to "voice" and "fax" in the text which means that the
microformat will be broken. However, if "voice" and "fax" were accepted
as attribute values, then I don't need to worry about the text in the
page because the attribute value would be used instead of the text.


This was covered recently, and general consensus is that the abbr design 
pattern is the most appropriate choice on resolving such issues.


Téléc

--
Paul Wilkins 


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

Re: [uf-discuss] microformats for normal people, like my mum

[Paul Wilkins]

From: "Alex Faaborg" <[EMAIL PROTECTED]>
I definitely agree that the microformats community should consider a  user 
facing name.  Similar to how RSS is exposed in Firefox to the  user as "Web 
Feeds" and microsummaries are exposed to the user as  "Live Bookmarks," 
microformat detection in Firefox 3 is going to need  a name.  What does 
everyone think it should be called?


To take an idea from Charles, I think that IntelliSmart is a good 
description of them.


IntelliSmart Web Pages.

--
Paul Wilkins 


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

Re: [uf-discuss] microformats for normal people, like my mum

[Paul Wilkins]

From: "Alex Faaborg" <[EMAIL PROTECTED]>
I'm a little wary of associating microformats too closely with Smart  Tags 
or IntelliSense given the massive public outcry Microsoft  received when 
they considered including the feature in IE6.  There  are obviously some 
very important distinctions between the two  systems, (microformats are 
open and extensible, and web site creators  place microformats in their 
pages instead of the browser injecting  them).  But these distinctions may 
be subtle enough to cause some  initial confusion if the user facing name 
is similar.


While reflecting on this over lunch I came to similar conclusions.

Perhaps we should use terms that we already have and know, and call the 
pages Semantically Rich, or something.


--
Paul Wilkins 


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

Re: [uf-discuss] microformats for normal people, like my mum

[Paul Wilkins]

From: "Tara Hunt" <[EMAIL PROTECTED]>

Personally, I'd love it all to be invisible and have more tools for
non-expert content producers to input plain text into stuff that spits
out properly marked up pages and other tools (like browsers and plug
ins and sites) that consume these well-marked up pages properly.


This means that the tools people use to create their web pages will need to 
provide a mechanism for them to add microformat data to their content, 
without necessarily having to dig into the code.


So, first steps.

Select an area of text to be used as an hCard and click an hCard button

When an hCard area of text is defined, buttons become available to define 
different sections


Select text to be the persons name and click a name button
- if the name appears to be parsable as a fn, ask if the given name is one 
of a series of example formats
- if the name isn't a correct format, let them pick and choose which parts 
are what


Select phone number and click a phone number button
- if an appropriate type is not included with the selected phone number, but 
one is nearby, ask if that should be included as the type



It should look like magic. What's that Arthur C. Clarke quote about
technology and magic?


it's not rocket science that we're doing here, it's tougher - usability for 
the masses.


--
Paul Wilkins 


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

Re: [uf-discuss] microformats for normal people, like my mum

[Paul Wilkins]

From: "Alex Faaborg" <[EMAIL PROTECTED]>
|> Mozilla's user experience team is going to continue brainstorming the
best way to expose microformat detection to end users, along with the 
rest of the mozilla community.  I'll post updates to this list from  time 
to time, and it will be interesting to see what interfaces and  names 
other people come up with as well.


The RSS feeds are accessed in the browser through the feed button.
So it makes sense that the microformat data should be accessed through the 
data button.


I do like data, it's concise and is easy to explain.

Q: What kind of data can I get from the data button?
A: Contact details, calender entries, geographic locations, . . .

Q: Does the data button always get the information?
A: No, only when the page author has specially marked out those parts of the 
page.


--
Paul Wilkins 


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

Re: [uf-discuss] Confused about telephone numbers in hCard

[Paul Wilkins]

From: "Rickards, Julian (NDM)" <[EMAIL PROTECTED]>

What I am doing is trying to make my markup work in Outlook 2003 by
exporting from Tails Export.

I started with:

Toll-free Phone:
1-800-670-5861


This is the correct way to markup that you're after.




Why is this so hard to do?


The trouble you're facing is that Tails is at version 0.3. The author says
" Thanks all for the feedback. I'm trying to construct a list . . ."

At this stage, Tails is incomplete and you will either need to be paitent 
until it works more properly, or for the interim, find some other solution 
than Tails.


--
Paul Wilkins 


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

Re: [uf-discuss] Confused about telephone numbers in hCard

[Paul Wilkins]

From: "Andy Mabbett" <[EMAIL PROTECTED]>

Paul Wilkins <[EMAIL PROTECTED]> writes


Toll-free Phone:
1-800-670-5861


This is the correct way to markup that you're after.


According to the spec, certainly; but it runs up against the known problem 
of abusing the abbr element:


According to the maxim: "People first, machines second" how should the 
following text be marked up so that it works with existing tools?


Toll-free Phone: 1-800-670-5861

--
Paul Wilkins 


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

Re: [uf-discuss] Hidden metadata no microformats

[Paul Wilkins]

From: "Andy Mabbett" <[EMAIL PROTECTED]>

Benjamin West <[EMAIL PROTECTED]> writes

I thought there was a prohibition on hidden metadata in the specs, or at
least somewhere on the wiki, but all I Can find now is:
visible data is much better for humans than invisible metadata
 <http://microformats.org/wiki/microformats#the_microformats_principles>

Can someone remind me what I'm missing, please?



http://tantek.com/log/2005/06.html#d03t2359 "Principles of visibility
and human friendliness".


Thank you, but I was after something canonical, not an op-ed.
Please don't top-post, and please don't quote sigs. Thank you.


You could try the FAQ.
http://microformats.org/wiki/faq

Where it says:

Q. Given that Google now looks at hidden content as potential spam, will 
invisible microformats be considered spam?


A. It is advisable not to hide information in your site, regardless of 
whether it is microformated or not. Microformats provide a mechanism for 
marking up visible content. Any mechanism for embedding invisible or hidden 
content risks being considered spam due to the fact that invisible 
(meta)data inevitably ends up being abused. Avoid invisible (meta)data. 
Publish visible data.


--
Paul Wilkins 


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

Re: [uf-discuss] Ufs on bbc.co.uk/music

[Paul Wilkins]

Michael Smethurst wrote:


Seem to remember at the time I asked what the line of demarcation would be
between people as people and people as organisations. Are you just saying
music artists? What about actors, politicians, bloggers? Music artists who
act? Actors who become politicians? Politicians who blog?

Feels like you're splitting the world into 2 camps: celebrities and others.
Unless it's clearer what the logic is going on here I'm not happy to do this
 



You have three ways of formatting a name for use in an address book.

1. n (family-name, given-name, additional-name, honorific-prefix, 
honorific-suffix)
Where you can mark up the explicit parts of the name with the above 
class names.

See http://microformats.org/wiki/hcard#Property_List

2. fn n
Where the name can be guaranteed to be one of the defined formatted name 
structures

* given-name (space) family-name
* family-name (comma) given-name
* family-name (comma) given-name-first-initial
* family-name (space) given-name-first-initial (optional period)
See http://microformats.org/wiki/hcard#Implied_.22n.22_Optimization

3. fn org
Where it is the name of not necessarily a person, but of an organisation 
with a varied naming structure.

http://microformats.org/wiki/hcard#Organization_Contact_Info

There is a clear demarcation line here.

If you can guarantee that the name will be given as family-name, 
given-name, etc... then Option 1 is used.
If you can at least guarantee the the name will be valid as a formatted 
name, then Option2 is used.
If neither of those two can be guaranteed, you're left with Option 3 or 
nothing.


There is a strong case for considering artist names as their 
organisational name. Their names are widely varying, and often have 
nothing to do with the persons individual name itself.


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

Re: [uf-discuss] making img machine-readable

[Paul Wilkins]

Andy Mabbett wrote:


Furthermore, you would speak:

   ndy
   Mabbett

as "Andy Mabbett", which is why microformats should also interpret it that
way.

 

That should be marked up in a more modern manner using CSS image 
replacement, which entirely resolves any issues.


Andy Mabbett

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

Re: [uf-discuss] [hCard] Implied type=work

[Paul Wilkins]

From: "Ciaran McNulty" <[EMAIL PROTECTED]>

I think technically a hCard @class="tel" without a type should be
converted to something like:
TEL:02076115040 and the consuming application default it to 'home',
but Outlook doesn't like vCard TEL without a TYPE, so most converting
apps will insert the default type explicitly.


As the person is wanting the work attribute to be included without actually 
specifying it, why can't an include pattern be used to specify the desired 
work attribute.


--
Paul Wilkins 


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

Re: [uf-discuss] Mediawiki accesskey shortcut usage instructions

[Paul Wilkins]

From: "Andy Mabbett" <[EMAIL PROTECTED]>
CTRL-S on my machine. *when editing a wiki page*, causes my browser to 
open a dialogue to save a local copy of the editing form.


When editing a wiki page you're right. The Accesskey is ctrl on IE5/Mac and 
it's variations of the alt key on most other browsers. The exceptions to 
this tend to be Firefox 2 with alt-shift, Opera with shift-esc, and ancient 
browsers that don't support Accesskeys.


Getting back to where this all started, the instruction in question is "use 
CTRL S to save"

That's only valid if the browser is something like IE5/Mac

It could be a lot better if it said
"Accesskeys differ according to your browser." which links off to a page 
that explains about Accesskeys, followed by "use ACCESSKEY S to save"


--
Paul Wilkins 


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

Re: [uf-discuss] Mediawiki accesskey shortcut usage instructions

[Paul Wilkins]

From: "Andy Mabbett" <[EMAIL PROTECTED]>

Tantek Çelik <[EMAIL PROTECTED]> writes
The analogy is false as the coffee directions apply to perhaps <1% of the 
people on this list, but the Mediawiki accesskey shortcuts apply to

99% of the people on this list.


I think you've just invented that statistic. Care to prove me wrong?


In the interest of public spirit, I use ctrl-s to save.

Perhaps this would be resolved more quickly if we get a hands-up of people, 
on this list, who aren't able to use ctrl-s to save.


--
Paul Wilkins 


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

Re: [uf-discuss] Mediawiki accesskey shortcut usage instructions

[Paul Wilkins]

From: "Andy Mabbett" <[EMAIL PROTECTED]>

Paul Wilkins <[EMAIL PROTECTED]> writes

It could be a lot better if it said
"Accesskeys differ according to your browser." which links off to a page 
that explains about Accesskeys, followed by "use ACCESSKEY S to save"


It would be better still to say nothing. We don't say "move your mouse 
pointer here and press the button to go to the page about..."


When I'm tutoring people who are new to the mouse I do.
Because access keys are a new concept to some people, such instructions are 
required somewhere. If nothing is said about them, then nobody will use 
accesskeys.


There is some very good information around on how to display the access key 
assignments.

http://www.cs.tut.fi/~jkorpela/forms/accesskey.html

--
Paul Wilkins 


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

Re: [uf-discuss] Figure Examples

[Paul Wilkins]

Chris Messina wrote:

>Specifically, there are many themes that I've discovered that use some
>variant of "float-right", "float-left", "alignright", "alignleft" and
>so on to mark up images in blog posts. While this is a useable
>convention for themers and designers, it is not semantic.
>
>Therefore, as I mentioned, I have developed my own practice that uses
>the order of class attribute values to define the alignment of
>figures. Thus, the classes that I use are:
>
>.figure, .figure-a, .figure-b, .figure-c, .figure-d
>
>This is infinitely extensible and, as Tantek has said, not
>"semantically negative" -- as in, it is better to be semantically
>neutral than to introduce presentational classnames.

This technique is wide open to abuse, because it is infinitely 
extensible. I don't want to have to deal with .figure-q that someone 
else has done, and try to figure out how the variations differ, yet the 
absolutes of left and right must be avoided.


It seems that that the .figure-b class has have nothing to do with the 
.figure class, even though their naming is very similar.


Imagine coming across someone elses custom design. How do you figure out 
which particular class name should be used for a particular situation?


I like to subscribe to the css naming principle of "Class names should 
describe their functionality, rather than their appearance."


We can look for inspiration from other fields that deal with figures and 
images, like newspapers for example.


- masthead, which appears once at the top of the page and often has a 
different appearance to the rest of the figures

- banner, which goes across the whole page
- cutout, where the background has been removed and doesn't require any 
bordering

- inset, set inside other content, typically a paragraph
- lead-in, which preceeds a paragraph
- logo
- promo, for promoting an item inside
- sidebar
- skybox
- stand-alone, as separate content between paragraphs
- teaser, giving just a taste of what's to come


>Here is the associated CSS:
>
>img.figure {
>max-width:460px;
>border:2px solid #f7f7f7;
>}


This is the default appearance for figures.

>img.figure-a, img.figure-c {
>margin-left:auto;
>margin-right:auto;
>display:block;
>}
>

The function of the figure-a and figure-c classes, as is being used 
here, is to let the image sit by itself, between other content.
A classname of "banner" or "stand-alone" describes this particular 
function without implying how you should handle it.


>img.figure-b {
>float:right;
>border:0;
>margin:0 0 6px 6px;
>}
>

The figure-b class appears to be one where the image is inset within 
other content, the classname "inset" would be perfect for this.


>img.figure-d {
>float:left;
>border:0;
>margin:0 6px 6px 0;
>}
>

The figure-d class does the same inset job, but to the other direction 
of figure-b. The naming of this could be one of a couple of choices: 
"lead-in" for when you want the figure to always be at the start of the 
content, or if it's to purposely allow you to alternate the positioning 
of the inset image from the standard one, we can take a leaf from how 
alternate table rows are handles, and call it "inset alt"


img {
max-width:460px;
border:2px solid #f7f7f7;
}
img.figure .stand-alone, img.figure .banner {
margin-left:auto;
margin-right:auto;
display:block;
}
img.figure .inset {
float:right;
border:0;
margin:0 0 6px 6px;
}
img.figure .inset .alt {
float:left;
border:0;
margin:0 6px 6px 0;
}

Now the code becomes understandable and instantly clear. The class names 
define the separate functions that the figures are to convey, without 
being presentational in their nature. The class names are in line with 
the principle of semantic naming of css classes.


"Class names should describe their functionality, rather than their 
appearance."


What issues would get in the way of a more functional naming of classes?


Compare before:

http://farm2.static.flickr.com/1331/1093837483_4fe0712799.jpg";
width="500" height="344" alt="NewsFire Software Updates" class="figure
figure-a" />

http://farm2.static.flickr.com/1209/1058437312_8cc542a2a2_o.png";
width="122" height="346" class="figure figure-b" alt="iPhone Template"
/>

And compare after:

http://farm2.static.flickr.com/1331/1093837483_4fe0712799.jpg";
width="500" height="344" alt="NewsFire Software Updates" class="figure
banner" />

http://farm2.static.flickr.com/1209/1058437312_8cc542a2a2_o.png";
width="122" height="346" class="figure inset" alt="iPhone Template"
/>

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

Re: [uf-discuss] Granddogma Goes to Bar Camp

[Paul Wilkins]

From: "Tara Hunt" <[EMAIL PROTECTED]>

This is an awesome post and goes back to a discussion I became very
frustrated in a while back:
http://groups.google.com/group/microformats/browse_thread/thread/611d4e6f671d64bb/378786b75487d62c?lnk=gst&q=Magic&rnum=2#378786b75487d62c


So what is it that a layperson would call what microformats does?

Off the top of my head, they help you share information, so you can use it 
with other systems.


It's a shame that "Use It" has already been taken by Nielsen, because I 
think that the term "Use It" nicely encapsulates what microformats allows 
you to do. "Use It" also provides a nice at-first-glance explanation to 
people who haven't seen it before.


--
Paul Wilkins 


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

Re: [uf-discuss] Nested Microformats and Operator

[Paul Wilkins]

Michael MD wrote:
Marking up the venue location is probably the most common use of nested 
hCard in hCalendar but the other cases are certainly possible.


How would a parser know which it is?


A parser could provide the ability to extract just the top-level elements.

The other elements could be accessed from a tree view, if you're looking 
at an overall structural view.


If you're looking at hcards, they could be notated to indicate which 
ones are embedded and which ones are not.


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

Re: [uf-discuss] Re: ‘XH TML’ references to ‘HTML’

[Paul Wilkins]

On Nov 27, 2007 8:28 AM, Edward O'Connor <[EMAIL PROTECTED]> wrote:
> Ben Ward wrote:
>
> > I'd like us to update the wiki to make all references to 'XHTML' and
> > 'X/HTML' or '(X)HTML' into clear 'HTML'[...] Does this seem worthwhile?
>
> I'm all for it. I'd love to take this even further, and s/XHTML/HTML/ in
> XMDP and XFN, but those ships have sailed.

The only concern that I'd have is that visitors to the site are likely
to think that microformats are an older less worthwhile idea because
of all the HTML references. First impressions can be important, so how
can that be dealt with?

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

Re: [uf-discuss] Re: ‘XH TML’ references to ‘HTML’

[Paul Wilkins]

On Nov 27, 2007 11:01 AM, Ben Ward <[EMAIL PROTECTED]> wrote:
> On 26 Nov 2007, at 21:21, André Luís wrote:
> > Here's an idea... since that would involve altering every page with
> > xhtml in them anyway, why not go one step further and in the first
> > reference to XHTML change it to "HTML or XHTML" with a link to an
> > explanatory page? Stating that ufs work on both worlds.
>
> We could, but does it need greater explanation than 'HTML or XHTML'.
> What more is there to say?

There isn't.
So let us change the first of each page to 'HTML or XHTML' and leave
the rest of the page as it is.

-- 
Paul Wilkins

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

Re: calendar (and other) items aren't always tidy (was: Re: [uf-discuss] using microschema)

[Paul Wilkins]

On Nov 27, 2007 11:57 AM, ken <[EMAIL PROTECTED]> wrote:
> Maybe I'm thinking too far outside the box, but it looks like the
> formats proposed thus far all assume that the (html) content we'll be
> "semanticizing" is going to written in such a way as to accommodate the
> format, that all the information going (ultimately) into, say, the vCard
> for one person will be presented discretely from the vCard information
> for another person.  For example, suppose we have the following text in
> a (fictitious local sports) webpage:
>
> "Bobby and Billy are on the same football team and on Sunday they're
> playing against the Falcons, whose coach is Ron Smith.  Ron Smith is
> Bobby and Billy's father.  The brothers are also the star quarterback
> and star fullback at Pittsfield High."

Now there's a challenge.


  
Bobby

  
  

and

  
Billy

  
  

are on the same football team and on Sunday they're
playing against the Falcons, whose coach is

  
Ron
Smith
.
Ron Smith is Bobby and Billy's father.
The brothers are also the
star quarterback
and star fullback
at Pittsfield High."

This has been tested with Operator, and others should have no trouble either.

Other information could have been marked up, but that's been left as
an exercise should you wish to take things further.

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

Re: [uf-discuss] Re: calendar (and other) items aren't always tidy

[Paul Wilkins]

On Nov 28, 2007 6:09 AM, ken <[EMAIL PROTECTED]> wrote:
> "Taking things further" was the point of my question.  In particular,
> mentioned in the three-sentence example are several organizations-- a
> couple high schools, a couple football teams, and a family-- and each of
> the three people mentioned are members of (have a role in) three (but
> not all) of these organizations.

This is trivial though because the include pattern takes care of most of this.
It takes but a few moments to include other data from the information
that's given.

The include pattern is where you put an id attribute on some piece of
information, so that you can include it elsewhere with
   

This was demonstrated at several places in the sample code, and the
reason for the "left as an exercise" comment.

I shall briefly add the highschool, their football team isn't
mentioned, only their opponents. I have been naughty and called their
football team "The Eagles", even though it's not stated explicitly in
the text.

The family relations come under the topic of genealogy, for which a
microformat is currently being developed
http://microformats.org/wiki/genealogy

The game that's happening "this sunday" doesn't have a date, but I'll
assume that it's the 2nd of December as the information was written
just a few days ago.

So the information that I've marked up from this for all three people is

- First Name
- Last Name
- Organization Name
- Organization Unit
- Role

Event
- Start Date
- Summary
- Location

Normally the code wouldn't be so many lines, it'd just be inline with
the text and less wieldy, but in the intertested of readability in
this email medium it's been given a more vertical layout.


 Bobby
   
 
 
   
   
 
 

and

   Billy
   
 
 
   
   
 
 

are on
the same football team
and

 on Sunday
 they're
 playing against the
   Falcons
 ,
 

whose coach is

 
   Ron
   Smith
 
 
   
 
 
.
Ron Smith is Bobby and Billy's father.
The brothers are also
the star quarterback
and star fullback
at Pittsfield High.

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

Re: [uf-discuss] hCalendar, geo & Operator extension

[Paul Wilkins]

On Dec 4, 2007 10:26 AM, Ben Ward <[EMAIL PROTECTED]> wrote:
> The critical part of the HTML4 spec that causes 'Rayenda, Bangladesh'
> *not* to be an abbreviation of '22.31119;+89.86145' is this:
>
> "The content of the ABBR and ACRONYM elements specifies the
> abbreviated expression itself, as it
> would normally appear in running text. The title attribute of
> these elements may be used to provide
> the full or expanded form of the expression."
>
> "as it would normally appear in running text."

For the ABBR element to be use properly the title attribute would need
to contain not a single point coordinate, but a representation of the
Rayenda area itself. While this could be done by combining the
techniques for image map poly coordinates with actual geo-coordinates,
this needs to be more carefully and fully thought out.

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

Re: [uf-discuss] Jeremy's inline friend link pattern

[Paul Wilkins]

On Dec 6, 2007 4:20 AM, Thom Shannon <[EMAIL PROTECTED]> wrote:
> Jeremy Keith wrote:
> > The spec says that the element should contain "a reference to other
> > sources" and even gives an example of citing a person:
> I had a look at the specs too and it did seem to make sense. If you're
> referring to something someone said then that's clearly a citation. What
> if you're just saying they were present at an event? You can't really
> cite someone for that.

Not unless they said or did something. The CITE element really
shouldn't stand alone, as there's an unstated source/target
relationship implied in its usage.

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

Re: [uf-discuss] Jeremy's inline friend link pattern

[Paul Wilkins]

On Dec 6, 2007 2:16 PM, Jeremy Keith <[EMAIL PROTECTED]> wrote:
> I don't believe that's true. The cite element can be used when the
> author is referring to something; not when that that something is
> doing the referencing. So, for example, if I refer to a book or a
> film, I'll enclose that inside a cite element. It can stand alone
> because there is no implied relationship other than "this is an entity":
>
> The Usual Suspects
>
> Designing with Web Standards
>
> I will use that markup even if I'm not quoting or citing anything
> from that entity. That seems to be perfectly in line with the spec.

It remains to be asked then, where is the citation?
The contents of the CITE element contains the object being cited, so
where is the subject?
You cannot have a citation without a subject.

How can you have any pudding if you don't eat your meat?!

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

Re: [uf-discuss] Jeremy's inline friend link pattern

[Paul Wilkins]

On Dec 6, 2007 11:46 PM, Jeremy Keith <[EMAIL PROTECTED]> wrote:
> As far as I can see, the
> CITE element can (and should) be used when you are *referencing* a
> resource (book/film/person, etc.) regardless of what the surrounding
> context is.
>
> So in HTML I could say:
>
> The film Gone With The Wind contains the line Frankly
> my dear, I don't give a damn.

Yes, that's fine, you have the relationship of
gone with the wind => quotation

> But I could equally say:
>
> Gone With The Wind is a film.

You could say it, but you'll be wrong.

> Or even:
>
> Gone With The Wind

it makes no sense to have a citation all by itself.

As time goes on, people have been using the cite element for more and
more inappropriate uses. The developers understand this and have been
providing more accurate descriptions of how the CITE element is to be
used.

HTML 5 says the following
http://www.whatwg.org/specs/web-apps/current-work/#the-cite

The cite element represents a citation: the source, or reference, for
a quote or statement made in the document.

A citation is not a quote (for which the q element is appropriate).

This is incorrect usage:

This is wrong!, said Ian.

This is the correct way to do it:

This is correct!, said Ian.

This is also wrong, because the title and the name are not references
or citations:

My favourite book is The Reality Dysfunction
by Peter F. Hamilton.

This is correct, because even though the source is not quoted, it is cited:

According to the Wikipedia article on
HTML, HTML is defined in formal specifications that were
developed and published throughout the 1990s.

And XHTML 2.0 has this to say
http://www.w3.org/TR/xhtml2/mod-text.html#sec_9.2.

The cite element contains a citation or a reference to other sources.

In the following example, the cite element is used to reference the
book from which the quotation is taken:

cite as book reference

As Gandalf the White said in
http://www.example.com/books/the_two_towers";>The Two Towers,
"The hospitality of
your hall is somewhat lessened of late, Theoden King."

cite to reference another specification

More information can be found in
http://www.w3.org/TR/REC-xml";>[XML].

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

Re: [uf-discuss] Jeremy's inline friend link pattern

[Paul Wilkins]

On Dec 8, 2007 2:22 AM, Jeremy Keith <[EMAIL PROTECTED]> wrote:
> I was chatting with  title="Tantek Çelik"> href="http://tantek.com/";>Tantek yesterday.
>
> So, quick straw poll: does that look a reasonable use of the CITE
> element? Does anything think that SPAN would be a better/safer option
> in this case? I suppose it would probably depend on the rest of the
> paragraph or blog post but usually you wouldn't mention someone in a
> blog post without some reason that probably involves referencing
> them, right?

If it is followed by something that was clearly sourced from Tantek
then it would be okay.

Think about it like this. The CITE element represents the source or
reference for a quote or statement.
No quote, no statement, no cite. It's as simple as that.

-- 
Paul Wilkins

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

Re: [uf-discuss] Jeremy's inline friend link pattern

[Paul Wilkins]

On Dec 8, 2007 2:22 AM, Jeremy Keith <[EMAIL PROTECTED]> wrote:
> However, I don't think that every use of the CITE element *requires*
> an accompanying citation (using Q or BLOQCKQUOTE). I think that Scott
> is write when he says that context is the key criteria:

The CITE element doesn't require that the citation be explicitly
marked up, but there has to be a citation of some form for the CITE
element to be involved.

This is right:
According to the Wikipedia article on HTML, HTML is
defined in formal specifications that were developed and published
throughout the 1990s.

This is wrong:
My favourite book is The Reality Dysfunction by
Peter F. Hamilton.

The above examples are explicit examples that the specifications give
to help teach you right from wrong.
You will need to convince the working group that created the
specifications otherwise, before your desired use is to be considered
right.

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

Re: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes)

[Paul Wilkins]

On Dec 15, 2007 9:19 AM, Martin McEvoy <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-12-14 at 19:21 +, Ben Ward wrote:
> > '3:23' IS NOT an
> > abbreviation of the string 'PT3M23S' (hAudio).

I think you're right. It should be P3M23S instead.

> A couple of us involved in the brainstorming and after, Myself and Andy
> I think recommended that the duration class should just be expressed as
>
> 3:23
>
> Its enough for hAudio I think and doesn't violate the abbr pattern as
> the current spec tentatively does.

Will you be contesting the date pattern as well? If the date pattern
is acceptable then the time pattern is directly acceptable as well
through the very same standards.
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes)

[Paul Wilkins]

On Dec 15, 2007 12:18 PM, Martin McEvoy <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-12-15 at 10:13 +1300, Paul Wilkins wrote:
> > I think you're right. It should be P3M23S instead.
>
> I dont think thats its possible to drop the *T*

You're right, the T has to be there to resolve any ambiguity between
month and minute.

PT3M23S is ISO 8601 notation for 3 minutes and 23 seconds.

> you could perhaps do PT3:23 ? which seems more accurate

Then it won't be able to be parsed as an actual time.



> No I do not have enough wisdom to say what is right or wrong.
> I do NOT however believe that machine data should be displayed in a
> people area such as @title, I think machine data can be stored elsewhere
> in a document such as in the  in a list of 's or 's

The data format is machine data, as are geo-coordinates as well.
The machine data has to remain with the human data so that
discrepancies between the two aren't allowed to occur.

When thinking about other time formats, consider how 3 seconds would
be marked up, or even days and weeks.

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

Re: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes)

[Paul Wilkins]

On Dec 15, 2007 1:21 PM, Martin McEvoy <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-12-15 at 12:33 +1300, Paul Wilkins wrote:
> > On Dec 15, 2007 12:18 PM, Martin McEvoy <[EMAIL PROTECTED]> wrote:
> > > you could perhaps do PT3:23 ? which seems more accurate
> > Then it won't be able to be parsed as an actual time.
>
> hmm are you sure? 3:23 is expressed as whole plus a decimal fraction

That's if you use a comma or a fullstop. With the full colon it's
interpreted as hours and minutes.
[QUOTE]
It is also acceptable to omit elements to reduce precision. [hh]:[mm],
[hh][mm] and [hh] are all used.

Decimal fractions may also be used with any of the three time
elements. These are indicated by using the decimal point (either a
comma (which is preferred ISO 31) or dot). A fraction may only refer
to the most precise component of a time representation. To denote "14
hours, 30 and one half minutes", do not include a seconds figure.
Represent it as "14:30,5" or "1430,5".
[/QUOTE]

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

Re: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes)

[Paul Wilkins]

On Dec 15, 2007 1:36 PM, Paul Wilkins <[EMAIL PROTECTED]> wrote:
> On Dec 15, 2007 1:21 PM, Martin McEvoy <[EMAIL PROTECTED]> wrote:
> > hmm are you sure? 3:23 is expressed as whole plus a decimal fraction
>
> That's if you use a comma or a fullstop. With the full colon it's
> interpreted as hours and minutes.
> [QUOTE]
> It is also acceptable to omit elements to reduce precision. [hh]:[mm],
> [hh][mm] and [hh] are all used.
>
> Decimal fractions may also be used with any of the three time
> elements. These are indicated by using the decimal point (either a
> comma (which is preferred ISO 31) or dot). A fraction may only refer
> to the most precise component of a time representation. To denote "14
> hours, 30 and one half minutes", do not include a seconds figure.
> Represent it as "14:30,5" or "1430,5".
> [/QUOTE]

The least that could be got away with is 00:03:23, at which point it
would be a toss up between that or PT3M23S

Both of the above formats are valid and should be accepted by parsers
as a part of the ISO 8601 time/date format.

Issues when people markup using the first example are that they are
tempted to leave out the hours part and put in 03:23 or even just
3:23, and are left puzzling about why it's interpreted as 3 hours 23
minutes.
Issues with the second format is that the abbr tag is in danger of
blowing up from excessive stretching of its semantic meaning.

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

Re: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes)

[Paul Wilkins]

On Dec 15, 2007 8:21 AM, Ben Ward <[EMAIL PROTECTED]> wrote:
> Agreed. I'll repost something I put into the GEO thread last week.
> It's quoting directly from the HTML4 specification. 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. We *do not* have the authority to disobey the
> spec. We may interpret it _more strictly_ perhaps, but we may not
> _relax_ any of the definitions it provides. Otherwise we have no leg
> to stand on regarding the effect our code has on _any_ consuming tool.

I agree, on the proviso that we take into account redefinitions from
HTML5 and XHTML 2.0, for in several cases they have provided a greater
understanding of the intention than the earlier HTML4 spec thought to
provide.


> 'One hour ago' is NOT ever an abbreviation of a timestamp. 'last
> week' IS NOT an abbreviation of a timestamp. 'London' IS NOT an
> abbreviation of a set of co-ordinates and '3:23' IS NOT an
> abbreviation of the string 'PT3M23S' (hAudio). In all of those cases
> they are 'alternative representations', or 'expansions' or perhaps
> 'precisions'. They ARE NOT abbreviations and they are in clear
> conflict with the HTML spec which states the TITLE attribute of ABBR
> must be 'the abbreviated expression itself, as it would normally
> appear in running text'. Sorry, but the ball got dropped on this, and
> people have been treating the ABBR-pattern as a handy pattern first
> and HTML second. That is the wrong way around.

I have to agree here.

> So we have a problem. We now have multiple use cases where it is
> necessary for publishers to include precise machine data alongside
> human legible descriptions. They are rarely real abbreviations.
>
> I am going to ask that we better define the problem. That we follow
> up the demand for a better pattern (regardless of whether your
> personal motivation is following the spec or assistive technology).
> I'd like to ask that people stop jumping straight in with ideas for
> alternative mark-up, ways of kludging the existing practice into
> different elements or attributes. Follow the process. We need to
> fully define the problem: We need a list of which microformat
> properties _require_ the facility for precise representations. They
> don't all need it, maybe we just need something that certain
> properties may opt into, rather than something that covers all
> microformats properties. That's what we need to determine. From
> there, we can move on how to integrate the data back into mark-up.

The hAudio time should be denoted in seconds. If 3:23 is given it's to
be seen as three minutes and twenty two seconds. If hours are needed
it should be 1:3:23 (0 prefix optional) to denote 1 hour three minutes
and twenty two seconds.

This way the hAudio standard can work without needing to modify the
text, the abbr pattern isn't required and everybody can go home and
sleep restfully for the night.

> Thank you,

I concur.

-- 
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?
>
> 3:23
>
> - 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."

3:23

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

3: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