Re: [uf-new] Microformats for hidden data
Hi Scott, Tantek suggested: 2. use the data-* attributes in HTML5 which were explicitly created to handle the use case of data attributes for scripts/script libraries among other things. You replied: The prohibition of using data- attributes for public data seems to be a problem with this particular use case, as analytics engines are generally independent of the site being tracked and These attributes are not intended for use by software that is independent of the site that uses the attributes. I believe you misunderstand the restriction on data-*= attributes. Here's how James Graham explained the restriction recently on the HTML WG mailing list[1]: [A] third party js-library is not considered independent of the site (since the site must decide to import the js-library into its pages). [...] To take a slightly different example, it is OK to have data-marquee that is used by a script that the author includes in the page to implement marquee effects. But it is not permitted for a user agent to provide its own marquee effects based on the presence of a marquee attribute. -- Edward O'Connor hob...@gmail.com 1. http://lists.w3.org/Archives/Public/public-html/2009Oct/0630.html ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: Comment Questions
I'm one of the original authors of the comment proposal--a proposal that we threw together without following the process, and that was made redundant by hAtom. I generally think simply using hAtom is enough; a separate comment format isn't necessary. That said, one thing to potentially look into would be the hAtom-ification of RFC 4685, the Atom Threading Extensions[0], to handle marking up which hentry is a reply to which other hentry. Something along these lines might do the trick: div class=hentry id=foo ... a href=#comments rel=repliescomments/a ... /div div class=hfeed id=comments div class=hentry ... a href=#foo rel=in-reply-to.../a ... /div /div Ted 0. http://www.ietf.org/rfc/rfc4685.txt ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Re: Namespace anti-pattern and hAudio TITLE
Manu wrote: Does it? If 'country-name' isn't namespaced, then we could get rid of country and 'name' by itself would have an unambiguous meaning. I think you're missing the distinction between 'namespace' and 'context', like Tantek suggested. Basically, you're stating the reductio for your own position -- you're basically saying that all adjectives are namespaces, and that's clearly incorrect. However, if we were to do that in practice, 'name' wouldn't mean 'country name' anymore... it would be more ambiguous. By being more ambiguous, we're stating that the prefix that we removed, 'country', actually does have semantic meaning. *Of course* 'country' has semantic meaning. It's an adjective that provides context for 'name'. But context does not a namespace make... 'country' is a namespace that gives scope to the following 'name' by specifying that we are talking about a 'country name' and not a 'person name'. No, country does that because of its adjective-ness, not its namespace-ness. Ted -- Edward O'Connor [EMAIL PROTECTED] Ense petit placidam sub libertate quietem. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Re: I propose a new microformat for poems.
I've been wanting to get rid of the break elements from poetry. We've shied away from a source code microformat, becuase the existing HTML compound of precode works. Isn't the poetry case analagous? (Except that we have no inline element to compound with the pre.) pre class=poem When Aubrey did live there lived no poor, The lord and the beggar on roots did dine With lily, germander, and sops in wine, With sweet-brier, And bon-fire, And strawberry-wire, And columbine. /pre -- Edward O'Connor [EMAIL PROTECTED] Ense petit placidam sub libertate quietem. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
