Re: [WSG] Was given a shocker this week ...
Geez, if only I was so lucky to get such an easy project... this is project from heaven compared to most of what comes my way Geoff Mike Kear said the following on 7/04/2009 2:42 AM: You might be amused to learn about the site I was given to rebuild this week. It was built by a photographer who had a mac and some free software, and the client said the problem was she had to get someone to update it for her every time she changed anything in her business. She wanted a content management system. That’s no problem for me – that’s mostly what I do . But I was appalled when I saw the site she was asking me to rebuild .. . here’s what I found – the work of a woman who was claiming to be a professional web designer: [A] the site consisted of 8 html pages [B] each page consisted of some invalid html code produced by a WYSIWYG app, presumably used incorrectly since most WYSIWYG apps are CAPABLE of producing valid code. [C] the content on each page consisted of a single image for the header 1169px x 168px and another jpg image with all the text, photos etc 702px x 961px [D] because of the sizes of the header image and the body image, none of the pages could ever possibly line up across the page without a lot of tinkering about. [E] the html contained no content whatever, except the name of the designer [F] all links inside the pages were using image maps – something I haven’t used for about ten years. I don’t think I’d even remember how to do that now if I had to. [G] the layout problems caused by the different widths of the header and the image in the body were corrected by nesting tables with lots of cells and a transparent spacer gif to stretch the cells out. I didn’t bother working out why there were so many of these spacer tables, I knew at a glance I wasn’t going to be needing anything in this code! [H] because my client has had such trouble getting her site updated on a timely basis, she has taken the site away and is hosting it with me, which has sparked off a war between my client and her former web designer, complaining that I have taken her site by using a web archive, in violation of her rights to copyright. (As a first step, I used a browser to copy the files from her existing site, so I could see what’s in there, just in case the former designer decided to take it off line. Which she did. So it was a good precaution. Then while my client and I are discussing her new site, I put the existing one up in her new hosting space with me just so the site stays alive while we work out what to do. You can almost hear the former web designer frothing at the mouth as she rants and raves on the phone DEMANDING that I pull everything down off the web within ONE HOUR – OR ELSE!!) It’s like a cat fight. I’m expecting to see them both pulling each others hair, biting, and rolling in the mud any time soon. Anyway, I’d done quite a few sites now that I’ve enhanced by making them standards compliant, but I think this is the most extreme case I’ve seen – well since I tried Frontpage v2.0 all those years ago. Maybe I can write it up as a case study later when the new site is up. If the client agrees. Cheers Mike Kear Windsor, NSW, Australia 0422 985 585 Adobe Certified Advanced ColdFusion Developer AFP Webworks Pty Ltd http://afpwebworks.com Full Scale ColdFusion hosting from A$15/month *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Website Directory Structure - Best Practice
Joseph R. B. Taylor wrote: Greetings Friends, A topic I haven't seen posted here yet, that I feel is relevant when it comes to working to have a standard way of doing things. When it comes to website directory structure, I'm curious to know how you gurus out there set up yours. I myself, have been using this set up: root web folder -images -main.htm -events.htm -bio.htm etc, etc Recently I was hired to do some cleanup on a site I hadn't built and the directory was set up like: root web folder -main --images --main.htm -events --images --events.htm -bio --images --bio.htm etc, etc Looking at these two layouts, I first notice that the 2nd layout has multiple images folders, one for each page in fact. This sort of organizes the images better, but now there's images all over the place. How do YOU set up your directories? Hi Joseph, I was nearly not going to reply to this as I am not a guru of any type or qualification, so I didn't think it was addressed to me, but here is a non guru reply; I think that before you address this as a basic design issue, you need to look at the web site as a whole, what is it, how how it may possibly evolve, who contributes to the content, how are users managed, how is the web site categorised into topics, and all the rest of it. Once you have done that you may find A may be more appropriate than B or visa versa. For instance, if you have a lot of groups contributing content, then B may be a better way of managing the user permissions, it may also allow a section to be moved more easily or run and developed on a local file system, whereas A and modifications of A may be more suited to a smaller (even a large) site that do not require complex content management rules. I also would like to be able to discuss usability issues with standards based developers on this list, but maybe that is a topic for another list or forum. Regards 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] .net question
kvnmcwebn wrote: hello, i just went to a lot of trouble style a form, fieldsets, legends and all. The visual studio programmer whos taking over the next phase says it will be coverted into tables. we can't control database content all we can do is contain it that was his argument. why cant he contain it with css. can somebody help me educate him? maybe i should have this on the cms list. -best kevin mcmonagle If you are working in an organisation or any sort of structure where there is a web development team the best thing to do is to raise an issue with the manager of the team to discuss the development processes. In my own experience, even developers who know about and appreciate the benefit of standards may be limited in what they can do via the tools they *have* to use. When it comes down to the bottom line, using the IDE for that particular environment, for all other productivity purposes, may outweigh any requirement to comply with standards. If you can work out a methodology to work with this situation you could offer it at such a meeting. That's quite possible, but it would have to fit in with the SDLC and budget. Regardless of whether you can solve this situation or not, it should be bought to the attention of the web and project manager that they should address this concern in their SDLC, because if they don't, the designer is going to spend their time coding to standards, which is all lost in the next phase. Not very good project management or ROI, but very few web teams I have seen refine their SDLC to address these issues. 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] Do you still support 4.0 browsers?
James Bennett wrote: I think the time has long since come to stop having disclaimers about browser support; make sure the content of the site is accessible whether people are using new browsers, old browsers, non-visual browsers, or just shouting into tin cans with strings attached. Then build on top of that any fancy styling or effects you like, so long as they don't get in the way of non-supporting user-agents accessing the content. -- I feel that is the crux of the issue too. If you are a standards based developer, you shouldn't have locked anyone out with your design implementation, but your design may degrade gracefully on older browsers. The content should still be accessible. -- 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] AIMIA Awards
Kat wrote: Gday, I find this list filled with dynamic, inspirational people. I come away being motivated and energised. I love youse guys. :) Today, I came across AIMIA (Australian Interactive Media Industry Association - http://www.aimia.com.au/) that are having their 12th Annual AIMIA awards. Is anyone a member of this group? Does anyone know anything about them? Is anyone a finalist? Used to be a member when it first formed. Went to the first conference way back in the early 90's. It was quite good actually, very interesting discussions, very informative on many levels. But after that, I didn't find any reason to follow up on it. Taken a look from time to time, and find the web standards based community much more interesting, informative, and addressing the issues I'm focused on. But like a lot of things, I may have missed a lot of good things going on over there just because they dropped out of my focus. Only have two eyes, hands, etc. I had a look at some of the finalists and although they seem to require WCAG Priority 1 Accessibility, to reach that, don't your websites need to actually validate (at least some of their finalists don't)? Have I misunderstood? Valid documents is a P2 checkpoint - http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-identify-grammar I rather think it's a good idea - but I think it misses a certain something (tableless design, validation, accessibility, etc). There are so many designers/developers on this list (and elsewhere) doing so many amazing things - why don't they ever get recognised for the good things they do? They deserve it more!! Would there be a way to give them the recognition they deserve? Kat If WSG members contribute to it, great, but does it provide value for membership? http://www.aimia.com.au/i-cms?page=1.3.329.8 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] Converting the heathen: never again
Christian Montoya wrote: On 2/26/06, SunUp [EMAIL PROTECTED] wrote: Hi folks, I hereby publicly declare that my days of complaining to website authors that I cannot view their site at 800x600, and then opening my big mouth about other dubious issues I notice on their site, are now over. Ah, but when annoying little standardistas like me tell others to make their sites accessible and validate their XHTML, I'm being too harsh. /rant I think you have come across a key lesson for the standards community: techies know about standards, they are not ignorant, they just have their own reasons (however lame) for not following them. I also think there are a lot of people who work in big organisations, companies and even universities, that know that to raise these issues is to put their job on the line. Some developers who have a good understanding of these principles will just shut up for their own sake as they have a mortgage and family to feed... the consequences of raising such issues are that great. And even if you do become successful, just watch yourself get shafted by the person further up the ladder, who takes the credit for it. There are also developers in these large organisations that make their living from writing code patches to address the short comings in the core approach. They have a vested interest in the problems not being solved. They love such challenges. And if you raise too many issues to say their needs to be a fundamental overhaul of the approach and system, you are basically told to STFU by everyone, not because of lack of credibility of your argument, but because it is stepping on too many toes. There is more than simple reasoning at play here. -- Geoff Deering - 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] Converting the heathen: never again
Lea de Groot wrote: On 27/02/2006, at 4:08 PM, Ben Buchanan wrote: Not to mention the fact that the people who implemented those bohemoths can't always separate standards advice from personal vilification - no matter how polite, rational, independently verfiable... I think its important to understand that, for a lot of people who actually work on a site, when you say your site doesn't validate/ isn't accessible/ doesn't work in my browser what they hear is your skills are no good / you don't know how to do your job/ say goodbye to that next payrise It takes incredible tact to tell people what a problem is without making it feel to them like a personal attack - and I don't know about you, but I'm a geek; tact isn't on my strong list :) I'm not saying don't confront - no way! But I am saying that if you can't reach the right audience (the people who sign off on the bills, quite often, not the developer) then don't be surprised when they act like you have hit them in the face with a wet fish. Actually, Sunny, have you thought about maybe you hit a home run and got all the guy's hot buttons? Maybe (s)he knew all those things were a problem and couldn't bear them being brought up by (cough, splutter) a *customer* g Lea ~ although I still can't believe the gall of a response like that: 'your problems with our site are your own problem.' Amazing! Can you imagine going into a supermarket and, upon asking for help finding the eggs, being told that the supermarket layout is your problem; find them yourself? g There are so many ins and outs to this. Basically, even if you have a very good client interface protocol, and you are not finding fault with their work, even when they are working with you and you are refining their design, everyone has so much *personal* investment in their design, it's very hard to be constantly presenting the business case for why you are doing what you are doing. I find myself constantly inheriting the hidden web wannabe in projects lately. They are not there during the initial discussion and signoff with the client, but somehow the client manages to bring them on board, and they seem to live in a world of complete creative freedom where there are no basic engineering principles to adhere too (accessibility, standards, usability, topography, etc). What makes it worse, is that when you have to cover the basics in this area they want a private 24/7 mentoring relationship, or the whole thing transmitted to them in a day or two, when it takes ages of practice and study to get to this level, and when you say there are undergraduate and post graduate degrees on these topics, and they are so large it takes lots of dedicated time to understand, they are left highly offended. Oh, and just as a pointer on supermarket design, there are many deliberately seemingly irrational locations of items in a supermarket so that it does not aid the user to easily find what they want, so that they have to walk past many other items, which they may not usually walk past, in the hope that they will purchase more items just buy the distance walked and items browsed. That is why milk, which is one of the most commonly purchased items is in a shelf usually the most further from the checkout. 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 **
[WSG] CSS Liquid Design Header
Hi, Can any one point me to a good example of how to do a css header with a background image 100% wide, while having two distinct images on the far left and right and they behave in a liquid manner as the browser window is resized, so that both images maintain being far left and far right. 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] CSS Liquid Design Header
russ - maxdesign wrote:
Do you mean like this?
http://www.maxdesign.com.au/presentation/liquid-background/
Russ
I wish it was that simple.
I need something like
#headerbanner {
color: ;
background: #1C3959 url(/images/banner.jpg) repeat-x top;
display: block;
height: 145px;
width: 100%;
border: 0;
}
#bannerleft {
padding: 0;
margin: 0;
float: left;
background: #1C3959 url(/images/lbanner.jpg) no-repeat top;
clear: both;
}
#bannerright {
padding: 0;
margin: 0;
float: right;
background: #1C3959 url(/images/rbanner.jpg) no-repeat top;
clear: both;
}
#headerbanner h1 {
padding: .5em 1em .5em 1em;
font-size: 140%;
text-align: center;
color: #F0;
background: transparent;
}
So #headerbanner has a 1 pixel width image and the left and right banner
have to sit on top of that so they behave in a liquid way keeping to the
left and right. There's probably a simple solution, but it's something
I normally don't deal with.
G.
**
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] CSS Liquid Design Header
Charles Eaton wrote: On Feb 22, 2006, at 4:50 AM, Geoff Deering wrote: I wish it was that simple. I need something like How's this: http://www.eatons.net/test2/test3/index.html Note: Float in your setup worked against the nature order of how computers read code, top down - left to right. Thanks for the suggestions and also the code corrections and improvements. This is like the jello mold that Tom suggests isn't it? It doesn't quite fit what I wanted, but I can actually achieve the same result with a bit of image manipulation, and will be able to be close to back on track with being close to the clients design (which has a lot of image layering). Nothing like a trip to the dentist in the morning to distract one from web challenges. Highly recommended when in need of other perspectives (on anything). Thanks 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] CSS Liquid Design Header
Tom Livingston wrote: On 2/22/06 5:04 AM, Geoff Deering [EMAIL PROTECTED] wrote: Can any one point me to a good example of how to do a css header with a background image 100% wide, while having two distinct images on the far left and right and they behave in a liquid manner as the browser window is resized, so that both images maintain being far left and far right. Have you tried jello mold? You can set a min width, so your images won't crash together. And have a bg color in between for wide pages. Just a thought... Yes, tracked that down. Think it's the same principle as what Charles recommended. Thanks for that. 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 **
[WSG] Feedback on ISO Standard Version of Access For All Metadata
Original Message Subject:reminder about new standard... Date: Sun, 12 Feb 2006 23:12:50 -0700 From: ozewai [EMAIL PROTECTED] Reply-To: ozewai [EMAIL PROTECTED] To: [EMAIL PROTECTED] (Mailing List Information, including unsubscription instructions are located at the end of this message) Time is running out for us with the ISO standard version of AccessForAll metadata. This is just a reminder that you could help by testing our forms and commenting - please --- See http://dublincore.org/accessibilitywiki/DiscussionOfFcd Other's comments are also available for you to peruse on that page. Liddy http://www.ozewai.org/ ** 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] Google and HTML5
Geoff Pack wrote: I like the idea of the nav and the aside elements: http://whatwg.org/specs/web-apps/current-work/#the-nav http://whatwg.org/specs/web-apps/current-work/#the-aside So instead of: html head/head body div id=header/div div id=nav/div div id=content/div div id=sidebar/div div id=footer/div /body /html We could have: html head/head body header/header nav/nav article/article aside/aside footer/footer /body /html Which is cleaner and more semantic. But it would take years to get it implemented by the browsers and to grow the installed base to the point where we can actually use it. Better to just standardise the id and class names - the web patterns / microformats approach. cheers, Geoff. Do others feel there are *elements* of presentation creeping back into the structure? The first approach keeps the semantics of the document whilst providing handles to present the sections of the document. The second does this by the semantically defining the presentation structure. (IMHO) I'd prefer to see a direct jump into the xml world (which would drag the soupsayers into the standards world). Maybe it's time for a better semantic language. Regards 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] Correct MIME types for non-standard file formats
Peter Levan wrote: Is there a good reference site that lists correct MIME types for various file formats? or is there a general rule to follow for non-standard file types? Specifically I'd like to know what MIME type should be used for SPSS portable (.por) files and in the past I've seen many variants for some file types (eg. MS office file types). Currently we are sending the MIME type application/por which I am fairly certain is incorrect, but it does give the browser behaviour that we want. Without the MIME type set the file displays like a text file in the browser window, however we want the download requestor to appear when accessing a file of this type as the file is useless when viewed as straight text as it is a data file designed to be used with SPSS. __ Peter Levan Have you tried http://www.google.com.au/search?hl=enq=MIME+type+SPSSbtnG=Google+Searchmeta= 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] what cms system
Romeo-Adrian Cioaba wrote: try joomla.org http://joomla.org. Joomla is the best open source CMS in the web. i'm working with it for over 1 year and all my clients were happy with it :) Does it handle standards based templates okay now? It used to insert it's own code in the Mambo days. Have they addressed that, as they were intending too. Can you build Strict DTD tableless designs with it? Do you have any example sites you have done? This discussion should be over at [EMAIL PROTECTED] 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] CSS Driven?
russ - maxdesign wrote: I don't know about anyone else but I often use angry mobs to control my web pages - though it is hard to get them to exhibit blind hate. :) Russ Could I please request a tutorial on this method please Russ... - 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] *Why* doesn't Google validate? was New logo scheme was talking points for standards
Lea de Groot wrote: On 10/12/2005, at 1:53 PM, Brian Cummiskey wrote: I wonder how many visits google gets in a day... Probably in the billions - plenty of people have it as their homepage. Of course, there'd be a lot of caching happening... Lea http://www.google.com.au/intl/en/press/funfacts.html http://en.wikipedia.org/wiki/Google_platform What's interesting is how they have set up their server cluster (15,000 back in 2003), which doubled from the 18 months before. If you google on that you'll find many articles. G ** 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] *Why* doesn't Google validate? was New logo scheme was talking points for standards
liorean wrote: Consider the entire www.google.com site. Or at least the search part of it. You probably want to create one stylesheet file and one javascript file for the entire thing, probably sent compressed if client supports it, so it gets cached and not requested again in that browser session. Also, how many users access the main page once but searches several times in a row, or move beyond the first listing page? How many access it from the Google bar or browser search fields instead of coming through the main page? The main page is just a part of the application, not the whole thing. These considerations probably make CSS layout an even better choice for reducing bandwidth consumption. -- David liorean Andersson There's no doubting the arguments here, but you are dealing with large organisations. Anyone who has worked within one of these large organisations as a web developer knows not to raise these issues or else they could find themselves without a job, even if their intention is only to benefit the organisation. Zeldman pointed out Yahoo's problems in DWWS, but it had little impact. *Jakob* Nielsen was utilised as the usability design person for Google's initial design, which has changed little from it original. I don't know if he's still on their payroll. Even take a look at an organisation like Telstra and it's implementation of Standards (http://telstra.com.au/standards/index.cfm). They have at least put an effort into this, but the people on this list will see the flaws in it's implementation, and it's assumptions. This movement has been going on for half a decade at Telstra, and the version 6 templates are at least 4 years old. It's almost impossible to effect these types of changes in these organisations, unless you have a position of authority. The only way to do it (so far) is to lead by example, and when there is enough evidence of good standards design implementation, then these large organisations may be willing to adapt best of practices. 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] Newcomers and Web Standards
Christian Montoya wrote: Lori, don't give up on us so fast. I can assure you that Lachlan's comments were not meant to be sexist, and I think the discussion that ensued has been helpful for us all. Even if someone on this list does say something you don't like, don't let it discourage you, because there are still a couple thousand other people that can be useful in answering your questions. And yes, there are women here. As far as editors go, I still use Notepad and Wordpad... maybe I should look into something new too. -- -- Christian Montoya I second these comments, and although debate sometimes ensues, generally, everyone is trying to be helpful and contribute, and quite often there are valid points on both sides (if that makes sense). Other text editors to look at; http://www.vim.org/ and http://webstandardsgroup.org/go/resourcecat30.cfm TopStyle Lite is the free cut down version of TopStyle Pro (http://www.bradsoft.com/topstyle/tslite/) 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] Mambo Accessibility
Lloyd wrote: Guys, Thanks for all the feedback! Backend is important as one of our content providers is blind. Does anyone know much more about Joomla? They are possibly prepared to upgrade (As they see this is just the same thing). I want to know whether its possible to do this with either Mambo or Joomla but I guess otherwise it will need be something else so your suggestions of other good CMS's are welcome! Thanks again. Regards, Lloyd Just as a point of interest, Mambo, before it split into Joomla, said that the next major release (5.x) would aim to generate web standard compliant code, they had taken on board as a core developer the person/people who takes Mambo, and fixes it to produce XMambo (http://mamboforge.net/projects/xmambo/). I don't think that will happen of itself, and will need web standards developers to work with the various teams to provide feedback. I don't know what has happened with these initiatives since the Mambo/Joomla split. The Typo3 people have said the same thing about Typo3 V4.x, which is in alpha (http://typo3.org/?tx_newsimporter_pi1%5BshowItem%5D=0cHash=e4a40a11a9). Again, it will require web standard developers to work with them on that. So I think there's the opportunity to work with and provide feedback to bring these products up to a standard where we can maybe*enjoy* good web content management tools. -- 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] Standards and Aesthetics
[EMAIL PROTECTED] wrote: Not a question so much as a discussion topic -- is there a particular look to standards websites? Is there an aesthetic developing from the technologies we use? Many standards websites have subtle gradients in backgrounds -- is this because designers are confident in using PNG files which do gradients better for smaller file sizes? Standards websites tend to use rounded corners -- is that because of moz-border-radius? And of course we see fewer designs these days which are just Photoshop files locked into a complex table -- designs with DIVs are more likely to have breathing space than try to be pixel-perfect. So, is the technology dictating the look, or are all these things just accidents of history because some major relaunch like the stopdesign/AdaptivePath redesign of Blogger looked that way? Maybe this can be identified as a trait in the many designs of developers who implement web standards, but I can't see how these attributes form marks of identification of attributes of adopting web standards (I realise this is not necessary what you are saying). I think it's more to do with what is achieved by following web standards, and what pitfalls are avoided. I would tend to say that developers that adopt web standards are much more aware of both the pitfalls of poor web development process and the benefit of better SDLC process and also are much more focused on real world usability and accessibility issues. http://www.maxdesign.com.au/presentation/benefits/ http://www.webstandards.org/learn/reference/web_standards_for_business.html etc, etc. --- 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] Standards and Aesthetics
Ted Drake wrote: Hi John Sites look similar because the early standards-based web developers were so influential. CSS-based design is different beast than table hacking and people feel more comfortable riffing off a successful site than learning a new technique with a design out of their head. Yes, the ones who had good design aesthetics did. There were a lot of early practitioners of standards back in the late nineties, but they did not have the same design sense to drive this movement. It was only when the better designers came along that there were examples of standards implementation that really showed a path to follow. Also, I don't think that five years ago you could market tableless designs with any success. As standards-based design matures, you will see new varieties that table hacking never dreamed of. Personally, I'm hoping to have some time to begin exploring CSS3 layouts much more. IE7 isn't that far off in the future and we can begin using more sophisticated behaviors now with Safari, Opera, and Firefox. Yes, I think that standards based designs are going to show marked better usability than those who stick with the old path. I choose to live in the countryside, no broadband, it's a good reminder just how frustrating some sites can be to use on dialup, a frustration rarely experienced with sites properly implementing standards. 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] Accessibility: Default placeholders
Herrod, Lisa wrote: for the record, I'm still following the thread. this isn't even close to finished. I think it's best if I take a time out and write a thorough article. If it is a topic worthy of more discussion, I think that is the best way to serve that purpose. --- 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] Accessibility: Default placeholders
James Bennett wrote: On 11/17/05, Patrick H. Lauke [EMAIL PROTECTED] wrote: Linking back to my philosophical question at the beginning: is web development a subset of software development, or is it - for lack of a better term - the development of an experience. A related point from that: should web applications (functional, intranet-type apps) still have their own feel or integrate seamlessly (from a visual standpoint) with the OS? I think part of the problem here is that, despite any wishes we might have to the contrary, web browsers don't consistently integrate with the look and feel of the OS. Internet Explorer uses Windows' form controls, yes, and Safari uses the Mac OS' controls, but (for example) Gecko-based browsers have their own set which, while reminiscent of older versions of Windows, really isn't native to anything. And despite much progress on the OS-integration front, Firefox still doesn't really feel like a native application on any platform. Opera occasionally has the same problem; here on Linux, even though it uses the Qt toolkit (or did last time I checked), it doesn't use the default Qt widgets for form controls. That's an absolutely spot on observation, and it does impact the user experience. Some applications style the look and feel of various system resources by compiling their own resource design into their own application, rather than purely passing it to the OS. And even if there were perfect consistency of browser form widgets with OS widgets, we would still be stuck with a fundamental problem: web applications, by definition, run in web pages, and no OS in widespread use has an application paradigm which matches that of web pages. So despite consistency of the widgets used for certain parts of web applications with widgets used in certain parts of traditional applications, we would still be working in a fundamentally different medium. And I think that web users, on the whole, have come to understand and expect that things on the web work differently from the other applications they use, so striving to be as much like the OS as possible would be a futile and counterproductive task. But the web developer still has to keep in mind that their application is being rendered on multiple devices for which they do not know how each are configured. Also, there are units of measure and design implementations that these device will be able to translate directly to suit the display of these devices, and there are others that will clash. If nothing else, WCAG is a very good basic check list to help the designer avoid many pitfalls. It can only help to be mindful of these things while designing. Which, I guess, leads us to the latter of your two options; as I see it, a web application ought to have a simple, intuitable interface (or experience) which is consistent within that application, because ultimately that is all the control the web application's designer will ever have. This does not mean that conflicts with widespread OS interface conventions should not be avoided when possible, but it does mean that consistency with the OS interface should not be valued more highly than consistency, simplicity or intuitability within the web application. Yes. This is probably so important it is an issue the both UAAG and WaSP should drive home to user agent developers. - 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] Accessibility: Default placeholders
Patrick Lauke wrote: Geoff Deering Okay, so if this was implemented in user agents, what would be your educated estimate of percentage of users who would configure this and therefore avoid this problem of interpreting the incorrect state of form controls? I'd estimate it to be roughly the same as the percentage of users that have reconfigured their OS to use different default colours which would make them get confused by *judiciously* styled form controls. Patrick And what percentage of users that access those web pages would you expect that to be? -- 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] Accessibility: Default placeholders
Patrick Lauke wrote: Geoff Deering I'd estimate it to be roughly the same as the percentage of users that have reconfigured their OS to use different default colours which would make them get confused by *judiciously* styled form controls. And what percentage of users that access those web pages would you expect that to be? You tell me...as they're the ones that you mentioned as a group that would potentially have problems with designers styling form controls in the first place, if I recall correctly... No, you tell me, because this is your suggestion on how it should be handled. it just says it changes the background color, because this is under the control of the custom settings of the users desktop Anyway, I think we've bored the rest of the WSG list enough with this fundamental philosophical difference. You advocate not styling form controls at all to avoid any potential problems; I say that judicious styling, combined with more refined and obvious browser controls (it should be fairly easy to find the overrides, not buried under 3-4 levels of options), plus possibly alternate style sheets / site preferences, should not be a major problem as long as designers are made aware of the potential problems and don't just make arbitrary design choices (which anybody who calls hHimself a designer shouldn't anyway). There's probably no way to get our two views closer, so I'll agree to disagree once again :) P I think that people on this list are intelligent enough to know that if they are bored with this thread they can easily ignore it by identifying it by it's subject heading. But it may just be, if anyone is still following it, that this discussion may at least provoke thinking more deeply about the impacts of such design implementations. I think that is one of the characteristics of the people on this list; they approach design in this medium with a real care about the user experience. I feel their intention comes for a real desire to be the best possible designers, implementing great design, and try to emulate best of practice within that context while understanding why there are standards conventions to aid the user experience, accessibility, appropriate use of markup etc. It's not a philosophical difference here, it amazes me that this is the perspective you draw, because it's clearly a difference of understanding and interpreting the impact of standard interface design elements when they clash with interface design conventions for communicating the state of the user interface. It's not a philosophical issue, it's clearly a functional issue. No, you are completely misunderstanding what I am saying if you have drawn the conclusion that; You advocate not styling form controls at all to avoid any potential problems. I know my English expression could be improved, but if you draw this conclusion, you have completely missed the point, and I think I have covered enough ground to make that clear enough. And the final solution you provide, which definitely has potential merit, has many problems right at this point of time. No user agent I know of currently has this capacity to abstract form elements styles. So this isn't something one can recommend. If designers are depending on users to override designs elements that conflict with standard interactive design conventions, I feel their fundamental approach to design is flawed, because they are not putting the basic principles of the design of the interface of device interact as a primary consideration. As for your last statement, are designers well aware of this particular issue? It seems from the discussion here they are not, and as I have mentioned before, it is therefore important to highlight this problem, because many designers try follow standard so they don't inflict miscommunication on users, and the sad thing is that this particular issue, I feel has not been address properly in web standards. It's not designers fault. It's just been overlooked. How do you feel when you have been designing something with all the best intention, then find out you have unintentionally implemented a design that conflicts with user interface principles? Software development and particularly web development are rich in history of these types of misunderstandings and implementation. -- 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] Accessibility: Default placeholders
Patrick Lauke wrote: Geoff Deering Secondly, by this recommendation you are actually addressing the flip side of the problem I am trying to address. The case you are addressing here is 1) A recommendation of how to deal with styles that may conflict with a form element that is in an activated state. 2) What I was addressing was dealing with styles that may conflict with a form element that is in a non activated state. Aeh...I don't see how recommending that users should have the ability to override the designer's style suggestions if they're proving to be confusing only addresses 1 and not 2. Yes, you are right, it does cover both scenarios I highlighted. But as I said, there seems no feasible way to technically implement this recommendation. Either way, that these recommendation could be feasible in practice, is for the functions within the user agent being able to detect at least two conditions; [...] I can't see how this type of functionality will ever be added to a user agent because it goes against the fundamental interface principles of OSs. The WAI/UAAG would come under scrutiny if they did this. And with all the bugs and unimplemented recommendations in user agent development, I can't see this ever seeing the light of day. Maybe I wasn't clear, but this functionality *already exists* in user agents (although it's a tad on the crude side, I'm hoping to see a more granular control) As for UAAG, this is an implementation of guideline 4 Ensure user control of rendering http://www.w3.org/TR/WAI-USERAGENT/guidelines.html#gl-user-control-styles Ensure that the user can select preferred styles (e.g., colors, size of rendered text, and synthesized speech characteristics) from choices offered by the user agent. Allow the user to override author-specified styles and user agent default styles. Are we now talking completely across purposes? Patrick No, I don't feel we are. This recommendation does not address the problems raised by this specific issue, according to my understanding. So I would very much appreciate if you could explain in thorough technical detail and functionality how this works and how it addresses the problems (I see) this specific issue raises, or at least show how you would address this issue in functional specifications. 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] Accessibility: Default placeholders
Patrick H. Lauke wrote: Geoff Deering wrote: No, I don't feel we are. This recommendation does not address the problems raised by this specific issue, according to my understanding. So I would very much appreciate if you could explain in thorough technical detail and functionality how this works and how it addresses the problems (I see) this specific issue raises, or at least show how you would address this issue in functional specifications. In thorough technical detail and functionality? Functional specifications? Why do you have to make this issue sound so inflatedly complex? Taking Internet Explorer as an example, at the moment you have access, under Tools Internet Options... General Accessibility, to three checkboxes: ignore colors specified on Web pages; ignore font styles specified on Web pages; ignore font sizes specified on Webpage. My proposal: why not add a further one ignore form control styles specified on Web pages? Technically, the browser should then simply ignore any author defined styling of form controls. There...sorry if it's not in functional spec or technical detail... P Okay, so if this was implemented in user agents, what would be your educated estimate of percentage of users who would configure this and therefore avoid this problem of interpreting the incorrect state of form controls? - 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] Accessibility: Default placeholders
Andy Kirkwood, Motive wrote: Hi Kevin, Nice example, top marks ;). Sometimes these discussions can get a little abstract and one (real world) example can help make the discussion less murky. Geoff, I understand your pain with regard to traditional (print) designers and the often rocky transition to screen-based design. (Although there's also no guarantee that a developer is any more aware of interface semantics.) By way of confession, back in '97 I coded a form using radio buttons as found them more satisfying aesthetically than checkboxes. Hopefully education or general awareness means that up-and-coming web designer/developers have more of a community to draw on. I often think the root cause of many issues with website usability come down to the mock-it-up-in-Photoshop-then-hand-it-over-to-the-tech-people-to-be-built approach. Ideally there would be meaningful dialogue between the brand/visual and the interface/usability. Yes I agree. And one of my points is you can't really go blaming designers for doing this. I'm just looking through some of my collection of Web Standards/Design References and I can't find any where that addresses this area explicitly, and that is probably because no one thought the need to state it explicitly, because who of us has omniscience to see this phenomena now starting to appear. I didn't. So if any one is to blame, it is someone like myself, who was aware of this and I should have maybe contributed this a long time ago, I was on the WAI GL and ATAG for a few years, a while ago, so I should have added it to the Techniques knowledge base. I don't think any designer is to blame, it is just an issue that should be in the knowledge base, but isn't. But I think it just important to draw peoples attention to it. I have for a long time thought of putting up a wiki, because no one here, IMHO is the holder of all the knowledge. I learn stuff all the time and am amazed at what everyone can contribute. I just think that a wiki would probably be the best way to represent the fantastic group knowledge that is here, but it would be a challenge just to structure it. -- 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] Accessibility: Default placeholders
Patrick Lauke wrote: Geoff Deering The problem is that web designers are now implementing designs that convey meaning to form controls, that they are not intending to imply in their design, Which, again, is a sign of a bad designer, and a problem that should be solved by educating the designer, not simply saying that inputs should not be styled. A far more open recommendation would be along the lines of feel free to style form controls, but ensure that you maintain clear and unequivocal visual clues as to the type, state, etc of the individual controls, in sympathy with system defaults and user expectations. That sounds absolutely nice and clear. Wonderful. But please explain how to execute this as a recommendation; but ensure that you maintain clear and unequivocal visual clues as to the type, state, etc of the individual controls, in sympathy with system defaults and user expectations? How do you know what device configuration is receiving your design? Because if you do not, and cannot be absolutely sure your design is not clashing with this principle, you cannot *ensure* you have succeeded. Unless you know for sure how users have configured their interface you are swimming in the sea of uncertainty. There is no guarantee you have not miscommunicated the state of the control. If accuracy of communicating the true state of the elements and attributes of your design is a primary principle to your design philosophy, you cannot be sure you have not interfered with this process if you overlay this type of css on these form elements. I don't mind going on debating this, but I would like to state clearly here; just as long as designers are aware that there is an issue here, and if they choose to do so, then there is no guarantee that their design may not clash against this functional convention. Just as long as they are implementing their design without ignorance, then I feel I've contributed all I want too. That's my issue. Once this is raised, and they realised that such recommendations, no matter how well intentioned (as the above), will not save them from the possibility that their design may clash somewhere, then they can make their own decisions empowered by knowledge, not hedged in ignorance. As an extended note; this could happen with any input field background color, but the likely probability that it impacts, would probably be very minimal, IMHO. But the minute I began to see grey becoming the default for conveying the presence of input fields in designs (which basically isn't a bad idea in many designs, in fact, when you look at it it appears to give better cognitive enhancement), *except* for this problem of this being the default reserve interface for conveying state to users on many major OSs. And if we are trying to future proof, who knows what wonders of usability research will lead to designing the next generation interfaces for operating systems. Then you have to go back and correct your styles to address this. And how many of use actually get a chance to go back and correct these on sites we have done years later. Your lucky if you can. It's just raising the issue. If designers what to go ahead and do that in full knowledge, that is their decision. I just feel it is important to discuss the issues, and not misled them into feeling there is any way around this. Nothing I have seen so far offers a solution to style input controls in this manner and be free of concerns of clashing with conveying interface state. this will degrade the user experience because of purely visual design degrading the inherent meaning of a standard interface between user and form element state. Carefully considered, as opposed to purely visual, design (and yes, there IS a difference, despite the general feeling evident in certain factions of the WAI that all design is just bad) has its place in enhancing and visually integrating form controls in an overall site design. I know many people feel that about the WAI GL, but I have never felt that. People complain about the WAI police and the lengthy drawn out debate that goes on there, but I mostly see a lot of people concerned *not* to write recommendations that restrict design. I know others see it differently, but I know lots of them that actually see accessibility and liberated design as interdependent. Is CSSZG not a great show case? I love it that by far the majority of the people on the Working Guidelines Group have a vision of incredible compassion and lack of self interest. I learnt *heaps*, not only from the knowledge and opinions of those on it, but also by their manner as people and as a group when discussing issues. I'm really grateful to have had an opportunity to work with them a little. I know it has driven some people to exhaustion, but still there remains a real integrity amongst those that work on it, and those
Re: [WSG] Accessibility: Default placeholders
Patrick H. Lauke wrote:
Geoff Deering wrote:
How do you know what device configuration is receiving your design?
Because if you do not, and cannot be absolutely sure your design is
not clashing with this principle, you cannot *ensure* you have
succeeded.
But that is true of pretty much any element and situation where you're
applying style. And that's why we have separation of content and
presentation: if the presentation does present a problem to the user,
the user agent should provide the user with a simple way of
overriding, or completely ignoring, the styles suggested by the designer.
Firstly, this still does not address the initial problem.
Secondly, by this recommendation you are actually addressing the flip
side of the problem I am trying to address.
The case you are addressing here is
1) A recommendation of how to deal with styles that may conflict with a
form element that is in an activated state.
2) What I was addressing was dealing with styles that may conflict with
a form element that is in a non activated state.
Either way, that these recommendation could be feasible in practice, is
for the functions within the user agent being able to detect at least
two conditions;
for your condition;
if(FormElementWebDesignerStyle != FormElementClientDefaultValue)
(FormElement == active) then do {apply correct display of state};
and for my condition;
if(FormElementWebDesignerStyle != FormElementClientDefaultValue)
(FormElement != active) then do {apply correct display of state};
I can't see how this type of functionality will ever be added to a user
agent because it goes against the fundamental interface principles of
OSs. The WAI/UAAG would come under scrutiny if they did this. And with
all the bugs and unimplemented recommendations in user agent
development, I can't see this ever seeing the light of day.
I'm really not up to date with CSS behaviour at all, but if someone can
show me a real world example of this recommendation and how it could be
applied, without programming the user agent functionality, and therefore
changing the UAAG specs, I'd be happy to see it.
You could probably do it with client side scripting, but then that
breaks when it's turned off.
Unless you know for sure how users have configured their interface
you are swimming in the sea of uncertainty. [...] If accuracy of
communicating [...] is a primary principle to your design philosophy,
you cannot be
sure you have not interfered with this process
With my intentional omissions (not trying to misquote you, just making
it generic), I'd say this applies to any styling, not just the
specific case of form elements.
If you are suggesting this is to be handled by the user agent, how are
you going to implement it? I'd like to know your suggestions on this,
and the functional logic.
I know many people feel that about the WAI GL, but I have never felt
that. People complain about the WAI police and the lengthy drawn out
debate that goes on there, but I mostly see a lot of people concerned
*not* to write recommendations that restrict design.
Fair enough...I'm probably thinking of some of the more radical (and
possibly most vocal and entrenched) elements here.
Yes, I know, but the way they are still worked with and appreciated for
their input is inspiring. I used to play the devils advocate there
because in the long run it helps to apply as much scrutiny and analysis
as possible for the most clear and comprehensive outcome. It's
incredibly hard work to develop accurate standards that are also free of
unnecessary restrictions. It requires that type of process.
---
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] Accessibility: Default placeholders
Patrick Lauke wrote: Geoff Deering wrote: With all due respects this is the way default graphical user interface on operating systems are designed to function. From page 158 of The Windows Interface Guidelines for Software Design; But we're talking about the design of web sites, not software that should visually integrate with, and adhere to, the OS defaults. It would be very strange indeed if web based user agents did not conform to the programming conventions for software interface guidelines. The minute that happens there is a breakdown in a system to be able to communicate its state clearly with the user, through whatever application or device it is running. This is a web standards based group, and I feel that web standards based developers can gain a deeper appreciation of the work that has gone into these standards if they are more aware of the relationship with the principles of software interface design and the interrelationship of user agents and digital devices. Understanding this, and it's history, can only help. The user agent has a completely interdependent relationship with the OS, its system environment and resources, it actually uses these system resources, where described in markup, and are then placed on the browser canvas as operating system resources (form controls). The people that worked on the various drafts of HTML are well aware of this, because the state of form controls are change via the markup. This shows that markup-user agent-OS have an interdependent relationship via software handles, and that the user agent is requesting the OS to communicate it's state to the user. This has a universal meaning across multiple devices. So I cannot see how your argument applies, to me, it doesn't stand up. A designer should not implement a design element where their design falsely indicates to the user that the form control is in another state than it is actually in. This is misrepresentation of state. This also leads to another problem, in that if users configure their operating system to a custom scheme, unwittingly the web designer may be indicating to the user that a field may be read only even if it is not grey. How does the designer know whether to use grey or not? They don't. All they know is the majority of users probably do not customise this setting. This is why I believe that it is best to not style form controls (or at least minimally) Taking this thought further, they shouldn't style the size, typeface, colour of body text, or any other aspect of the web page either, as it may unwittingly clash with, or go against, user defined settings? No, I'm not saying that at all. That is different than what I have stated. This has to do with a standard way of communicating state in both OS and user agent. The point is that these design standards have reserved meaning, and if the designer does not pay heed to this they may not communicate the correct state of the control to the user. Personally, I still think don't style form controls is far too sweeping a rule to catch certain edge cases. As you said yourself or at least minimally... which is very difficult to quantify, and depends on the specific situation. It may be, I agree with that. My point is, just be aware of this and make sure you do not inadvertently create an unintentional conflict of communication of state of form control because of a lack of awareness this standard way of representing state. Oh well, I guess we'll have to agree to disagree on this one, P It's a free world, and I do appreciate reading your opinions. - 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] Accessibility: Default placeholders
Hassan Schroeder wrote: Geoff Deering wrote: This also leads to another problem, in that if users configure their operating system to a custom scheme, unwittingly the web designer may be indicating to the user that a field may be read only even if it is not grey. How does the designer know whether to use grey or not? They don't. Erm, well, actually, they do :-) http://www.w3.org/TR/REC-CSS2/ui.html#system-colors :: or at least, they know what color to use... Yes, thanks for pointing this out. I'd say the system defaults do these anyway, I can't think of anything off hand where you'd need to explicitly declare these, but I guess there possibly are... -- 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] Accessibility: Default placeholders
Patrick H. Lauke wrote: Geoff Deering wrote: So I cannot see how your argument applies, to me, it doesn't stand up. A designer should not implement a design element where their design falsely indicates to the user that the form control is in another state than it is actually in. This is misrepresentation of state. The interpretation of the state a form control is currently in also depends on the surrounding context. To pick up the earlier don't use grey at all example: that may well be true if the surrounding background is very light, but on a page with a very dark or black background I'd posit that it would not immediately trigger that grey=disabled/read-only association. As a sidenote: it's been a while since I've actually come across any read-only inputs, and can't really think of a scenario in which I'd want to use one (and therefore, maybe I'm not thinking along the same lines - the need to differentiate between writable and read-only inputs?). But basically what I think I'm getting at is: just because there is a chance that designers may not be judicious in their style choices and confuse the user is not a strong enough reason to give a blanket we shouldn't style inputs at all recommendation. I think you are missing the whole point. You find these types of web environments mostly on intranets. For a lot of people in large organisations, these are primary interfaces they have to work with. To neglect to address this issue correctly could easily impact the integrity of data because the interface is not communicating *state*, because if the designer is unaware of this, and overrides this visual communication of state that the user agent is conveying, with their own arbitrary design implementation, it would be miscommunicating the state of the data. In this case, it would be a major design blunder. -- 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] Accessibility: Default placeholders
Patrick H. Lauke wrote: Geoff Deering wrote: You find these types of web environments mostly on intranets. For a lot of people in large organisations, these are primary interfaces they have to work with. To neglect to address this issue correctly could easily impact the integrity of data because the interface is not communicating *state*, because if the designer is unaware of this, and overrides this visual communication of state that the user agent is conveying, with their own arbitrary design implementation, it would be miscommunicating the state of the data. In this case, it would be a major design blunder. But is the solution to make a sweeping don't style inputs recommendation, or to actually educate the designers not to just make arbitrary decision, but decisions firmly based on usability (including expected behaviour/presentation of state)? And, assuming that a design has been implemented which does not exactly match OS conventions but is nonetheless clear, understandable and usable, is it not just as valid, as long as the interface design within the pages themselves is consistently applied? No, because what you are saying here is a whole heap of criteria that does not address the priority issue, and that is not doing anything by design that will override the user agent visually representing the state of the data (controls) to the user. I'm talking explicitly about misrepresentation of state. -- 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] Accessibility: Default placeholders
Terrence Wood wrote: Patrick H. Lauke said: But is the solution to make a sweeping don't style inputs recommendation, or to actually educate the designers not to just make arbitrary decision, but decisions firmly based on usability (including expected behaviour/presentation of state)? Yes, this is indeed the correct approach. kind regards Terrence Wood. That's a good general rule of thumb. But I am talking about something that is very specific here that is currently being implemented incorrectly, and if general rule of thumb overrides what is a standard primary mode of communication of the true state of the interface, the designer has failed to provide the correct interface. -- 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] Accessibility: Default placeholders
Andy Kirkwood, Motive wrote: Hi Geoff, (To pick up on Patrick's point.) Have you come across a scenario on a website where it seems appropriate to use an input element to indicate that an option exists but cannot be edited by the user? Yes I can (domain registrars). In various states fields are often read only. Also control panels, Webmin, SWAT, etc, workflow in CMSs where you can see certain data but don't have the rights to modify it. Perhaps it's preferable to show such content as text rather than as an input? (Seems like an instance of yes, we have no bananas: yes this is an input, but no you can't.) No, populating form elements is the correct method for displaying such data if there is need for any input. Sure you can render all the content onto the user agent canvas without any form controls. But the minute you put a form element like input there, you are inviting interaction from the user. If you represent that in a way that says to the user this is in a read only state, then of course the user will not regard it as a data field that they can input data. In this instance, form elements are designed to represent the state of the data according to that level of users rights to view, modify and delete. Now it is not the correct use of these that is the issue here. This has been a standard in GUI interface design for a decade and a half or more, and the web inherited these standards, but it seems they really have not been documented properly and web designers have not been educated in these fundamentals. It's not their fault, it's just one thing that has really been overlooked. The problem is that web designers are now implementing designs that convey meaning to form controls, that they are not intending to imply in their design, and I am seeing this spreading at a rapid rate, and before to long, this will degrade the user experience because of purely visual design degrading the inherent meaning of a standard interface between user and form element state. -- 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] Accessibility: Default placeholders
Rebecca Cox wrote: Could be useful depending on the context. For example, if you wanted to show that a field was editable content (within the whole application), but not on the particular screen you are on right now (especially if the user knew that by clicking on edit or some other option they would be able to edit those particular fields.) You could even fine tune this so that if some users were able to edit a limited subset of the fields, they would only be only shown the disabled input for those they would be able to edit. As with the bananas, knowing that a shop usually has them but not today could be useful to someone. Cheers, Rebecca Yes, that's it, in the given context, it has implicit meaning, given the data set it is being applied too. --- 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] Accessibility: Default placeholders
Kevin Futter wrote: On 15/11/05 3:20 PM, Andy Kirkwood, Motive [EMAIL PROTECTED] wrote: Hi Geoff, (To pick up on Patrick's point.) Have you come across a scenario on a website where it seems appropriate to use an input element to indicate that an option exists but cannot be edited by the user? Perhaps it's preferable to show such content as text rather than as an input? (Seems like an instance of yes, we have no bananas: yes this is an input, but no you can't.) Best regards, I actually used read only input fields recently for our online subject selections. Compulsory subjects were pulled out of a database and displayed as read only input fields, while other fields were normal select elements. Why not just display the compulsory subjects as plain text? Because then there is a visual and cognitive dissonance between the two information sets - they can seem unrelated, especially when you consider that high school students rarely read a web form's accompanying text, no matter how important. I think in this case the fact that the information was displayed with as part of the form avoided that problem, while using the readonly attribute and styling the input text a medium grey took care of the rest. What you are saying is completely logical. In some contexts, it would be much better to show the data retrieved in markup that has more semantic value and is more appropriate to styling. The only problem you have here is when you go to the web programmer and suggest your idea (which is a good one), he say Now I have to go and write two sets of markup to address those with purely read only access (no form elements), and those with access rights for modification (requires form elements). If they are generated by different systems from the same data set, as can be the case, then I think that is a better option. But it comes to money, try convincing the web manager, the Ex Director of It and all the rest of them... Good luck. --- 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] Accessibility: Default placeholders
Patrick H. Lauke wrote: Bert Doorn wrote: Is it really necessary for accessibility to include default place-holding characters in edit boxes and text areas per WCAG 1.0 Checkpoint 10.4? Is that an obsolete guideline? Personally, I'd say it is an obsolete guideline indeed. However, I recently heard on the WAI IG list that some braille software requires at least a space as a placeholder, otherwise it just does not expose inputs to the user. I'd argue that this is a fault of the software...but it's something that might have to be taken into consideration. http://lists.w3.org/Archives/Public/w3c-wai-ig/2005JulSep/0034.html Why can't the braille software detect an empty form element and inform the user it requires data? Is this an authoring tool problem or a problem with the way standards are prescribed? I agree with this from two perspectives 1) that to address this to the nth degree, where it is actually a problem with either the way the software functions or is a bug. How much of our time do we spend addressing bugs in user agents? Isn't so much of the information on lists like this sharing insights into how to address bugs in user agents. I think this is what turns non standards developers off standards development. Admittedly tag soup has it's own set of bugs, but being a standards developer means, to me, you have to be prepared to work with lots of buggy software, far more than should reasonable be expected. 2) often I feel place holders are not good usability, because the forms themselves should be designed well enough to represent the data sets required. I think it can add to all sorts of cognitive problems in complex screens. Regards 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] Accessibility: Default placeholders
Jonathan O'Donnell wrote: Leaving it there can be a problem. I have seen a demonstration (at a Melbourne WSG meeting, no less) where the agent placed the cursor at the end of the place-holding text without reading it. There is a real danger that the user will enter text without knowing that the place-holding text is there. Yes, I'm not surprised at this observation at all. --- 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] Accessibility: Default placeholders
Herrod, Lisa wrote: I ran a usability evaluation last week where some (few) of the form elements had place-holding text and others didn't. This caused problems as you might expect as users scanned over those fields thinking that as they were already populated, they were therefore optional. Of course they were mandatory and caused validation errors. This was more an issue of inconsistent design, though it does illustrate possible usability/accessibility issues. Lisa Exactly, and how many users make the same mistake on complex pages where the form fields are pre populated, thinking that the system has added the appropriate data or is not inviting the user to add data. *Another* thing I see that is happening in design a lot lately is that input fields are in greyed background by design, not function. What this is telling the user is that that field is *read only*. That is the standard way operating systems manage read only data, and the same way it is done on web based systems. It's absolutely sending the wrong message to users, when the input field is open to accept data input. If users are used to working on complex data retrieval systems, where there is a lot of read only data, then they will be confused by this because this type of design breaks the standard by which GUI's function. If this type of design continues, it will only confuse users more. -- 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] Accessibility: Default placeholders
Herrod, Lisa wrote: Yes this is an interesting point. And it differs from visually highlighting a field once the user has encountered a form validation error. For example, a user misses or incorrectly fills out a mandatory field and when the form is re-presented, those fields are visually highlighted with a background colour. In this example, I find users actually like this method and find it useful/helpful. This may work okay for visual users, but it has no means of communicating with those who cannot rely on visual indicators. This leads to something that has not enough attention has been drawn to; Mandatory data fields, Required data, fields that require correct data after validation should all be grouped together with a *fieldsetlegend*. This informs all users of the requirements of that data. Leave fields that do not meet this criteria outside this group, either in a separate group or ungrouped. This standard of putting an asterisks * after (or before an input field) does not only not inform an unsighted user, it often gives the indication after they have tabbed through the field, to late for them to manage their input without back tracking. It is a much better practice to group all these fields together. Not only is it better accessibility practice, I feel it offers better usability by design. -- 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] Accessibility: Default placeholders
Derek Featherstone wrote: On 11/14/05, Geoff Deering wrote: Why can't the braille software detect an empty form element and inform the user it requires data? Is this an authoring tool problem or a problem with the way standards are prescribed? Agreed, Geoff. We really do need to know more. We'll need to add this to the hitlist for the WaSP Accessibility Task Force. It is something that is of concern to all - I'll see about running some tests with a local braille display user and see what I can determine from his tests... See my previous post to Lisa. I think this actually needs a major article on ALA or somewhere where it gets a lot of exposure. Your blog would be okay too. I encourage you or Patrick to write something addressing this. Also need to address this issue of greying input fields (which indicates read only status). --- 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] Accessibility: Default placeholders
Bert Doorn wrote: Geoff, I know exactly what you mean with the greyed out fields. Came across it myself only yesterday - a form where all inputs had a grey background. It wasn't until I clicked in one of them that I realised the field was not disabled. Yes, someone please, who writes for some of the major design magazines or ezines, please address this before it gets too out of hand because I feel a lot of people are implementing this, not realising that it does have a standards based meaning as an interface design attribute. 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] Accessibility: Default placeholders
Patrick H. Lauke wrote: Geoff Deering wrote: *Another* thing I see that is happening in design a lot lately is that input fields are in greyed background by design, not function. What this is telling the user is that that field is *read only*. That is the standard way operating systems manage read only data, and the same way it is done on web based systems. It's absolutely sending the wrong message to users, when the input field is open to accept data input. The problem with this is obviously that it's difficult to say *how* grey an input has to appear before a user thinks it's read only. Do we sit down and define a required luminescence/contrast to the background? In my mind, hard to quantify other than to say: be careful, don't make it too dark/grey, otherwise some users may think they can't use them. I think it is quite simple, don't use any scale of grey at all. Grey is reserved for meaning *read only*. 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] Accessibility: Default placeholders
Derek Featherstone wrote: Agreed. Putting them after *visually* and leaving them before in source order, and as part of the label can be really useful - its semantically meaningful, can be emphasized (using label em /em/label) as shown in the second example on that page is useful. You could easily use the same technique to emphasize the text required instead of an asterisk. Yes, I agree, doing both is probably a better option as the asterisks has become a standard flag for marking required fields visually. It's too hard to go back now. I'm a minimalist, so I'd just use the fieldset, but I think your solution offers better overall usability (and accessibility). - 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] Accessibility: Default placeholders
Patrick H. Lauke wrote: Geoff Deering wrote: I think it is quite simple, don't use any scale of grey at all. Grey is reserved for meaning *read only*. With all due respect, that sounds a tad too draconian for my tastes...and it's exactly the kind of talk that will make web *designers* simply stop listening to anything we say about standards and accessibility. It's a design and usability issue (with obvious accessibility implications stemming from it) that cannot be boiled down to a simple, one size fits all rule. It needs to be evaluated on a case by case basis. With all due respects this is the way default graphical user interface on operating systems are designed to function. This is what the user agent should adhere too, the basic principles that form GUI standard software design, and it is something that designers should understand when implementing their design, because if they fail to do so, it most likely will cause both usability and accessibility issues. If you set any input control to read-only this is how it will behave, this is how it communicates to the user; This field is read only. That is what it means visually, it is greyed by default. From page 158 of The Windows Interface Guidelines for Software Design; You can also use text boxes to display read-only text that is not editable, but still selectable. When setting this option with the standard control, the system automatically changes the background color of the field to indicate to the user the difference in behaviour. Notice it doesn't say greyed, it just says it changes the background color, because this is under the control of the custom settings of the users desktop. This also leads to another problem, in that if users configure their operating system to a custom scheme, unwittingly the web designer may be indicating to the user that a field may be read only even if it is not grey. How does the designer know whether to use grey or not? They don't. All they know is the majority of users probably do not customise this setting. This is why I believe that it is best to not style form controls (or at least minimally), they can differ dramatically, not only over various operating systems, but over various versions and implementations of those operating systems, and the various custom desktop that the designer has no idea is being superimposed over their design, or visa versa. If you don't style form control I think it is less taxing cognitively. I used to style them, but I have abandoned that long ago because I think users become so used to seeing the standard controls of their operating system, that on complex pages, it begins to become too difficult to easily recognise them, IMHO. -- Geoff Deering I think Bert D ** 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] Accessibility: Default placeholders
Philippe Wittenbergh wrote: This makes kind of good argument for *not* styling form inputs at all, and leave it to the OS. On most of my OS X browsers, disabled form fields are not really greyed out, but rather use opacity reduction to indicate read-only. Philippe --- I agree with this observation exactly Philippe. I addressed this somewhat in my post to Patrick. - 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] Accessibility: Default placeholders
Terrence Wood wrote: Philippe Wittenbergh said: This makes kind of good argument for *not* styling form inputs at all, and leave it to the OS. On most of my OS X browsers, disabled form fields are not really greyed out, but rather use opacity reduction to indicate read-only. A quick test of unstyled input type=text on winXP and IE6 reveals there is *no indication at all* that a field is disabled. Nice one IE6. Oh, I lie or I'm tired, the outline may have an indiscernable gaussian blur into the field. FF is grey, as is Opera. kind regards Terrence Wood Yes, I'd really like to know the usability studies that changed the design of form controls so dramatically when MS designed XP. The buttons I think are fine, but the form fields... I'd just like to know how they were scene as an improvement? There are both *readonly* and *disabled* attributes in input elements. My main exposure to this was an Intranet application I was working on in 2000, aimed at IE5. Like many things that aren't major issues, I don't think it is well supported. I haven't done a general check on this for ages, to see how well it is supported these days. -- 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] Accessibility: Default placeholders
Graham Cook wrote: Geoff Deering wrote: Mandatory data fields, Required data, fields that require correct data after validation should all be grouped together with a *fieldsetlegend*. This informs all users of the requirements of that data. Leave fields that do not meet this criteria outside this group, either in a separate group or ungrouped. I can't agree with this Geoff. There are many examples where some fields are mandatory and others optional but need to be in one fieldset group. Some examples include; first and surname mandatory, middle name optional, home phone mandatory, fax or mobile optional, addresses where extra optional fields are added for long or complex addresses. Yes, I agree with you on that. Maybe there is a better way to approach those problems. Don't have an answer to it. In general though, I'd try and stick with what I have said before, but as you have pointed out here, there are obvious cases that don't easily fit to be able to present a logical flow of information. This standard of putting an asterisks * after (or before an input field) does not only not inform an unsighted user, it often gives the indication after they have tabbed through the field, to late for them to manage their input without back tracking. The standard that I had used for the past several years was to place a statement at the start of the form explaining the significance of the asterisk. These are then included within the field labels and are read by screen readers (use text asterisk not an image). Any errors identified upon validation are listed at the top of the form (after the asterisk description) and preferably include a link to go to the offending field(s). The fields in error should also be identified both visually and textually (ref http://telstra.com.au/standards/docs/accb_03001.doc page 27). I think this is good implementation, but I think it makes it much less taxing on non visual users if such form fields can be clearly grouped together, but when this can't be done, it's fine. This also helps visual users. At lot of work went into the Telstra standards, it's a shame they never utilised the knowledge within Rob Pedlow's Research team, because those set of standards, that have been in use for almost half a decade, are full of holes and misunderstandings. -- 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] Naked metadata
Jonathan O'Donnell wrote: Hi WSG'ers In general, data (including metadata) should be stored in one place only. This prevents drift: if it is only stored in one place, it can only be updated in that place. Often, the information that we want to store as metadata already appears in the Web page. Examples include the title, description (especially as opening paragraph) and the author's name. In footers, we often find rights information, the URL, and date information. If this information already exists in the data, and we replicate it in the metadata, there is the danger of drift. Perhaps pointing to the data from the metadata fields is a way of preventing drift, and ensuring that the metadata is as up-to-date as the data. ** Method ** Hi Jonathan, Given what you have said here, and what I would expect to see in serious authoring tools and CMSs, I think this area is generally neglected in most publishing tools (last time I looked). Quit a few CMS's say that they are DC compliant, but as you mentioned, do they actually store the data in one place, and not in the web pages? Is it part of the work flow and version control of the documents? I don't think so. I'd be glad if anyone can point me to a product that does address this need. For a CMS to address this properly, it needs to have incorporated a normalised schema based on DC into it's database. This was all the pages published from this system can incorporate the various metadata as well as alt and longdesc for images. Many organisations have legal requirements where they require snapshots of published data from any given time. A publishing system based on DC not only allows this features, but allow a complete analysis of all the subcomponents of a document and the various contributors. That also leads to problems with document management systems that manage their meta data from properties within the documents and network environment variables. Last time I tried to extract metadata from MS Word, using Perl and Python, I could only get the standard set of properties, any data in custom properties was unretrievable (at least by me). I don't know what OO or the latest MS Office offers. But I don't think asking users to maintain this data will work, unless they are librarians. I think that it has to be as automated and as transparent to the user as possible, because most users are just not interested in this level of site QA, unless it is an important component of the job. Regards 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] Avoiding the evil br
Vlad Alexander (XStandard) wrote: Hi Hope, There is nothing evil about the br element unless one is using it for visual effect. In your example, you are using br correctly. For addresses, you might want to use the address element instead of p. Regards, -Vlad http://xstandard.com I agree with you about br, but address should only be used when it refers to the author or owner of the document http://www.w3.org/MarkUp/html3/address.html http://www.w3.org/TR/2002/WD-xhtml2-20021211/mod-text.html#sec_8.2. 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] Font-size em and reseting within
Lea de Groot wrote:
On Thu, 25 Aug 2005 14:51:00 -0700, Janelle Clemens wrote:
If you are using em with font-size is there is a way to clear the font-size
of a box element (stop the inheritance)?
No, not really.
I normally get around this by only setting font-size in two places, as
a general rule (which always has exceptions, but very careful ones :))
The two places are:
- on the body tag, eg
body {
font-size: 90.1%;
}
- on leaf elements, ie. I will rarely set something like:
#wrapper {
font-size: 0.9em;
}
I am more likely to put:
h1 {
font-size: 1.6em;
}
and
div.subnote {
font-size: 0.9em;
}
Both of these will be 'leaves' in the DOM, ie they will not have any
children (except maybe a span)
HIH!
Lea
I'm just wondering how people handle the IE text resizing problem, where
IE handles percentages much more accurately than em?
It would be more ideal to us em, but it seems more practical to use
percentages for better accuracy of font scaling? What do others think?
see
http://www.clagnut.com/blog/348/#c790
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] Font-size em and reseting within
Patrick H. Lauke wrote:
Geoff Deering wrote:
I'm just wondering how people handle the IE text resizing problem,
where IE handles percentages much more accurately than em?
You can safely use ems as long as your highest font size is
something else, like %.
For instance, as long as you have something like
html { font-size: 100%; }
you can do anything you like with ems after that, like
body { font-size: 0.9em; }
etc
Can you give a technical explanation of what is going on there? What is
happening inside the user agent that once it sets it basic
initialisation through such declarations, after that it can then render
relative units correctly?
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] Accessibility, the possibilities
Stuart Sherwood wrote: Are any of the validation tools: Bobby, Cynthiasays, Watchfire...more respected then the others? Regards, Stuart. You can use any of these, and all of them, but you should combine them with your own knowledge base and common sense. I also use Marc Gueury's HTML Validator(http://users.skynet.be/mgueury/mozilla/). There's no tool that I trust explicitly, but if you arm yourself with some basic knowledge, then even if a tool has it's short falls or faults, and you are aware of them, you can still use what it renders correctly to assist you. Tabindex: one piece of advice, if you code tabindex, don't use intervals of 1, use something like 10, 20 or even 50; tabindex=10 tabindex=20 tabindex=50 whatever. If you have to go back and change the order or add items, it's a pain in the arse if you have to change every tabindex in the document. Tabs will naturally flow to the next highest value, it doesn't matter if the interval is 10 or 100, whatever, this allows you to insert other items later on, without having to edit the rest of the document. What I usually do is break the document down into sections, and within the section increase at intervals of 10, but when I go to a new section, jump either one hundred or even a few hundred, even a thousand. Gives breathing space... phew. But in general, if the document is well structure, and still reflects that structure when styles are turn off, the tab flow is often the same with or without coding tabindex. If that is the case, why bother coding tabindex (I realise there are exceptions like using an initial tab to set the focus/skip navigation)? --- 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] Accessibility, the possibilities
Stuart Sherwood wrote: Hi All, First, I'd just like to check I understand something correctly. Validation for WAI AAA = WCAG 1.0 Priority 3. Is this correct? Ok, we can validate for: * W3C HTML/XHTML * CSS * WAI * Section 508 And I've recently learnt about accessibility checks for: * Colour blindness * Contrast * Flicker/strobe If you pass all these test, does this exhaust all accessibility issues or are there more? Regards, Stuart http://www.w3.org/TR/WCAG10/full-checklist.html http://www.w3.org/TR/WCAG10/checkpoint-list.html I think there are P3 checkpoints that are not covered here that you would need to check manually. Just as a side issue, there is a lot of debate in the accessibility community about the merit of using accesskeys, tabindex, etc. Sometimes there is no clear cut path to take regarding these issues, in some places, accesskeys can cause problems in the way they are implemented by user agents and also how they fit the site design, at the same time they can be of great help in forms on intranets where users are doing a lot of repetitive tasks. Similar debates surround tabindex, sometimes it's best to leave this to the natural flow of tabs managed by the user agent, sometimes not. IMHO, many accessibility practitioners aim for WAI-AA, whilst incorporating the most practical of the WAI-AAA checkpoints to aid accessibility. What I'm talking about here is a basic set of checkpoints one implements for all sites, in such cases, with ROI in mind. My general target is WAI-AA with what I would call the essential AAA checkpoints. Some sites (or clients) warrant all of P3/AAA, which is what is required to certify it as AAA. My 2 cents worth. 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: Staying on topic (was RE: [WSG] Accessibility, the possibilities)
John Foliot - WATS.ca wrote: There are in fact checkpoints under all three Priorities which require brain intervention - they simply cannot be tested mechanically. Try running a page through something like Cynthia says (http://www.cynthiasays.com) will quickly show you what needs to be manually checked. Cynthia says also provides a fairly extensive chart of what and how their tests are run (http://www.cynthiasays.com/Standards/CynthiaVersusBobby.htm) I'm glad John picked up on this thread and illucidated and expanded on it (and that the JF accesskey parser is working well ;-) ). -- 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: Staying on topic (was RE: [WSG] Accessibility, the possibilities)
John Foliot - WATS.ca wrote: There are in fact checkpoints under all three Priorities which require brain intervention - they simply cannot be tested mechanically. Try running a page through something like Cynthia says (http://www.cynthiasays.com) will quickly show you what needs to be manually checked. Cynthia says also provides a fairly extensive chart of what and how their tests are run (http://www.cynthiasays.com/Standards/CynthiaVersusBobby.htm) I'm glad John picked up on this thread and elucidated and expanded on it (and that the JF accesskey parser is working well ;-) ). -- 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 **
[WSG] Evaluating Web Sites for Accessibility with Firefox (article on Chris Pederick's FF ext Web Developer toolbar)
Hi, I know this article was bunched in with a reference to Ariadne back on 10th August by sunny, but given it's relevance and importance in building a toolbox for evaluating web accessibility, and the recent question by Stuart Sherwood, I'll mention it prominently here, because it's a shame to not mention it. Patrick H. Lauke has written this article (http://www.ariadne.ac.uk/issue44/lauke/) on Chris Pederick's Web Developer toolbar http://www.chrispederick.com/work/firefox/webdeveloper/, a tool Derek Featherstone also mentions as a great aid for web standards development. -- 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] Longhorn Avalon - seismic shift for web standards?
David Pietersen wrote: Sorry, trying to be aware of the request to stay on topic, but... You shold be more forward-thinking if you're responsilbe for .gov web site. (No offence, please.) I never said my site was not compliant. Every page of anything I serve (apart from the legacy apps) works perfectly in FireFox and Opera, and has at least a 1 A rating. The content even works on my pda, which is Pocket PC of course ;-) My whole point is... why bother? Why spend the massive amount of time (and therefore 'the peoples' money) making it work across all these technologies when practically everyone who is using it has access to IE. It is JUST a browser, heck, you don't even need to pay for it. Years ago, in a different organisation I worked for we made a piece of 'Windows Only' software available for free. The 'Apple People' screamed their heads off for three months until we also made their version available (at GREAT expense to the organisation). I left about nine months later, and at that point 0 (zero) people had actually downloaded it. Not one. Zilch. I respect everyones right to be different, but there comes a point when kowtowing to the vocal minority is just not fiscally responsible. Anyway, I did not mean to hijack your list. This is my last post on the subject. Have a good day :-) IMHO, it seems to me that everything you are saying here are basically all the same reasons to adopt web standards as part of the systems development lifecycle. It does take more effort to learn to apply web standards, but the whole point is that there is less pain for both the user and developer in the process. If you can't see that then why bother, and I'd have to agree with you, just go back to being happy with tag soup. But there is also something else at play here, in that if it is a government department, there is probably some form of CMS involved and all the government procedures for managing digital documents, and that may or may not allow easy upgrades in the design, and some systems/CMSs are a nightmare to try to deploy standards compliant web sights. In regards to large organisations, you are right, if the site is quite workable and accessible, it may create more problems than it's worth to try and implement a fix. But at the same time I think the experience of people on this list is that they achieve everything you aim for in accessibility and multiple deployment, and maybe more so, by using web standards, at least in the environments they work in. Not only that, when you want to redesign your site, in any way, let alone upgrade it to address future technologies or devices, there is a lot of evidence to show that there is a big difference between those who do so with a base of standards compliant documents and those whose ones are marked up in tag soup. This is something that quite often cannot be solved just by developing in web standards. In large organisations the real problem is systems that are able to transform documents whilst maintaining the document structure, semantics and metadata. There are hardly any systems out there that can do that. But those who are looking to solve these problems, and have a keen eye to making sure the architecture and systems they are using will be able to accommodate such changes, along with being able to quickly adopt new technologies like SVG, AJAX, etc, will be in a far better position than those systems that are not trying to address these problems. Also, IMHO, I feel that the overall quality of solutions offered as a web standards approach as opposed to tag soup will always offer superior advantages when do well. Regards 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] HTML Codes - Characters and symbols
jackie reid wrote: this is handy for people like me who dont know the HTML Codes - Characters and symbols off by heart or even 1% by heart http://www.ascii.cl/htmlcodes.htm cheers Jackie If you are like me, looking for short cuts and wanting to economise on how much information is stuffed into your brain, you can use something like Tidy (http://tidy.sourceforge.net/) to do these conversions for you. Many good web tools have a tidy interface, you just have to make sure you keep up to date with the most recent version of Tidy. Regards 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] help or web standards group?
Lea de Groot wrote: On Tue, 12 Jul 2005 09:26:22 +1000, Richard Czeiger wrote: Perhaps there should be two lists - one for discussing standards/accessibility/best practice and one for how do I fix my float/site check please. Having multiple lists also starts lots of flame threads on 'to which list topic X belongs'. Given the number of tech lists with large membership and large traffic, I don't think anyone has solved the problem :( I think the flip side is that a) newbies need to see the 'advanced' stuff to learn by osmosis and b) its really good for gurus to see the newbie questions (and maybe occasionally answer them? Hint, hint people ;)) to keep them grounded. warmly, Lea It's a huge Help when the Subject line clearly defines the topic, that way you can quickly identify threads where you may want to participate. It also helps when browsing archives. Russ has covered this in the intro, and most lists do, but people still persist with Help Needed and equivalent vague and general subject titles. If the subjects are titled in clear descriptive language, then a lot of these list problem are solved, and you may more readily attract people on the list who can contribute to that thread. 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] help or web standards group?
Jason Foss wrote: If I can chip in too - I don't have a problem with newbie posts, nor more advanced posts. But I don't even open Help Needed type subject lines. A descriptive subject line is all that's needed; you can quickly decide if you want to read or get involved in the thread. My 2c, anyway... :D Exactly 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] help or web standards group?
Joshua Street wrote: There's a minor problem with this, though I agree with your core argument. Newbie posts requesting site reviews can't very easily bear a descriptive subject line when all they want is advice on semantics/markup and best practises. There isn't a core problem they want addressed, nor a core problem we as a group should seek to address. I think Subject :Site Review Request/Help indicates what that post is all about, and I think the help people get on this list from those posts is really helpful, even for those of us just reading them.. There is, however, scope for refinement here. If someone requests a site review and an aspect of this website is found wanting, the way in which this is discussed should not need to be confined within the original thread. I agree. For example, if the subject line was Please review - example.com in the initial request, and example.com used definition lists (just because everyone loves to argue about the application of those!), then it may be appropriate, when (inevitably) the scope of the discussion broadens to bear a highly tangential relation to the originally referenced website, to alter the subject line - RE: The undefined definition list (WAS: Please review - example.com). I'm aware this happens, though perhaps not as often as it should. I agree with this, but some lists don't. The trouble is when the thread is hijacked rather than a new sub thread is started to address the need to seperate discussion on a number of topics within the thread. I think we need to accept that some subject lines are never going to be descriptive in the way some members desire - and this isn't anyone's fault, but it is something we can work to correct as the thread of discussion progresses. Kind Regards, Joshua Street Agree, if there is this level of thoughtfulness applied, I can't see any/too many problems as long as there is a reasonable effort to make the subject line descriptive. Maybe enough said on this, at least from my part. 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 **
[WSG] Call for Review: Working Draft of WCAG 2.0
Apologies for cross posting, but here's your chance to provide feedback on the W3C WCAG 2.0 http://lists.w3.org/Archives/Public/w3c-wai-ig/2005JulSep/.html 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] Dumbing Down Validation in WCAG
Steven Clark wrote: Has everyone read Gez Lemon's post on Validity and Accessibility? http://juicystudio.com/article/validity-accessibility.php Validation got moved down from level 1 to level 2 in the WCAG... Steven Clark I understand why it was given P2 status in WCAG 1.0, as that was way back in 1999, but for all the reasons we try to adopt standards, and for all the reasons we try to support them, I cannot find any good arguments for dumbing them down. I feel the W3C WAIGL may be trying to be helpful here, they are trying to be as expansive and inclusive as possible to all, they really do work hard at that, but what I think most people here understand, is that the standards themselves are meant to be inclusive. Isn't there evidence enough on lists like this that shows a community of developers working together to solve such problems whilst still working with standards? I mean, surely the only reason one would do that is out of the benefits, and not out of any dogmatic propensity to just abide by a set of standards. If that is the case, why is there need to be regressive? What I feel is happening here is that they are catering for the ATAG (http://www.w3.org/WAI/AU/) and UAAG (http://www.w3.org/WAI/UA/) world, who are trailing behind the web standards based developers, and WCAG is trying to accommodate that. I don't really know, it's just outsider looking in. There are a lot of tools and user agents that need to be applauded for the efforts to better support W3C standards, but at the same time there are some, well many, that really need the ATAG and UTAG tests applied to them to show them for what they are. Unfortunately very few people are willing to do this, and I can understand why, along with time and everything else, who really wants to be a web standards reviewer of tools and user agents? I have thought about doing this myself, but I have found that the inner voice of criticism far outweighs the inner voice of complements when approaching such subject matter, and it seems just such a waste of time to get involved in if that is the outcome, even if it does help prompt some companies to address issues in their products. But maybe it is time to do so. I have thought about setting up a wiki to address this issue (I have the web server space to do it), and others regarding accessibility, because even if you go ahead and put Dreamweaver and FrontPage, and the rest of them, to the ATAG test, there should also be some knowledge base to show people who want to work with those products, or who are locked into working with those products, ways, means and methods to use these tools, in conjunction with other techniques and tools, to produce standards compliant web content. If WCAG2 allows validation to be watered down to L2, I can only see this as being soft on ATAG and UTAG sectors of the industry, again making it much harder for developers. Really, isn't so much of our time, knowledge and development now spent on working with the many user agent and tool bugs and shortcomings? It's ridiculous to keep pandering to these weaknesses in our industry and actually accommodating their lethergy to do anything through the actual standards. Maybe there should be either collective letter of protest written or individual voice their public concern over this to : [EMAIL PROTECTED] Regards 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] small and big : accessibility usage?
Alan Trick wrote: Acording to the WHAT-WG the small element does have semantic meaning. I don't have the link though. They basically said that it was good for things like 'small print' and such cases. I think small is an unusal case here and is meanigful and useful. Alan Trick I think that when we are trying to apply accessibility principles we need to try to keep in mind the notion of device independance, and to a blind user small and big have no relevant descriptive meaning, because that element is then telling them that the word or phrase is either *small* or *large* in size, which isn't a true semantic markup, it's presentational. I like Tim Bray's discussion on Descriptive markup as opposed to Semantic markup. http://www.tbray.org/ongoing/When/200x/2003/04/09/SemanticMarkup 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] Character encoding (HTML Tidy)
Gene Falck wrote: Tidy is one of the programs I have been thinking of getting, so I would like to hear about any bugs and bug fixes. Regards, Gene Falck Tidy has evolved from it's beginning with Dave Raggett. Like many tools, it's great when you learn how to use it, and to work with it's bugs. I haven't had to use it recently, but will so again soon. It's available in many forms http://tidy.sourceforge.net/ Here's the reference on Encoding http://tidy.sourceforge.net/docs/quickref.html#char-encoding Programs like Homesite and TopStyle use Tidy, but it is your responsibility to make sure you are using the latest version of Tidy.exe (from SF.net), which is located in each programs root directory. In Homesite it is dated 16 June 2001, so it's pretty old and out of date. TopStyle is 8 Aug 2004, where the latest version on the SF.net site is 22 May 2005. Just download it and update it. I remember there used to be a bug that drove me nuts where it would escape characters it shouldn't, but can't remember what the situation was. Probably been fixed, it was a while back. It has got better and better, with less bugs. I find it a great tool to have in the kit. 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] Character encoding
Matt Thommes wrote: What benefits or problems avoided do you perceive by doing this and what other characters are you escaping? Lea, I'm not sure why I always escape the dash - perhaps because I can??? :) I am assuming the dash will someday cause me problems, so I just escape it now, to avoid a lot of re-work. Other than that, I escape a lot of usual characters, such as single quotes, double quotes, and ampersands. For some reason, I feel I have to escape every character that is not a letter or number. I think this is quite an interesting discussion, and I'm sure some of the members of this list can shed more light on this, but I do think developing with the best of practice forsight of the day does at least help to future proof web sites to address evolving technology. We never know if the search engines or parsers of the future are going to have a hard time or easy time making sense of our sites. I know I have developed sites in the past that I have felt pretty confident have been a good attempt at best of practice, but age sure shows their vintage, and I am not talking about the CSS, just thinking of the (X)HTML. Tidy can help with transforming characters, but it does screw some pages up (don't know if those bugs have been fixed). So what about Q or quote (XHTML2)? Who bothers to use it? References http://www.w3.org/TR/charmod-norm/#sec-WhyNormalization http://www.w3.org/TR/charmod/ --- 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 **
[WSG] FYI: Web Accessibility Engineer position open at W3C/WAI
From memory, this position has come up time and time again over many years. I don't know if it has ever been filled. Original Message Subject:Web Accessibility Engineer position open at W3C/WAI Resent-Date:Thu, 02 Jun 2005 03:52:57 + Resent-From:[EMAIL PROTECTED] Resent-CC: recipient list not shown: ; Date: Wed, 01 Jun 2005 23:41:13 -0400 From: Judy Brewer [EMAIL PROTECTED] To: WAI Interest Group [EMAIL PROTECTED] Dear WAI Interest Group Participants: The Web Accessibility Initiative (WAI) at the World Wide Web Consortium (W3C) is currently seeking a Web Accessibility Engineer. Please feel free to circulate this notice, avoiding cross-postings where possible. The job description is listed below, and is also available on the MIT/CSAIL Web site along with instructions on how to apply. Please note that any correspondence related to the position should be sent via the contacts on the MIT/CSAIL site, not in reply to this email. Regards, - Judy Job description and application instructions: http://www.csail.mit.edu/contact/jobs/2002.html Job Description: Title: Web Accessibility Engineer Req Number: mit-2002 WEB ACCESSIBILITY ENGINEER, Computer Science and Artificial Intelligence Laboratory, to ensure that core web technologies support accessibility for people with disabilities as part of the World Wide Web Consortium's (W3C) Web Accessibility Initiative (WAI). Will assist in developing guidelines, techniques, and test suites for authoring tools, browsers, and media players; provide staff support to W3C WAI (http://www.w3.org/WAI/) working groups; assist in reviewing W3C technologies while under development to ensure their support for accessibility and develop and negotiate technical solutions for accessibility requirements; manage issues lists for comments received on working group documents; edit working group documents; and maintain working group resource pages. Will also give presentations on W3C/WAI technical work, provide technical assistance on implementation of WAI guidelines, and liaise with organizations pursuing related work. REQUIREMENTS: computer science or related degree; a minimum of two years' experience working in team settings; and in-depth knowledge of W3C technologies and WAI guidelines, including WCAG, ATAG, UAAG, XAG, and EARL. Must be familiar with the web industry, accessibility support in mainstream web technologies, assistive technology, disability communities, and the accessibility research community. Excellent oral and written communication skills needed. Must be available to travel. Knowledge of project management, W3C process, web applications, QA procedures, CMS, user interface design, VoiceXML, RDF, Semantic Web, and DOM preferred. -- Judy Brewer+1.617.258.9741http://www.w3.org/WAI Director, Web Accessibility Initiative (WAI), World Wide Web Consortium (W3C) MIT/CSAIL Building 32-G530 32 Vassar Street Cambridge, MA, 02139, USA ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] EDS embracing Web Standards
Had cause to visit the EDS.com web site tonight. I used to work for them years ago. They had one of those absolutely horrible corporate sites last time I visited, but shock horror... http://www.eds.com/site/standards.aspx AMAZING. Regards 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] best way to approach markup of an address
Lea de Groot wrote: On Mon, 23 May 2005 06:48:55 +1000, Geoff Deering wrote: The first is correct, but address should only be used when referencing the author of a document. http://www.w3.org/MarkUp/html3/address.html http://www.w3.org/MarkUp/html-spec/html-spec_5.html#SEC5.5.3 It's not used for general contact information, which is kind of waste of a good element. Happily, both of the examples you cited contradict you. Do put street address in ADDRESS tags :) warmly, Lea What I meant was that it is not used for general contact information as in using it for any sort of address. It is specifically for the contact of the person responsible for that document. The *ADDRESS* element is not appropriate for all postal and e-mail addresses; it should be reserved for providing such information about the contact people for the document. see http://htmlhelp.com/reference/html40/block/address.html which is probably a much better reference. That is the semantic meaning of address on a web page. Regards 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] best way to approach markup of an address
Patrick H. Lauke wrote: Geoff Deering wrote: The first is correct, but address should only be used when referencing the author of a document. Arguably, though, if these are the contact details of the company whose site you're on, then it *is* correct (as they would, in the wider sense, be the authors of their site - and not Bob down in the IT department). So establishing whether or not it's correct obviously depends on context, which Bruce didn't provide in his question. Yes, it can be anyone responsible for the content on those pages, such as the address of the real estate agent on a house for sale page, but I couldn't use it (correctly) to make a list of addresses of places I visited during my holidays, whatever. In other words, if you use the address element on a web page, that is telling a parser that that is the contact address information associated with the content of that document. Thanks for the HTML4 reference. Regards 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] make poverty history website
Patrick H. Lauke wrote: And now I just realised that the original question was not about accessibility, but about specifications in general (such as the XHTML/CSS/etc ones). In which case, even more of a reason why the W3C can't release a spec for Flash: it's not their technology. They can't release a spec if it's owned by a commercial company.Of course they'd only be releasing *their* specs, as they relate to *their* official technologies. It would be a bit like saying Why don't Microsoft release a spec for Quicktime movies... It's actually the other way around, companies and organisation developing technologies are encourage to develop them according to W3C recommendations. So 1) Web developers are encouraged to follow WCAG, 2) Authoring Tool developers are encouraged to follow ATAG (http://www.w3.org/TR/ATAG10/) 3) User Agent developers are encouraged to follow UAAG (http://www.w3.org/TR/UAAG10/) The UAAG applies to Flash. http://www.w3.org/WAI/UA/ The current versions of Flash have improved their accessibility to some degree, thanks to both pressure from groups like this, and a fair bit of working behind the scenes by W3C accessibility people. Bob Regan is the accessibility product manager for macromedia (http://www.markme.com/accessibility/). I notice that Macromedia is not on the UAAG participants list (http://www.w3.org/WAI/UA/wai-ua-members.html), but I think they are on the authoring list (http://www.w3.org/WAI/AU/), but not currently in good standing. If you really want to chase up the current state of companies working with ATAG and UAAG it's best to ask Matt May (http://www.w3.org/People/Matt/), he's the guy working with these companies (last I checked). He's be a good person to throw 10 questions at for the WSG:-) 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] W3C and Flash
Prabhath Sirisena wrote: Until Flash becomes an open specification, we'll have the song and dance. Making it an open spec won't happen because Adobe won't really benifit from the deal. Prabhath http://nidahas.com I don't think it has to be an open specification at all. It can remain closed and do it's own thing on a proprietary basis, but it needs to comply with UAAG to meet the W3C standards compliance we are trying to work with to make our web sites as standard and accessible as possible. We don't ask IE or Opera to be an open specification, or JAWS, or anything else, but we do encourage them to meet W3C UAAG, so that we can then use them and incorporate them into our web content with full confidence that they meet web standards and accessibility guidelines. Regards 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] make poverty history website
Patrick Lauke wrote: Geoff Deering It's actually the other way around, companies and organisation developing technologies are encourage to develop them according to W3C recommendations. That still does not detract from the fact that the Flash format is not a W3C technology. The UAAG applies to Flash. http://www.w3.org/WAI/UA/ True, but that does mean that the W3C is in a position to release a spec for the *format*. I can't see what the point is. The W3C has no control over Java or many other technologies that are proprietry or closed, but that does not stop them from becoming or meeting W3C standards or compliance. But it is still a headache for us developers, because then we have to deal with plugins. It would be far better to be living in a world where the user agent run everything native; SVG, SMIL, etc. But how far are we from that? One thing that gets my observation about watching discussions on lists like this, is not so much the education and learning of standards, which is enough to do as is, but the huge amount of time and investment in learning all the user agent bugs and gotchas. I just wonder, if we really had to cost our development time, how much of it is dealing with both authoring tool and user agent bugs? And another thing, the effort developer put into dealing with this is not recipricated, in my view, by many of the companies producing the tools. If you really want to chase up the current state of companies working with ATAG and UAAG it's best to ask Matt May (http://www.w3.org/People/Matt/), he's the guy working with these companies (last I checked). Unfortunately, Mayy is leaving (or has already left) the W3C http://www.bestkungfu.com/archive/date/2005/04/quittin-time/ That's sad. He doen't say so, but I think a lot of them get W3C burnout trying to deal with those companies. They can't speak freely, but I suspect a lot of the companies have their token member on W3C working groups, where back at HQ the project manager really doesn't give it much priority. 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] make poverty history website
Patrick Lauke wrote: Geoff Deering True, but that does mean that the W3C is in a position to release a spec for the *format*. I can't see what the point is. The W3C has no control over Java or many other technologies that are proprietry or closed, but that does not stop them from becoming or meeting W3C standards or compliance. Geoff, don't misunderstand me. I'm not advocating that only W3C technologies should be used, and that Flash is in any way bad. I was merely replying to the do the W3C have specs for Flash question that was originally posted. Thanks for clarifying that, now that I look back at the discussion I see the thread of the logic now:-) I see your point (unless I'm misunderstanding): the W3C should provide standard and compliance requirements for any type of content, be it Java, Flash, PDF, etc But this does seem well beyond the W3C's remit, and yes it goes against their utopian but we have all these wonderful technologies of our own...SMIL/SVG/co view. I think it is the best of both world. If it is an open specification developed by the W3C then that is obviously going to provide a better premise to work from, but if it is proprietry, then it's also okay as long as it meets the various standards. But the W3C has become so complex that anyone working in one area may not realise that they may possibily be not working properly with other standards. At the same time, from what I have seen, they really do work hard at trying to be inclusive of everyones needs. And another thing, the effort developer put into dealing with this is not recipricated, in my view, by many of the companies producing the tools. Very true. sigh:-( 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] Playing a sound file - what is the best way?
Mike Foskett wrote: I completely agree, use Flash. I'd say the same for video too, for the same reasons. Why: One solution multiple platforms. Saturation on all computers is over 90%. That's more than any browser. What data is this statistic based on? Regards 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] Playing a sound file - what is the best way?
Tom Livingston wrote: On Tue, 17 May 2005 14:13:50 -0400, Mike Foskett [EMAIL PROTECTED] wrote: Stat based on these figures from Macromedia: I might add that these are merely posted on MM's site. The study was independent. http://www.macromedia.com/software/player_census/flashplayer/ There is a link that speaks to the company that did the survey... Can someone please educate me to the claim here; http://www.macromedia.com/software/flash/survey/ that; In March 2005, NPD Research, the parent company of MediaMetrix, conducted a study to determine what percentage of Web browsers have Macromedia Flash pre-installed. The results show that 98.3% of Web users can experience Macromedia Flash content without having to download and install a player. 1) I have never come across a browser, which installed with Macromedia Flash pre-installed. 2) I never knew that 98.3% of Web users can experience Macromedia Flash content without having to download and install a player. If they are coming from the standpoint that Flash was already installed (by someone), that to me seems to not be clearly stating the whole picture they are basing their scenario on and not presenting it in a true objective fashion. Last time I did a check on a series of browsers for the accuracy of HTTP_ACCEPT (a few years ago), it was quite unreliable. I had flash installed on all browsers, but not all of them reported this to the server, yet it was registered in their plugins. If there are more reliable methods of detecting plugins I appreciate people sharing them. Then there are the users out there that have flash installed and other 3rd party software to stop Flash from playing, so that they can control it. I agree with the suggestions to the various implementations of Flash to solve the original problem posted to this site, I think when all is taken into account, usability, design, accessibility, that is the best strategy. But statistics can be used to serve misinformation, and what I see on the Macromedia site gives me no reason to have any confidence in an accurate evaluation via clear and thorough methodology. 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] Playing a sound file - what is the best way?
Kay Smoljak wrote: On 5/18/05, Geoff Deering [EMAIL PROTECTED] wrote: 1) I have never come across a browser, which installed with Macromedia Flash pre-installed. IE6 comes with Flash player pre-installed. All versions, or a specific implementation/installation? 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] Playing a sound file - what is the best way?
Kay Smoljak wrote: On 5/18/05, Geoff Deering [EMAIL PROTECTED] wrote: IE6 comes with Flash player pre-installed. All versions, or a specific implementation/installation? I can't say for sure, but my feeling is that it's all versions. Well, I have installed WinXP (initial release) and the recent release with SP2, and downloaded IE6 on a number of occassions and installed it on other versions of windows, and not one of them has had Flash installed. It may come with an OEM install, but I have never seen it come with IE6. Also, I have found that even when it is installed, and the user has installed something like Crazy Browser so they have a tabbed version of IE, for some reason Flash does not load. 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] mutli language websites
sam sherlock wrote: Hello WSG List Members, I am delveloping a website that can switch between english and itallian. I am wondering if I should be using en-GB or en-gb for my lang attributes and also for the meta http-equiv=Content-Language content=en-GB / are these attributes sensitive to casing? or should I just have en also is the charset iso-8859-1 OK for italian content? I would also appreciate any links to web standard sites using multiple languages? thanks in advance, Sam Does anyone use transparent content negotiation to handle multiple language sites? I get the feeling this is hardly ever used, if so, why not? Regards 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] mutli language websites
Robin Berjon wrote: The problem IME is that when you use it you have to also provide a way for the user to pick her language which will override the negotiation (I've been accessing the Web a lot from computers localized in Japanese recently, and they're probably not sending Accept-Language headers that reflect the reality of languages I can really accept :). It's not complicated to mix both together but the extra feature of negotiating the default language rarely seems worth it. Yes, these are some of the problems I would have expected using this approach. Let alone if you are in some other country, in a net cafe and it is defaulting to another language, as what often happens with Google, which can be annoying for the user. Regards Geoff D ** 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] mutli language websites
sam sherlock wrote: I am using ip2couuntry class in PHP to decide the default lanuage. Thanks to Evandro who sent me a link to his site in Portugese and English. The site in question does not use the language attribute as inteneded (as far as I understand) all Lan attributes are set to en for Portugese, Itallian and English. What is the web standards best practise for multi-lingual sites 1. Should I use en or en-GB is the casing important? 2. What charset should I use for the Itallian version the same as english or other? 3. Are the any link available to webstandard best practise examples? Maybe you will find some of the info you are looking for here http://www.w3.org/International/geo/html-tech/resources/ G ** 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] Re: XHTML Strict alternative to ol start=11
Andy Budd wrote: So what do they believe the accessibility advantages of XHTML Strict are? As far as I'm aware valid and semantically correct HTML is just as accessible as XHTML strict. And I'm guessing they probably aren't serving their pages up as XML so strictly speaking they are serving their pages up as HTML anyway. This kind of pettiness and misunderstanding of accessibility really gets my goat. It's a damn shame if you ask me ;-) Andy Budd http://www.message.uk.com/ There are a number of advantages to using HTML/XHTML Strict. Firstly, the term strict implies the strict separation between content and presentation. This is meant to have benefit for both user and developer (in an ideal world). It is meant to free up both the user and designer. Normally with think STRICT, those W3C Nazis (like I saw recently on another list:-), but the whole idea behind Strict is the strict separation of content and presentation, ultimately aiming for both users and designers worlds to be much more free and flexible. That's the point. Using strict frees the markup of attributes that are bound to the content layer. This ideally frees the web pages to accommodate more flexible designs. With strict you could develop alternate style sheets, one with absolute units (to satisfy client requirements), and one with relative units (to satisfy accessibility requirements), whatever you want. If you use transitional, that is exactly what you are doing, and you may need to do it, strict may not work for your design because of current lack of support and other things, but you are using a DTD that is transitional between the aim of separating content and presentation, and mixing them together. It's basically a compromise. From a developer's point of view, in large content systems, one of the major problems is separating content from presentation. It is very difficult to regenerate sites with fresh designs if this issue is not addressed at the foundation level. This also aids addressing accessibility issues. We just have to look at any of our own work, when better user agent support arrives in the future, and the customer requires a redesign, will we be able to leave the HTML/XHTML as is, and just modify the CSS, or will it require an overhaul of both? Regards 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] Re: XHTML Strict alternative to ol start=11
Patrick H. Lauke wrote: I think what Andy meant (as I've got a feeling he's well in the know when it comes to css and separation of content and presentation) is what the advantages are if you can effectively write strict code while still declaring a transitional doctype. Yes, transitional doesn't make certain elements illegal, but that doesn't mean that developers can't do nicely separated content/HTML and presentation/CSS which happen to have a transitional doctype. There are *no* inherent benefits to tableless, css driven layouts in XHTML strict versus tableless, css driven HTML (strict or transitional) or even XHTML transitional. That is a misconception. There are differences to the way a rendering parsing engine will work with the different doctypes. Just as a C programmer thinks what will the compiler do with this code, there needs to be some understanding of what is happening at the parser level. That's also why this list exists, because, from what I can see is that most of us need a list like this so that we can deal with the bugs that are in the parsers and rendering engines. But I'm also talking about working with bug free parsers, even if that is in the future. In that case there is quite a bit of difference with the way a parser will work with the same design in Strict as it will in Transitional. If we fail to understand that we are failing to understand what is happening with DOCTYPE parsing and rendering. I can understand why you'd use Transitional, where you could use Strict, ie where there may be a lack of browser support for a particular design implemented in Strict, but not supported properly, so you'd use Transitional. But it makes no sense to use Transitional where Strict does exactly the same job. In particular, when served as text/html rather than application/xhtml+xml, and when not mixing in additional X technologies, for all intents and purposes XHTML is simply HTML with a slightly funkier syntax (self-closing elements for instance) which older browsers treat like broken HTML. There is no added benefit to the user. All the things you mention (switching stylesheets for different layouts, etc) can be done fine in transitional. You are missing my point completely. Try maintaining or redesigning large content sites that need to meet web and accessibility standards that are caught in this dilemma. I'm surprised both of you, who have more knowledge than I do in the design area, have not come across this very problem. I really see it as something basic that web developers who take accessibility and web standards as their core approach would understand that to redesign sites that meet valid strict (either HTML or XHTML), are much easier to rework than Transitional. And it has very little to do with the deprecated elements. The real lose is the attributes for elements found in both DTDs, which are not part of Strict, because they are presentational by nature. XHTML (and strict in particular) being more accessible than HTML (and particularly transitional) is a myth. Conscientious coders can use exactly the same approach (tableless etc) in both. Please explain why you would use a transitional DTD where a Strict one is valid and works just as well? Regards, 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 **
[WSG] FW: The list cms@webstandardsgroup.org is a private list
Can someone please clarify what is going on with the CMS list? I've been away for a few months, and off list. I've resubscribed to this one, but get the error/rejection below when I try to subscribe to the CMS list. I emailed info@webboy.net with the problem this morning at 8.45am. No reply. http://webstandardsgroup.org/go/resource131.cfm is certainly hidden away from the main contents. Geoff -Original Message- From: cms@webstandardsgroup.org [mailto:[EMAIL PROTECTED] Sent: Wednesday, 2 February 2005 8:02 AM To: [EMAIL PROTECTED] Subject: The list cms@webstandardsgroup.org is a private list Sorry, the mailing list cms@webstandardsgroup.org does not allow subscriptions. ** 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] standards and meta tags
-Original Message- From: Patrick Lauke From: designer After looking at the site mentioned by Anthony (relating to standards and local government) I noticed a lot of meta tags on that site [ http://www.salford.gov.uk ] which I haven't seen before [...] Forgive my ignorance on this, but can meta tags just be 'invented' and be acceptable 'standards'? Unless I'm mistaken, you can make up your own META if you want, for whatever reason you may have (e.g. something specific to your own site management / CMS tools, your internal search engine, etc). Of course, to be truly useful, the META should follow a formally published standard (e.g. Dublin Core), but there's nothing stopping you from writing your own standard - if people find it useful, they may use it. But yes, I'd liken it to the way in which you can make up your own elements in XML, but how it's only useful if two or more people then agree to use the same format (and then you publish something like a DTD or Schema, etc). The HTML4 spec also mentions the use of the profile attribute in a document's HEAD, which can be used to give more context to META. http://www.w3.org/TR/html4/struct/global.html#h-7.4.4 (but again, nobody stops you from making up your own profile). Patrick That's right. There are all sorts of metadata and subsets thereof, the most common standard being the Dublin Core. Vocabularies, Qualifiers, etc are used to extend and further define the core elements via subsets. And if you just can't get enough metadata, try this http://dublincore.org/2003/03/24/dces#title http://dublincore.org/2003/03/24/dces#creator The Semantic Web (W3C) version is all about metadata. It's not the same thing as we refer to when we talk about documents being semantically correct. In my opinion the W3C Semantic Web Initiative is an admission that the efforts to make a semantically rich web via semantically correct documents has failed. But I don't think the Semantic Web really addresses the root of the problem. The major problem is that metadata is not maintained at the file system level, and only at the document level. This makes it almost impossible to track versioning, history, and regenerate web sites and document sets, and everything else that is associated with proper document management. This is supposed to be addressed in the next version of MacX and Windows, but I doubt it. Also no CMS manages metadata at the filesystem or at the versioning level. Also see http://dublincore.org/usage/documents/overview/ http://www.w3.org/2001/sw/ http://www.w3.org/TandS/QL/QL98/pp/dstc.html http://www.medra.org/en/metadata.htm http://www.naa.gov.au/recordkeeping/gov_online/agls/summary.html http://www.edna.edu.au/metadata http://en.wikipedia.org/wiki/Metadata_%28computing%29 http://home.wlu.edu/~blackmerh/meta/acs12vi.html http://www.xml.com/pub/a/2003/04/16/deviant.html ** 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] about.com's Web standards article
Back about a year ago about.com were using Movable Type for all there sites. So they should be in complete control of their code. If they wanted to save money on bandwidth why don't they gzip up all their pages and configure the server to send those to user agents who handle them, which, I think, is pretty much most these days. - 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 **
[WSG] Mac Tools Kit for Web Standards Developer
Hi, I'm wondering what tools Mac developers out there use? I'm basically and windows and linux person, but will get a small iBook for travelling and testing on next week. I'll be OS in Nov/Dec and need to still do some work, so I need to be able to work pretty comfortably on the Mac. On Windows I mainly use TopStylePro. Appreciate any Mac software tips for standards based development - Regards 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] Is XHTML harmful?
Paul Connolley wrote: Geoff Deering wrote: I am talking about CSS applied to HTML and the rendering of the CSS as applied to the parsing of the document. But still, strictly speaking, an XML based document is bound to be more semantically correct because it is well formed. This means that the CSS can be applied without fear of the parser misunderstanding where a declaration could have finished. There is no possibility of any guess work in xhtml as it is well formed. You are talking about two distinctly different parsers. XHTML is a XML subset, HTML is an SGML subset. For example: In XHTML: ul liOne item/li liSecond item liThird item/li /ul This will throw an error because it is bad XML In HTML it will not. With the SGML parser it knows that when it arrives at a new li it is the beginning of a new list item. The same would apply, for example, to a p paragraph. Surely you don't believe that it would render pThis paragraph pThis other paragraph as a paragraph within a paragraph. You need to revise your understandings. HTML is NOT XML. Admittedly, XHTML contains inheritance to certain HTML objects but it is wholly a XML subset. You shouldn't try to argue about parsing when they are parsed by two different types of engines. But that is entirely my point. You're missing the point. Closing tags is being completely accurate with punctuation, where markup is the punctuation. Not closing tags CAN lead to ambiguity. In XHTML there is no syntax ambiguity, in HTML4 there are possibilities. It may not happen when validating against the doctype. Once again you are arguing for ambiguity. It is wrong to assume this. SGML allows for the omission of end tags because it follows a different ruleset That's exactly the point I am trying to make. - 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] Is XHTML harmful?
What Dean says so well here are also the reasons I prefer XML defined markup, and I don't think it negates the arguments that others have been expressing here for HTML. I think each on of them have valid points. But it seems to me that there are more reasons to use an XML based vocabulary than have previously been put forward. I also agree with him about writing parsers and their performances based on stricter or looser rule sets. I also try to see XML vocabularies as having a richer and more accurate rule set to express the content they encapsulate. I dream of a true semantic web were I can find content from searches that are based on arguments and phrases that are derived from clean document tree analysis of content. Even if we have those documents out there, current search methods and technology are far too primitive to understand that. Not that the search engine engineers are dumb, it's just that for all the content out there, there are only small portions of it that can be stored and analysed semantically, so there is not much point in doing that regarding ROI. And I don't agree with a lot of the way the W3C are handling the semantic web. - Geoff Deering Dean Jackson wrote: Friday, 8 October 2004 2:23 PM On 7 Oct 2004, at 02:09, Vlad Alexander (XStandard) wrote: Hi Kim, Ian Hickson is _not_ saying XHTML is harmful, he is saying that serving up XHTML with the wrong MIME type is bad. That's right. It's probably not the best title for the document, but my feeling is that people using the ... considered harmful approach are typically looking more for attention than for examination. Nevertheless, it's still an interesting read. Today, the real benefits of XHTML are on the production side. Say your CMS has 1000 documents and you need to change the class name of a div tag in all 1000 documents. If your content is in XHTML, you can use XML related technologies like DOM or XSLT to process all 1000 documents quickly and accurately because XHTML can be processed by XML parsers. I agree. Using XHTML over HTML brings some benefits that are hard to measure. The way I think of it is that XHTML allows more people to use your content in ways that you didn't originally expect. For example, at W3C we extract a lot of semantic info from our XHTML pages: building calendars, issue lists, relationships between pages, etc. This could all be done using HTML, but XHTML makes it easier (much wider range of tools in the XML world). The same goes for modifying pages. I have a huge range of tools available to do a site wide change with XHTML, and these tools are interoperable because they conform to the XML specification. If my Web guy gets hit by a truck, then I can call up another developer and assume that her XML skills will be enough to do the job (even though she may not be familiar with the tools). Then there is the whole Web Applications trend. Again, HTML and XHTML are pretty much the same in functionality here, but if I'm using an application on the Web then I want to make sure it is well-formed and well-structured. I don't want a typo by a web developer (such as leaving off an end tag) to cause my credit card to be debited twice. That's an extreme example, but in the general case, would you really run an application on your desktop that you were not sure was compiled correctly (or had millions of compiler warnings)? Allowing sloppy markup in applications is a security risk IMHO. On the design front, if you are thumping your head against a wall trying to wonder why the page is off by three pixels, wouldn't you like to rule out as much as possible in order to reduce the number of places you look for the bug? In most cases, this is easier with XHTML - you can check the document and then focus on the CSS. While the existing browsers are parsing and rendering HTML faster than XHTML, then you can serve XHTML 1.0 as HTML. I'm not sure exactly why HTML parsing/rendering is faster than XHTML, since in general it is much easier to right a high-performance parser for a strict language than a less strict one (and HTML also carries years and years of quirks to handle). Maybe it is just that the HTML code has been around for so long that it is highly optimized. Let's hope the desktop browsers will move into 2001 soon ;) To ask the question the other way around, what are the real benefits of using HTML over XHTML? I'm interested to hear the reasons (and I'm sure they are valid). Dean ** 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] Re: Is XHTML harmful?
From:Of Alan Milnes Ian Hickson is _not_ saying XHTML is harmful, he is saying that serving up XHTML with the wrong MIME type is bad. I've read the article and what I don't understand is that if it is so bad why is it acceptable to the Validator? I write my pages in XHTML with a XHTML 1.1 doctype and send the content type as text/html. That's how I was taught (doesn't make it right I know) and it validates. I've tried several methods of sending different headers depending on the browser but have yet to find one that works properly. Alan http://www.gameplan.org.uk Actually that's a good point. Most people who are trying to manage this are using TCN (Transparent Content Negotiation), or similar technology set, on the server side to serve documents according to the user agent capacity. - 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] Mac Tools Kit for Web Standards Developer
From: Kristof Rutten Hi Geoff, I've 'switchted' sides in March of this year and haven't returned to my old Win-platofrm ;) Yes, I suspect it could happen to me too, especially when you have the best of both worlds; Mac front end, and *nix backend, although I really do like GNOME and KDE. Tools I use most while desingning : CSSEdit from MacRabbit - http://www.macrabbit.com/cssedit/ Transmit - a great FTP client -http://www.panic.com/transmit/ CocoaMySQL - database tool - http://cocoamysql.sourceforge.net/ Take care, the OS X platform is highly adictive and you are not likely to return to your old win/linux boxes ;) Regards, .K Suspect you're probably right... thanks for the user friendly warning:-) - 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] Mac Tools Kit for Web Standards Developer
I have a 19 and 21 for development, so I'll just KVM the iBook (can't afford a Powerbook) Thanks Upon a little test run, the live preview of the code (literally 'as you type') is neat. This looks like it might be a pain for a small screen though. I have a 17 Studio Display, and i wasn't fond of the amount of room I had to code in. Still nice though. Tom Livingston Senior Multimedia Artist mlinc.com Get FireFox http://spreadfirefox.com/community/?q=affiliatesid=0t=1 On Oct 8, 2004, at 9:35 AM, Tom Livingston wrote: http://www.tumultco.com/HyperEdit/ ** 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] Mac Tools Kit for Web Standards Developer
From: Andy Budd Not forgetting Style Master http://www.westciv.com/style_master/ Andy Budd Yeah, I was waiting for that one to come up. Thanks 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] Is XHTML harmful?
Chris Bentley wrote: Are there any parsers out there you explicitly trust to get it right every time? I don't. I know of one, http://validator.w3.org/. Are you say though that User Agents are generally better/fast at parsing/rendering valid XHTML than they are valid HTML? No, that is not what I meant at all. I'm talking about the parser and rendering engine in user agents. No, you are missing the point. Maybe you need to go back and study parser logic rendering markup a bit more. They may well do, but they are still guessing if there are no end tags. I'm much more happy to explicitly declare my design than have parsers guessing at what I've designed, the performance trade off is not so great. I like to write valid markup too, and if your HTML is valid (written against the DTD) then the parser doesn't have to guess anything, I don't see your point as to why valid XHTML is technically better than than valid HTML. I am talking about CSS applied to HTML and the rendering of the CSS as applied to the parsing of the document. But still, strictly speaking, an XML based document is bound to be more semantically correct because it is well formed. This means that the CSS can be applied without fear of the parser misunderstanding where a declaration could have finished. There is no possibility of any guess work in xhtml as it is well formed. This may or may not be an obvious problem. But I would not be surprised to see complex designs misrendered when transformed from xhtml to html4 with all optional ending tags taken out. What I am saying is that with XHTML the designers knows this won't happen, given the correctness of the parser. Now go into the area of accessibility, how are you going to tell all sorts of user agents and devices the full semantic meaning of the markup. What about when aural.css becomes mature? Will complex document in HTML4 be as exact as those following XML syntax? Yes, if you write it against the DTD and follow accessibility guidelines. There is no difference between the semantics or the accessibility of HTML4.1 and XHTML1.0. You may be right, but I don't agree. It's only a small difference, but it is there. In my view, you cannot fully mark up documents with a trusted explicit semantic fullness without and XML definition. The border here might be small, but it's small enough for one definition to allow for best of interpretation and the other an explicit interpretation. Well-formedness has nothing to do with semantics. You're missing the point. Closing tags is being completely accurate with punctuation, where markup is the punctuation. Not closing tags CAN lead to ambiguity. In XHTML there is no syntax ambiguity, in HTML4 there are possibilities. It may not happen when validating against the doctype. That is not the problem. The problem is the CSS container, it's boundaries are often not certain. Except for the reasons give by Peter Ottrey the only technical reason for using XHTML is that you need the XML (this being the only technical difference between HTML4.1 and XHTML 1.0 ). Any other reason simply comes done to a matter of personal preference. I don't agree with that. - 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] Is XHTML harmful?
I think there are valid arguments for both sides of this. This is also where I agree with the approach of the Apache/Cocoon advocates in that you serve up the solution which be suits the user agent. As standards developers we are working in an imperfect world and it's what frustrates us all. What I feel actually saves the HTML argument, in this case, is that browsers actually have very very intelligent parsers in them. It takes a lot of work to handle the thousands of cases that quirksmode can throw up. Thankfully that also works in our favour when we slip up on our own validation. If you took all the quirksmode logic out of the parser in the browser and it only did valid DTDs for HTML4 and XHTML, and spat the dummy like SGML and XML parsers when it found invalid markup, and where all documents were valid, I bet you that out of all the designs the XHTML would render more accurately. The reason being that if you are not closing all your tags it can become a guessing game for the parser where the CSS declaration may end in various parts of the document. It always strikes me that when using HTML4 you are at the mercy of the arbitoriness of the parser. I know there doesn't seem to be any obvious problems, but just the basics of parsing seem to leave you with the feeling it is inherently there. That to me is the main reason to use XHTML over HTML in this argument. - 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] Is XHTML harmful?
On 07/10/2004, at 10:07 AM, Geoff Deering wrote: The reason being that if you are not closing all your tags it can become a guessing game for the parser where the CSS declaration may end in various parts of the document. It always strikes me that when using HTML4 you are at the mercy of the arbitoriness of the parser. There is nothing to stop us writing well-formed HTML. Elements which have optional closing tags are just that - optional. I agree with everything you have said, but.. in complex designs, take out the end tags and that's exactly what you leave the parser to do... guess. Are there any parsers out there you explicitly trust to get it right every time? I don't. They may well do, but they are still guessing if there are no end tags. I'm much more happy to explicitly declare my design than have parsers guessing at what I've designed, the performance trade off is not so great. Now go into the area of accessibility, how are you going to tell all sorts of user agents and devices the full semantic meaning of the markup. What about when aural.css becomes mature? Will complex document in HTML4 be as exact as those following XML syntax? In my view, you cannot fully mark up documents with a trusted explicit semantic fullness without and XML definition. The border here might be small, but it's small enough for one definition to allow for best of interpretation and the other an explicit interpretation. - 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 **
