Re: [uf-discuss] Human and machine readable data format
Hello, The English calendar prior to 1752 was a Julian calendar with the start of the year on 25th March. Samuel Pepys diary is an example of publishing that calendar online (I think): http://www.pepysdiary.com/ I imagine any historical date prior to the 20th Century is potentially a problem, as the Julian calendar was still in use as late as the 1920s in some parts of the world. http://en.wikipedia.org/wiki/Gregorian_calendar has handy timelines and tables showing when the Gregorian calendar was adopted around the world, and when 1st January was adopted as the beginning of the year in various countries. TEI has some guidance on marking up historical dates, which might be relevant. http://www.tei-c.org/Guidelines/P4/html/CO.html#CONADA I don't know if there are any other online guides to encoding dates and times from different calendars. Jim Original Message: - From: Scott Reynen [EMAIL PROTECTED] Date: Tue, 15 Jul 2008 08:19:38 -0600 To: microformats-discuss@microformats.org Subject: Re: [uf-discuss] Human and machine readable data format On [Jul 15], at [ Jul 15] 5:51 , Ciaran McNulty wrote: Another example of non-Gregorian calendaring is Saudi Arabia, where the arabic calendar is in common usage: http://www.sama.gov.sa/ Thanks Karl and Ciaran. I've added these examples to the wiki here: http://microformats.org/wiki/hcalendar-brainstorming#Non-Gregorian_Calendars Please add any more examples you find so we can keep the discussion focused on what would help publishers. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss mail2web.com What can On Demand Business Solutions do for you? http://link.mail2web.com/Business/SharePoint ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] HTML 5 data- attributes
I believe this new HTML feature found in the HTML 5 draft
specification should be taken into account in here, since it is
relevant to many ongoing discussions...
via John Resig (jQuery main developer)
A new feature being introduced in HTML 5 is the addition of custom
data attributes. This is a, seemingly, bizarre addition to the
specification - but actually provides a number of useful benefits.
Simply, the specification for custom data attributes states that any
attribute that starts with data- will be treated as a storage area
for private data (private in the sense that the end user can't see it
- it doesn't affect layout or presentation).
This allows you to write valid HTML markup (passing an HTML 5
validator) while, simultaneously, embedding data within your page. A
quick example:
li class=user data-name=John Resig data-city=Boston
data-lang=js data-food=Bacon
bJohn says:/b spanHello, how are you?/span
/li
The above will be perfectly valid HTML 5. This should be a welcome
addition to nearly every JavaScript developer. The question of the
best means of attaching raw data to HTML elements - in a valid manner
- has been a long-lingering question. Frameworks have tried to deal
with this in different manners, two solutions being:
Using HTML, but with a custom DTD.
Using XHTML, with a specific namespace.
The addition of this prefix completely routes around both issues
(including any extra markup for validation or needing to be valid
XHTML) with this effective addition.
On top of this a simple JavaScript API is presented to access these
attribute values (in addition to the normal get/setAttribute):
var user = document.getElementsByTagName(li)[0];
var pos = 0, span = user.getElementsByTagName(span)[0];
var phrases = [
{name: city, prefix: I am from },
{name: food, prefix: I like to eat },
{name: lang, prefix: I like to program in }
];
user.addEventListener( click, function(){
var phrase = phrases[ pos++ ];
// Use the .dataset property
span.innerHTML = phrase.prefix + user.dataset[ phrase.name ];
}, false);
The .dataset property behaves very similarly to the the .attributes
property (but it only works as a map of key-value pairs). While no
browsers have implemented this exact DOM property, it's not hugely
needed - the above code could be done with the critical line replaced
with:
span.innerHTML = phrase.prefix +
user.getAttribute(data- + phrase.name );
I think what is most enticing about this whole specification is that
you don't have to wait for any browser to implement anything in order
to begin using it. By starting to use data- prefixes on your HTML
metadata today you'll be safe in knowing that it'll continue to work
well into the future. The time at which the HTML 5 validator is
integrated into the full W3C validator your site will already be
compliant (assuming, of course, you're already valid HTML 5 and using
the HTML 5 Doctype).
http://www.w3.org/html/wg/html5/#custom
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] HTML 5 data- attributes
I agree this is a nice solution to solve, for example, the
accessibility problems with the datetime pattern. But not for the
entire set of properties.. it darkens the data, makes the author
repeat information, etc...
For the abbr-based design patterns, I totally agree. For the rest, not so much.
A good compromise, IMHO, that has already been sugested here, would be
to port these attributes to classnames (data-*).
Custom DTDs for HTML, adding new namespaces to XHTML... I believe this
is a whole new path for microformats that needs to be assessed whether
we actually _need_ to go.
--
André Luís
On Wed, Jul 16, 2008 at 11:28 AM, LucaP [EMAIL PROTECTED] wrote:
I believe this new HTML feature found in the HTML 5 draft
specification should be taken into account in here, since it is
relevant to many ongoing discussions...
via John Resig (jQuery main developer)
A new feature being introduced in HTML 5 is the addition of custom
data attributes. This is a, seemingly, bizarre addition to the
specification - but actually provides a number of useful benefits.
Simply, the specification for custom data attributes states that any
attribute that starts with data- will be treated as a storage area
for private data (private in the sense that the end user can't see it
- it doesn't affect layout or presentation).
This allows you to write valid HTML markup (passing an HTML 5
validator) while, simultaneously, embedding data within your page. A
quick example:
li class=user data-name=John Resig data-city=Boston
data-lang=js data-food=Bacon
bJohn says:/b spanHello, how are you?/span
/li
The above will be perfectly valid HTML 5. This should be a welcome
addition to nearly every JavaScript developer. The question of the
best means of attaching raw data to HTML elements - in a valid manner
- has been a long-lingering question. Frameworks have tried to deal
with this in different manners, two solutions being:
Using HTML, but with a custom DTD.
Using XHTML, with a specific namespace.
The addition of this prefix completely routes around both issues
(including any extra markup for validation or needing to be valid
XHTML) with this effective addition.
On top of this a simple JavaScript API is presented to access these
attribute values (in addition to the normal get/setAttribute):
var user = document.getElementsByTagName(li)[0];
var pos = 0, span = user.getElementsByTagName(span)[0];
var phrases = [
{name: city, prefix: I am from },
{name: food, prefix: I like to eat },
{name: lang, prefix: I like to program in }
];
user.addEventListener( click, function(){
var phrase = phrases[ pos++ ];
// Use the .dataset property
span.innerHTML = phrase.prefix + user.dataset[ phrase.name ];
}, false);
The .dataset property behaves very similarly to the the .attributes
property (but it only works as a map of key-value pairs). While no
browsers have implemented this exact DOM property, it's not hugely
needed - the above code could be done with the critical line replaced
with:
span.innerHTML = phrase.prefix +
user.getAttribute(data- + phrase.name );
I think what is most enticing about this whole specification is that
you don't have to wait for any browser to implement anything in order
to begin using it. By starting to use data- prefixes on your HTML
metadata today you'll be safe in knowing that it'll continue to work
well into the future. The time at which the HTML 5 validator is
integrated into the full W3C validator your site will already be
compliant (assuming, of course, you're already valid HTML 5 and using
the HTML 5 Doctype).
http://www.w3.org/html/wg/html5/#custom
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] HTML 5 data- attributes
On 16/07/2008, André Luís [EMAIL PROTECTED] wrote: I agree this is a nice solution to solve, for example, the accessibility problems with the datetime pattern. But not for the entire set of properties.. it darkens the data, makes the author repeat information, etc... For the abbr-based design patterns, I totally agree. For the rest, not so much. A good compromise, IMHO, that has already been sugested here, would be to port these attributes to classnames (data-*). Custom DTDs for HTML, adding new namespaces to XHTML... I believe this is a whole new path for microformats that needs to be assessed whether we actually _need_ to go. Well, as of *now* it's not about need so much as want. Custom DTDs and new namespaces etc. just aren't in the realm of what microformats are doing, or should be doing, at the moment. -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] HTML 5 data- attributes
2008/7/16 Frances Berriman [EMAIL PROTECTED]: On 16/07/2008, André Luís [EMAIL PROTECTED] wrote: Custom DTDs for HTML, adding new namespaces to XHTML... I believe this is a whole new path for microformats that needs to be assessed whether we actually _need_ to go. Well, as of *now* it's not about need so much as want. Custom DTDs and new namespaces etc. just aren't in the realm of what microformats are doing, or should be doing, at the moment. --- the other reason microformats work so well is that they compliment already existing, widely deployed technologies. We should avoid hanging any design patterns on a format that has yet little or no adoption. We should focus on a solution that works in HTML 4.0 on the billions of pages that are already published. If and when other technologies emerge, we can solve problems then, no need to spend the effort on early adopter edge-cases at the moment. -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] HTML 5 data- attributes
On 16 Jul 2008, at 11:28, LucaP wrote: I believe this new HTML feature found in the HTML 5 draft specification should be taken into account in here, since it is relevant to many ongoing discussions... http://www.w3.org/html/wg/html5/#custom In addition to the existing replies, and the fact that microformats are currently designed to work in HTML4 and not unstable drafts, quoting the specification itself: User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values. -data prefix attributes are, by design and intention, for use by individual applications. They are explicitly excluded as a mechanism for microformats and the like. B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] HTML 5 data- attributes
On Wed, Jul 16, 2008 at 10:20 AM, Ben Ward [EMAIL PROTECTED] wrote: User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values. -data prefix attributes are, by design and intention, for use by individual applications. They are explicitly excluded as a mechanism for microformats and the like. Indeed. And: Embedding custom non-visible data goes rather against marking visible data. Brief #whatwg conversation: http://krijnhoetmer.nl/irc-logs/whatwg/20080520#l-70 -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Extending hCard with RDFa
I mentioned that I was working on an article about extending hCard with RDFa a few weeks ago on the Microformats discussion list, but then went on holiday and forgot about it for a while. Anyway... http://tobyinkster.co.uk/blog/2008/07/16/hcard-rdfa/ -- Toby A Inkster mailto:[EMAIL PROTECTED] http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
