Re: [WSG] Fixed vs flexible layouts
Lee Roberts wrote: Andy wanted to know what the WCAG working group members had to say about fixed and scalable width layouts. I am a member of the working group. Well, I gave an education and it seems the topic has grown to now include more about mobile devices. The purpose of variable width or elastic designs is to help people by allowing them to increase their font size without destroying the design. Yes, you will end up with right-scrolls. It doesn't matter what you do. Thanks for that Lee. So are you saying that the sole purpose of checkpoint 3.7 is to accommodate the resizing of layouts along with text? Does that mean in this case, pixels aren't being considered as relative units, contrary to what the specs say? I have to admit that I have huge problems with the guidelines. Most notably because they don't really tell you why each checkpoint is necessary and how failure to comply can reduce accessibility. Some are obvious, but many others aren't. Andy Budd http://www.message.uk.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Fixed vs flexible layouts
Yes, Checkpoint 3.7 is for resizing along with text. Pixels are not scalable. A pixel is a pixel regardless of how one might look at it. As I recall on a 800x600 screen resolution IE used 1.25 microns for a pixel while Netscape uses 1 micron. On the 1024x768 I recall that IE uses .8 micron for a pixel while Netscape uses .5 micron. Of course, I'm an old guy so my memory may be a little off. That's why looking at pixeled fonts in IE looks larger than pixeled fonts in Netscape. Mac and Linux are different as well. But, a pixel is supposed to be 1 micron. So, technically a pixeled font is not scalable. It does not resize. Only the monitor resolution resizes. Pixels are absolutes. There are many holes in WCAG1. WCAG2 is attempting to fix those problems. I hope this helps. Lee Roberts http://www.applepiecart.com http://www.roserockdesign.com -Original Message- From: Andy Budd [mailto:[EMAIL PROTECTED] Sent: Monday, August 02, 2004 4:26 AM To: [EMAIL PROTECTED] Subject: Re: [WSG] Fixed vs flexible layouts Lee Roberts wrote: Andy wanted to know what the WCAG working group members had to say about fixed and scalable width layouts. I am a member of the working group. Well, I gave an education and it seems the topic has grown to now include more about mobile devices. The purpose of variable width or elastic designs is to help people by allowing them to increase their font size without destroying the design. Yes, you will end up with right-scrolls. It doesn't matter what you do. Thanks for that Lee. So are you saying that the sole purpose of checkpoint 3.7 is to accommodate the resizing of layouts along with text? Does that mean in this case, pixels aren't being considered as relative units, contrary to what the specs say? I have to admit that I have huge problems with the guidelines. Most notably because they don't really tell you why each checkpoint is necessary and how failure to comply can reduce accessibility. Some are obvious, but many others aren't. Andy Budd http://www.message.uk.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help * * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Fixed vs flexible layouts
Andy Budd wrote: Lee Roberts wrote: Andy wanted to know what the WCAG working group members had to say about fixed and scalable width layouts. I am a member of the working group. Well, I gave an education and it seems the topic has grown to now include more about mobile devices. The purpose of variable width or elastic designs is to help people by allowing them to increase their font size without destroying the design. Yes, you will end up with right-scrolls. It doesn't matter what you do. Thanks for that Lee. So are you saying that the sole purpose of checkpoint 3.7 is to accommodate the resizing of layouts along with text? Does that mean in this case, pixels aren't being considered as relative units, contrary to what the specs say? I have to admit that I have huge problems with the guidelines. Most notably because they don't really tell you why each checkpoint is necessary and how failure to comply can reduce accessibility. Some are obvious, but many others aren't. Andy Budd If I can just add my 2 cents worth. 3.7 has to do with using markup in the correct semantic way. HTML is for marking up content. q and blockquote have meaning to user agents and parsers that are parsing documents for semantic value. If a designer was using this purely as a visual formatting technique, a blind person would have a different understanding of the way the information is communicated, because that information is being communicated via another device as a quoted block of text. If the designer wants to indent something in their design, which in itself could even be said to convey a visual semantic meaning, then they should do that with CSS. The problem is, that when TBL first adapted HTML from SGML, he only took 66% of the equation, he took from the SGML family HTML and DTD, but left out the DSSL component, and this oversight was latter addressed with CSS. Because there was no DSSL equivalent in the early drafts, default value for displaying the various elements are handled by the browsers... ie indent blockquote. pixels are relative units, but em is regarded as a far better representation of a relative unit from an accessibility point of view. The same principle is true in software development. But designers have to work with how well or how poorly user agents support the designs they want to implement. If you are having trouble understanding the guidelines I would suggest that you do go back and look at the history of human interface guidelines for digital devices and try to find the common thread. If you do this you will begin to see how WCAG evolved, and that the basic principles are consistent. You could also discuss specific checkpoints here, or on the W3C WAI Interest Group list, or the one at WebAIM. Regards Geoff * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Fixed vs flexible layouts
Well i think i found the best of both worlds... and Fluid/Elastic Design http://www.southtyneside.info/project_area/southtyneside/xhtml/elastic.asp :) * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Fixed vs flexible layouts
I have not made a study of the accessibility guidelines in depth, but my guess would be that they are referring to elements that can be resized like text rather than positional elements and that confusion arises because of vagueness like that. Just a thought, probably wrong, but hey. :) -- Iain Gardiner http://www.firelightning.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Budd Sent: 30 July 2004 10:47 To: [EMAIL PROTECTED] Subject: [WSG] Fixed vs flexible layouts Hi folks, Everybody has an opinion on fixed vs flexible layouts. Some people prefer how fixed width sites look, and there is little doubt that they are easier to build. Others hate the whitespace around fixed width designs, thinking they look ridiculous on large monitors. For a site to get a AA accessibility rating, you are supposed to use relative units (%, em) rather than fixed units (px). However the WAI guidelines do say that, if you use fixed units, you must make sure that your site is usable. Personal preferences aside, what accessibility problems to people see with fixed width layouts and what are the scale of these problems. Could the same arguments hold true for elastic layouts (layouts based on ems) and do flexible layouts (those based on %) have their own accessibility issues? Is it acceptable for the vast majority of fixed width CSS based sites to claim AA compliance if all other priority 1 and 2 checkpoints are met? Andy Budd http://www.message.uk.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help * * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Fixed vs flexible layouts
Fixed vs. Liquid. Excellent! I love these arguments. I'm sure we'll see about 300 replies to this that go way off topic in a general Fixed is better! - NO! Liquid is better style. The accessibility concern with fixed (pixel) width layouts that instantly jumps to mind is that if a user with poor eyesight decides to bump up the text size, you're going to find yourself with fewer words per line. If you're not careful, such an action can lead to content being more difficult to read, especially in narrow columns. This is one of the benefits of elastic fixed (em) width layouts - you should maintain the same number of words on a line, no matter what the text size (but then, the larger it gets, the greater the likelihood of dreaded horizontal scroll bars appearing gets). Oh, and then there's the accessibility problems with small-screen devices. If you were to set your content area to 600px wide, for example, some mobile browsers (I'm thinking Pocket PC Windows IE here) will apply that width and you have a scrolling nightmare on screens that will probably be much less than 600px wide. The WCAG are so vague, often with a get out clause of well, if you can't really achieve that then if you vaguely do this to compensate then that's alright kind of thing. It's not that difficult to argue that something is AA for example, because the guidelines give you a lot of flexibility and are open to interpretation. This is why, personally, I don't think WAI standards badges are that useful. Good as guidelines, but not as rules. Patrick Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.com - Original Message - From: Andy Budd For a site to get a AA accessibility rating, you are supposed to use relative units (%, em) rather than fixed units (px). However the WAI guidelines do say that, if you use fixed units, you must make sure that your site is usable. Personal preferences aside, what accessibility problems to people see with fixed width layouts and what are the scale of these problems. Could the same arguments hold true for elastic layouts (layouts based on ems) and do flexible layouts (those based on %) have their own accessibility issues? Is it acceptable for the vast majority of fixed width CSS based sites to claim AA compliance if all other priority 1 and 2 checkpoints are met? * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Fixed vs flexible layouts
I'd argue that the best compromise are elastic layouts, where things are positioned and sized in relation to other factors like font size. To say that if we just set our width to 100% or something and rejoice that the site will work in all sizes is misguided; there will always be extremes at both ends of the spectrum (really large desktop sizes, really tiny handheld displays) which will need a complete rethink. As for can I claim AA, I'd say the most pragmatic approach would be - and I know I keep banging on about it, but hear me out once more - to create separate stylesheets, a designery one (with fixed/elastic layout, pastel colours, small-ish font size, all that stuff) and a more accessible one (flexbile layout, higher contrast, slightly large font sizes, etc) and a clear, simple, and obviously accessible mechanism to switch between them. A bit like the if you can't make it accessible, offer an accessible alternative idea (and certainly a lot better than text only versions). And going back to the problem of extremes (ultra large/ultra small displays), I could envisage a few more stylesheets available...lightweight (which could also be set to media=handheld for instance (if any of those little bleeders actually support/understand it), widescreen, tv (again, couple with a media=tv attribute)... (to muddy the waters further, there's also, in my mind, an issue of adapting the content itself to the context; if I'm using a browser on a small mobile phone and access, say, a cinema website, I don't care about the flash intro, the sections about the history of that particular company, etc...I'm just after a quick way to check times when movies are playing; the context is different, my purpose is different, and possibly the site should be different - maybe as a separate domain, or in any case showing a different view into the same data that is more tailored to that specific situation. heck, I'm digressing quite badly here) But yes, my personal opinion, worth about GBP0.02 or less :) Patrick Patrick H. Lauke Webmaster / University of Salford http://www.salford.ac.uk -Original Message- From: Andy Budd [mailto:[EMAIL PROTECTED] Sent: 30 July 2004 10:47 To: [EMAIL PROTECTED] Subject: [WSG] Fixed vs flexible layouts Hi folks, Everybody has an opinion on fixed vs flexible layouts. Some people prefer how fixed width sites look, and there is little doubt that they are easier to build. Others hate the whitespace around fixed width designs, thinking they look ridiculous on large monitors. For a site to get a AA accessibility rating, you are supposed to use relative units (%, em) rather than fixed units (px). However the WAI guidelines do say that, if you use fixed units, you must make sure that your site is usable. Personal preferences aside, what accessibility problems to people see with fixed width layouts and what are the scale of these problems. Could the same arguments hold true for elastic layouts (layouts based on ems) and do flexible layouts (those based on %) have their own accessibility issues? Is it acceptable for the vast majority of fixed width CSS based sites to claim AA compliance if all other priority 1 and 2 checkpoints are met? Andy Budd http://www.message.uk.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help * * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Fixed vs flexible layouts
Well im just swaying away from my gotta keep it fixed way of thinking and slowly getting on with Stretch it like a rubber Johnny as i still dont think a full fluid layout works 100% of the time. But an Elastic one does! As you can still set your width's and if you do everything in EM's images,margins,padding and borders then it should scale up and down very well! the only problem i've seen is with the like of floats and positioning... I've started playing with this (http://www.southtyneside.info/project_area/southtyneside/xhtml/test.asp) yesterday to see if an Elastic design is viable and im pretty much set to move over from Pixel to EM's as it not any harder, just gotta learn the relative size's! The only thing i've found a problem is controling the Text size! Cos as soon as you change the font-size of and element it starts to mess with it width and height too!! * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Fixed vs flexible layouts
Patrick Griffiths wrote: The accessibility concern with fixed (pixel) width layouts that instantly jumps to mind is that if a user with poor eyesight decides to bump up the text size, you're going to find yourself with fewer words per line. If you're not careful, such an action can lead to content being more difficult to read, especially in narrow columns. This is one of the benefits of elastic fixed (em) width layouts - you should maintain the same number of words on a line, no matter what the text size (but then, the larger it gets, the greater the likelihood of dreaded horizontal scroll bars appearing gets). That's my problem with using ems. You maintain the 'words per line' but risk horizontal scrolling. Yet the horizontal scrolling/small screen issue seems to be the main reason why the WAI advocate using relative units instead of absolute units. Oh, and then there's the accessibility problems with small-screen devices. If you were to set your content area to 600px wide, for example, some mobile browsers (I'm thinking Pocket PC Windows IE here) will apply that width and you have a scrolling nightmare on screens that will probably be much less than 600px wide. If you are embedding widths in the HTML this is definitely an issue. However if you are doing it using CSS, these devices should really use 'handheld' stylesheets instead of those intended for 'screen'. I doubt that using a flexible layout would be that much better. Take your typical 3 col layout for instance. Reduced down to a mobile phone sized screen you'd have exactly the same issue as described in your first para. i.e. The text in each col would be so squashed up as to be unreadable. The WCAG are so vague, often with a get out clause of well, if you can't really achieve that then if you vaguely do this to compensate then that's alright kind of thing. It's not that difficult to argue that something is AA for example, because the guidelines give you a lot of flexibility and are open to interpretation. This is why, personally, I don't think WAI standards badges are that useful. Good as guidelines, but not as rules. Agreed. One of the reasons I posted here was because there are a few WCAG members on the list. I'd be interested to hear their rational behind this guideline. It seems to me that whether you use fixed or flexible layouts there will always be accessibility issues at the extreme ends of screen size. Andy Budd http://www.message.uk.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Fixed vs flexible layouts
Andy Budd wrote: If you are embedding widths in the HTML this is definitely an issue. However if you are doing it using CSS, these devices should really use 'handheld' stylesheets instead of those intended for 'screen'. Indeed they should. Unfortunately, a lot of mobile browsers (such as PPC IE) apply the screen media type. I doubt that using a flexible layout would be that much better. Take your typical 3 col layout for instance. Reduced down to a mobile phone sized screen you'd have exactly the same issue as described in your first para. i.e. The text in each col would be so squashed up as to be unreadable. For some (maybe most) devices, sure, but some screens (especially those on PDA's and PDA-style phones) are wide enough to accommodate multi-column layouts. It depends what you need to do with your design. 3 columns would certainly be pushing it, but two column or (obviously) single column designs would probably usually work better within a fluid design. Like I say, it comes down to what you're trying to do with the page. Dog Boy Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.com - Original Message - From: Andy Budd [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 30, 2004 11:53 AM Subject: Re: [WSG] Fixed vs flexible layouts Patrick Griffiths wrote: The accessibility concern with fixed (pixel) width layouts that instantly jumps to mind is that if a user with poor eyesight decides to bump up the text size, you're going to find yourself with fewer words per line. If you're not careful, such an action can lead to content being more difficult to read, especially in narrow columns. This is one of the benefits of elastic fixed (em) width layouts - you should maintain the same number of words on a line, no matter what the text size (but then, the larger it gets, the greater the likelihood of dreaded horizontal scroll bars appearing gets). That's my problem with using ems. You maintain the 'words per line' but risk horizontal scrolling. Yet the horizontal scrolling/small screen issue seems to be the main reason why the WAI advocate using relative units instead of absolute units. Oh, and then there's the accessibility problems with small-screen devices. If you were to set your content area to 600px wide, for example, some mobile browsers (I'm thinking Pocket PC Windows IE here) will apply that width and you have a scrolling nightmare on screens that will probably be much less than 600px wide. If you are embedding widths in the HTML this is definitely an issue. However if you are doing it using CSS, these devices should really use 'handheld' stylesheets instead of those intended for 'screen'. I doubt that using a flexible layout would be that much better. Take your typical 3 col layout for instance. Reduced down to a mobile phone sized screen you'd have exactly the same issue as described in your first para. i.e. The text in each col would be so squashed up as to be unreadable. The WCAG are so vague, often with a get out clause of well, if you can't really achieve that then if you vaguely do this to compensate then that's alright kind of thing. It's not that difficult to argue that something is AA for example, because the guidelines give you a lot of flexibility and are open to interpretation. This is why, personally, I don't think WAI standards badges are that useful. Good as guidelines, but not as rules. Agreed. One of the reasons I posted here was because there are a few WCAG members on the list. I'd be interested to hear their rational behind this guideline. It seems to me that whether you use fixed or flexible layouts there will always be accessibility issues at the extreme ends of screen size. Andy Budd http://www.message.uk.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help * * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Fixed vs flexible layouts
-Original Message- From: Andy Budd For a site to get a AA accessibility rating, you are supposed to use relative units (%, em) rather than fixed units (px). However the WAI guidelines do say that, if you use fixed units, you must make sure that your site is usable. The absolute irony here is that pixels (px) are classified as relative units. I know, I can never get my head around this one either, but it's great news for those of us trying to get good layouts and address accessibility. see http://www.w3.org/TR/1998/WD-css2-19980128/syndata.html#h-4.3 http://www.htmlhelp.com/reference/css/units.html http://www.juicystudio.com/tutorial/css/units.asp Zeldman addresses this on p316 of DWWS. So if you use em and px for the right elements, following the likes of Eric Meyers and Russ's collection of Liquid designs you fullfil that part of WCAG-AA no problems. The WAI purists would say an all em site is better, but that is just not realistic in todays world. Is it acceptable for the vast majority of fixed width CSS based sites to claim AA compliance if all other priority 1 and 2 checkpoints are met? If they have done that much work to get to almost AA, then it seems that designing with both em and px should not be too much of a further step to take. - Geoff Deering * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Fixed vs flexible layouts
Geoff Deering wrote: The absolute irony here is that pixels (px) are classified as relative units. I know, I can never get my head around this one either, but it's great news for those of us trying to get good layouts and address accessibility. A pixel is relative because it can be any physical size - it can be one millimetre wide or one inch wide, for example. That's not particularly helpful for a web designer though. It *is* absolute in relation to the screen size, which is kind of a contradiction, but a much more useful way to think about it. I'm quite sure that when the WCAG authors say absolute units they are talking about pixels. If my memory serves me correctly, they more or less say this. Again, it's open to interpretation, but we all know what they're getting at, really. The WAI purists would say an all em site is better, but that is just not realistic in todays world. Sure it's realistic. It's one of many options and some people have opted for ems and successfully built elastic pages. Fido Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Fixed vs flexible layouts
To Fix or not to Fix, dang we're back in Shakespeare's time with To Be or Not To Be, that is the question. Let's start with the easy stuff ... fonts. If you use font-size: percentage, then your layer or table layout widths should be in percentages. If you use font-size: em, then your layer or table layout widths should be in em's. But, do you know what they both do? Interestingly enough, they take the default font size set in the browser and use it as a basis. If the font-family is a sans-serif and the user set the browser to 10pt then 100% would be equal in size to 10pt. If the you used em's, then the 1em would be equal in size to the 10pt. This allows the visitor the ability to declare their own font sizes without the use of programming a stylesheet ... effectively they are with setting defaults in their browser. So, if I come in and say that I want me font-size to be 1em or 100% then my font size is relative to the browser's default. Now, coming in and using the width attribute with fixed values will obviously cause your width to maintain a fixed value. This is unfriendly to the users of screens smaller than the values you set. It also doesn't always look professional on larger screens - in some people's opinions. By applying percentages you end up running the problem with the presentation causing drip effects in font presentations once the font-size gets too large. The drip effect is when the words start dripping off the line and eventually it will start dripping more quickly so as to make the words drip their letters as well. (Yes, I coined the term drip effect). The only truly scalable width is the em. As you increase the default font-size, the width increases as well. For example, if my default sans-serif is 10pt and I change that to 72pt, then 1em becomes equal to 72pt. If my mobile device uses a font-size of 6pt then 1em is equal to 6pt. But, please don't try to use 6pt on a regular computer. The problem with using scalable widths is people tend to not use them correctly. They'll use a scalable width such as 100% for the width and then turn around and use px or pt for their font-size. I've done it many times ... shame on me. But, now you know how to use scalable widths ... you have to use them with scalable font-sizes. So, I guess your next question would be how many em's would I need to use to make my presentation fill the screen without scrolling right? That is a good question and one I can't answer. In fact, you couldn't answer it either even if you guessed. The reason you can't is because of the visitor. Each visitor can set their own font-size values in their browser. And, since the em is based upon the font-size selected by the visitor, we have no control. My best advice is to tinker until you are happy with the default presentation. But, remember, you will make someone scroll right eventually. For example, if the 800x600 only hold 75em's wide and you decrease the screen resolution to less than that the user will have to scroll. But, still the em is the only truly scalable width. The purpose of having scalable widths is to help prevent the drip effect. I hope this helps. Lee Roberts http://www.roserockdesign.com http://www.applepiecart.com * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Fixed vs flexible layouts
From: Geoff Deering [snip] If you are designing for handheld you should be considering display:none for the none content columns, header and footer and just be using the link element for prev, next, etc. Some sort of minimalist approach may be more appropriate for that media. actually, I'd go even further than that and say that this is a case in which we may need completely different sites (or entry points to the same information) depending on user preference - using something like XSLT, or in any case some hefty-ish server-side system. Then, you could serve targetted content for those who wish to have a minimalist view, or more media rich version for those who want it. before anybody jumps up and down and scream bloody murder: i'm not talking about browser sniffing, but about having two or more version of the site (ideally all powered by the same content) to allow modal access to information. yes, you can just display:none, but particularly considering handhelds, mobile phones, etc, you're still sending the data, wasting bandwidth, in an environment where it may well be a scarce commodity (and/or expensive... imagine being charged by the kilobyte or something) just thoughts, P Patrick H. Lauke Webmaster / University of Salford http://www.salford.ac.uk * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: Re: [WSG] Fixed vs flexible layouts
I am on holiday between the 30th July and the 14th August. I will reply to your e-mail as soon as possible on my return the following day. Thank you for your understanding. Jay Hills - Ikonik.net (This is an automated response. Please do not reply to this e-mail as it will simply send another back - Thanks) * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Fixed vs flexible layouts
Lee Roberts wrote: The purpose of variable width or elastic designs is to help people by allowing them to increase their font size without destroying the design. I think the better statement of purpose is to allow the users' choices of font sizes to work with the designs. Your statement implies that sites are purposefully designed such that users should need to zoom on sites. Users shouldn't routinely need zoom. The exceptional eyesight of the average web page designer compared to the population in general is what makes a browser zoom feature necessary. -- If you are wise, your wisdom will reward you;Proverbs 9:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://members.ij.net/mrmazda/auth/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: Re: [WSG] Fixed vs flexible layouts
I am on holiday between the 30th July and the 14th August. I will reply to your e-mail as soon as possible on my return the following day. Thank you for your understanding. Jay Hills - Ikonik.net (This is an automated response. Please do not reply to this e-mail as it will simply send another back - Thanks) * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Fixed vs flexible layouts
Users shouldn't need zoom, but the problem is graphic designers think 9px font sizes should be the standard. I'm afraid even I can't read that. So, until we get rid of graphic designers who believe concepts such as small font sizes is best we will continue to have the problems. No, IE doesn't allow you to increase or decrease font size when the designer uses px, pc, or pt. So, zoom is required. IE also does not support multiple choice for style sheets. So, the option of allow ing the user to select a font-size isn't always acceptable. However, if you are using the DOM you can help visitors by offering varying style sheets based upon a selection within the code of the page. I think there is an article about this on A List Apart. Lee Roberts http://www.roserockdesign.com http://www.applepiecart.com * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: RE: [WSG] Fixed vs flexible layouts
I am on holiday between the 30th July and the 14th August. I will reply to your e-mail as soon as possible on my return the following day. Thank you for your understanding. Jay Hills - Ikonik.net (This is an automated response. Please do not reply to this e-mail as it will simply send another back - Thanks) * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Fixed vs flexible layouts
-Original Message- From: Patrick Lauke From: Geoff Deering [snip] If you are designing for handheld you should be considering display:none for the none content columns, header and footer and just be using the link element for prev, next, etc. Some sort of minimalist approach may be more appropriate for that media. actually, I'd go even further than that and say that this is a case in which we may need completely different sites (or entry points to the same information) depending on user preference - using something like XSLT, or in any case some hefty-ish server-side system. Then, you could serve targetted content for those who wish to have a minimalist view, or more media rich version for those who want it. I completely agree with that, I think it is rare that the same content fits both types of media. This is also why I am trying to move to server side XML based solutions like Cocoon / Axkit / Forrest, and use TCN for delivery of content. It may be an overkill for some sites, and doesn't fit all situations, but it seems the most encapsulating type of solution for some sites where you need to address these issues. before anybody jumps up and down and scream bloody murder: i'm not talking about browser sniffing, but about having two or more version of the site (ideally all powered by the same content) to allow modal access to information. This is what Cocoon is meant to address, or using TCN (Transparent Content Negotiation) intelligently from the server side (I know TCN is not perfect.. thanks to user agents identifying themselves as someone else). yes, you can just display:none, but particularly considering handhelds, mobile phones, etc, you're still sending the data, wasting bandwidth, in an environment where it may well be a scarce commodity (and/or expensive... imagine being charged by the kilobyte or something) I agree. I'd get frustrated with anyone trying to ram unnessary content to me via a handheld. Geoff * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Fixed vs flexible layouts
-Original Message- From: Andy Budd Sent: Saturday, 31 July 2004 2:10 AM To: [EMAIL PROTECTED] Subject: Re: [WSG] Fixed vs flexible layouts Some very interesting discussion point here. I think the topic of fixed vs flexible layouts tends to cover a number of areas. - Accessibility - Usability - Device Independence - Personal Preference - User Control These principles are pretty well executed in desktop GUIs. The developer really does not have to do anything other than follow the SDK and APIs and the application should deploy correctly addressing these requirements, because there features are in the domain of the operating system to manage the application correctly. There are some things the application developer has to do, they have to work with the GetSystemMetrics() information and display according to that, that is mainly working with the resolution the software is running under, and other user preferences. These are the same principles that have been used to develop WCAG. Unfortunately the developers of user agents have either in their ignorance, or by choice, or the need to be quick to market, ignored many of the principles and standards required to build user agents correctly. Some of it is just poor software architecture. If feel there is constant need to expose the short comings in user agents, much like WASP did a few years back. There is a need to keep doing this, because, if we don't, it only makes web developers work more and more difficult, and user agents companies just become complacent. WCAG is not meant to make it hard for developers, it is really meant to try and help everyone, the user and the developer (ideal world again). The W3C people in this area do try and work with the user agent developers, but because they are W3C sponsors they cannot openly critise them. I have done so in shere frustration on those lists and I have been asked to refrain from open critisism on that forum. And I think that request is appropriate, it is not the place to express those things. But developer forums are. It would be great to see some kind of wiki set up so that developers could put data into a public forum addressing user agent compliance with standards, see; http://www.w3.org/WAI/UA/2001/10/eval http://cita.rehab.uiuc.edu/wai-eval/index.php?option=Test%20Suites http://cita.rehab.uiuc.edu/wai-eval/index.php?option=Evaluations http://www.maccessibility.com/archive/000595.php If anyone thinks such a site to lobby all the user agent developers would be a good idea, please contact me off list. Also, if you think it is not a good idea, I'd also appreciate such informed feedback. Many people quite understandably end up mixing these issues together. For instance, if you create a fixed width layout and then reduce the browser so that the viewport is smaller than the layout width, you are going to get scroll bars. The same thing happens if you create an elastic layout and up the font size too much. However surely these are more usability issues than accessibility issues. People often bring up the question of mobile phones and PDA's but where does accessibility end and platform independence begin? Many mobile developers would argue that you should be developing specially for mobile devices as the needs of the users and limitations of the medium are very different to that of computer screens. While it's an idealistic goal, it's probably unrealistic to develop once then deploy across all internet enabled devices. Personal preference is a bit of a red herring. It seems that as many people like fixed width layouts as they dislike them. Pretty much all these areas have been covered here, and elsewhere, yet I'm still left feeling that we've not had a definitive reason why fixed layouts are bad for *accessibility*, only personal opinion. Probably because accessibility is a subjective concept that, at certain times, can include all the other areas I've mentioned. This is a fundemental HCI principle that is applied well in the major operating systems. If you read any of the following you will begin to see how these common threads type HCI principles together, and why this is also important on the web and for user agents to comply with these parameters in handling instructions, so that web developers can better support usability and accessibility in their designs. http://developer.apple.com/documentation/MacOSX/Conceptual/AppleSWDesign/HID esign/chapter_3_section_1.html#//apple_ref/doc/uid/TP3353 http://developer.apple.com/documentation/MacOSX/Conceptual/AppleSWDesign/ind ex.html?http://developer.apple.com/documentation/MacOSX/Conceptual/AppleSWDe sign/HIDesign/chapter_3_section_3.html http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html /vxconAccessibilityDesignGuidelines.asp http://developer.gnome.org/projects/gup/hig/ http://developer.gnome.org/projects/gup/hig/draft_hig_new/ http://www-306.ibm.com/able/guidelines
Re: [WSG] Fixed vs flexible layouts
Geoff Deering wrote: I'm quite sure that when the WCAG authors say absolute units they are talking about pixels. If my memory serves me correctly, they more or less say this. Again, it's open to interpretation, but we all know what they're getting at, really. No, that is not correct, WCAG directly references the HTML and CSS specifications and does not have their own differing interruptation of any of the specifications. Okay, well I took a quick look and there is no direct reference to pixels. It is quite clear that the gist is to use ems or percentages however. In http://www.w3.org/TR/WCAG10-CSS-TECHS/#units for example: ...you may position an image to be offset by 3em from the top of its containing element. This is a fixed distance, but is relative to the current font size, so it scales nicely. It works for simple layouts, but I don't think it works for complex layouts across multiple users agents. If it does, can you please show me an example. http://www.csszengarden.com/?cssfile=/063/063.css I don't see what the big deal is. You can just take a pixel-laden layout and replace values with suitable ems values. Why isn't this realistic? Mutley Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.com * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Fixed vs flexible layouts
- Original Message - From: Patrick Griffiths [snip] I don't see what the big deal is. You can just take a pixel-laden layout and replace values with suitable ems values. Why isn't this realistic? until we have fully supported scalable vectors, images will either not resize (changing the font size on the zengarden example, you end up with illegible chopped off text) or look crud when attempting ad-hoc i'll use ems instead of pixels for width/height methods. Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively. [latin : re-, re- + dux, leader; see duke.] http://www.splintered.co.uk | http://www.photographia.co.uk | http://redux.deviantart.com * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Fixed vs flexible layouts
-Original Message- From: Patrick Griffiths Geoff Deering wrote: I'm quite sure that when the WCAG authors say absolute units they are talking about pixels. If my memory serves me correctly, they more or less say this. Again, it's open to interpretation, but we all know what they're getting at, really. No, that is not correct, WCAG directly references the HTML and CSS specifications and does not have their own differing interruptation of any of the specifications. Okay, well I took a quick look and there is no direct reference to pixels. It is quite clear that the gist is to use ems or percentages however. In http://www.w3.org/TR/WCAG10-CSS-TECHS/#units for example: ...you may position an image to be offset by 3em from the top of its containing element. This is a fixed distance, but is relative to the current font size, so it scales nicely. The WCAG1 references the CSS2 specifications on this, which includes pixels as relative units, but it is true that the emphasis is on em as it is the more prefered relative unit for usability and accessibility. It works for simple layouts, but I don't think it works for complex layouts across multiple users agents. If it does, can you please show me an example. http://www.csszengarden.com/?cssfile=/063/063.css I don't see what the big deal is. You can just take a pixel-laden layout and replace values with suitable ems values. Why isn't this realistic? Mutley I would not put CSSZenGarden in this category. What I mean by more complex layouts are multi column multi box designs, complex forms within columns, etc. It's not that it is not doable, but if you are trying to compete with the designs houses that use quirks mode and hacks across multiple user agents, maybe it's a bit difficult. If it was an easy solution to address, then why is there so much discussion on lists like this trying to find solutions? I'm not up to date with all the CSS browser design issues at all. I haven't been doing a lot of CSS the last few years, so I'm here to learn. But I'm also curious to find out how developers are dealing with these problems. --- Geoff Deering * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
