I too find ths area of microformats one of the weaker areas of consensus and of having strong examples of best practices.
On the one hand, there's the matter of style, where certain data are hidden in the interest of visual appeal (CSS Zen Garden, etc). Other times, data that is necessary for computer interpretation is hidden to save cluttering the human-friendly view -- lately a discussion on the inclusion of countries at Upcoming. Then, and these are the compelling cases to address for me, there are cases of data fidelity both on lesser devices (like mobile phones -- i.e. without any CSS) and then the matter of fidelity when copying data on the client-side from one app or site to another (see live clipboard). In any case, I think we need best practices on the implementors side and then set expectations on the end-user/client side. And, in most cases, some semantics are better than none. I mean, let's face it, MP3s serve a purpose even when FLAC is a superior format so all this hand-wringing, while important, should still be considered in applicable contexts. Microformats don't replace filesystems, but they do help us represent and pass data around a bit more freely. Chris Chris On 1/13/07, Chris Casciano <[EMAIL PROTECTED]> wrote:
On Jan 13, 2007, at 1:19 PM, Scott Reynen wrote: > On Jan 13, 2007, at 8:47 AM, Mike Schinkel wrote: > >> It really makes more sense to look at the use-case rather than to >> issue a >> blanket edit of prohibition. > > It does. My answers were addressing only the ~80% use cases we're > seeking to cover here. For anything involving the other ~20%, I > continue to recommend RDF as a good solution for hidden data. I > hope no one will restrict themselves to microformats as a blanket > solution to all data markup problems, as that's not what > microformats are intended to be. > > Peace, > Scott I tend to include myself in the camp of those who can't seem to reconcile this POV with my other notions of good web development practices. I can't argue that in some cases other data methods might be more appropriate, or that there are dangers in maintaining "hidden" information but each time this discussion has surfaced I'm left with the feeling that the party line around these parts brush off three things: the amount of data we're already "hiding" by other means, the ability of technology to bypass the issue of not updating hidden information and some of the core strengths of web techs (css, js). On the first issue I don't see a huge gap between the "harmfulness" of display:none vs. data being included in HTML attributes that also don't get seen by huge numbers of visitors... rel XFN values, title attributes or alt attributes used in cases like FN derived from photo alt. In my own experience I have seen countless more cases of ALT attribute content being missed [either not changed with the photo change or good values being replaced with junk] when an image gets changed then I could ever imagine seeing in a microformats data case. But I would be the last person to suggest that ALT attributes are considered harmful on today's web. In sort-of-but-not opposition to that notion, I think that there are many, many cases where content is generated not by hand but from some bigger content generation system thus throwing any maintenance issues out the window. Be it user data generated from the system, event data, or any other automated data there is little impact on the quality of information by the presentation of that same information. At least insofar as not being included in the HTML at all vs. including it but using display:none [the discussion of user behavior and their willingness to update a field in their profile that they never 'see' anywhere is, i would expect, the same for both cases]. Additionally, in cases of rudimentary systems like static includes the ability to use CSS to hide the information in some of the situations the data is used I would think would be preferred over having to manage multiple include blocks - one for each desired presentation. Which leads me to my last issue, and one that I think is the one i struggle most with when thinking about how to do web dev the "right" way. Clearly good data in title and rel attributes is 'right', as is using markup in ways that would get you into the alt attribute cases. But it is hard for me to reconcile the use of previous web development methods [separation of content and presentation & progressive enhancement] with the camp that takes a hard line on hidden elements being harmful. There are little cases like the ways in which elements may be manipulated in techniques like image replacement or accessible scripting techniques... On some level we do things like "hide" much more important informations like navigation day in and day out. Then there are other cases like multiple media types, alternate style sheets and similar cases which I just don't see how they square with the "hidden elements considered harmful" sentiment. Outside of the extreme CSS Zen Garden cases, or the mostly impossible & impractical site redesign by changing /only/ the CSS holy grails, there are still cases where it would be more 'proper' to leverage CSS then it would be to edit the HTML or HTML generation code. Message board applications with different user selected skins that present content a bit differently (Vanilla), Blog themes, community sites where users edit their profile presentation via CSS... all cases where CSS usage in this way would be seen as leveraging the strengths of the technology. -- [ Chris Casciano ] [ [EMAIL PROTECTED] ] [ http://placenamehere.com ] _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
-- Chris Messina Citizen Provocateur & Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable [X] ask first [ ] private _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
