Re: [uf-discuss] using rel to point to remote meta-data resource for a url identified resource
On Wed, Dec 17, 2008 at 7:20 AM, Toby A Inkster m...@tobyinkster.co.uk wrote: Which brings me to the point that this is re-inventing something that RDFa can already deal with very easily: img src=photo_of_cow.jpeg rel=meta resource=metadata_about_photo_of_cow / This is already supported by many existing tools. You might also consider using the longdesc attribute of the img tag. This attribute takes a URI which points to a resource containing the long description of an image. You might consider putting any metadata about the image in this longdesc resource along with the long description itself. This method, however, is only relevant to image tags and is not a catch-all for any old resource. ~Jason ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard UID was: hatom tumblr theme
On Wed, Dec 17, 2008 at 4:01 PM, Scott Reynen sc...@randomchaos.com wrote: I can use that same URL as my UID on any site, not just blogs and wikis. Whenever I find myself stating something that seems obvious like that, I start to suspect there's some larger misunderstanding underlying the discussion, but I have no idea what that might be. Real world examples are a good way to reveal hidden assumptions... I'd just like to clear up at least one assumption, if only for myself. I don't believe anyone is advocating that UIDs may *only* be URLs. So if for some reason a URL is not available or cannot be guaranteed to be unique (to the subject of the hCard), then other forms of IDs are acceptable. The only argument that I see here is whether URLs are *ever* acceptable as UIDs, correct? ~Jason ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] xoxo double newline in ie6
This is a hasLayout bug in IE. Simply giving 'layout' to either the LIs or the UL will solve the problem. There are many ways to do this (applying height, setting the zoom property, using display:block) and each have their own benefits and drawbacks. For a full explanation and many possible solutions, see: http://www.satzansatz.de/cssd/onhavinglayout.html To jump directly to the list-specific info, see: http://www.satzansatz.de/cssd/onhavinglayout.html#list ~Jason ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Lets talk about rev?
I agree with Martin that it's sad we are unable to take advantage of this attribute where possible. The whole idea of completely ignoring a tiny piece of semantic markup simply because it's often mis-used in the wild seems misguided to me. If we (as users of web standards, not the microformat community) were to use markup as used in the wild, we would still be stuck with font tags and tables. The difference is that we know better and can inform others of its proper use. I see a striking resemblance to the use of the address element. It is quite often mis-used in the wild to markup any contact information whatsoever not being limited to contact info for the page. But with regards to this element, the community has simply taken the stance of informing its proper use, not ignoring it completely. Why not the same with @rev? ~Jason ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Human and machine readable data format
The premise that publishers will pick any old format is merely an assertion with no evidence. Please show us an example somewhere else where this has happened, or perhaps a better argument than merely insisting on the obvious truth of it. The way I see it, if they publish in the wrong format, then the parsers won't pick up the date. This is what happens with microformats already. I don't know about anyone else, but when I publish a microformat, I test whether parsers can read it correctly. I do the same thing with any html. If a publisher can't take the time to test, and publish in the correct format then they take the consequences. it's exactly the same with any other technology. Why should microformats be any different? Why do you think making a microformat resemble natural language drastically changes this set of rules? The problem is as simple as testing in a parser to verify that the format is correct. NLP is too difficult to easily solved in every parser. The outcome will be that different parsers will handle different levels of NLP, parsing only subsets of accepted 'native language formats'. This is similar to the way many parsers are now. (Many parsers handle different portions of the specs. Few handle the entire spec. Case in point: the include pattern.) Even assuming the very extreme case that all parsers handle the same string formats, no parser will ever handle every possible language permutation. The only solution that will result in practical parser use will *require* some amount of data duplication. Just as you stated: 1. metadata and information hiding is out of the question 2. putting ISO 8601 style dates (machine dates) in any place where a human can see it or have it read to them is the problem that we are trying to solve, so we can't do that. 3. The date cannot resemble anything a human might want to read. One of the above rules must be broken. #2 is the problem as you said. #3 will result in a 'spec' that will never be fully implemented in all parsers and will thus never be practical for publishing. #1 therefore must be broken. I don't understand why this is even an argument at this point. The abbr-pattern was already accepted though it violates this principle. The only reason it is rejected now is because of the semantics of the @title attribute. Thus any solution that violates principle #1 in the same way as the abbr-pattern should also be acceptable so long as it does not suffer the same accessibility issue. Any sort of class=data-* solution seems to be an acceptable compromise (and a compromise is what is required). It keeps the data machine-readable without making parsing impractical. It keeps the machine data out of human-readable context (@title). And it keeps the duplicate data near the human-readable version for maintenance. (Though I take exception with the duplicate-data principle as most publishers use automated tools that easily duplicate data without causing stale-issues.) ~Jason ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar Acid Test #1
On 4/15/08, Dmitry Baranovskiy [EMAIL PROTECTED] wrote: Very nice. I was working on creating an ACID test for µf for couple of weeks now, but in different way. I was trying to find all the edge cases in parsing any µf. Here is a link: http://microformatique.com/optimus/test.html It is not finished however. But it is quite tricky and helped me to find a lot of bugs in Optimus. I would add an edgecase where: span id=summary class=summarySummary SPAN/span ... th id=title axis=summary em class=summarySummary EM/em strong class=descriptionDescription/strong /th ... td headers=titleCell contenta href=#summary class=includetext/a/td I am working on an example to test this with Operator, because Operator picks up the summary and description properties from the TH (using @headers) but only when the a include is not used. I would assume that default behavior should be to use any properties found first in the TD cell. Then follow the include pattern to find any additional properties. Lastly, search for properties found in the TH cell(s) as referenced by @headers. Any property values defined more than once are taken as the value defined first. (I believe this is already the case with the include pattern, I am simply generalizing to the @headers pattern.) ~Jason ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microservices
On Wed, Mar 12, 2008 at 1:47 AM, Gustavo [EMAIL PROTECTED] wrote: I may be wrong - in which case, it's probably a good idea if we see if Microsoft's OpenService stuff gets implemented anywhere outside of Internet Explorer 8. Mike Kaply has produced another microformats-related extension for Firefox that uses IE8's Activities. http://www.kaply.com/weblog/2008/03/07/microsoft-activities-for-firefox-new-version/ ~Jason ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: hCalendar for events in a table format
On Wed, Mar 5, 2008 at 1:45 PM, Ryan King [EMAIL PROTECTED] wrote: On Mar 5, 2008, at 7:30 AM, Tantek Çelik wrote: On 3/5/08 5:02 AM, Toby A Inkster [EMAIL PROTECTED] wrote: However, implied headers like this while lowering the barrier to entry for authors, would considerably raise the barrier for parsers -- mostly because of colspan and rowspan, which would be an absolute pain to handle. Speaking from the experience of working on a browser rendering engine which *did* have to handle colspan and rowspan, I can certainly state that requiring a microformats parser to perform a table layout (effectively what it takes to support colspan and rowspan) would *drastically* raise the effort necessary and would introduce numerous opportunities for subtle bugs and incompatibilities. Though I don't disagree with you that requiring table layout is too much, I just wanted to point out that the current HTML5 draft includes a more fully specified algorithm for determining table headers: http://www.whatwg.org/specs/web-apps/current-work/#header-and-data-cell-semantics -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss I am a little worried about dropping support for hCalendar in table markup. If the most semantic markup for a given hCalendar is in a table, then to use hCalendar authors would be required to use less-semantic markup. I think we can all agree this is not a desired side effect of using microformats. We would then have the table-based markup situation of the 90's, only reversed. (using alternative markup such as divs and spans where tables *should* be used). ~Jason ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Precise Expansion Patterns
I realize that the OBJECT element has lost favor in the include-pattern due to browser issues. But it provides a @data attribute which, can be used to specify the location of the object's data, for instance image data for objects defining images, or more generally, a serialized form of an object which can be used to recreate it. [http://www.w3.org/TR/html401/struct/objects.html#adef-data] Given the browser issues, this won't work for everyone all the time but, truth be told, nothing ever does. Could the object/@data pair be considered as an option to be used at the author's discretion (perhaps as an alternative to the empty anchor proposed earlier.) ~Jason ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
On 9/5/07, André Luís [EMAIL PROTECTED] wrote:
Hello everyone.
- when the user hovers on the margin-mark, the user-agent should
'target' to the (root?) element (like what's done with the #anchor in
urls) and that would allow the publishers to specify the
looks/highlight accordingly. Like:
.vcard:target {
border:1px solid red;
}
or even
.vcard:target .actions{
visibility: visible;
}
(without constraining the publisher to a specific class name or element)
I agree with many of the previous sentiments. Dimitri's mockups are
an excellent idea and I also think it would be great to style the uf
targets via CSS :target as suggested by André. I would just like to
suggest we keep in mind the way Tails Export displays the available
microformats on a page. As opposed to Operator (which is an
invaluable tool) which uses perhaps too much menu nesting, I feel the
sidebar is the perfect place to organize this type of content.
Coupled with Dimitri's margin-marks, we could have a winner.
Jason
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] adr should be address
An additional reason, is that the address element cannot contain block-level children, so to have block-level children, you would need a block-level parent. Jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thom Shannon Sent: Sunday, February 25, 2007 7:18 PM To: Microformats Discuss Subject: Re: [uf-discuss] adr should be address Sorry Ben! it was you. And you're right, the examples in the docs are a bit misleading. Ben Ward wrote: On 25 Feb 2007, at 23:19, Thom Shannon wrote: Brian Suda made a point at barcamp about the documentation using only divs and spans, so people don't get confused and think that the element types matter. Obviously people should use the most suitable elements in the context they're using them. But I think this should be made much clearer in the wiki. Actually it was me who made that point, unless Brian did as well, separately from the panel. Anyway. Some time ago I suggested we put a disclaimer at the top of each spec making it clear that SPAN/DIV are used for example purposes and then have a new set of 'rich examples', complementing the existing ones, showing more diverse mark-up in use with microformats. Unfortunately I suck and haven't had the organisation to do anything with it, Though it remains on my to-do list. Ben ___ 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Include-pattern issues
I have two issues with the include-pattern, though they are less with the pattern itself and more with simply implementing it. 1) When using IE (6 and 7) there are many styling issues involved with hiding the object element. Simply display:none is not sufficient. 2) Many accessibility 'validators' will flag empty object elements as errors if no fallback text is supplied. Should these issues be listed on the wiki under include-pattern issues, or on a page as special notes about authoring with the include-pattern? Jason Karns ~~~ The Ohio State University [www.osu.edu] Computer Science Engineering [www.cse.osu.edu] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Include-pattern issues
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Breton Slivka Sent: Monday, February 05, 2007 12:51 AM To: Microformats Discuss Subject: Re: [uf-discuss] Include-pattern issues If I remember correctly, these issues can be dealt with by using an a element instead of an object element. This is endorsed in the spec for the pattern, I believe. On 05/02/2007, at 4:00 PM, Jason Karns wrote: I have two issues with the include-pattern, though they are less with the pattern itself and more with simply implementing it. 1) When using IE (6 and 7) there are many styling issues involved with hiding the object element. Simply display:none is not sufficient. 2) Many accessibility 'validators' will flag empty object elements as errors if no fallback text is supplied. Should these issues be listed on the wiki under include-pattern issues, or on a page as special notes about authoring with the include-pattern? Jason Karns ~~~ The Ohio State University [www.osu.edu] Computer Science Engineering [www.cse.osu.edu] ___ 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 That's correct. I meant for these issues to be more like notices when deciding between object and a. When I first started using the include pattern, only object was supported. Luckily, Safari caused enough trouble that a was included as an option. I meant to only add these issues as further reasons for using a. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Extension to include-pattern
As per the include-pattern, I'd like the ability to reference a previously
defined object and include it in a subsequent hcard. In my case, I have the
organization marked up as an hcard and later in the document, I have
additional hcards for employees. As it stands now (or at least how I
understand it), the include object needs only the class 'include'. The
class(es) of the included tree are carried along and used for parsing. Would
it make sense to have any classes on the including object override a class
specified on included tree's root? For instance, my organization is marked
up as an hcard like so:
span class=vcard
span id=firm class=fn org3AM Productions/span is a
span class=noteweb design firm/span
/span
...
span class=vcard
a class=fn url href=jason.php title=see more about
JasonJason Karns/a
/span
And later in an employee's hcard, I would like to include the organization
from the previous hcard. However, due to the overloading of 'fn' and 'org',
if I were to simply include '#firm' into an employee's hcard (which already
has 'fn' defined), I would have a conflict with 'fn'.
span class=vcard
a class=fn url href=jason.php title=see more about
JasonJason Karns/a
object data=#firm class=include/object
/span
Parsed vCard
FN: Jason Karns 3AM Productions ???
URL: jason.php
ORG-NAME: 3AM Productions
NOTE: web design firm
My proposal would be to allow any extra hcard classes on the including
object override the class value on the included subtree. So following the
above example,
span class=vcard
span id=firm class=fn org3AM Productions/span is a
span class=noteweb design firm/span
/span
...
span class=vcard
a class=fn url href=jason.php title=see more about
JasonJason Karns/a
object data=#firm class=include organization-name/object
/span
Notice the extra class on the object element. This class would then override
the classes specified on the included element ('firm'). Thus 'fn org'
becomes 'organization-name' and possible conflicts are avoided.
Parsed vCard
FN: Jason Karns
URL: jason.php
ORG-NAME: 3AM Productions
NOTE: web design firm
Any thoughts?
Jason Karns
~~~
The Ohio State University [www.osu.edu]
Computer Science Engineering [www.cse.osu.edu]
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
