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

[Chris Casciano]

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 ]