RE: [WSG] When is invalid CSS okay?
Gunlaug Sørtun wrote: The real reason for me to not use 'CC' for separation, is that the versioning goes on on HTML level and adds unnecessary garbage to every single page. If you happen to be designing an XHTML site and decide you want to use server-side scripting to deliver your pages as XHTML/xml-application to standards-compliant browsers and as HTML/text to MSIE, then you can selectively include your various Conditional Comments into only the HTML, dumbed-down-for-MSIE version. Then the unnecessary garbage CC's will not even show up in your pristine XHTML/CSS version. This is probably not that practical in most real-world cases, but it does take the separation idea to its logical conclusion. And for those who really want pristine, separated code, it is a viable solution. I like the CC method because it is easy to understand and it should be easy for a different developer to understand five years from now. CSS hacks, on the other hand, require a bit of arcane knowledge that may be difficult to understand for a newbie five years from now, even with explanatory comments added. But I agree with Gunlaug that the down-side of CC's is that it requires adding unnecessary garbage to every single X/HTML page's head section. Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Usability Accessibility Over Design?
James Jeffery wrote: It is possible to get good Accessibility, Usability and Design, but usually you have to give and take for each or one of them. [] Its not our fault or the clients fault, whatever the client wants he gets [...] The client is the hard part. Sometimes they want something that you know is not going to be great on the Accessibility front, and you try to advise them, but they do not listen, so you then have to do the best possible Joseph Taylor wrote: As a web designer/developer, its my job to create the accessible version whether they consciously desire it or not simply because I know it should be built that way and it is my desire to build it properly. There are many different approaches to client-designer relationships, just as there are many different web design philosophies. I personally like Joseph's approach, but such an approach means that as a designer you are not approaching the client-designer relationship in a way that means the customer is always right. You are rather approaching it from a perspective that the customer does not know what is right, and needs you to educate and inform her/him. This can be good for your sense of moral certitude, but bad for your pocketbook. There will be some clients who are outraged by such an approach (especially if they are competing in a market where their competitors are going all flash-and-pizzazz AJAX-ey on you and doing it on the cheap by hiring the lowest bidder). There are others who will thank you for it (especially the government/NGO sector or any other sector where a a governing body will eventually bring in a set of accessibility/standard guidelines that become required for all parts of the sector). I don't think you can find a way of satisfying both groups and at the same time satisfying yourself. Choose your target market and live with it. If you have enough time to browse the WSG Mailing List and write articles about the relationship between accessibility, usability, and good design, then you are probably already at risk of having the prices for your web design services severely undercut by someone who is younger and faster, and who places less importance on accessibility or standards...I mean, seriously, whatever! As long as it works, right!?! In which case, your target market has already been narrowed for you. Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Usability Accessibility Over Design?
Philip Kiff mailto:[EMAIL PROTECTED] wrote: If you have enough time to browse the WSG Mailing List [] then you are probably already at risk of having the prices for your web design services severely undercut by someone who is younger and faster, and who places less importance on accessibility or standards...I mean, seriously, whatever! As long as it works, right!?! A quick clarification, to deflect any criticism about my implied ageism. That was just an example. There are of course lots of young whippersnappers who can code like demons and do so in fully accessible and standards-compliant fashion. Indeed, I expect that there are many more *old* web designers who do things wrong than young ones. But the younger ones are often willing work for less (at least initially), and so they are the real competition in the context of my earlier message... Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] (X)HTML Best Practice Sheet updated for MSIE
Philip Kiff wrote: Tested this link: http://keryx.se/resources/html-elements.xhtml [corrected] This link does not seem to work in MSIE 7, 6, or 5.55 on my test machines. Works now as designed on all MSIE browsers listed above - it serves HTML 4.01 Strict version, with a note added about my browser not being able to display true XHTML. Not sure when it started to work -- it could have just been a cache issue on a server between here and there, or even just on my ISP's server. Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] (X)HTML Best Practice Sheet updated for MSIE
Philip Kiff wrote Tested this link: http://keryx.se/[...].html Ooops. That isn't the link I tested. I tested the xhtml one that is supposed to get rewritten in the htaccess rules: http://keryx.se/resources/html-elements.xhtml Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] (X)HTML Best Practice Sheet updated for MSIE
Keryx Web wrote: This is the set of rules in my .htaccess that I think should do the trick: [snip] It works with FFox, Opera 9.2, Safari for Windows (complained at first about too many redirects for no apparent reason) and MSIE 6. Tested this link: http://keryx.se/resources/html-elements-plain.html This link does not seem to work in MSIE 7, 6, or 5.55 on my test machines. The same link works on the same machines in Opera v.9.22. Did not test beyond that. Not sure about your htaccess code. You might also consider an alternative scripting method of serving the page to MSIE versions, such as one of these: http://sitesurgeon.co.uk/articles/serving-xhtml-correctly.html http://www.workingwith.me.uk/articles/scripting/mimetypes Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Absolute positioning in the flow of the document?
Paul Collins wrote: I've spent a while trying to figure this out and I'm not sure there is a solution. I've got two levels of navigation here; visually one sits on top of the other, but the second level will change according to what top level link you click: http://www.method.com.au/newWebsite/ Probably you are just in the middle of making changes or something, but the nav menu doesn'tt seem to show up at all on my Internet Explorer version 7 or version 6? It does show up correctly on Opera and Firefox. Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] To target or not
Designer wrote: Can we just step back a moment, and consider what we are doing. As I write this reply, I am typing the content of this mail IN A NEW WINDOW.[] Do those who proclaim annoyance at having 'new windows forced on them' apply the same thinking to mail, Dreamweaver (and all the other programs). Okay, stepping back for a moment, I would first of all admit that I quoted somewhat selectively from the WCAG in order to make it seem like it was absolutely wrong to open up a new window when a person clicks on a link. In a more even-handed moment, I might have pointed out that the issue is not necessarily the opening up of a new window, but rather the *method* one uses for opening up a new window and whether one can make a user aware of what behaviour to expect when they click on a particular link. So although I would advise against it, it is nevertheless technically possible and within accepted web standards to code a link in such a way that it will open up a new window, provided that you notify your users that such behaviour will occur. Since we're looking at this from a web standards perspective, there are other web standards that come into play. For instance, although target=_blank is regularly used to open a new window, I would argue that this code is actually part of the HTML code intended for use with FRAMES, and therefore, the use of this code to create pop-up windows in a non-frame environment is an abuse of the HTML code. In XHTML 1.1 Strict, of course, target=_blank has been removed entirely in order to make such use impossible if one wants to write valid XHTML code -- and I would suggest that part of the reason it has been removed is precisely because of the abuse of its intended use within a frames environment. There remains, however, the possibility of using JavaScript to create new windows. And I would admit that there are certain contexts when such usages are valuable for a user -- especially in those instances where a website is attempting to serve more like a web application than a static, information-only site. But whenever you use JavaScript to code some behaviour, you should from the very beginning be thinking about how you can emulate that behaviour in a non-JavaScript environment -- if only because a certain percentage of users will have JavaScript disabled. With the wildly popular use of AJAX and other scripting technologies to make web sites behave more like standalone programs, there is a temptation to compare the two and draw similarities between them. I would note however that there remain deep, structural and perceived differences between web-based applications and stand-alone programs that run on one or two operating systems. For instance, assistive technology like screen readers can tap directly into an operating system's API or interface so that when a modal/dialog box pops up it can always, without fail notify a user in the exact same way every time. By contrast, on the web, there are many different methods of simulating the opening up of such modal windows, and despite a decade of development, screen readers still cannot reliably communicate to their users when such pop-ups occur and how to navigate through them. If there were a web standard that required that all pop-up windows be created using the exact same specific coding method, then I am sure that screen reader software could be written to predict and communicate such activity. The challenge for those who create AJAX/dynamic-scripting web applications, then, is to find ways of ensuring that those sites are usable by ALL users with CURRENT, or even somewhat-out-of-date, user agents (since users with disabilities in particular are often financially disadvantaged as well, and so are unable to purchase the latest versions of their preferred assistive technologies). With respect to the use of multiple windows and learned web behaviour generally, I think there is some confusion. Like you, I also use multiple windows when browsing the web, and they are an integral part of my web experience. My annoyance with links that are coded to always open up in a new window is that such coding actually gets in the way of my experience. My web browser allows me to choose whether I want to open a link in a new window or not. When someone codes a site so that those links are forced to open up in a new window, then it *breaks* my browsing experience. Some less experienced users may also get frustrated because such links *break* their back button: there is no way back when you open a new window -- you have to close the window in order to get back. In general, this makes my browsing experience less predictable, and it discourages a user who knows exactly what they want and what the fastest way is for them to get it. The problem is not then with the use of multiple windows, but with the lack of predictability and control over those windows. In an operating system environment, I only have to learn about a
RE: [WSG] To target or not
Joyce Evans wrote: I always thought it was a good idea to open links to other websites in a separate window, so you don't lose the visitor. [...] I think that the weight of public opinion has been steadily turning against this view over the past 10 years or so. I would be interested in knowing if there is any current research that supports the theory that opening links in new windows will somehow keep visitors interested in your site longer. Sure it may keep them *stuck* there longer, but does that keep them *interested*? My impression is that in 2007 the reverse is true. There is certainly a considerable amount of anecdotal evidence that suggests that for a certain percentage of web users, nothing infuriates them more than forcing causing a new window to pop-up unexpectedly when you click on a link. I personally now use a JavaScript snippet to strip all target=_blank entries from the DOM before rendering pages are rendered in my browser. From a web standards perspective, the argument against opening links in new windows dates back to the very first W3C Web Content Accessibility Guidelines (1999), if not before: Guideline 10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. [Priority 2] http://www.w3.org/TR/WAI-WEBCONTENT/#gl-interim-accessibility See also, the WCAG Techniques document notes for 10.5: http://www.w3.org/TR/WCAG10-HTML-TECHS/#no-new-windows Lastly, if one really must spawn new windows with certain links, then I quite like the method suggested by Bill Posters (note that this is apparently still a Work In Progress): http://test.newplasticarts.co.uk/dom-js/flag-toggle-external-links/ Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] To target or not
Hassan Schroeder wrote: I've done usability tests where users *preferred* off-site links to open in another window. I find that surprising. I am sure you are right, however, that it is all about context. Certainly if you sat down in a room full of 20- to 25-year-olds today you would not find that the majority of those users *preferred* off-site links spawning new windows. My impression is that the more a user knows about how to use their web browser, the less they like windows or tabs opening up without their consent. As more and more people become better and better with their web browsers, fewer and fewer will want off-site links to open up in new windows or tabs. This almost seems like common sense to me now. Should I be rethinking this? Aren't there any current studies that demonstrate this? Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] intuitive text resizer for accessibility toolbar
Benedict Wyss wrote: My idea is to have a basic font size to allow a reasonable amount of content with less scrolling and then in an accessibility toolbar give the visitor the oportunity to increase the font size in the main content area. This to me seems like a decent compromise. I am open to correction on that, but it seems fair though. So I will still need to place a text resizing mechanism to cover that government standard for the site. I'm not sure what you mean by government standard here. There is some debate about whether text resizer widgets are a good idea at all, and I don't think that there is any government standard that explicitly requires them. There are a variety of arguments about this, but a couple quick ones are: is the widget usable without JavaScript? (This is required for the site to meet W3C WCAG 1.0 Priority 1 Guidelines). Is it usable without cookies? How can you inform a visitor that the widget exists, and what it will do, if they cannot read the text on the site to begin with? What is usually required from a standards perspective, at minimum, is that a site use relative font sizes in a way that allows a visitor to increase the font size of the site using browser controls. Some very respectable sites provide a link to increase text size that offer simply an explanation of how to increase the text size in different browsers, rather than trying to change the size of the fonts being sent to the browser. [...] I worked on the assumption that lower that normal font sizes are unneccessary but as a standard we are obliged to offer a larger text size alternative, and one that differs from the cnrt+/- that applies to the whole site. I don't think you are obliged to offer a larger text size alternative, and one that differs from the cnrt+/- that applies to the whole site. On 6/21/07, Felix Miata wrote: I think what you want is to reinvent the wheel and clutter your page duplicating browser tools. One job of a modern web browser to provide its user with whatever text size adjustment is required to make a page comfortable and/or usable. [] All you need to do is accommodate them all by leaving the base size as you found it and setting only contextual sizes relative to the base size presumptively chosen by each individual user. I'd have to agree with Felix on this one, particularly for a site whose target market includes large numbers of seniors. Seniors are more likely to be unfamiliar with how web browsers work than the younger population, and as a result, they will be less likely to know how to change the font size in their browsers, and they will also be less likely to understand the function of font resizing widgets on a page, no matter how you present them. And given that deteriorating vision is such a common issue for that population, the best approach for a site targeting that market would be to use a large enough default size that most users can use it. To do this, I would seriously consider following Felix's recommendation of leaving the base size as you found it. Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Accessibility and fly out menus
Mary-Anne.Nayler wrote: I was wondering how members here feel about the accessibility of Fly Out menus. The type I'm talking about are CSS based, ie no JavaScript but I'd be interested to hear what people think about those that utilise JavaScript. There was a discussion about this *exact* same topic on this list just one to two weeks ago: http://www.mail-archive.com/wsg@webstandardsgroup.org/msg29150.html and http://www.mail-archive.com/wsg@webstandardsgroup.org/msg28989.html Those earlier threads address the questions of CSS vs. JavaScript flyout/dropdowm menus, keyboard navigation, hover delays, etc. Additional older threads on the same topic can be found in the archives: http://www.mail-archive.com/wsg@webstandardsgroup.org/ Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Back to the Future
Chris Taylor wrote: [] My initial tests show that NN4.03 handles some CSS (float, background, border, font etc) but not some important things (list-style, margin and padding on lists). Is there a source for information about CSS support on old browsers? Nick Roper wrote: Info on CSS support at: http://www.w3schools.com/css/css_reference.asp If you're forced to work old-school, then you might find some old, otherwise outdated information websites of value. For instance, I would combine the W3CSchools info with old info from the CSS Pointers Group: http://www.dev-archive.net/articles/pointers/bugs-ie.html and http://www.dev-archive.net/articles/pointers/bugs-nn.html and also from RichInStyle.com: http://www.richinstyle.com/bugs/netscape4.html The CSS Pointers Group info was especially useful in the early 2000's in understanding how to deal with the many failures of different browsers to meet the W3C CSS standards. Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Accessible Drop Down
Ryan Moore wrote: I see that it relies on a source of JS to complete the effect, and i'm wondering if it's possible to complete this purely with XHTML CSS. Anyone have a good example of this? Keryx Web (Lars Gunther) wrote: Just do not do it. It cannot be done. a. JS is the best tool for *behavior*. CSS for design. b. There are huge accessibility and usability issues with pure CSS menus, such as: - off-screen positioning - moving the mouse the shortest distance will often lead to the menu getting closed - non-intuitive keyboard navigation Ryan Moore wrote: Ok. So typically is any form of navigation that relies on a rollover or hover state would be a bad practice of accessibility/usability? It depends on how it is done. I would disagree with Lars that it cannot be done, but to do it properly in a way that meets usability and accessibility guidelines requires a great deal of care and attention to detail. I think that the Ultimate Drop Down Menu 4.5 by Brothercake comes about as close as any I've seen to meeting those guidelines (someone else mentioned it last week in response to a similar question about accessible drop-down menus): http://www.udm4.com/ UDM4 normally uses JavaScript, but it is designed so that the it will degrade gracefully and you can set it up so that your menu will work the same way as a CSS-only menu if JavaScript is turned off. It also includes a keyboard module that allows you to configure better keyboard access. UDM4 is copyrighted and there is a licensing fee, but non-profit organizations can obtain a free license. I do not have any relationship, business or personal, with Brothercake/UDM4 other than having used it when working on a non-profit site in the past. Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Safari now on Windows
Michael MD wrote: Speaking of Mac browsers - a friend called me on the weekend and said he can't find anything newer than IE5 for OS9 but won't upgrade to OSX because it would be way too slow on his G3. (and he doesn't have the money to buy a new machine) now that is something to think about! I ran into this problem a year or two ago, and the local sys admin explained that my best bet would probably be to use Netscape for Mac OS 9 instead. I ended up installing IE, Netscape and iCab and then switched back and forth depending on which site would work with which browser. It looks like you can actually get Netscape 7.02 for OS 9 (Mac PowerPC), which, while buggy, would still probably be better than IE5 in most cases: http://browser.netscape.com/downloads/archive/ Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] What does Semantic mean?
Lucien Stals wrote: It seems to me that many people here have different ideas about what semantic means. It would be helpful it we shared a common understanding in our conversations. I welcome, and invite, a *polite and professional* debate about the use of the term semantic as it relates to our work on the web. I have also noticed that the term semantic seems to be understood differently by different people, especially with respect to websites and coding. There are probably many reasons for this, but one reason is that there really are at least two different definitions in use: one is based on the proposal/theory of the Semantic Web, and the other is based on linguistics and the theory of how language produces meaning. These two definitions are similar and related, but not identical. And sometimes it appears that people slip back and forth from one definition to another. I'm not sure that I can define what semantic means in each case, but I would nevertheless highlight these two cases as two different uses of the word, and as one reason it can be difficult to come up with a common language to discuss semantics as they relate to web standards. Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] layout/font site test - please
Felix Miata wrote on EDT: On 2007/06/02 11:06 (GMT+0100) Designer apparently typed: Sparked partly by the recent discussions on elasticity, I've been attempting to put together a 'template', based on em's and with a max-width. [] You can see it at: http://www.marscovista.fsnet.co.uk/newtemplate/template.html I only looked in IE7 FF. Pretty good, although the line lengths are on the long side of what I like, and the text is too small. http://mrmazda.no-ip.com/auth/Sites/ksc/dancesrqb.html is the same basic layout, but without breaking IE's font resizer, with no special treatment for antique browsers, and without disrespecting the visitor's choice of font size. Just FYI, on my default browser settings, the font sizes used on Designer's site provide better readability than those on the DancesSRQ site. In particular, the subheading tag line on the DancesSRQ is just a wee bit too small for my tastes -- my browser computes it as 10px. The same size font is displayed in the bottom copyright statement. By contrast, the smallest size that appears on Designer's site shows up as 12px. No doubt it is a matter of taste and personal preference, but I would be cautious in promoting the current DancesSRQ design over the one used by Designer as far as font sizes are concerned. Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] layout/font site test - please
Designer wrote:
Sparked partly by the recent discussions on elasticity, I've been
attempting to put together a 'template', based on em's and with a
max-width. I've used an expression for max-width in IE 7 (pinched
from Georg!). I've tested it in FF1.5, IE6 IE7, Opera 9, and Netscape
4.02.
[]
http://www.marscovista.fsnet.co.uk/newtemplate/template.html
Felix Miata wrote:
http://mrmazda.no-ip.com/auth/Sites/ksc/dancesrqb.html is the same
basic layout, but without breaking IE's font resizer [...]
As Felix points out, your current template breaks IE's built-in font resizer
(View - Text Size - Larger/Largest). This problem is caused by your
definition of the default body text size as 14px. The use of px
measurements for font sizes is not scalable under Microsoft Internet
Explorer.
Here is the specific line in your CSS file that is causing this problem:
htmlbody { font-size : 14px; }
In terms of standards, using a px-based measurement is not technically
against the font and unit guidelines of the W3C Web Content Accessibility
Guidelines version 1.0, since the error is actually caused by Internet
Explorers misunderstanding of px units. But since the W3C WCAG also
recommends testing with actual users of actual browsers, then the use of
px-based font sizes becomes an identifiable barrier for users of Internet
Explorer, and so ends up as something that goes against the WCAG in the end.
To resolve this issue, you should use a different kind of relative font
measurement (like em or percentage), or better, leave the default body font
size untouched -- youve already set the body font size to a percentage
value in your body { font-size } setting anyways.
Phil.
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
RE: [WSG] Converting font size from pt to % or em
Felix Miata wrote:
Your mission, should you choose to embrace it, is to convince the
client that maintaining an anachronistic practice is the wrong thing
to do, and that doing the right thing is always the right thing to
do. Maybe this will help whenever that discussion ensues.
http://www.lighthouse.org/accessibility/top-10/
Perhaps not the best example to provide for this thread...from their default
stylesheet:
body {font-size: 80%;}
Phil.
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
RE: [WSG] Converting font size from pt to % or em
Felix Miata wrote: On 2007/05/25 17:47 (GMT-0400) Philip Kiff apparently typed: Felix Miata wrote: What matters is: [...] 5-that any deviation a designer makes from 100% is arbitrary, as it's made from an entirely unknown starting point 100% of the visitor's choice equals respect for the visitor. I'm not really convinced that this is an issue of respect for the users of one's site. The reference that Kane provided to Owen Briggs's charts over at thenoodleincident.com I think demonstrates how the operating system manufacturers and browser companies are the ones who have been arbitrary about what 100% font size on the body element means. Here is a link to Owen Briggs's page discussing Sane CSS Typography: http://www.thenoodleincident.com/tutorials/typography/index.html That's the 2nd time in this thread that poison-pill anachronism has been included. Its focus is on pixel perfection with tiny fonts that provides at most marginal utility when applied to the much larger pixel sizes necessary on modern high resolution/high PPI displays. It only applied when the very overwhelming majority of browsers had 16px defaults *and* most users were running sub-~72DPI displays. It misleads the uninitiated into thinking mousetype is an OK standard for web pages. I included the 2nd link to the Briggs article because I thought that perhaps the first link might not have been understood since it went directly to the a page of Briggs's images. I realize that you have spent considerable time studying this issue, but your explanation of Briggs's technique seems misleading to me. Under Briggs's technique, the body font-size is set to 76% and then the p font-size is set to 1.0 em. All other elements are then sized with ems. This should not produce tiny fonts on most people's systems: that is the whole purpose of his going through the exercise of producing all the screenshots using different browsers and operating systems. Although the screenshots date back to 2002, they do include IE 6, and I doubt there are differences in font-size rendering between IE 6 and 7 that would make Briggs technique suddenly unusable. Briggs's method will produce pages where fonts appear similar to what they appear like if you use 12pt text as your base font-size. This is the size that is still used today by millions of websites. No doubt some people find that size too small, but that is still the norm on the web these days. I don't quite understand the issue with the different dpi displays. Won't that have the same affect on all browsers, regardless of what method is used to size fonts -- unless you use pixel sizes, of course? I would also add that the reason I found the Briggs method attractive was that there is a certain elegance to the code involved, and some other designers may have been attracted for the same reason. Under Briggs, your base site font text is 1.0 em. Headings, lists, and other elements can all be set in relation to that 1.0em base. Whenever you are working on the CSS file, you can immediately grasp what the relative size of any element will be in comparison to your base body text (2.5em = two and a half times). Also, you can upsize your entire website simply by changing the body font-size from 76% to a larger number. There is no need to go through and change each and every percentage or em value of your other elements since the whole site should scale with the body font-size setting. As Kane pointed out, and as Owen Briggs's screenshot studies demonstrate, the use of 76% as the body font size is to create a more even base-line size across multiple browsers. This 76% figure is not therefore entirely arbitrary: The arbitrariness is an illusion induced by a mindset that all browsers should make every web look like a clone of that page in every other web browser. Modern browsers do a remarkable job of providing the similarity among themselves that they do, which is due in no small part to the standards bodies considerable efforts to create sensible and achievable standards. Different, within reason, should be a perfectly OK standard. I agree wholeheartedly. Different viewports and preferred sizes are perfectly OK. But if a designer finds a way to make sites appear almost identical across all major browsers and platforms at a screen resolution of 1024x768 on a 17 monitor with everything else set at default settings, and those sites are STILL scalable for other users, then shouldn't that be OK too? setting the body font size to 65%-76% or so is the size that 76% was a particular sweet spot for a particular period that has since passed. Any deviation from 76% did and does move the result out of that anachronistic sweet spot. designers have come up with over the years that allows them the most freedom to produce designs that appear similar across different browsers and different operating platforms. That particular basis doesn't make it any less arbitrary
RE: [WSG] Converting font size from pt to % or em
I spent some time carousing through various sites and email lists and ended up trying to pull together some of the disparate techniques, arguments, and references about page font sizing into a single document. Because this message grew to an unwieldy size, I've divided it up into 5 sections: 1. Common Body Font Size Settings 2. Best Practices with Respect to Web Standards 3. User CSS Stylesheets 4. Sample Sites 5. Additional References -- 1. Common Body Font Size Settings -- Christian Montoya wrote: I hate to make a quick reply to a long post, but not all designers set body font size to 62.5% when creating websites... Out of curiosity, I did some browsing through the style sheets of some major websites and some other selected sites with an interest in design and standards, and it would appear that Christian is right here. I did not of course think that all designers set body font size to 62.5%, but I did think that I would find default body font-size settings of 60-75% being quite common, if not the norm. From what I can tell, however, body font-size settings are all over the map. Some of the biggest major sites, like Google, Flickr, YouTube, and Amazon use keywords (usually, font-size: x-small) and then scale up from there. Lots and lots of the other big sites also set the body font-size to a point size (12 and 13 seem to be the most common). Of those that are setting body font-sizes to a percentage value, the numbers range from the 62.5% that Paul mentions right up to 95%, and there does not seem to be any trend towards one number or another. Patrick H. Lauke wrote: Though I agree with the sentiment, the fact remains that the large majority of websites out there do size text below 100% (and yes, more often than not around the 75%ish mark). It appears that Patrick is right here: the number of sites that leave the body font-size element untouched (and so allow the browser defaults to stay at the usual defaults of medium, 16pt, and 100%) is a clear minority. I think that this statistical fact is an important piece of information for designers who are weighing the advantages and disadvantages of leaving the default body font sizes untouched in their stylesheets since it forms the real world usage background against which such decisions are made. For reference purposes, in section 4 below, I've provided links to a selection of significant sites that set body font-size to a percentage value. -- 2. Best Practices with Respect to Web Standards -- Sagnik Dey wrote: I'm developing a website that have some standards defined. The font size specified is 9pt. But due to accessibility standards I wanted to convert that in % or em. Can anybody tell what do i need to use to view the same size in different browsers? To respond to the original poster's question, I would say that there are at least three general techniques for converting page styles from point-based font sizes to a relative font size system: 1. Use Percentage on body font-size, then apply ems on the rest Owen Briggs The Noodle Incident - Sane CSS Sizes http://www.thenoodleincident.com/tutorials/typography/ 2.. Use Keywords on body font-size element, then apply relative sizing on rest Dive Into Accessibility: 30 days to a more accessible web site Day 26: Using relative font sizes http://diveintoaccessibility.org/day_26_using_relative_font_sizes.html 3. Use some combination of percentage and em sizing on all elements Note that if you avoid changing the default base font-size setting, then this method can be used to create a fully scalable/zoomable design while still addressing the objections of those who believe that the default text font size should be left unchanged. The one clear no-no, is that absolute font sizes, like points, should not be used. As the original poster points out, the use of point sizes can cause accessibility issues for some users. For more information about this, see: CSS Techniques for Web Content Accessibility Guidelines 1.0 Units of Measure: http://www.w3.org/TR/WCAG10-CSS-TECHS/#units There has been considerable discussion about the potential use of pixel sizes because pixels can be technically described as a relative font size. Unfortunately, Internet Explorer does not treat pixels as such, and using pixel sizes will break the View - Increase Text Size function on most versions of Internet Explorer, and so pixel sizing is not a viable option at present. The last major position, of course, is the one advocating against any changes to the default base font sizes for the body text. This is the 100% Easy-2-Read Standard advocated by Felix Miata: http://www.informationarchitects.jp/100e2r?v=4 From my browsing around, I learned that the debate over this position is a recurring discussion in various communities of coders and designers. I find some of the arguments in favour of Felix's position compelling. For instance, I had not fully examined the potential problems
RE: [WSG] Converting font size from pt to % or em
Felix Miata wrote:
BBC
http://www.bbc.co.uk/home/d/
body {font-size: 62.5%}
http://www.bbc.co.uk/ was recently overhauled. It used to be 13px.
Here's a look at before: http://mrmazda.no-ip.com/SS/bbcSS.html
Ooops. My mistake, your screenshots are right. The BBC news site uses the
same 13px setting that you based your screenshots on. Those are useful
screenshots for understanding the differences across screen resolutions and
screen sizes.
I guess I reviewed the BBC site too quickly and assumed incorrectly that the
BBC used a uniform set of styles across their site. It turns out that they
different settings for different sections of their site. The main front
page uses the body font-size 62.5% that I found, but the news site uses the
13px setting that you identify.
Compare:
http://www.bbc.co.uk/
body {font-size: 62.5%}
http://news.bbc.co.uk/
body {font-size: 13px}
Phil.
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
RE: [WSG] Converting font size from pt to % or em
Felix Miata wrote:
On 2007/05/28 02:43 (GMT-0400) Philip Kiff apparently typed:
1. Use Percentage on body font-size, then apply ems on the rest
Owen Briggs
The Noodle Incident - Sane CSS Sizes
http://www.thenoodleincident.com/tutorials/typography/
This is the method of undersizing that is least visitor unfriendly.
Gecko browsers don't compound an enforced minimum font size as badly
as on Clagnut pages. More importantly, a simple user stylesheet with
'body {font-size: medium !important}' fixes all or substantially all
of most pages that strictly use this method.
The last major position, of course, is the one advocating against any
changes to the default base font sizes for the body text. This is
the 100% Easy-2-Read Standard advocated by Felix Miata:
http://www.informationarchitects.jp/100e2r?v=4
There is at least one rather significant other proponent. From
http://www.w3.org/QA/Tips/font-size
'Size: respect the users' preferences, avoid small size for content
* As a base font size for a document, 1em (or 100%) is equivalent
to setting the font size to the user's preference. Use this as a
basis for your font sizes, and avoid setting a smaller base font
size * Avoid sizes in em smaller than 1em for text body, except
maybe for copyright statements or other kinds of fine print.'
I was not aware of this document. Thanks for highlighting it. I note that
it is merely a tips document and therefore should not be seen as anything
else than informative bits of wisdom, and especially, they are not normative
W3C technical specifications. But having noted that, I think you are right
that it suggests that the W3C collective wisdom on this topic is to
recommend leaving the base font sizes unchanged, especially given that their
own site follows that policy as well.
I guess that means that now I'm not sure if I agree with the W3C either (!).
I know some people are quite comfortable occupying that position, but for
me, I'm not so sure... G...
Phil.
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
RE: [WSG] Converting font size from pt to % or em
Felix Miata wrote: What matters is: [...] 5-that any deviation a designer makes from 100% is arbitrary, as it's made from an entirely unknown starting point 100% of the visitor's choice equals respect for the visitor. I'm not really convinced that this is an issue of respect for the users of one's site. The reference that Kane provided to Owen Briggs's charts over at thenoodleincident.com I think demonstrates how the operating system manufacturers and browser companies are the ones who have been arbitrary about what 100% font size on the body element means. Here is a link to Owen Briggs's page discussing Sane CSS Typography: http://www.thenoodleincident.com/tutorials/typography/index.html As Kane pointed out, and as Owen Briggs's screenshot studies demonstrate, the use of 76% as the body font size is to create a more even base-line size across multiple browsers. This 76% figure is not therefore entirely arbitrary: setting the body font size to 65%-76% or so is the size that designers have come up with over the years that allows them the most freedom to produce designs that appear similiar across different browsers and different operating platforms. These levels don't come from any disrespect felt towards site visitors, but from a disrespect for the arbitrariness of different browser defaults and a desire to override the choices made by those browsers. Isn't this basically the same kind of thing that a designer does when they apply zeroing to the body margins or body padding or to any other CSS element that different browsers set differently. Designers modify the default settings of CSS elements all the time - that is what a designer does in order to create a design. Sure, designers should create designs that scale nicely and play well with user specified font sizes, and of course web designers should learn to embrace the idea that the sites they create will be accessed in different ways and with different technologies that will not permit pixel-perfect identical versions to be served to all users. However, that doesn't mean that they have to give up on trying to produce designs that look almost identical to the way they want in the default settings of the browsers that appear most frequently in their site traffic logs. I wonder, is it possible that 65%-76% base size body font is in fact the level that has become a kind of standard on the web? Or perhaps the web has a dual standard: one is 65-76% and the other is 100%? In any case, I'm not convinced that the choice by many web designers to use 65-76% will be easily overcome, especially given its usefulness from a design standpoint, and the apparent arbitrariness of the 100% alternative. Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] wa state guidlines question
Thierry Koblentz wrote: The script can do much more than just adding the event. It can add a title attribute, plug an icon or even add some text within the anchor tags. That way the info about the behavior is plugged only if the behavior is available. Frank Palinkas wrote: You can find more info on the use of unobtrusive DOM/JavaScript in Jeremy Keith's book [...] and James Edwards and Cameron Adams book [...] While I personally agree with Michael that such scripting is not really something to be encouraged, nor something that can be done in a way that really meets accessibility standards 100%, I would point to the following test site by Bill Posters as the closest I've seen to a best practices method of doing this: http://test.newplasticarts.co.uk/dom-js/flag-offsite-links/ No need to buy anyone's book to get caught up on the latest methods! Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Markup for Poetry?
Jeremy Boggs wrote: Are there any discussions or examples on strategies for marking up and styling poetry? I don't know of a set of guidelines for simple markup of poetry in X/HTML, but you can find some discussions about it as well as some more involved methods of marking up such texts through the Text Encoding Initiative (TEI): http://www.tei-c.org/ TEI uses SGML markup, which theoretically could then be run through a parser to produce whatever flavour of X/HTML one wanted. But because it requires its own DTD or a server-side XSLT/translator of some sort, it is probably not what you are looking for. If you are really interested in poetry markup however, they have done some fairly extensive thinking about it. For e.g., check out A Gentle Introduction to SGML: http://xml.coverpages.org/gentle.html or TEI - 4 Encoding the Body - 4.3. Prose, Verse and Drama: http://www.tei-c.org/Lite/U5-body.html#vedr In actual practice, if you are just encoding a couple poems, then I think that the simple use of either pre or p + br as suggested by others makes more sense. Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] site check - almost ready for prime time
Bob Schwartz wrote: The test site at http://www.fotografics.it/fife/ has been refurbished [...] I would appreciate it if you guys could check it out for any errors or wrong practices It looks like the site may have problems displaying at widths of less than 1000px in Opera 9 and Firefox. The backgrounds don't stay within the three columns properly, leaving some text unreadable. Probably an issue with div positioning, and the box model since the problem doesn't seem to show up in IE -- which is what you presumably used to test the positioning. Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
