[WSG] Articles/reasearch/experience of screen readers
Dear list, Not sure if this is exactly the place to ask, but I am very eager to get any authoritative (and by now, 'authoritative' can be qualified by anybody who's so much as seen one) information on screen readers. I am a css-enthusiastic web designer who sees the value of standards as a concept but does not necessarily bow to baseless trends, and more and more I see potentially brilliant ideas get shot down in the community because of 'standards' zealots who are very keen to violently condemn certain methods of working because of very dim notions of accessibility. While there is always common sense to fall back on, and we are lucky enough to live in a world with such a thing as the w3c, there are times when I become suspicious of accessibility precepts. "You can't do this because screen readers will mess it up" is incredibly common for inexperienced, adventurous web designers, before their imagination and creative approach to code is finally conditioned out of them without their ever being too sure why. Despite the fact I haven't been able to find anyone who has ever used a screen reader, I (have no choice but to) respect the notion that web sites should allow them a seamless, fulfilling, experience. I am obviously not doing this for any practical reward - as I've mentioned I have never had any contact with a screen reader user - for all I care they could not actually exist; but as a challenge to a very pure state of markup, the grail of smooth screen-reader navigation is worth achieving. Only I can never know if I have achieved it, because I can't test it; nor can I find anybody else to test for me, or even pin-point known problems. I think the myth surrounding screen readers is an incredibly bad thing because it fills the community with superstition. A great many otherwise intelligent, adventurous and imaginative potential innovators in the world of web design are completely crippled by this thing that they have no experience of whatsoever - it may as well be imaginary. w3c's accessibility guidelines are highly revered, and for the most part there is good cause for this - and as I've said I am a supporter of the notion of standardisation - but when talking about the precepts of design for the blind, I become very cynical because this stuff is pure idle theory from sighted people. I would love any links to articles/archived polemic/research studies/the appropriate list... If anybody here has actual experience of a screen reader, I would be overjoyed to hear from them. Likewise, if this is wholly irrelevant to this list then please tell me. :) Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Rotten Standardistas
Andreas, you elucidate what I mean pretty well. Christian - I know it's a shame that the only way I could express myself somehow makes standardistas look bad through implication. I don't want to give that idea at all. As for naming and shaming, I object to the notion strongly. The kind of bully I'm referring to doesn't include any particularly accredited or influential tyrants, it's just for the most part faceless extremists who use the banner of good intentions to spout domineering vitriol. To go and 'sort these people out' would be lowering to their level, and besides these people tend to be able to create their own flame wars very easily by themselves! *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Additional space between sentences ?
Which is semantically worse, and why? 1. Just manually putting the extra space in the markup. 2. Manually putting an extra inline element around the full stop and styling said element to create a presentational space. To me, they seem just as bad as each other - in the first instance because there is no meaning or purpose behind a genuine double space, and the desire is purely presentational; but in the second there is also semantically unjustifiable extra markup (more of it by volume - but at least it doesn't impinge upon real content) and requires even more stupid hard work in going about manually or dynamically editing the content to insert these tags... *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Articles/reasearch/experience of screen readers
@ Rahul: The preference thing is very strange. I read another small study where the findings indicated that the 2nd biggest problem for screen reader users was to find that the nav wasn't the first thing available. I'll try to find the article. My conjecture prior to this would be that, unless you are on a homepage with contents significantly greater than a simple blurb and a few 'quick links', you would not want to be informed of where you can go from somewhere immediately after arriving - and besides if the page did turn out to be not exactly what you wanted, you would start tabbing then rather than having to tab to avoid listing all your options over again. Another finding of the study was that site map presentation and immediate availability were key factors in getting the sus of a site without visual recognition. By the way, could anyone elaborate on what tab-indexing is? And how does the Alt+# system work? These seem to be crucial elements of screen reader browsing but I have a very limited grasp of their convention and application. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Articles/reasearch/experience of screen readers
@Matthew Hodgson: That's brilliantly useful information, Matthew. It is interesting you mention screen magnifying, because it is my company's policy to use ems as measurements as far as possible, based on the conjecture that partially-sighted people would probably want to increase their default font-size, and having the whole site (within reason) scale with that would make the whole design far more continuous. I recently discovered my Mac's zoom function (I'm forever startled by serendipity while slipping on F keys) which was nice. On a related note, I was horrified to see the effects of what I thought was IE7's text-size scrolling (Ctrl + mouse wheel up/down) - IE is still really bad at re-sizing images (FF is beautiful) and using this function, rather than simply zoom in on the rendered image, it attempts to re-render the whole thing based on botched calculations and creates some hideous results. This function, however, is not text-size scrolling (as it is with every other browser). IE7 still retains the 5 size scrolling but this is accessible only through the menu. I think this change is rather bad because we all expect those two actions to produce the same process, and also it's just not very good and creates a horrible experience for anyone who'd wish to use it. Is default text size adjustment as common as I'd presumed in the partially-sighted community, or is it for the majority, as you suggest, magnification that is used instead? @Steve Green: Steve, what you're doing is exactly what I wanted to hear! Sadly as much as I approve and would want to take part, I can't justify this time off work - my boss has no problem with sending me to design conferences up and down the country, but as far as building on accessibility, company policy is just to accept general standards. As long as you can stamp the site with 'valid code', 'works without script', and 'no tables'... There's no commercial incentive to put any serious work or insight into accessibility (at least as far as our practice dictates). @Frances: The schism between web designers and developers is a terrible thing wherever it appears... And you're right - only pointed work on the part of designers to understand developers and influence them is going to heal the rifts. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Articles/reasearch/experience of screen readers
Rahul Gonsalves wrote: This article seems to be good food for thought (and it references the earlier study that I did ;-) ). http://www.alistapart.com/articles/workingwithothers It was after reading this that I found the guts to question Talibani standards tyrants. It's an absolutely fantastic article that everyone should read - some of the best web philosophy that's ever been on ALA. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Additional space between sentences ?
'The point'. Very interesting notion. Presumably, sticking any kind of extra markup in is going to cause you to have to put in as much attention, effort and typing (at least) as putting in the space manually, and css can't yet select sub-element 'objects'. So seeing as you need extra markup anyway, you are in a sense being just as much, if not more, of a burden with content (bizarre spans all over the place or one more space?). The advantage of javascript is that the spaces can be procedurally generated, which removes the odious task of parsing every sentence in this new class, or telling all your writers to manually double-space. Regards, Barney Christian Montoya wrote: As for Javascript, the whole point of Javascript solutions is to "fake" a technique by adding in the same amount of markup as you would in the plain HTML case, but simply hiding that markup from "view-source." It's still in the DOM and you can see it with "view-generated-source," so there's no reason why a Javascript alternative to an HTML/CSS technique is going to be any lighter. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Additional space between sentences ?
Designer wrote:
Agreed, naturally. But can you point to an actual example of how to do
this? Apart from the (complex) problems of avoiding Mr. Mrs. etc, I
often use PHP and this is riddled with 'periods' where I don't want
spaces. It seems to me to be a complex issue to select only ". " and
replace with ". " ? But then, you probably know something I don't!
Horrible though the span thing is, it does at least leave control of the
layout to the CSS. If you subsequently want to eliminate the spacing,
you just change the {padding-right : 0.5 em} to {padding : 0} and all
the spaces on the site go back to normal. . .
If you can already do what you've just described in PHP, I can't really
help you. I didn't think of the case of Mr. etc - neither can I think of
any intelligent system for finding ends of sentences.
Not much help from me then.
Regards,
Barney
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Using JS to expand Abbreviations
I suppose server-side makes the most sense, since the page view isn't required to be dynamic per se. Very neat idea. Thierry Koblentz wrote: [EMAIL PROTECTED] wrote: Is there a good reason for doing this with JavaScript rather than doing it server side? Do you know of a SS solution to do this? I'd be glad to link to it from my article. IMHO, it's not a "server-side vs. client-side" thing, but a simple matter of what's available to authors. --- Regards, Thierry | www.TJKDesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Using JS to expand Abbreviations
[EMAIL PROTECTED] wrote: This is not about styling. Without the measures being discussed, the consensus is that it is all styling. How the abbreviation element is styled will, short of javascript, dictate how the abbreviation's full form will be made available. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Using JS to expand Abbreviations
[EMAIL PROTECTED] wrote: I think it is a little early to be claiming consensus on this! Correct me if I am wrong, but without this fix, most users will never see the full form of the abbreviation. That seems like a little more than just styling to me. Mike I think this is a misunderstanding. I'm saying that, prior to this whole conversation, the use of abbreviations relies on styling to govern how the full form is displayed. What Thierry is suggesting is use of the abbreviation element by script to modify the content - but without this (say, upon the javascript degrading - and by degrading gracefully, we mean being removed without crippling the site) you have to rely on styling to get your abbreviations effective. Generally, people give abbreviations a dotted bottom border and make the full form available as a tool-tip upon mouse-over. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG CMS] Re: digest for c...@webstandardsgroup.org
Kupu under Plone does a great job where I'm from. http://kupu.oscom.org/ Regards, Barney cms@webstandardsgroup.org wrote: From: "Peter Firminger" <[EMAIL PROTECTED]> Date: Thu, 9 Nov 2006 20:35:56 +1100 Subject: AJAX Editor anyone? Hi CMSers, Does anyone know of an inline HTML editor that can be spawned similar to a Flickr deacription field (click the content or an icon to edit) for editing various discreet sections of content within a page? I can do it with text inputs and textareas but can't seem to fine one with an HTML editor. This needs to work cross platform/browser if possible. P ** Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ** *From*: "Peter Firminger" <[EMAIL PROTECTED]> *Date*: Thu, 9 Nov 2006 20:35:56 +1100 *Subject*: AJAX Editor anyone? Hi CMSers, Does anyone know of an inline HTML editor that can be spawned similar to a Flickr deacription field (click the content or an icon to edit) for editing various discreet sections of content within a page? I can do it with text inputs and textareas but can't seem to fine one with an HTML editor. This needs to work cross platform/browser if possible. P ** Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ** ** Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] **
Re: [WSG] Coding Tables
James O'Neill wrote: Here is a link to the chapter in Joe Clark's book online book that deals with accessible tables: http://joeclark.org/book/sashay/serialization/Chapter10.html Hopefully, that will help a little bit. =) "Tables prompt eye-gouging hissyfits among accessibility advocates and Web designers of all stripes, whether oldschool or avant-garde. Both sides are saddled with myths and both argue in large part from ideology. Let’s do a reality check, shall we?" Brilliant! A more concise summary has ne'er seen the light of day! Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Coding Tables
Patrick Lauke wrote: I don't think that there's any argument about whether or not tabular data should be marked up as a table or not, and the hissyfits I'd say referred to the "don't use tables for layout" debate, which nowadays seems a bit passe... P That's not a question, so I'm not going to answer it. Hehehe. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] We do not support the Safari browser yet
Matthew Pennell wrote: I believe Safari has some issues with certain Javascript/Ajax implementations, maybe? Or maybe they only had earlier versions to test on and couldn't get the site to work in 1.2... Safari's javascript support is very patchy, to the extent where you can no longer rely on functionality degrading gracefully if you have heavy functional implementation of js. I also get the impression that there is a bit of an unspoken culture of "I built this up nice and clean to work in Firefox, and then I worked my fingers to the bone getting it to work in IE because it's the majorities' browser... Safari can fuck off". Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] We do not support the Safari browser yet
Will Jensen Personal Public wrote: I caution all designers to never do anything on company or personal sites that may alienate a group of customers who frequently have little say in what browser is on their company-owned computer or who have limited knowledge of how to upgrade their current browser or to install a different one. I bite my tongue beyond this point In terms of commercial website design it is utterly unforgivable - even the tone of the message is arrogant. However there's something perversely refreshing from the view-point of someone who continually tells friends and family to use Firefox only to have the 'if it ain't broke' line pulled on me. The only reason it ain't broke is because people like us spend hour upon hour fixing it - and to a certain extent, unless we let things break occasionally, nobody else will fix them! Childish logic, but I do contemplate it a lot. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] CSS resources for Graphic designers?
Nick Fitzsimons wrote: On 14 Nov 2006, at 07:13:48, Paul Novitski wrote: I'm leaning toward the opinion that Photoshop is not a good tool in web design ... Fonts are anti-aliased At one design studio where I worked I went round to all the designers showing them how to turn off Photoshop's font anti-aliasing. They complained that it didn't look as good; I pointed out that that's what it would look like in the browser (at least on Windows without ClearType, which is still pretty much the default), so if they expected me to implement their designs, the original designs had to look as bad as they would in a browser. Do most people have ClearType turned off, though? My team has two designers - my colleague uses Illustrator simply because it's extremely convenient in its system of layers and general object-based attitude. I use PhotoShop for the simple reason that it is pixel-based and as such everything _except_ text can be made to appear identical to my sketches. With vector programs you're dealing with a conceptual world that will have to be completely re-defined for the purposes of appearance. I would say that unless you're using it as a photo editor, PhotoShop is expressly for non-print design. The text problem is immense for any question of typography - you can have your beautiful type design on any application fall apart completely because the colour (typographic sense) ends up lighter - at which point you have to compensate by modifying line-feed, size and colour and generally all your reference from the design suite end up useless. I am infuriated that there is this stupid distinction of none; crisp; smooth and strong. There is a huge gap between 'none' and 'crisp' (crisp generally being very heavily anti-aliased) - why can't we have a slider? _And_ turning anti-aliasing off still leaves PhotoShop with its relatively intelligent kerning systems. To be honest, IE (or even bloody Word until the latest edition) without clear-type is absolutely unbearable with smaller font sizes. If you live and design for that world, expect spaces in the middle of words, characters with no division between them, and all manner of horrors. You may as well ignore typographical issues. How ironic that Arial, supposedly designed for reading off screens, renders worst of all. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Safari DOM inspector
Hi all, Very occasionally I get bizarre inconsistencies with Safari display compared to other browsers. Back in the day I'd sit back, take a look at the code, go through archived bug reports and allocate the problem via deduction. Sadly these days I have my developer toolbars and DOM inspectors, and I'm too lazy and out of practice to do that. Today I found this fantastic utility [http://webkit.org/]. WebKit is a terribly vague name, but I suppose 'the WebKit nightly build' about sums it up. I fired it up and went to look at my bug in question and got so distracted by its fantastic inspection frames (metrics! woo!) that it took me a while to notice that the bug in question had disappeared. Can anybody suggest a useful alternative? Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari DOM inspector
[EMAIL PROTECTED] wrote: Barney, I am confused by this - did you download WebKit, or some other utility? If it was just WebKit, then at least you know that the bug will be gone from a future version of Safari ! Mike Yes, I did... And that is kind of a guilty, comforting thought; hopefully by the time the project goes live, everybody using Safari will have updated to a version that doesn't suffer the same problem! However I'm not sure that's how it works... All Apple-made Mac OS html readers use WebKit, and WebKit is open source - are the two instances of WebKit in that sentence referring to exactly the same thing? For one, webkit.org doesn't mention the word 'Apple', nor does it have much in the way of documentation re:release dates. So I'm a little confused. If this is the bona fide, official, endorsed shape of things to come, we're all very lucky people! In the meantime, Safari appears to be completely vanilla, in that it has no extensions, and is utterly opaque. Are these assumptions correct? Or is there some way I can find out what the current release of Safari is reading, other than staring at the source code and the final render? I do know that generally it treats the styling of forms with disdain (plus I'm using javascript on them for display purposes, oo-er). Is there any other significant 'bug' I should know about? Can't divulge urls sadly, but it's a question (as far as I can see) of measurements mis-calculations inside a form element. I know that's vague as anything... ??? Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari DOM inspector
Philippe Wittenbergh wrote: WebKit is the rendering engine behind Safari. What you have downloaded is a nightly build of what will be Safari 3.0 in Spring 2007. And yes, Safari 3.0 will have a WebInspector, just as OmniWeb 5.5 already has one - not a surpirse, as it uses the same WebKit rendering engine. And it is very possible that a bug you see in Safari 1.3/2.0 doesn't exist anymore in those nightly WebKit builds. One would hope that some bugs get fixed, after all... Indeed! I'll reserve my bitterness over inconvenient progressions for IE7. Hehehe. Thanks for the info - I downloaded the OmniWeb 5.5.1 trial (gorgeous tabs system, incidentally); and it renders the page in question, with bug, exactly like the current release of Safari. Excellent (for my purposes). However I see no sign of a WebInspector... It's not immediately apparent from OmniWeb's interface, Omni don't seem to think it's worth mentioning in their list of fancy features, and a site search for 'inspector' only finds instances of it in their other products (all irrelevant in this case). Is it a third party plugin? Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari DOM inspector
Philippe Wittenbergh wrote: Close Omniweb and type the following (exactly !) in a new terminal window: defaults write com.omnigroup.OmniWeb5 WebKitDeveloperExtras -bool true (one line, watch out for wrapping). And you'll see that it is still missing some panes. Fantastic! This is exactly what I need. Thank you very much. (to keep it ore on topic, aka debugging tools) One feature is sorely missing in WebKits inspector: the ability to live edit properties and values for an element. I use that the whole time with Gecko's DomInspector. IE's toolbar also has this option. It is a very useful (if a little unreliable) feature of Gecko's... I still prefer the dev toolbar live css modifier for the purposes of trial. IE's toolbar infuriates me a bit, but it does at least give some indication of what IE thinks is going on. As far as I can work out, the only dynamic ability is the creation or removal of id or class attributes, which I really can't conceive of as being useful in any but the most specific situations. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
WebKit: '-khtml' ?!! (Was: Re: [WSG] Safari DOM inspector)
OmniWeb's inspection kit isn't fully functional yet - the search tool (great idea) doesn't work yet, and the same goes for the metrics and properties tabs. However the style viewer is incredibly useful. It specifies that it is a 'computed style' viewer - an interesting distinction. Gecko happens to be so compliant that such a thing is incredibly rarely useful, and as such its own inspector is great in that it only displays 'read' code. IE has a bastardisation of the two: its inspector reflects the fact that in many cases it digests code and then converts it into 'behaviours', and you often end up with expressions similar in syntax to the notorious hasLayout property. As far as I can see though, WebKit displays what appears to be _every possible relevant property_ along with their values... Very useful for the purposes of allocating bugs. I notice what appears to be WebKit-specific code... Things like -khtml-text-decorations-in-effect ...Which I have seen in effect - proprietary and usually only used in Apple sites since it is naturally not w3 css. There are also more intriguing rules like -khtml-line-break Oddly enough, a right click allows WebKit to search for the clicked term as a Google string - useful enough as Google finds _nothing_. I would love to play around with these, but apparently they are completely undocumented in the public arena (aka the internet)! Regarding my original bug which prompted all this, it reads (by the inspector) as if it shouldn't be (unless, of course, the -khtml comments mean something significant). I may, heaven forbid, resort to hacking Safari to give it uglier specification for the element in question. I seem to remember there is a weird selection method involving seemingly banal child-of-parent-of-child-of etc. specification. Regards, Barney @Mike re:Apple: You're right. It is still a little obscure, isn't it? *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Sliding Door Tabs
Tom Livingston wrote: Hello list, I am about to embark on my first Sliding Doors tab adventure. Just wondering if Doug Bowman¹s ALA articles from 2003 are the best resource for this. Are there newer updated resources? I'd say Doug's article is absolutely fine for what it does. It's entirely possible to get completely bogged down with the notion of sliding corners for more complex specs, but for anchor tabs, I know no better. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] FF understands body:last-child
Anybody know about this?
body:last-child ... {}
I saw this a while back and chuckled, but today I found cause to use it.
It's supposedly a hack for WebKit browsers (I don't understand how there
could be any ambiguity over what the last child of the body could be,
but there you go). I've seen examples of such rules only being picked up
by my Safari, with everything else I've got ignoring it - however when I
applied it myself it was picked up by Safari and my Firefox.
Any idea why this is?
Regards,
Barney
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Safari DOM inspector
[EMAIL PROTECTED] wrote: On the other hand, one of the major plusses for Camino is that it is more tightly integrated with the OS than FireFox is, so it also uses the OSX form elements au-naturale. (And pays attention to the proxy settings in the OS, which is rather handy on my laptop.) I think what you really meant to say is that it treats the abuse of its own chrome with disdain... many of us still believe that styling of Chrome is a Bad Thing(tm) I think form elements suffered a similar kind of fate as tables (ie branded css-incompatible). The monstrous symptoms of this that I bump into daily are a) form elements styled by html in otherwise valid sites b) forms designed for Safari users that fall apart visually when viewed otherwise c) unbearable amounts of chrome and glowing blue when navigating with Safari. It's not an inevitability, but I'm sure there's a stigma out there in the minds of designers who think that forms mean either give up all hope of a controlled design or make improper use of html. The project I am working on is highly stylised with plenty of circles and rounded edges everywhere - during the design process my co-designer sketched up visions for various templates, and got screen caps off her mac to simulate form elements - this actually chimed very well with our design, and would have been very close to how she would have seen the site on her setup with the forms left vanilla. On PC however, the visuals were horrible. Eventually, Peter Ned saved my life by developing a script that replaced buttons with anchors that retained all the key functionality: http://www.xs4all.nl/~peterned/blog/accessibleform.html For some people this presents a semantic obstacle... But I wouldn't have my site without this. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Standard available fonts
Ben Buchanan wrote: Here's another survey that might help: http://www.visibone.com/font/FontResults.html Cheers! That is a very cool resource. It helps to keep track of such surveys and tests, just to be aware of the ever-influential grey area between the absolute minimum (that we have to design for) and the absolutely ideal (which we'd want to design for). Sadly, Minion turns out to be an Adobe-supplied font. Tsk! I'm getting just about sick of Georgia. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] inside - bad practice?
I have a particular design where I want to put a inside an h3 element - now I know that in theory brs are redundant when using paragraph (or is it phrase?) elements, because they happen between one and the next. Is it inherently wrong to do this though? I can't help feeling like I'm doing something very sneaky. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessibility of forms, do you always need a label with drop downs?
Whether or not I want it to look that way (in many cases it's visually obvious what a set of form elements are for), I always try and put labels before inputs in the markup, and then use relative positioning (for example to put 'username' and 'password' below their respective inputs in the display, or as everyone else is always keen to do, shove them off page). Steve, do you know what JAWS' attitudes to display:none; and visibility:hidden; are? Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessibility of forms, do you always need a label with drop downs?
Mel wrote: http://www.access-matters.com/screen-reader-test-results/ Mel, I've been looking for this site for the better part of my life. Now I can get back to designing websites (or just cursing IE6)! That's a great set of results - but I still wonder about things I'd consider far more obvious than the second half of methods, like visibility:hidden; and font-size:0;... Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Fieldset but no legend
Gaspar wrote: How can i group just one single input? i think there's no reason to do that, sow i removed the fieldset and just use the label for the input. am i right or not? For my own tuppence, I'd say there's no reason for it. I'm almost certain I've seen pages adorned with every kind of WAI-related medal on the side include single forms without fieldsets. If it were up to me, we'd have a 'caption' or 'legend' attribute for form elements, but in this case there is no room for ambiguity or confusion if your single input has a corresponding label. From a humanist stand-point, I find it extremely hard to conceive of any sentient being that might navigate your site and be distressed in any way by your lack of a fieldset - in fact it's easier to imagine people getting infuriated at having to wade through containing elements. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] The Decline of Print Styles
CK wrote: Hi, After browsing some favored CSS sites, some by Standards Evangelist, there seems to be a decline in the use of print styles. Has some movement escaped my research? Decline? There are only two truly decent print styles I've ever seen, ala and bbc news. Every wonderful article I've ever read about print styles is all but illegible in physical form. It's a shame because if I know I'm going to be reading for over 3 minutes I far prefer to have physical copy. I would love to hear of other well-printed sites though. I strongly believe in css for print but have seen far too few good examples of it. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] The Decline of Print Styles
Raphael Martins wrote: > Look at http://www.tsa.ind.br > they have print styles, and also a php print preview, using the print CSS. The preview looks decent but the php causes my browser to tell me that 'the page was replaced while you were trying to print it'... Google uses a similar process to decent effect - the same policy of just printing the main frame content with the logo and title pasted in at the top. I suspect the best way to create serious (from a design-for-print standpoint) web-to-print systems is to install a php-based pdf generator, because at the end of the day no matter how sophisticated web technologies get, printing from within the browser is always going to leave a world's worth of factors out of your control. I believe Adobe have a very nice system based on this principle. Had a fun experience recently when developing my own print stylesheet whereby my overflow:hidden properties caused the print to be limited to one page no matter what. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] The Decline of Print Styles
The preview looks decent but the php causes my browser to tell me that 'the page was replaced while you were trying to print it'... Google uses a similar process to decent effect - the same policy of just printing the main frame content with the logo and title pasted in at the top. I suspect the best way to create serious (from a design-for-print standpoint) web-to-print systems is to install a php-based pdf generator, because at the end of the day no matter how sophisticated web technologies get, printing from within the browser is always going to leave a world's worth of factors out of your control. I believe Adobe have a very nice system based on this principle. Had a fun experience recently when developing my own print stylesheet whereby my overflow:hidden properties caused the print to be limited to one page no matter what. Regards, Barney Raphael Martins wrote: Look at http://www.tsa.ind.br they have print styles, and also a php print preview, using the print CSS. Barney Carroll escreveu: CK wrote: Hi, After browsing some favored CSS sites, some by Standards Evangelist, there seems to be a decline in the use of print styles. Has some movement escaped my research? Decline? There are only two truly decent print styles I've ever seen, ala and bbc news. Every wonderful article I've ever read about print styles is all but illegible in physical form. It's a shame because if I know I'm going to be reading for over 3 minutes I far prefer to have physical copy. I would love to hear of other well-printed sites though. I strongly believe in css for print but have seen far too few good examples of it. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *********** -- Barney Carroll Text Matters Information design: we help explain things using language | design | systems | process improvement ___ phone +44 (0)118 918 2382 email [EMAIL PROTECTED] web http://www.textmatters.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Semantics of news
I think that in the original case, the date can't really be perceived as a header item. And moreover, although I'm embroiled in a similar thread on another list arguing against tradition, I feel that having an h[n] immediately following an h[n-1] is very strange. However there are a few things I'd like to say about header semantics generally. - Love of the DOM will not teach you good English. HTML is as full of (often ambiguous) tags as it is to accommodate writers, not vice-versa. - Headers do not grow on trees. ie The logic of having: h1 h2 h3 h3 h2 h1 h2 h2 ...is flawed. Headers do not contain anything other than themselves. - There are plenty of real-world examples of documents where the header is not the first object on the page - in the case of the news article mentioned; letters where an address contextualizes the document before its subject becomes apparent... - There is a reason and are distinct. One might think this is simply because the same object cannot simultaneously be in the head and body of a document, but that's not necessarily true. A may contain what the body would display as a combination of h# tags, for instance Organization - Your profile = Organization Members area ... Your profile Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Skip Navigation question
John S. Britsios wrote: Dear members, I would like to ask your opinion about the use of the "Skip to Main Content" and "Skip to Sub Navigation" links. We recently designed our second web site http://www.seoworkers.com and as we did not want to have the links visible, we have hidden them with CSS techniques. My question though is, where would be better to have those links. Before, or after the logo of the page? Thank your very much in advance for your kind support. Best wishes, John The first time I was really struck by this device was when I saw the new WaSP website [http://webstandards.org/]. I think that method is very good - you get to the page and immediately you get the opportunity to head to what you want from it. The only thing about your site is that your header contains an important heading, which you may or may not deem crucial to their reading. If you're thinking about this in the first place you may want to consider the increasingly popular philosophy that navigation is 9 times out of 10 the last thing someone wants to see first on any page (you just used it to get here, it's only if you've made a mistake that you're going to want to navigate away again immediately). If you subscribe to this usability belief, you may consider sequencing your page and including a 'Skip to navigation' at the end of the header. Using a bit of clever CSS, this needn't affect the visual layout of the page. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Skip Navigation question
Thierry Koblentz wrote: This might be confusing for sighted keyboard users as tabbing navigation would work differently than what they would expect; this would be different if the menu was some vertical navigation bar (right hand side next to content) rather than an horizontal one showing above the content. True - however I've become a big fan of tab-browsing recently (my home PC's mouse broke a week ago and I haven't seen fit to get a new one yet), and it is generally quite a jumpy affair - you're never exactly sure where you're going to jump to visually, and it's often not immediately visible with objects that don't highlight once activated. As it stands, John's site already employs a nav that is above but below the header (as does the WaSP example I mentioned). Admittedly if you're entirely reliant on visual presentation and tab-browsing (what kind of a demographic is this, I wonder?), I can imagine some users might get infuriated at going through the header and starting to plow around the content and extras without being able to access that nav that's apparently 'right there'. I would start back-tabbing at this point, but I don't know if that'd occur to most. Also, I think (I may be wrong though) the WCAG 2 (FWIW) recommends to "display" the elements in the same sequence as they show in the markup. Would be interested to see if this is the case. Quickly skimmed the guidelines but couldn't find anything. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] ie-only hack
Cool hack, Rafael I love the way people live in constant fear of Microsoft fixing bugs. And when their developers eventually do sit down to tackle IE's problems and release an update, they're not going to tackle any of the crippling rendering problems and will instead devote their time to removing all the life-saving compiling methods. Based on personal experience, I find no real cause for worry. An ".ie-only" selector is a fantastic little creature that I hadn't seen before. It has the advantage of being semantic - people will look at your code and know what's going on. My alternative is ending your selector with a comma "," which causes everything apart from IE to ignore the rule. I'd say that in this case IE performs logically, but (especially if you don't know about it) it's easily missed and can easily confuse my target audience (other designers reading through my CSS code). But whereas the star hack "* html" relies on a bug which remains (it is often used to compensate for behaviour that IE7 has mostly fixed, so I hardly think the sites that rely on it are turning in their graves), I think the two hacks above are not exploiting bugs (I can't imagine .ie-only being a mistake, somehow). Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Semantics of P element (?)
I somehow got the impression p stood for phrase... (?!) Mariusz Nowak wrote: Anyway I wonder how it really should be treated.. (I'm not 100% positive that my approach is right) or maybe both way are semantically valid to treat p as I do and more strictly as you do.. However due to lack of clear statement on it in w3c specs I doubt that there is a clear answer for that. Regards, Barney Carroll *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] ie-only hack
Geoff Pack wrote: Gunlaug Sørtun wrote: So, old hacks like the 'star html' hack for IE6 (and older versions) is now "perfectly valid" IMO, while hacks relying on bugs that have survived into IE7, are extremely unsafe. 'extremely unsafe'? I'd say they are safe until Microsoft releases another IE version. With their track record, that could be *years*. Given the choice between littering my html (thousands of pages) with conditional comments, or adding couple of hacks to a single CSS file, I'll take the hacks, thank you very much. Despite all the doomsayers, I had zero problems with pages breaking when IE7 came out. cheers Geoff. I agree with this. If we're going for zen purity, I agree that theoretically hacks could be a liability. But seriously, how many years have you been telling yourself the star hack is unsafe? What did that lack of safety ever mean? Lack of support for multiple classes can hardly be called a 'bug' at this point. It's more like a 'feature'. It's slightly arrogant to believe that you can exploit a program's invisible weaknesses to cover its visible others; but it's more naive to believe that Microsoft would tackle hacks like this. Seriously - if you're going to ascribe IE's dev team the virtue of wanting to tackle IE's problems, you'd think their priority list would start with rendering flaws and end with "let's see how css coders are fixing our browser and screw it up for them". Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Re: digest for w...@webstandardsgroup.org
Kay Smoljak wrote:
At least you will know where to look, instead of trying to work out
which combination of backslashes and asterisks fixed the particular
issue for which version.
One would hope that this information would already be somewhere in your
head when you implemented the hack.
If the real issue is that hackers are fundamentally stupid, that's a
problem separate from the inherent pitfalls of different techniques.
Conditional comments do have that feature of giving you a template of
sorts, a structure to your additional rules. And without that guidance
(plus general criticism), hackers are more likely to end up on their
own, working without the benefit of convention, and quite possibly
writing a big confusing jumble.
One method is to write all your IE hacks at the bottom of the relevant
stylesheet. You can have
/* The civilised world */
...
...
/* IE 7 compensations */
...
/* IE 6 compensations */
...
...which would make things easier to allocate in a similar way to
arranging things in separate css files. However this
compartmentalisation is one of the reasons I dislike conditional
comments - with pages that rely on heavily different techniques you end
up having to sift through so much css, computing it or looking at it
through different windows, that it's just not worth it. I recommend
grouping them together, so that you can look up your selector and see
*everything* that can possibly be computed for objects answering those
description. So if my object requires different rules for different
browsers, I will put them there and then, one after the other:
object{}
object,{}
* html object{}
Of course, when I put it this way, I realise that Rafael's hack has the
problem of being limited to objects which already have a class -
selectors such as the following can't be converted:
*,{} div,{} #id,{}
Clever but inflexible.
Regards,
Barney
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] ie-only hack
Paul Novitski wrote: But seriously, how many years have you been telling yourself the star hack is unsafe? What did that lack of safety ever mean? Same as it means now -- the likelihood that someday your code will fail because it depends on the coincidence of two unrelated bugs in an evolving software product. I believe that even the most clueless of futurologists can believe that IE6 isn't going to get any radical updates in our lifetimes :) Lack of support for multiple classes can hardly be called a 'bug' at this point. It's more like a 'feature'. Only if you accept Microsoft's bugs as standards in preference to the W3C spec. It's not just a question of what we and the w3 believe. The only reason we tackle these things in the first place is because Microsoft is incredibly influential. We have to consider the fact that to this day (and the concept has been floating a pretty long time) they still don't want to implement multiple class selectors. When I say this, I'm not suggesting that multiple class rules are a bad thing at all. I'm asserting what I believe to be a fairly certain judgment that Microsoft don't like the notion. If they do, they've had plenty of time to implement it and haven't. It's an incredibly basic translation process, after all. I would like to see IE support multiple classes, but if it resolutely doesn't, we can use this feature inventively. Given their recent work on IE7, I don't think it's too naive to ascribe to them a desire to fix their software to match the spec: I am by no means suggesting that IE7 is less advanced than IE6, but it is still plenty buggy in both familiar and fresh ways. A significant update such as this creates all sorts of new problems and new ways to solve them. We have to evolve with them. All of us. Hackers have developed sites which fail to some degree under IE7, and they have had to investigate, look over their code, test and amend. The same has happened to everyone else. There seems to be this notion that hackers run the risk of having to do some extra work when a new browser comes out. Who doesn't? Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] ie-only hack
Gunlaug Sørtun wrote: To me a 'conditional comment' is a "constructed hack", and I see no reason to litter anything with it, unless there's no other option. However, those 'conditional comments' won't target any other versions than they are set up, so they are pretty safe in themselves. A point worth making. A valid html page with conditional comments linking to valid css would not load that css in a valid environment. Imagine an IE only stylesheet that is called, in one instance, by a conditional comment and in the second, by a regular comment - but in this instance every selector ends in a comma. 1.In terms of valid computing, the first one contains content in the comments. The second contains extra content, but the css called by this content 'doesn't have selectors'. 2.In terms of human readability, you can pretty much work out what those 'comments' are doing. In the second instance, a semantic filename might make it equally clear what's going on in the special stylesheet - when you look at it you may or may not get thrown by the commas but hopefully their significance is pretty clear. 3.In practice, IE has no problem with either method. They make as much of a difference due to key differences in what IE can conceivably understand. Validity-respecting browsers will give errors for every rule of the second method, but at least they can see everything. The only reason the first method passes is because utterly invalid functions are being hidden from it. Validity is abused on both counts as far as I see it. The psychology of the first count is that you're saying validators can't accept browser differences, so you're duping them into thinking there are none and hiding crucial content from the validation process. My psychology is that what could be debated as ambiguous or just plain wrong in the status quo of valid css coding does in fact get digested in IE. Both of these methods rely on abusing bugs in the validation process. I believe both would be fixed in an ideal world - but actually none of us have suggested this because we need these methods. The notion that IE should coherently evolve in the scope of standards at a faster rate than the development of standards is one that has never stood the test of time, but one espousers of the first philosophy take for support when suggesting their methods are safer. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Minlo Technologies | Sri Lanka
Chamara Peiris wrote: Hi guys, All ur comments about website are welcome. http://www.minlotec.com Cheers, Chamara Very nice. I think spacing is a big issue - if elements could have larger vertical margins the whole thing could breathe a lot easier: this is especially true of the headings, which stick to the rest as if they were ps; and the footer, which really clings to the last piece of content. That's a subjective design judgment tough. It's fair to say there's a strong tradition of these corporate identity websites whose priority is to avoid scroll bars and have a header the size of the content. I don't quite understand that aesthetic, so my opinion isn't the most objective. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Tissue (valid code) vs shirt sleeves (wysiwyg editors and those who use them and also refuse to use tissues)
The search engine thing is pretty much a lie. People are begging Google to factor w3c validity into the relevance of their results, but there's no good reason they should - and I personally believe this is a bit sinister. Invalid code should succeed or fail on its own merits, not because standardistas bully 'validity' into practice. I hold Google in very high esteem for their complete magnanimity over standards while maintaining (some might say as a result) the highest elegance and popularity. If human beings or machines start complaining that this irreverence is in any practical way detrimental to their experience, then standardistas should flock to the rescue. Until then, the notion cannot help but smell mafiosi - protection racket kind of stuff (- You need this 'help' I'm giving you. I know it seems inconvenient and expensive but you really do. - This really doesn't look like help to me. - I don't remember asking you a goddamn thing). ... I sympathise with the client: if I can't justify how it's useful to them, then there's no reason they should be bothered with it. If I can't justify it to myself, there's no reason I should bother myself with it. This is the ultimate opportunity to question yourself and work out whether you adhere to standards because of their actual virtue or simply because you like rules, big crowds, and being better than other people. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Tissue (valid code) vs shirt sleeves (wysiwyg editors and those who use them and also refuse to use tissues)
Andrew Maben wrote: Wow, that's kinda harsh - and at Christmas!! Sorry Andrew, I always come out wrong with these things. It's a warning as opposed to a criticism. I'm only on this list because I think standardisation is an integrally good idea, especially when it serves purposes. > (Who could he mean??) When I mention 'standardistas', it tends to draw up tribal defensive feelings. By no means am I criticising standardistas in general. I just think that the banner of standards is often used to patronise people without due cause. When you belittle your client and ignore their concerns without being able to justify your own enthusiasm for standards, you need to take a step back and ask yourself why you're doing it. Standardistas are a majority. Their guiding hand can be extremely useful to the uninitiated, but they must guide with reason. I'm concerned that inventive, creative coding and design is often dropped simply because of standard practice. This is tragic. Guidelines must evolve. If we all just follow them without knowing why, that can't happen. If you have good reason (and good reason abounds), you are utterly successful in my eyes. I think you've got it backwards. Those of us who aspire to live in a standards-based www are not fascists trying to impose some arbitrary and unreasonable set of conditions. We just want our stuff to "just work". Our fight is not with users or clients, or even our competitors, but with monopolist organizations who use their flouting of standards as a weapon against their competitors. Monopolies and fascists are different, and both are threats. Monopolies have corporate interests at heart and will not serve the public if there is no louder voice - hence W3C. There is the further threat of general disorganisation and confusion within the trade - and the Standards Project seeks to remedy this as much as it does the discompassionate hand of developers with market share in mind. I argue with neither of these in principal. To the contrary, I uphold them. But as much as it is crucial to do a lot of the research, thinking, development and guidance for mere individuals who cannot by themselves see the greater picture, I am greatly discomforted by cases where people come into situations where their abidance of standards is seen as faintly ridiculous, and they cannot rationalise it themselves. Andrew Ingram wrote: > The justification for charging more is > experience and expertise. Exactly. I believe that experience and expertise as regards standards is indispensable. A complete lack of experience or expertise but huge doses of enthusiasm regarding standards is worth nothing - and it is dodgy territory when you believe that, even though you could never argue this rationally, it is in fact worth just as much. ... Rather than playing devil's advocate all my life (nobody's too keen to divulge answers, only further questions!), I think I might come clean and tell you all why I respect validation: It's a universally approved and agreed way of reducing code ambiguity to the bare minimum. Massive fundamental differences in the various ways documents can be mis-interpreted are ruled out with validation. As far as markup is concerned, I am actually entirely supportive of 'validity' as it stands. Not blindly enthusiastic about, but understanding and respectful of it when it tells me my code needs extra / more concise information. As far as CSS is concerned, I cannot respect it fully because as it stands, complex CSS designs that are utterly valid will fail in their intended goal - near-enough identical computing on all major systems. The only reason this is the case is because developers haven't held their side of the bargain - and validity is not useful in and of itself, only if it represents a working method - which in this case it doesn't. I bypass validity here and achieve the desired end I believe is more important: identical content for all users. Regards, Barney P.S.: I just want to make it clear that I'm not challenging anyone here. Sharron's analogy is a brilliant one but it can work both ways - a web designer with superior ideas they can't communicate to you, and their ideology on the cuff of their spotless shirt, isn't somebody clients will sympathise with. You need to show them why. When standards alienate the people the website is for, something has gone disastrously wrong. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Tissue (valid code) vs shirt sleeves (wysiwyg editors and those who use them and also refuse to use tissues)
[EMAIL PROTECTED] wrote: The point is there are validation tools, information and help available for free everywhere. It doesn't mean one has to spend money to validate their pages. If one takes the time to build a site for themselves using whatever method, well then why not take a bit more time and use valid code? I am certainly not suggesting you turn away from validation on principle (I think I gave that impression). The thing is, your rhetorical 'why not' will sound weaker than the client's 'why'. Is that what you're going to tell them, or is that the kind of statement you could only let go unquestioned in a community of web developers? I'm not your client, and you shouldn't feel the need to justify your practices to me. Them, however... As you put it, there is a notion of 'niceness' to validation. But as a paying civilian, it's unlikely your client will sympathise with this. Saying your reason for it is that they will get better search results is an abuse of their ignorance and possibly ours (I'm not quite sure how seriously that was taken). I think you should tell your client that validation will... 1. Make their site accessible cross-browser, cross-language, cross-medium. 2. Be future-proof and never need integral re-designs to work across these factors in the future. 3. Make the back end of the finished product manageable and understandable in case they should ever hire someone else to tweak, upgrade or re-design it in any way. The snot on the shirt is not visible to the client, only 'our friends on the internet' - who should not be your target audience; too many people design for designers, and they are not the ones who need it. Design for the client. Explain to the client how snot is unhygienic, how it will matte the shirt, how it will make it difficult to clean. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Image markup clarification
Paul Bennett wrote:
Personally, I've had good experience with the very simple:
Paul
I'm in two minds over this technique - on the one hand the image has
meaning, and therefore should be part of the markup; on the other hand
this might feel a bit bloated for some, since there are not two objects'
worth of meaning there - I use this:
HTML:
Page title
CSS:
h1
{
display: block;
width: 200px;
height: 100px;
background-image: url(pagetitle.gif)
font-size: 1px;
font-size: 0;
color: [background-colour];
}
This is slightly messy because many browsers (IE and WebKit for
starters) don't recognise "font-size:0" as valid, so I have to make what
might be considered an ugly compromise by giving that text the illusion
of invisibility with their minimum font-size and a specific color.
However I can see how this is too much of an unstable compromise for
most people. There is a halfway house I've seen done gracefully which
still has two elements but keeps plain old h1 text:
HTML:
Page title
CSS:
h1 div
{
width: 200px;
height: 100px;
background-image: url(pagetitle.gif)
}
At the end of the day it's a question of semantic aesthetics. I can
easily see many people far preferring Paul's unambiguous and predictably
rendered system, but I've also met a few people who for reasons as vague
as mine simply aren't happy enough to have an image contain that amount
of meaning.
Regards,
Barney
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] display:none; property and screenreaders
Mihael Zadravec wrote: So, the best thing to use if we want not to display something, but still want it to visible to the screenreader, would be use of negative margins? Those effect something? Mihael That seems to be the case. Generally when people want something to be invisible but present, they give it absolute or fixed positioning and take it miles off the screen. I find this very annoying - tools are made available to us to hide things from view, yet we have to make them visible and render them off-screen instead... It feels incredibly ugly and protracted. 'display', by my definition, should affect display; even less ambiguously, 'visibility' should affect visibility - exclusively. The fact that screen readers remove these things from rendering is not a good thing in my eyes (hahaha). A better term for their currently implemented behaviour would be 'render:none;' - although actually, if something is not wanted in the user-available content at all, we are no longer talking about style and should be talking about whether or not it is in the HTML markup. Depending on circumstance, PHP and javascript can remove content that may not be desirable. If we are to hide the HTML from visual, tactile and audio rendering, then surely it is only available through source navigation, in which case we already have the standard of comments. Surely completely depriving the user of markup isn't CSS' job in the first place? Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] display:none; property and screenreaders
David Dorward wrote: I'm yet to run into a situation where it would be useful to have content presented only to screen reader users. From an experienced HTML coder's perspective such a thing may seem illogical but there are plenty of instances where a graphic designer may wish to use information other than linear text to convey meaning - and if CSS truly did cater to our needs, there would be no reason to deny them such opportunities. Colour, icons, text already available to sighted users in the form of images (until full CSS3 support and the rest of the civilised world catching up to WebKit's text controls, this will always be a temptation for typographers)... Of course it is irrelevant to discuss pure visual art and post-modernist poetry in terms of standards, but even in terms of legitimate informative documents - take propaganda pamphlets for example. In many ways the world of print has much more control than that of the internet. In some ways this is inevitable, but in others it is inexcusable. In concept, print designers are much more restricted than web designers. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Image markup clarification
David Dorward wrote: * Users with images turned off see nothing This is a difficult one. I have a FF extension that disables flash by default (mostly to avoid downloading, seeing and hearing awful adverts), and in doing so I am resigned to occasionally seeing the site in ways the designer did not intend. I grumble at a lot of stuff, but when this deprives me of content and/or the rest of the site refers to things I don't understand, I blame only myself. People who disable images fit into the same box as those people who attach !important to their custom stylesheets... They are aware that they are depriving themselves of the designer's intention. This philosophy can't be taken too far, but within reason I believe that, quite literally, we cannot cater for people who deliberately chose to turn off content. For what it's worth, the instance I use this in has h1 as the site title and h2 as the section title - these things are already, to an extent, implicit, and hence not absolutely crucial to the viewer. Because I'm so used to developing sites with CMS, the page title and all crucial subordinate information cannot have this treatment. For example, I have objections to CSS zen garden in the way it has many sub-headings as images. * Most browsers have a Minimum Font Size these days That's what the colour and 'font-size:1px' properties are about. Granted, the text may still be visible. At least Firefox loves me back :). -- Barney Carroll Text Matters Information design: we help explain things using language | design | systems | process improvement ___ phone +44 (0)118 918 2382 email [EMAIL PROTECTED] web http://www.textmatters.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] display:none; property and screenreaders
David Dorward wrote: Hello the alt attribute. In terms of my job as a CSS designer, 90% of my workload is all the stuff you're ignoring. That's not to say you're fundamentally wrong or useless in terms of my world-view, but the world of the graphic designer (especially as a semantics-obsessed information designer) is solar systems bigger than what you're suggesting. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Image markup clarification
David Dorward wrote: HTML comes with built in methods of providing alternative content for pretty much everything that isn't text. There's no need to try to turn the concept upside down and have text replaced with other content using CSS - it doesn't work as well. If anything, I'm suggesting markup content that's 'stronger' than alt tags. Removing significant text content is not my game at all. > What does being a graphic designer have to do with not using the > mechanism built into HTML to provide graphical content with an > accessible, text-based fallback, but instead using CSS to create a > similar, but less accessible, effect? I think there's been a horrible misunderstanding somewhere. I don't think anybody in this conversation has made any false moves as regards accessibility. I am talking about visual content defined by CSS that isn't in the scope of s, yet may need alternative text content for those without visual reference... Which can be handled in a great many ways, and could be handled in many more (CSS is constantly evolving, I'm not suggesting anything's being coldly ignored by the powers that be). 'Images' is a very limited way to address many visual semantics a designer may wish to incorporate into a site, and occasionally those semantics may be arguably crucial rather than additional - in which case some clever use of markup/styling is needed. As much as this sounds like dodgy territory, I don't think the practical examples I suggested way back in the thread (unorthodox styling in headers) caused that much of a problem (apart from the invalid within ). If they did, please refer back to them (all observations are useful!) - but I fear we're getting rather vague and argumentative here. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] - how wrong?
Styled buttons are a bucketful of issues. Normally it's practice to
complain about the current release of WebKit, but I've just bumped into
the issue of :hover and all those other pseudo-classes IE believes
should be reserved for s exclusively.
My client complains that my heavily styled buttons do not obey the
modern convention of highlighting when mouseovered (which they do in FF,
but of course my hover properties are ignored by IE) - hence being
ambiguous in their interactivity. They're entirely right, but do I have
to strip my buttons of their styling to be able to achieve this?
Moreover, just how evil would it be for me to simply wrap the buttons in
s, and giving the CSS [a:hover input.button{cursor:pointer}]?
Regards,
Barney
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] - how wrong?
Thanks all for your insightful replies. Interesting case study. @Rob: Thanks for recommending Peter Nederlof's csshover.htc - my new year's resolution was to write a site without crediting him, and while I still have time, it won't happen this month! I'm going with this over javascript because as it's MS proprietary code, it's almost certain to be enabled for most users. @Kay: Some of my inputs were indeed submits, but type="button" doesn't help for this particular problem. @David: IE7 does indeed support :hover on all sorts of elements. I have a vague paranoid memory of certain circumstances breaking it, but that was back in beta era. The cursor:pointer is misleading in name - it generates a hand, not the standard cursor - and in IE6 buttons give the standard cursor on hover. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] - how wrong?
David Dorward wrote:
div:hover { cursor: pointer; }
means "When the mouse is over a div that the mouse is over, change the
cursor."
div { cursor: pointer; }
means "When the mouse is over a div, change the cursor."
The :hover in the first example is redundant and causes the selector
to fail in IE 6. The second example works fine.
You're utterly right. That's fascinating.
Update:
Couldn't get csshover.htc to work - dumped it in with my stylesheets and
called it via body{behavior:url(stylesheets/csshover.htc)} but it
wouldn't have any effect... May turn out to be a stupid oversight but in
the meantime, your suggestion [button{cursor:pointer}] works fine for
the cursor, and wrapping the inputs in and changing the
style to a:hover input{...} works great across the board, providing the
relevant s are styled with text-decoration:none;
...
Regards,
Barney
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Visited Links and Accessibility
Andrew Ingram wrote: I'm not entirely sure if this query falls under the scope of this group, apologies for that. One of the points in accessibility checks is that information conveyed using colour is also conveyed without. The most common way of doing visited links is to have them be a slightly different colour. It's my opinion that in a purely visual sense (because I don't know how screen readers announce visited links) this approach is inaccessible. The approach itself is inaccessible, but it's not as if you're hiding anything. What are your accessible methods of styling visited links? I'd imagine there'll be some votes for bold/normal, underline/normal. Is total inversion of background and foreground colour accessible? You can use fancy checkbox images (but obviously requires images which raises another issue) you can use :before or :after and content to add a unicode tick to any visited links (requires that your browser supports the pseudo-classes). Some people might not even bother styling visited links. There are two things I'd watch out for: Screen reader users aren't used to style information indicating visited links, so make sure it's clear that's what it's doing. I'd also advise against bold text or anything so widely-used and... Well, strong - because these things are steeped in semantic value, and giving visited links the impression of being utterly different things. I like the tick idea a lot. You should look at PPK's unusual but very clever system for attaching info to links [http://www.quirksmode.org/blog/index.html] - he does a similar thing, only without express use of :after. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Using "cursor:default;" on the whole page but links
On a personal note, universal custom cursors are my most hated thing in websites. They irritate me even more than pron pop-ups, and generally scream out 'features for the sake of features', rarely coming from any desire to make things easier or more elegant for the user. ...So if I'm your target audience, steer clear! Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Background images turned off? (was Visited Links and Accessibility)
Andrew Ingram wrote: Barney Carroll wrote: I like the tick idea a lot. You should look at PPK's unusual but very clever system for attaching info to links [http://www.quirksmode.org/blog/index.html] - he does a similar thing, only without express use of :after. Regards, Barney I like this approach too, but it doesn't work if background images are disabled. It seems to address the other issues though. - Andrew On the issue of background-images: I had never heard of people turning off background images before coming to the list. How is it done? Why is it done? How common is it? Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Background images turned off? (was Visited Links and Accessibility)
@Matthew: And the only 'tampering' Opera Mini does as far as styling is concerned is ignore background-image rules? Or does it not render images, full stop? Tyssen Design wrote: The launch of Apple's iPhone could also have a significant impact in this area too. On the iPhone's site, I thought the Safari demo [www.apple.com/iphone/internet] was the least impressive thing. The fact that it's the most sophisticated (read: complex) hand-held browser is not necessarily good - for example, the browsing of the nytimes and fandango as demonstrated looked completely ineffectual. Having said this, it should not be the browser manufacturer's job to customise their rendering process to magically make sites intuitively accessible on small devices - and if they do, it impinges on our ability to decide on what's best for the user. Incidentally, screen-size-sensitive stylesheets are an excellent notion [http://alistapart.com/articles/switchymclayout]. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Using "cursor:default;" on the whole page but links
James Crooke wrote: Here's one for you. OK, we are all in agreement that its not a good idea to change the default cursor. But even Krug's "Don't Make Me Think" has a pointer (the finger cursor) hovering over a button on the front cover of his book - yet in IE and Firefox buttons have the cursor. Personally I think that all buttons should have pointers, the same as hyperlinks. I always apply "cursor:pointer" to my buttons - partly because my boss tells me too, but I also agree with him (and Krug, it seems) that it helps usability. Who disagrees? I have resigned myself to this. I decided last night that I couldn't justify the amount of time I spent specifically on IE6 for each project - my design process involves designing the best-case site, building it, and then making it work in IE6+7, which involves a lot of work that I am now not so sure is valid use of time. What I'm getting at is that I'm ditching my .htc and .js ideas for hovering buttons and falling back on this [cursor:pointer] technique, which is actually more than enough to denote interactivity - and has indicated this since time immemorial. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Using "cursor:default;" on the whole page but links
Patrick H. Lauke wrote: James Crooke wrote: Personally I think that all buttons should have pointers, the same as hyperlinks. "Personally" being the key here, again. Overriding browser default behaviour and UI cues is not a sustainable model, just because *you* think you know better, in most cases. Who disagrees? Browser manufacturers, quite obviously. Woah! Was it somebody on this list who suggested that recommending Firefox on your personal homepage was akin to Nazism? All CSS is over-riding browser behaviour. Sometimes this runs contrary to what is best for the user, but that's entirely what a good designer's judgment is about - and what I thought this list was for. Making all text blue and underlined would be bad judgment in over-riding browser pre-sets. Making the mouse cursor turn into a pointer over buttons is very intuitive and I don't think it'll ruin anybody's browser experience. Too much trust in browser developers is never a good thing. At the very least they should be able to look to the design community for usability experience. If we're just nodding, everything spirals into inanity. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Using "cursor:default;" on the whole page but links
[EMAIL PROTECTED] wrote: To answer your query, I would suggest that buttons have a different action to hyperlinks (most of the time) so your argument that they should have the same curser does not seem valid to me. You can't deny their similarity though. Seriously - are there any elements more similar to either? A visual distinction is often needed between buttons and anchors (although based on context you could argue against), but as long as they're not identical, I can see why you'd want to emphasise their shared aspects with common semantic styling; hence the hand icon, which traditionally denotes objects you can click on. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Using "cursor:default;" on the whole page but links
Mihael Zadravec wrote: I think it's good to leave the cursor behavior as it is by browsers default, when using the visual style for button that is also browsers default ( if we are talking about input type="button" or "submit"), but if designer created his own style and it is not so clear that it is a "system button" then it would be good to change it's cursor properti to "pointer"... Mihael I agree completely. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Using "cursor:default;" on the whole page but links
Patrick Lauke wrote: James Crooke We have conducted usability testing on 100's of sites and my argument is that when you hover over a button and nothing happens, users sometimes think "oh the button is dead" A counter argument to that: So they'll get confused on every site that uses a button. You then change it just on one site, which only reinforces their confusion "oh, on this site it turns into a hand, so that means I can click it, but on these other sites it's dead". It's about consistency in browser behaviour/UI feedback (which, I'd argue, is different from making design choices for the visual presentation of information per se). This is an interesting philosophy. I personally believe that Microsoft and the awful IT education in this country (UK) have created a terrible culture of people who are so steeped in the logic of Microsoft's very worst user interfaces, that they perceive and value objects akin to these systems ahead of innately intuitive interaction processes. A massive amount of common culture must be used on any document for it to be legible, and in the domain of websites there is also a lot of convention to follow. However an integral part of my job is producing 'outside-of-the-box' solutions that don't depend on a user's knowledge of computer systems convention, and instead rely on innate human psychology. This sounds pretentious but good designers do this (or at least they try) all the time. Another aspect includes 'branding' sites. There are those weirdos who want their site to look exactly like a Windows desktop, but most people want a look and feel and way of doing things that is unique to them and their site, which can then be incorporated into their corporate identity. By the way, I'm not a corporate identity or particularly commercial designer, most of my projects are for government and non-profit organisations. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Using "cursor:default;" on the whole page but links
Nick Fitzsimons wrote: When using a site which turns the cursor to the link-style cursor when hovering over a button, I would tend to assume that it wasn't a button (which causes an action [2]) but a hyperlink (which merely causes navigation) styled to look like a button. Links and buttons aren't the same thing, in terms of the fundamental principles of UI design, which is why they give different feedback. I am not attempting to discredit these distinctions, which bear a lot of relevance; but I strongly doubt the notion that distinctions down to this level (some are indeed needed, and nobody here is suggesting that buttons be indistinguishable from links) are of vital importance to users. Conceive of a persona who is not a read-up fan of Apple's UI recommendations (my target audience, incidentally). Are they going to hover their cursor over a button, see it turn into a hand, and get baffled? I very much doubt it. In fact I think it would elucidate the functionality of the button. Action as opposed to navigation is an important difference, and I make it visible. The cursor, in my mind, has no bearing on this difference. I don't think I'm flippant in thinking that this is standardisation gone mad - it is at the point where designing no longer requires insight or creativity, and simply demands mechanical processing according to ancient presets without analysis. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Using "cursor:default;" on the whole page but links
Nick Fitzsimons wrote: When using a site which turns the cursor to the link-style cursor when hovering over a button, I would tend to assume that it wasn't a button (which causes an action [2]) but a hyperlink (which merely causes navigation) styled to look like a button. Links and buttons aren't the same thing, in terms of the fundamental principles of UI design, which is why they give different feedback. I am not attempting to discredit these distinctions, which bear a lot of relevance; but I strongly doubt the notion that distinctions down to this level (some are indeed needed, and nobody here is suggesting that buttons be indistinguishable from links) are of vital importance to users. Conceive of a persona who is not a read-up fan of Apple's UI recommendations (my target audience, incidentally). Are they going to hover their cursor over a button, see it turn into a hand, and get baffled? I very much doubt it. In fact I think it would elucidate the functionality of the button. Action as opposed to navigation is an important difference, and I make it visible. The cursor, in my mind, has no bearing on this difference. I don't think I'm flippant in thinking that this is standardisation gone mad. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Using "cursor:default;" on the whole page but links
James Crooke wrote: > P.S For those that are interested: http://www.kare.com - it's an > interesting site! Brilliant! I miss Windows 3 so much - it's all downhill from there! Interesting to see the person behind all this. Mihael Zadravec wrote: > I think that the best resolution was: If changed the default style of > the button, use "pointer", if not changed, and buttons style is > browsers default button style, than leave it as it is. A very sober conclusion, and the one I've gone with. Neither this nor its opposite are imperative standards in my eyes though. @Nick: I think it's fair to conclude that we simply disagree! I still maintain my belief that the cursor icon does not associate with the difference between link and button in the minds of most. It is also true that usability should not be taken lightly, and my decision to change the cursor over buttons is based entirely on usability considerations. "Users spend most of their time on other websites... This means that they form their expectations for your site based on what's commonly done on most other sites. If you deviate, your site will be harder to use." While this is a useful mantra to remember, if it is taken as gospel, it means that a site less confusing and more usable than existing sites is impossible. If I were more cynical, I might say this is blind and hopeless promotion of the status quo, whatever it may be, and shuns innovation. It's like saying you shouldn't vote for people who aren't already in power! Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Using "cursor:default;" on the whole page but links
Andrew Maben wrote: On Jan 11, 2007, at 6:47 AM, James Crooke wrote: We have conducted usability testing on 100's of sites and my argument is that when you hover over a button and nothing happens, users sometimes think "oh the button is dead" So it's not just my personal preference to have a cursor change to a finger-pointer on a button. "We" as designers know (presumably!) that a form button performs a different function from a hyperlink - submit/reset a form vs. direct browser to a new URL. To a user (who has no need to know, still less understand the technicalities of this difference) the result in each case is broadly the same: different content is presented in the browser window. As the pointer cursor means "click and something will happen", it makes sense to have the pointer appear in each case. (The use of form elements purely for navigation is another discussion...) Where the browser's defaults fall short, i think we have at least the right, if not a duty, to override them. In this instance I'd be astonished if any user whose browser default button cursor is an arrow would exclaim, if presented with the pointer instead, "ohmigod! what happened? where's my arrow?", whereas the complementary "huh? is this button 'dead'?" reaction is fairly predictable. Andrew This is exactly my stance. I believe this common sense (now that somebody's confirmed it's not the product of insanity!) has a duty to override proprietary guidelines. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Background images turned off? (was Visited Links and Accessibility)
Brothercake wrote: > I agree - and this is precisely what Opera Mobile does. It begins with > a handheld-media stylesheet and honours that if it's there. If not it > tries to honour the screen styles, applying increasingly aggresive > styles of its own as available space decreases and/or the layout > requires. What I'm not too keen on is the notion that we have this massive generalisation - 'mobile' (which I believe is what you guys are referring to by handheld), which can be used - and without that then it's safest to assume mobile devices aren't catered for in the css - so it should be ignored. Mobile browsing is very young and there are all sorts of devices about (the iPhone's Safari looks, render-wise, just like the current WebKit) - and significantly, different screen sizes. One size fits all seems a bit harsh to me. What would your mobile css change compared to the screen one? Would it, in effect, pre-empt some browser manufacturers' decision and just get rid of everything except fonts and text colours? This is what I believe the solution to be [http://www.sarmal.com/] - javascript tests for viewport dimensions and serves appropriate CSS. Try firing it up on a desktop and re-sizing your browser window. Thoughts? Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Re: usage of fieldset
Mihael Zadravec wrote: Hi! What would be your reaction, if you'd see someone using for something else than containing forms? eg. something like... Some tite here This is some content. cya! Mihael It's incorrect and pointless. Why would anyone want to do such a thing? Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Logo and H1's
I swear we just had this thread last week, but can't find it in the
back-catalog. Must be getting my lists confused.
Mihael, I share your view that is a bit ugly. I'm aware
from extensive debate that the following idea is pretty unpopular, but I
like to assign an id to my and style it to display the logo...
Corporation Ltd.
h1#logo
{
display: block;
width: #; height: #;
background-image: url(#);
background-repeat: no-repeat;
text-size: 1px;
text-decoration: none;
color: [background-colour];
text-size: 0;
}
First of all I make the text size minuscule and indistinguishable from
the rest of the page (for browsers that refuse to understand zero
font-size - like IE and current release Safari), and then supersede that
with font-size:0 so that clever browsers can make the text dissapear
completely. Afterwards you are left with nothing.
The arguments against this are first of all that the above technique for
hiding text isn't perfect in a lot of browsers, and that even if it does
work, any user agent that has disabled images will make the whole
illegible. Valid points, but I haven't bumped into them yet to the best
of my knowledge :P.
Another method is to include an empty non-image object into the h1 that
has all the non-text properties written above. I've seen this work, but
the problem is that it's strictly speaking invalid to A) put a 0
inside an or B) have an empty .
So don't say I didn't warn you of the cons, but those are two methods I
find pretty interesting!
Regards,
Barney
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Logo and H1's
Google: It is the oldest trick in the standardista's book, when lacking in citations, to say that the technique impinges on SEO. Shame on you! Hehe. Not seriously suggesting malice. I also believe Google puts my site ahead of everything else based on my excellent CSS management. Hehehe. Logo: I think the only reason this debate can carry on for so long without anybody bumping into hard regulatory standards is because the semantic definition of a logo is an ambiguous thing - Jens, recommending them as elements for HTML5 would be great, hehehe. There's always the thing of corporate branding websites being thin on content and massive on flashy presentation. The presentation is the content in those cases. You get the impression with these things, when the only real translatable content is meaningless marketing jargon, a catchphrase and possibly contact details, that these people would want an alternative for the apparently ever increasing demographic of users with large black Times over a white background, an alternative content of "Just go away". In these cases I really believe there's nothing to offer people who whether through choice or ability cannot access visuals/some basic amount of ten-year-old technology. Many sites want their logo at the top of the page, and they want it to make an impression. However, if the user has no access to images, do you really want them to go through "header: image: logo" or "this is the brand title and slogan" at every turn? I'd argue against. They will most likely know where they are (at least I hope so) from having accessed the page via a search results blurb, a descriptive external link, the site's root, and/or the - if they don't, something's amiss there. Ultimately, what I'd want is a CSS3 function "text-display:none". Jens is right, a logo's a complex thing... But in most instances I feel that a logo _is_ a purely visual icon. Granted, it has meaning, but as I struggle to explain to a great many CSS designers, for me, all visual content must have meaning and all of it is some abstraction of content in my eyes (I'm not insane, most people do access the web via their eyes, not through view-source!). I'm not explaining this incredibly well, but there is a gist somewhere in the last 3 paragraphs. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Logo and H1's
Jeffrey Sambells wrote:
html:
Company Name
css:
h1 span { display:none }
h1 {
width:100px
height:100px;
background: transparent url(/images/logo.png) no-repeat;
}
That's a great notion, and one I'd agree with - but sadly the consensus
in the user agent development community is that display:none should mean
'does not exist as far as the user is concerned'. All the major screen
readers ignore it as well.
Even more ironic, visibility:hidden would do exactly the same thing.
Regards,
Barney
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Logo and H1's
Andrew Ingram wrote:
Couldn't we use media rules to make things visible to screen readers?
@media aural, braille, embossed { h1 span { display:inline; } }
Again, that'd be wonderful, but as it stands nothing actually supports
those to the best of my knowledge.
The tragedy is that the wealth of CSS available since the inception of
CSS2 for targeting all sorts of different user agents is ignored, and as
such we increasingly have to account for the custom overrides of users.
Regards,
Barney
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Logo and H1's
Christian Montoya wrote: Maybe because no self-respecting user is going to take the time to contact you and let you know that your page doesn't quite work for them. Then again, it's not the main content of the page... maybe some users don't care if they can't see it at all. I know, I know - the invisible minorities are also by and wide silent. It takes the responsible idle theory and judgment of designers to take them into account and deal with them with due weight. Revision: My attitude was consciously (and uncharacteristically, I hope) flippant, I've revised it. Kim Kruse wrote: > Maybe one of these could solve you h1 problem... > > http://tjkdesign.com/articles/tip.asp or > http://tjkdesign.com/articles/a_perfect_Image_Replacement_technique.asp > > Kim That's amazing. How could Thierry leave us in the dark this long? I may very well play with this... Regardsm Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Legitimate uses of and
Patrick H. Lauke wrote: End of the day: if you're really after showing a visual style even if CSS is unavailable or disabled, heck, stick with presentational markup and use then, and don't abuse where it's not appropriate. Call me sad, but I love these conversations. As far as I'm concerned, and were mistakes in the present hindsight of HTML's grand design. The idea that I'm going to be looking through your DOM and find... A body, containing a div, containing a paragraph, containing text, and... A bold? An italic? Suddenly you've destroyed the notion of self-defining abstract nodes independent of medium. i < em b < strong Emphasis and strong emphasis are far stronger and more independent concepts, and have that sought-after advantage of creating the same visual effects by default, without recourse to CSS. If your top priority is making your text italic no matter what, use . However, in the case of describing the species, you aren't really emphasising it - you want to differentiate this text from the surroundings, but not as an emphasised portion of flowing prose. In fact what makes it different from the rest of the text (it describes a species) is not a fundamental difference in type of information, in fact it's very specific. So as such there is no shame in confining it to something as pedestrian as a classed and styled . There is not really a middle ground in my mind (for this particular example) - if you are adamant about visual user agents without CSS displaying this item in italic, use or , but realise that you're compromising substance for style. I'm not of the opinion that that would be a cardinal sin, it just depends on how dearly you value semantics. There is this notion that higher powers will punish you. They won't. Our Lord Google who art in heaven does not, contrary to the teachings of some, analyse the names of your classes or content of your text nodes and then rate it on arbitrary strength of meaning. It takes a human to make that kind of judgment - and that person is you. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Legitimate uses of and
Rob Kirton wrote:
I am suggesting that an should be used with the same class. That
is if she so wishes or as convention dictates, latin emphasis can be
made italic and globally changed if required later. Other forms of
emphasis could be applied for non latin phrases / other purposes. I see
it presentation of the semantic meaning and as such would not use a
purely presentational element such as
It just struck me that of course, small spans of foreign text in italic
is an incredibly common tradition.
If it's this specifically that we want to implement, we just put in
span:not[lang^="en"]{font-style:italic}, and wait a couple of years for
it to have some kind of visible effect.
Regards,
Barney
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Legitimate uses of and
David Dorward wrote: On Thu, Jan 18, 2007 at 02:01:49PM +, Barney Carroll wrote: Emphasis and strong emphasis are far stronger and more independent concepts, and have that sought-after advantage of creating the same visual effects by default, without recourse to CSS. If your top priority is making your text italic no matter what, use . In my copy of lynx, is represented by purple text, not italics. Proof that, no matter how many rules you break, no matter how far you run, some people will just never see italics on the internet. Your loss David. Hehe. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] website checker
Jon Gunderson wrote: The university of Illinois at Urbana/Champaign has developed a tool call the Functional Accessibility Evaluator (FAE). You can try it out at: http://fae.cita.uiuc.edu Hey, this is really really cute! Are you involved with it, Jon? Got good readings for my latest site, bumped into two failings: 1. No headings preceding navigation s (debatable intrinsic worth). 2. No navigation s. That second one is news to me. Anybody have any explanations/opinions on this? Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] AIMIA finalists
Katrina wrote: I notice a very interesting phenomenon: CSS is widely used, but validation is not considered important, for either CSS or HTML, and I don't think accessibility has been given a high priority either amongst these pages. Does anyone know why? Why have many of them made similar choices? For a lot of people validity is difficult to grasp as an inherently useful thing. What doesn't help is that when these people ask standards-loving communities why validation is so indispensable, the most enthusiastic advocates often don't have legitimate reasoning - e.g. the most common answer I get given is that Google penalises invalid pages in search ratings. If you're primarily concerned with looks, and are making a website that's unlikely to be handled by anyone else without your express guidance (and that you understand completely, of course), valid coding will often be a bonus nicety rather than a pre-requisite. As for valid CSS, I completely sympathise with those who reject it out of hand. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] AIMIA finalists
Hey, I've just looked at a dozen of these... And I know this is a web standards list, but does it strike anyone that, more so than being full of invalid code, these sites are just ugly, cumbersome and uninspired? Forgetting coding standards and going on user experience, I wouldn't rank any of these in the top 50 websites I've seen this month alone. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Title attributes
I was recently told by an automated accessibility test that my navigation was not up to scratch because it simply consisted of a plain ul at its highest level. It penalised me for not having a preceding heading to give some kind of indication of what the ul was about. Now I've never seen a navigation marked 'navigation', and even in the most of eccentric sites I've always been correct in the assumption that the first list of links with category denominations is some kind of navigation tool. I'd like to know what people think about that first of all - does anybody give headings to their navigation? ...But I discovered per chance (this thing didn't have great typographic semantics!) that the statement regarding headings was a link to an elaboration on navigation labeling - and it also suggested title attributes for lists. Now that's interesting. Does anybody use that? And more to the point, how would this come to use? Would it be read by screen readers as "unordered list - title - site navigation"? Is it the case that every tag name, attribute and property in the markup is pronounced by screen readers? Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Title attributes
Katrina wrote: Your post really reminded me of an older post that talked about this: http://www.usability.com.au/resources/ozewai2005/ May I asked which automated accessibility test? Hope that helps. Kat http://fae.cita.uiuc.edu/ - it's pretty good generally, but as with all automated tools it is only really a tick box. Validity for pseudo-human readability if you will. That link of yours is pretty good. The source order debate is one worth having again and again - although I think the writer puts too much faith in what people have come to expect (which is varied and incongruous enough) and not enough in what people might want. Superfluous headings: Sure, repeated information of any kind is irritating. But whenever I see 'Site Navigation:', I can't help but feel it's incredibly inane. Incidentally, I did not fail absolutely on that particular criteria - the site in question has the first two levels of navigation in separate columns on the left, while the third level takes the shape of an inline ul right-aligned at the top of the main content... Because of possible ambiguity what with the different format, this is headed Inside [section name]:. In that instance I think it's forgivable, and necessary, because it rests inside different block elements, and for users with CSS and a visual display, the semantics of position may confuse. Otherwise I think there's no confusion over a list of links (provided they have conventional text) being a navigation tool of some kind, and the general one need not be labeled. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Art and accessibility
Ben Buchanan wrote: It's a persistent misconception that accessibility has anything to do with the design. We all have to educate clients on this point and hope the message gets out there. Ben... You must elaborate loads on that. If you're saying that a site, no matter how terribly designed, is still possible to navigate and extract information on as a yes no answer, then your comment stands. But I'm afraid you're suggesting something else. 'Nothing to do with'... My every single design decision is based on accessibility. Perhaps I have something revelatory to learn? Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Tooltips (was: Title attributes)
Steve Green wrote: The use of hidden headings for navigation is of benefit to anyone whose user agent does not support CSS, not just screen reader users. We are seeing an increasing number of sites built that way and there isn't a downside that I can think of so perhaps it should become standard practice. That's pretty enlightening. Screen readers do not read 'title' attributes by default. You can configure some to read 'title' attributes instead of the on-page text but no one is going to have that as a permanent setting. You can also read the 'title' attribute for a specific element but that presupposes the user knows which elements have 'title' attributes. That's definitely worth knowing. You're priceless for this info, Steve! Tooltips of any kind can be a nuisance for screen magnifier users because even a small one can obscure a large proportion of the screen at modest magnification levels. It is even worse when the tooltip is caused by the 'title' attribute for a structural element such as a paragraph or a div because the user does not know where to move the mouse to get rid of it. It may not even be possible if the element fills the entire screen. For this reason I would not recommend using a 'title' attribute for a list. I think, because of the neatness and fun code around tooltips, especially CSS-generated ones, these things have acquired a popularity that isn't at all sober. My advice to people is: Is that information really desired, and if so, why not in the document's inactive state? Of course, I've seen 'pop-up' info via hidden/visible objects used tastefully, but a lot of the time I agree with Steve - it is an irritant. In particular, the new Google Image search - flashy effect, but utterly useless. Why is it so much better to see nothing but pictures? Why do I have to hover over each of them to get that information that I find particularly useful in determining the image's use? For one-off elaborations these are great (SNAP previews), but when it's a regular feature in your UI, it is just a pain. It also makes what would be pleasant, productive skimming a slow, challenging and clunky process. That's my opinionated usability tip for the day. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Google Image changes: inaccesssibility for all
Brian Cummiskey wrote: The majority of Google is inaccessible in some shape or form. What's one more piece going to do? I hate to sound like a fascist, but in terms of usability for sighted users with compliant browsers (I know, why would we even care?), this is the first time Google's eccentric attitude to standards has actually impeded my use of any of their services. The notion merits consideration: These incredibly 'inaccessible' services are some of the most incredibly accessed on the web. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Google Image changes: inaccesssibility for all
Barney Carroll wrote: I hate to sound like a fascist, but in terms of usability for sighted users with compliant browsers (I know, why would we even care?), this is the first time Google's eccentric attitude to standards has actually impeded my use of any of their services. The notion merits consideration: These incredibly 'inaccessible' services are some of the most incredibly accessed on the web. Sorry, I'm turning into a demagogue. Of course I still believe it would be great if I could get less than 2000 validation warnings per page, and perhaps less than 10 sub-nested tables in my Gmail app. Of course Google could be better - but still, I /do/ care now that one of their products has become practically less usable from a user perspective, as opposed to just abominable by theory. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Art and accessibility
Ben Buchanan wrote: I strongly suspect the "usable = ugly" myth is perpetuated by design firms that don't feel like updating their skills; and don't want their clients to get a clue and go elsewhere. So they spread misinformation so everyone has an excuse to keep doing the same old thing. Right right right. For me it's not hard to attribute this to the character of individual 'designers'. Some of them are designers and some of them are coders. The majority of them are coders. Graphic communications and formal writing are well-established crafts that can conceivably be far more stringent than the full set of w3-backed standards to a person with no visual or literary sensibilities at all. I am forever seeing sites of seamlessly blissful clarity turn to fetid soup when I open up the source, and likewise the elite standardista's site often has to be forgiven its childish aesthetics and perceived semantics because of its very neatly arranged code (and the fact it runs on every system within a mile). I seriously believe it is down to individuals as such - even in teams, the leadership will say "Who cares about this invalid code that needs fixing? You could be doing much better stuff, it already works great" or "I don't have time for you to re-design the third level navigation, it exists and it's in a logical place in the source". Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Art and accessibility - my opinion ;)
Matthew Smith wrote: tolerate screen motion? (A bit off-topic, I know, but I believe that accessibility/standards doesn't stop at the content, but extends to software and OS.) Not liking fancy animations does not make you an accessibility advocate. Apparently everyone hates flash, but for different reasons. Hehehe. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Smallest valid html document (was validator.w3.org broken?)
But is it accessible? Rimantas Liubertas wrote: > That's not minimal document. This one is: > .. Strictly speaking, the is optional - you only need a title and some content In this case dots are optional, is not. What you say is true for Transitional DTD. The shortest page I think is valid is: . Anyone? Well, I'll limit myself to HTML4.01 for now :) Regards, Rimantas -- http://rimantas.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Art and accessibility - my opinion ;)
Milosz, those sites are incredibly flash-intensive. Without flash, they fail. With flash and a slow connection (or even processor), they run badly. I'm afraid any objective source would give those low marks for accessibility. But they are entirely based on style - there is no real substance in there, it's just visuals. So the demographics they're excluding have nothing to gain from accessing the sites anyway. At which point, to be honest, I'd stop worrying. There is no reason for you to beat yourself up over these things - perhaps nice little flash tests and messages of 'nothing for you here!' on fail, and you've left no-one unaccounted. Having said that, for creations entirely dedicated to art, they're awfully flimsy. This is the 'art' of college design student bimbos drunk on their own hormones and stumbling about the room looking to fall into the lap of the nearest fad. Of course the only fads that stand out when you're inebriated to this point are the ones with garish colours and stuff jumping out all over the place. I suppose if you gave these guys creative directors they could do corporate ads on the internet, possibly music group web sites. 'Emotional' is too strong a word, I reckon (or not strong enough, depending on where you stand). 'Sentimental' might be better. Although it still gives a good indication of the contents. We were warned! Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Art and accessibility - my opinion ;)
Now that's what I'm talking about. When everything is available as raw XML and you've got XSLT, you're in flexible heaven. Rob O'Rourke wrote: Not necessarily, check out what Dan Cederholm wrote about his work on MTV.com [1], they have a fully flash site that runs from a server-side generated xml file. Dan's role was to create XSLTs that transformed the same information into an accessible HTML version of the site so that users could chop and change as they saw fit. Now that's the way things should be done if an ENTIRE site is to be made in flash =] [1] http://www.simplebits.com/work/mtv/ I'm actually working on a browser-based multiplayer game with a friend of mine that will work in this way, hopefully it'll be the first truly accessible one too. Rob O *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Art and accessibility - my opinion ;)
Jermayn Parker wrote: It is not that good... Yes it may load quick but it is a useless uninformative site and apart from the home page it is ugly and bare as naked bones. Lets hope that the designer does not win any awards That's all down to inevitable site content though. The designer has done the most he or she could, barring turning down the job. I am involved in a long-term project to design a site with accessibility features similar to this - it is a site primarily concerned with presenting music and graphic art, in key instances using flash and javascript-assisted stylistic presentation, and as such its content is mainly of a hi-tech, sensory and artistic nature. It just so happens that there is a lot of very wordy prose around the site, so perhaps it might meet your standards, but there are very large portions of the site whose raison d'etre is a method of accessing intrinsically audio and visual content that by its nature, cannot have a truly worthwhile text substitute. I am not going to tell the artists to create accessible 'alternatives' to their creations, neither am I going to tell them that their work has no place on the internet except as trivial extra features - I'm proud to be able to help them prove that the internet is exactly the place for them to do whatever they want, all the while abiding by intelligent accessibility standards. The question we should be asking ourselves is how web-based content whose ultimate purpose is to present artistic (and this includes - crucially - corporate art) media should be made to be as accessible as possible, not 'if'. But to say that such sites cannot be well designed is tragic wishful thinking. Remember design is always a means to an end. The Ivy Hotel has done a great job as far as design is concerned. Its content is indeed flimsy in concrete terms, and as an informative document it is very weak - but the internet shouldn't be limited to encyclopedias, reference manuals and opinion columns. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] CSS calling methods survey
?
Re: [WSG] HR tag and Semantics
Christian Montoya wrote: The actually carries semantic weight, and is meant to be used carefully... the does not. http://www.w3.org/TR/xhtml2/mod-structural.html#edef_structural_section Then again, XHTML 2 does have a element which is just like ... http://www.w3.org/TR/xhtml2/mod-structural.html#edef_structural_separator But you will notice that XHTML 2 has both and , and is weightless while is not. I am intrigued by this. There are those who believe HR is completely obsolete /on a semantic level/ because, as we all supposedly know, a document's semantic structure is divided entirely by headings. I would like to see if these people have ever swallowed their own medicine and then developed a site that satisfies anyone. Furthermore, surely these people should be horrified at the idea of sections and separators? Occasionally I get tempted to abide by these bizarre rules and create my heading minefield of a document that will satisfy these monsters when they switch to the ultimate view-source browsing experience, but use a display:none class to maintain readability by human beings with an existing culture of literature to consider. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] HR tag and Semantics
Rob, I see where you're coming from - although it becomes easy at times like these to mythicise (why isn't that a word?) the benefit of having a document that requires no intelligent analysis. What I believe you're getting at... Is that 'horizontal rule' in itself does not 'mean' anything - it is off-putting because it is a tag whose name signifies a visual symbol which signifies an abstract value. Far better for all of us, I think, to have this replaced by the term 'separator' - which could be styled to appear as a horizontal rule if such is required of the medium the document is rendered in. The element is slightly more complex, because 'break' is a more useful term. As it happens, the only application of a is to separate objects with a line-break - which is made redundant because it is possible to customize just such an effect with the natural separation of the two elements it divides. If could be styled, I would far prefer to use that then an . But we're all agreed, I hope, that having an element achieve this effect is much desired (even if it might be difficult for a machine to quickly interpret its value) - after all, it's long been in semantic use in human literature pre-ML. I think we're also all agreed that is a better name for such a thing. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] HR tag and Semantics
@Designer:
separates text into individual blocks. It is used for the same
reason as we use spaces, commas, full-stops (periods), page breaks... A
paragraph should be self-contained in meaning. If you argue that this is
presentational, there's not much stopping you from making the leap to
the fact that text itself is purely a collection of signs which only
mean anything once interpreted on some level. I hope we can leave it at
this without getting into perceptive psychology and the ultimate
meaninglessness of life itself.
@Rimantas:
It only takes imagining any occurrence of a to make clear that your
example obviously isn't enough. Of course we don't want one of these
between all s or s. No-one has ever used it like this. It is
only because it is used as a distinct element that anyone acknowledges
its value. Horizontal rules do not necessarily divide chapters - and
neither do they divide all paragraphs in any instance I've seen.
You seem to be of the camp which maintains that use of the horizontal
rule as a visual device is never justified. I disagree.
*
If people were to say there should be such a thing as
p.breakFlow:after{display:block;height:1px;color:#00;margin:2em 0 0
2em} on the basis that there should not be such an 'object' in the
markup, I might be tempted to get into a discussion about semiotics. But
saying that a staple of human literary culture over the past 500 years
has been made obsolete by Google doesn't really merit acknowledgment in
my eyes.
Regards,
Barney
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] HR tag and Semantics
Designer wrote: separates text into individual blocks. And that's different to div or span because . . .??? Span is an in-line text divider, most of the time. It can be used to highlight all sorts of differences in text significance. Paragraphs are block level elements. A div-level separation usually means you are dealing with a very separate piece of text - one that is outside the flow of the rest of the document, and often not part of the'document' at all. Moreover it has no defined relationship to text - divs are much more free in their use. As Rob suggests, div and span are far looser in their interpretation than s. @Akella: You mention divisions between chapters, Akella, but I am more familiar with such devices (the '*' format of horizontal rules in print) being used at levels lower than the chapter. In novellas they generally signify a distinct break of timeline or protagonist. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] HR tag and Semantics
Tim wrote: Can we discuss in this group Google's effect on the English language, promoting pagerank for compliance with their search algorithms. Tim I'm pretty sure these people are never actually hired for the 'service' of their attitudes to the shape of documents to come, and as such I sleep easy at night. I don't know what has to happen to you for you to browse the web in browse-source mode and go "Hang on, these nested divs are fine, but what's this non-functional empty element between paragraphs?" - but I'm fairly certain those're a distinct minority compared to the deluded masses, who still rely on such outdated things as their experience of 'human languages', 'deductive reasoning' and 'sensory apparatus' to read stuff on the internet. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] HR tag and Semantics
The face of standardisation that wants to drag every form of media into an indefinitely future-compatible world where everything is stripped down to the lowest common denominator of systematically-compartmentalised data... Has its place. But it often takes the romantics to keep it in there. You can't erase your ancestry! We're driving into the same argument that the 'Art and accessibility' thread died on - namely that only certain forms of information are legitimate on the internet. This is an awful stance to take. As far as possible, every element of information should be clearly labeled and understood even if the rendering device has no use for it... But if there is a problem with these ephemeral and hard-to-define elements, standardistas should use their sense of order and clear markup to help integrate these elements - attempting to remove them is futile, if anything it'll just result in them being used or simulated badly. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
