W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2003

RE: [166] Organize documents so they may be read without style sheets

From: Joe Clark <joeclark@joeclark.org>
Date: Fri, 11 Jul 2003 14:08:13 -0400
Message-Id: <a05200f06bb34ace31ee1@[]>
To: WAI-GL <w3c-wai-gl@w3.org>

I said I'd get Eric Meyer's expert opionion on this issue--

>>>And the difference between floated and positioned elements, very 
>>>roughly, is that floated elements are moved to one side or the 
>>>other but are the same vertical position as they would be if not 
>>>floated, whereas positioned elements can be placed more or less 
>>>anywhere in the page, and can stay in one place on the screen 
>>>while the rest of the page is scrolled.
>>In a word, no. _Eric Meyer on CSS_, p. 197: "So why did we go to 
>>all that effort to use positioning when we'd already used float to 
>>achieve the same effect and didn't have nearly as much to worry 
>>about? Because now we have much more flexibility in terms of where 
>>the sidebar markup can appear. With float, the sidebar had to come 
>>before the entry. Now its markup can be anywhere from before the h1 
>>to after the entry." Merely one example.
>Sorry, this statement by Eric Meyer turns out to be based on a 
>limited view of what can be done. Float allows two or more elements 
>to exist side by side in the presentation. Which one of these is 
>considered a "sidebar" has nothing to do with markup order.
>Concretely, in order to put your menubar after the main content in 
>markup order, but still have it appear to the left of the main 
>content and starting at the same height, you simply put your main 
>content in a div and float it right. Quod Erat Demonstrandum (the 
>thing that needed to be proven).

I asked Eric to confirm or deny. He writes:

>    Deny, to a degree.  He's correct so long as one is only 
>discussing two "columns."  If there are three or more things, then 
>floats can become limited.
>    For example, consider the following markup structure:
>    <div id="masthead">...site's masthead...</div>
>    <div id="skipper">...skiplinks...</div>
>    <div id="content">...main content...</div>
>    <div id="sidebar">...supporting information...</div>
>    <div id="navigation">...get-around links...</div>
>    <div id="footer">...footer...</div>
>Now, assume the navigation ends up as a horizontal list of links 
>between the masthead and content (as we do on DevEdge).  Floats 
>won't help you there: only positioning will do the trick.  True, we 
>could re-order the HTML to match our needs, but that would defeat 
>the purpose of ordering content in a way that's accessible and 
>useful to those without graphical browsers, like cellphone surfers.
>    As well, if you wanted to put the navigation and sidebar in 
>"columns" to the sides of the main content, positioning makes it 
>easier than floats do, in my opinion.  That may be more a matter of 
>personal taste than any sort of inherent technological superiority.
>    In the book, there may have been the implication that positioning 
>was a better solution for that particular markup situation.  What I 
>actually said was that with positioning, the markup could be 
>arbitrarily re-ordered and the layout would stay the same.  Perhaps 
>it would have been better for me to say that positioning, being 
>almost totally insensitive to markup order, provides more layout 
>flexibility than floats, whose behavior does depend on source order. 
>For example, the source order determines which of the two "columns" 
>needs to be floated for a layout to work as intended.  But that 
>leads to discussions of how floats provide more flexibility in terms 
>of footers (since you can't guarantee positioned elements won't 
>overlap, whereas you can keep floats from doing so) and we only had 
>so much space in the book.
>    Hope that helps.


     Joe Clark | joeclark@joeclark.org
     Accessibility <http://joeclark.org/access/>
     Weblogs and articles <http://joeclark.org/weblogs/>
     <http://joeclark.org/writing/> | <http://fawny.org/>
Received on Friday, 11 July 2003 14:17:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:45 UTC