[uf-discuss] Hidden elements considered harmful (Was: Inline style conflict?)

[Chris Messina]

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 <chris at placenamehere.com> 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 ]
> [ chris at placenamehere.com ] [ http://placenamehere.com ]
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> 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