Benjamin Hawkes-Lewis wrote:
Martin McEvoy wrote:
One question what is actually wrong with using an extension eg:
<span class="bday" style="-uf-content:'1968-01-04';">4th Jan,
1968</span>
apart from the CSS validation issues, which when you compare it with
the current <abbr> and @title accessibility issues doesn't seem so
bad to me?
The only direct accessibility issue I can think of is that if you had
a tool that stripped out styling information before presentation to a
user who needed to apply their own formatting, the data would be
stripped along with the presentational suggestions.
agreed....
There are a couple more indirect considerations:
1. Encouraging non-conforming code could produce more mistakes;
without a quality control process, mistakes are less likely to be
noticed when they only affect users with certain disabilities.
yes this too....
2. It would constitute a barrier of adoption to publishers aiming to
produce webpages that conform to accessibility guidelines that require
conforming or even just valid CSS and reduce the benefits of such
microformats reaching users with disabilities via sites designed to be
usable for them. For example, a page using this syntax probably could
not pass WCAG 1.0 Checkpoint 3.2 ("Create documents that validate to
published formal grammars.") and therefore could not pass at the
Priority 2 level.
Nicely said thank you very informative absolutely correct also.
These issues are by no means as significant as the accessibility
problems with abbr and title.
the lesser of the two evils so to speak.. :-)
But in terms of what is wrong with it more generally, this solution is
every bit as non-conforming (though not quite as risky) as an HTML
custom attribute, with the additional ugliness of putting required
data into a layer intended for optional presentational suggestions.
even if they are just presentational suggestions for a parser? because
this is practically what the abbr pattern does using @title? where would
I put that data then? if I were copying popular usage patterns that data
would be in the head in a meta tag referenced in some meaningful way
(how I don't know), but instead it seems (to me) that I have to take
that data and place it in the content hidden in @title a cool trick! I
guess that's why microformats are referred to quite often now as
"hacky". This is just my though so don't jump up and down, I am known to
think a little out of the box, microformats can overcome their issues if
they just accept one thing machine data belongs in the head of a
document, not in the content were it currently is.
Given that HTML custom attributes are a non-starter for microformats
because they build on existing standards, I can't see how this
proposal is going to gain any traction.
It wasn't really a proposal of any kind I am just cycling through the
many options.
--
Benjamin Hawkes-Lewis
_______________________________________________
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
