Re: [WSG] IE ignores MIME type
On 12 Apr 2010, at 06:53:46, David Hucklesby wrote: This is a demo I made for him. The view source is named with a .txt suffix, and sent as Content Type text/plain. But Internet Explorer, alone among my browsers, insists on displaying the two files containing HTML as if they were text/html. This MSDN article http://msdn.microsoft.com/en-us/library/ms775147(VS.85).aspx explains how Microsoft, in their infinite wisdom, chose to break the web because they know so much better than those who wrote the RFCs. Basically, they chose to assume that text/plain was probably wrong in most cases (which might have been a real problem around 1997, but not one they should have taken it upon themselves to fix in this way), and instead examine the content to see if it might be something else. As in this case it looks like HTML, IE ignores the server and treats it as HTML. This post on the IE blog http://blogs.msdn.com/ie/archive/2005/02/01/364581.aspx explains that, when they tried to fix things in XP SP2, they found that the damage they had caused was so widespread that they had to abandon the fix (despite the fact that this content sniffing can be a serious security issue). They offer no useful solution. This article on the subject from Google http://code.google.com/p/doctype/wiki/ArticleContentSniffing has little to suggest either. Sorry I can't help, but with that information perhaps somebody can come up with a workaround. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[Spam] :Re: [WSG] Is page-break-before broken in Webkit?
2009/10/14 David Hucklesby huckle...@gmail.com: James Ducker wrote: Hi there, As a test, try using that style on an element that isn't floated or inside a floated element. That was worth a try - I added a break-after to the preceding paragraph, but Safari 4 seems intent on ignoring my wishes. (I double-checked in other browsers - either place works fine.) Thanks for the idea... It looks like there are long-standing issues with WebKit's page-break-* handling: https://bugs.webkit.org/show_bug.cgi?id=5097 https://bugs.webkit.org/show_bug.cgi?id=9526 Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] An Acceptable Dropdown
2009/8/23 Bushidodeep field.ni...@gmail.com: All debates aside on drop-down menus, they're called for, demanded by some. I like this onehttp://www.csun.edu/, and wondered if anyone has a tutorial URL bookmarked? WAI-ARIA has a number of menu-related roles and properties [1]. Newer browsers, including IE 8, offer reasonably good levels of support, as do newer versions of some assistive technologies. There's a good video by Todd Kloots of the YUI team demonstrating the use of ARIA to enhance accessibility of a drop-down menu: I'll link to the copy on Eric Miraglia's blog [2], as that includes a transcript. [1] http://www.w3.org/TR/wai-aria/#menu [2] http://ericmiraglia.com/blog/?p=132 Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] The head of the document
2009/7/23 Paul Collins p.coll...@twentyfirst.com: - Good search engine rankings - Best charset for English text (utf-8, right?) - Do we need robots - all anymore? - Any Accessibility issues? (Can't think of any) - Does anyone bother with descriptions, keywords anymore? - Dublin Core metadata, is that a forgotten fad?! Google pays attention to meta description: see their SEO Starter Guide, a PDF linked from http://googlewebmastercentral.blogspot.com/2008/11/googles-seo-starter-guide.html. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Form question
2009/7/15 steve.haffen...@gmail.com: Can anyone tell me why the HTML specification does not restrict form elements from appearing outside of the form tag? HTML 4.01 section 17.2.1: The elements used to create controls generally appear inside a FORM element, but may also appear outside of a FORM element declaration when they are used to build user interfaces. http://www.w3.org/TR/html401/interact/forms.html#h-17.2.1 Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: Re: [WSG] Form question
2009/7/15 Mathew Robertson mat...@optusnet.com.au: Another related question to ask... Why is putting a hidden input field, as the first child of a form element, disallowed? The HTML 4.01 DTD specifies that only block-level elements or script elements may appear as the immediate children of the FORM element; input elements are inline: http://www.w3.org/TR/html401/interact/forms.html#h-17.3 As to _why_ this is the case, I'm really not sure :-) Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] font size - was [ Accessible websites]
2009/7/7 designer desig...@gwelanmor-internet.co.uk: I've been reading (and trying to learn from) the discussions on accessibility and particularly font size. I have never had any success at using ways other than pixels. When I read: http://informationarchitects.jp/100e2r/?v=4 I agreed with the author that the text size looked OK (he uses Georgia), so I tried knocking up a simple test/template and I found that Verdana 'looks' much bigger than Georgia, and Arial slightly smaller than Georgia. I also found that firefox was different to Safara, these two in turn being different to IE and Opera. IE7 looked huge and clumsy! See for yourself: http://www.betasite.fsnet.co.uk/gam/fontstyle.html So, whilst the idea of text at 100% sounds reasonable, I always get a mixed bag of results. I feel as a designer(suggester), that I cannot possibly allow something I've done to look laughably clumsy in some browsers. Contrary to the idea that users want to choose there own settings, my experience is that very very few even know they can do it, let alone want to be bothered! Is there a way around this, which provides a more consistent interface AND maintains user choice for those who want it? Different fonts have different sized letter forms; _of course_ they look different. Look up x-height http://en.wikipedia.org/wiki/X-height for starters. Verdana not only has a larger x-height than Georgia or Arial, it also has wider letters; that is why the Verdana sample occupies seven lines, while the Georgia and Arial samples only occupy six. Using the MeasureIt plugin for Firefox, I find that six lines occupies exactly the same amount of vertical space in all three fonts, which is what one would expect given that they have the same font-size and line-height. It's just that Verdana doesn't fit as many letters into the same space widthways, and so runs on to an extra line. If you expect all typefaces to occupy the exact same space letter-for-letter then you're going to have to turn your back on hundreds of years of typographical history. Using only monospaced fonts will give roughly the effect you desire ;-) Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Safari 4 and 3.2 Running Simultaneously
Hi, You could run a nightly build: http://nightly.webkit.org/ If you find out what build the 4 Beta is, you can get that (or the nearest) build from the Windows build archive at: http://nightly.webkit.org/builds/trunk/win/1 HTH, Nick. On Thu, February 26, 2009 2:30 pm, Gregorio Espadas wrote: Hi folks... I want to install Safari 4 in Microsoft Windows for testing pourposes, but I don't want to dismiss Safari 3.2. I've been searching for a solution (installing Safari 4 without affect the current installation of Safari 3.2), but I didn't find anything. I find out that the Safari 4 installation updates the Webkit Framework, not only the browser itself... so, I guess installing in a different folder won't work. I'm aware that Safari 4 includes a User Agent changer, but I guess this tool is not for rendering, only for masquerade in order to use certain webapps. Any one knows how to accomplish this goal? I'll appreciate any suggestion. Gregorio Espadas *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] IE and the button element
On Tue, February 24, 2009 1:54 am, John Horner wrote: Advantages of using buttons: 1) Button elements don't need styling, they take their styling from the user's operating system, which they are, I assume, familiar and comfortable with. I won't be reinventing the wheel. Actually, the specific purpose of the button is to allow one to have buttons that *don't* look like ordinary buttons: Buttons created with the BUTTON element function just like buttons created with the INPUT element, but they offer richer rendering possibilities: the BUTTON element may have content. http://www.w3.org/TR/html401/interact/forms.html#edef-BUTTON In other words, the purpose of the button element is to allow the functionality of a button without imposing the appearance of one. 2) Anchor elements don't have a built-in disabled mode, buttons do, and again the styling comes directly from the OS and the user is familiar with it. If it doesn't do anything (that is, it is disabled), then it shouldn't be an anchor element. An anchor element used as a hyperlink has a semantic meaning. If that meaning should not be attached to a piece of content - e.g. the words Next page when there is no next page - then the link should be absent. While there may be good usability reasons for retaining the content, such as maintaining consistency of interface, to think in terms of providing functionality and then disabling it is to put the cart before the horse: instead, only provide the functionality when it is functional. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
On Tue, February 24, 2009 10:57 am, David Dorward wrote: Nick Fitzsimons wrote: Actually, the specific purpose of the button is to allow one to have buttons that *don't* look like ordinary buttons: Buttons created with the BUTTON element function just like buttons created with the INPUT element, but they offer richer rendering possibilities: the BUTTON element may have content. http://www.w3.org/TR/html401/interact/forms.html#edef-BUTTON No, you can have richer rendering possibilities without giving up looking like ordinary buttons. The typical case is a button with an icon on it. http://www.packagekit.org/img/kpk-confirm.png for example. True; I didn't phrase that very well. The point I was really trying to make is that to suggest that the value of the button element is that it *looks* like a button is to miss the point; the point is that it *behaves* like a button. In other words its purpose is to provide a specific kind of functionality, not a specific kind of appearance. Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] selectutorial
On Thu, April 17, 2008 3:51 pm, kevin mcmonagle wrote:
hi,
My friend wants to learn about css so i told him to do the selectutorial
on the maxdesign site.
It says to reset the margins in the body then use ems for padding.
I was reading somewhere that cancelling out the margins in the body
tells the browsers to go through all the tags and cancel out the margins
and that it actually adds to download time. I dont know if thats
realistic or not but ive been using margins for spacing between divs for
a long time.
Assuming you're talking about
body {
margin: 0;
}
this only resets the margins on the body; it doesn't affect anything else.
However
* {
margin: 0;
}
using the universal selector * will indeed reset the margins on
everything, and can have an impact on performance depending on how the
browser rendering is implemented.
It isn't that the universal selector goes through all the tags, more
that it has to be checked every time a tag (more accurately, element) is
rendered, which can slow down rendering time (it has no effect on download
time); if you want some deep technical detail on how the WebKit engine
used in Safari, for example, goes about this, read Dave Hyatt's blog post
at http://weblogs.mozillazine.org/hyatt/archives/2005_05.html#007507
This is one reason why most modern reset-CSS files will specify all the
elements on which default margins and padding are to be zeroed: it
improves rendering speed if the * selector is not applied to absolutely
everything in the document. (It can still be of value without impairing
rendering efficiency unduly when applied at a more specific level, e.g.
#example p *.)
Regards,
Nick.
--
Nick Fitzsimons
http://www.nickfitz.co.uk/
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] PNG file sizes
On Wed, April 16, 2008 5:59 am, Rachel May wrote: Only my personal website I've used transparent PNGs a lot... I've been rather picky on how it looks, so that the shadows look natural etc. But this means that the file sizes are HUGE and download is really long. I created the PNGs in Photoshop (CS3) and just wondering if there are any better tools or ways of saving the PNGs for smaller file size, while still retaining their high quality?? If you just use Photoshop's normal Save functionality, selecting PNG as the type, it will include a large amount of information in the file to assist it when the file is opened for editing at a later time. Use the Save for Web and Devices dialog instead and it will create much smaller files. HTH, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] * { display: inline; }
On Mon, February 18, 2008 12:06 am, Tim White wrote:
On Feb 17, 2008 6:00 PM, Katrina [EMAIL PROTECTED] wrote:
So in the header of my document, I included
style type=text/css
* {
display: inline;
}
/style
OK, I just tried it and got the exact same effects. So, I tried
combinations and body * works (and I see Patrick just posted the same
thing).
My best guess is that the browsers are setting head as an inline
element, along with style, etc.. If you change inline to block you
get the expected behavior.
very odd indeed.
Not so very odd...
If you hunt around through Firefox's files you'll find one named
html.css which specifies the default styling of all HTML elements. It
includes the following:
/* hidden elements */
area, base, basefont, head, meta, script, style, title,
noembed, param {
display: none;
}
The new rule is overriding that rule, and so all those elements become
visible.
So, far from being odd, it's actually precisely the behaviour one would
expect according to the rules of CSS.
The only reason IE _doesn't_ exhibit the same behaviour as the browsers
Katrina listed is that it has an incomplete implementation of the HTML/CSS
rendering model which prevents it from rendering the contents of the
head element. So it's IE that's odd :-)
Regards,
Nick.
--
Nick Fitzsimons
http://www.nickfitz.co.uk/
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] hello
Could somebody enlighten me as to what any of these irrelevant ramblings about a marketing buzzphrase have to do with Web Standards? NickFitz in about time to unsubscribe from this list if it's going to degenerate into pretentious drivel mode... -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Background images versus image
On 23 Jan 2008, at 17:29, Christian Snodgrass wrote: [quote] Although, in your specific case, I would go with what Dave Woods said. If you really want those image check boxes, use normal check boxes, and then use Javascript to swap those out for your image ones. With that solution, if they don't have Javascript, normal check boxes appear (which are easy for screen readers and the like), and if you do have Javascript, you get your cute image check boxes. And, I'd say use normal images for those as well and use alt text like checked, unchecked, disabled, however, that wouldn't work well with a screen reader. [/quote] Even the JS approach would potentially be an issue for screen reader users. When a screen reader is used for filling in a form, it switches from its usual reading mode into forms mode, which allows the user to interact with the form. If, however, your JavaScript has removed the form elements, there is then nothing to interact with - it can't tell that the images are supposed to be like the clicky widgets it understands. So you would definitely need to look into using some kind of offscreen positioning technique, rather than just replacing the checkboxes with images, so that users of such assistive technologies would be able to use the page. HTH, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Rockwell?
On 21 Dec 2007, at 10:05, Jos Flachs wrote: Hi, I got a font problem: for a site I'm working on I'd like to use rockwell.ttf, in the h1 tag. Rockwell isn't a standard font, but every windows user has them, and it is also available for Mac. But I don't know if this font is in the Mac fontbook. And I'm pretty sure *nix users don't have it at all. I don't have Rockwell on any of my Windows installations (Win 95, 98, ME, 2000, XP Pro and Server 2003). I do have it on my old PowerMac (I can't remember which piece of software it came with), but not on my MacBook or MacBook Pro. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Testing emails for Outlook 2007
On 7 Nov 2007, at 14:01, Paul Collins wrote: I think the best thing to do is grab a version for XP, I didn't actually know I could add it to that. On 07/11/2007, Joshua Street [EMAIL PROTECTED] wrote: On 11/7/07, Mohamed Jama [EMAIL PROTECTED] wrote: You could always open the page in word document and if everything looks fine there it will look fine in outlook 2007 since its using MS Word to render! Problem with that is potential differences between Word HTML rendering 2003 - 2007. I haven't really looked into it but it would stand to reason there may be differences... they stupidly thought it good enough to be the sole renderer for the most widely used email client on the planet, so you'd at least hope it improved... It might be worth downloading the Word 2007 Viewer - it's a free download which allows you to View, print and copy Microsoft Word documents, even if you don't have Microsoft Word installed: http://office.microsoft.com/en-us/downloads/CD102258581033.aspx Maybe somebody with access to Outlook 2007 can compare the two to see if they are comparable. HTH, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] SilverLight
On 30 Oct 2007, at 16:01, Patrick H. Lauke wrote: I recently spotted it in this article http://www.regdeveloper.co.uk/2007/05/11/ silverlight_programming_q_and_a/ Quoting Keith Smith, product manager of the user experience platform and tools team at Microsoft covering Silverlight as well as WPF and tools like the new Expression Studio: The pattern we follow with Ajax is to make smart decisions on behalf of the designer and developer When Microsoft say that kind of thing, my heart grows heavy with trepidation... remember all the grief they've caused in the past with stuff like determining how to display content by using assorted heuristics rather than just obeying the Content-Type HTTP header? All inspired by the idea that MS know what you really meant, and can make smart decisions on your behalf, presumably because you can't make them yourself. I'm reminded of a blog comment I read earlier today by a chap called barbecuesteve concerning the just-announced null characters exploit: This really illustrates my fundamental problem with Microsoft’s attitude. “The data you have is not accurate. Here, let me fix it for you.” As if Microsoft is the sole determiner of what constitutes accurate data and what doesn’t. http://blog.didierstevens.com/2007/10/23/ a000n-o000l00d00-0i000e000-00t0ric000k/#comment-16560 Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] browsers render differently with Optroup
On 24 Oct 2007, at 14:37, Tee G. Peng wrote: We must use 'label' right? option label=3.7 value=pm2_3.7PortMaster 2 with ComOS 3.7/ option The label attribute is only required on optgroup; it is optional on option. If browsers are behaving differently when it's used on option, just remove it. http://www.w3.org/TR/html4/index/attributes.html is a quick way to check whether an attribute is required or not. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 19 Oct 2007, at 04:59, Kepler Gelotte wrote: I created a test page that demonstrates the technique. I tested it with my email but changed it to a dummy domain so I won't get flooded with emails. Kepler, mydomain.com isn't a dummy domain: http://www.whois.net/whois_new.cgi?d=mydomaintld=com If you need to use a dummy domain name, example.com and others have been reserved for exactly that purpose: To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. http://www.ietf.org/rfc/rfc2606.txt Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 18 Oct 2007, at 15:49, Anders Nawroth wrote: IMHO captchas are used too much, as they suck considerably! And they are also frowned upon by the W3C because of their inaccessibility, and the fact that they provide a false sense of security: http://www.w3.org/TR/turingtest/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] introducing a prompt to download or open a pdf
On 17 Oct 2007, at 04:50, Chris Knowles wrote: Kit Grose wrote: Just a note: Your function doesn't currently use the RegExp function for anything useful (you might as well use indexOf). RegExp is the right way to do it, though, so you can enforce word boundaries to match complete classNames only (if I want all a.pop to be new window links, I wouldn't want a.popcorn to turn into a popup window). See http://snook.ca/archives/javascript/your_favourite_1/ for more info (specifically the update) on how to enforce word boundaries but allow for multiple classnames. good point - here it is modified to use word boundaries: Word boundaries aren't right either; for exmple, they will match a hyphen, so matching on some-thing will match some-thing-else. As per the HTML spec, class names are space-separated, so you need to match on spaces and the beginning or end of the string. To save time, Robert Nyman has already been through all these problems, so have a look at his ultimate getElementsByClassName: http://www.robertnyman.com/2005/11/07/the-ultimate- getelementsbyclassname/ including the comment from Bruce Weirdan explaining the above: http://www.robertnyman.com/2005/11/07/the- ultimate-getelementsbyclassname/#comment-1583 HTH, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] introducing a prompt to download or open a pdf
On 17 Oct 2007, at 13:47, Chris Knowles wrote:
Nick Fitzsimons wrote:
Word boundaries aren't right either; for exmple, they will match a
hyphen, so matching on some-thing will match some-thing-else. As
per the
HTML spec, class names are space-separated, so you need to match on
spaces and the beginning or end of the string.
of course, class names are separated by whitespace so hopefully
this is
it...
var re = new RegExp('\\s' + className + '\\s');
Nope, that won't match thing to thing, only to thing - you
need to check for the start or end of the string as well as a space :-)
HTH,
Nick.
--
Nick Fitzsimons
http://www.nickfitz.co.uk/
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] javascript/DOM scripting in cross-browser-land [UPDATE]
On 17 Oct 2007, at 17:29, Ray Leventhal wrote: Are there known issues with DOM scripts and Win/FF2, or is there something that I as a newbie to JS/DOM have overlooked? So, the question then becomes, is there an accessible and standards-valid way to make the script continue to execute? Not sure when Mr Langridge last updated that script, but as a general rule FF on Win is extremely reliable - and so is Stu :-) The easiest way to debug a script on Firefox is to install the Firebug extension. If there's an error it will appear in the console; the link to the script source file and line number will put you at the place that the error occurred. You can set a breakpoint there and that allows you to see what value variables have, etc. HTH, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] introducing a prompt to download or open a pdf
On 16 Oct 2007, at 08:40, dwain wrote: i did not put the pdf icon (don't know where to get one) http://www.adobe.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] introducing a prompt to download or open a pdf
On 16 Oct 2007, at 10:43, dwain wrote: On 10/16/07, Nick Fitzsimons [EMAIL PROTECTED] wrote: On 16 Oct 2007, at 08:40, dwain wrote: i did not put the pdf icon (don't know where to get one) http://www.adobe.com/ thanks, i found one. where do i put this icon before or after the link? dwain It used to be quite easy to ind the relevant page, but they seem to have let their legal department loose on the site :-( Personally, I include the icon within the link; whether it goes before or after the text of the link is purely a matter of personal preference, or the dictates of the graphic designer. I tend to expect it before: a href=blah.pdfimg src=pdflogo.gifDownload blah.pdf/a Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] London Meetup for people interested in an informal discussion around web standards
On 11 Oct 2007, at 10:58, Joseph Ortenzi wrote: Thanks Karl, but the pubstandards group appears to have withered away and died, unfortunately. at least the UK one. Erm... http://upcoming.yahoo.com/event/290703/ Next pubstandards UK meetup is next Thursday :-) HTH, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] London Meetup for people interested in an informal discussion around web standards
On 11 Oct 2007, at 12:00, Ross Bruniges wrote: For general meet-ups with presentations and such (like Geek Dinners or things similar) then it really is best to just keep a close eye on upcoming.yahoo.com for things as they pop up from time to time - you will also get a good idea of who to follow so that you can see when things are occuring as they say they are attending or watching. Just to let people know, the London Web Standards Group page on upcoming is at http://upcoming.yahoo.com/group/1610/ By all means please come to pub standards, its a hell of a lot of fun but don't expect to learn too much : And if you _do_ learn anything, don't expect to remember it the next day :-) Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] document.getElementById slow?
On 5 Oct 2007, at 13:28:32, Simon Cockayne wrote: So which is faster? document.forms.myform.elements.field1 or document.getElementById(field1) When in doubt, test! All else is futile speculation: http://www.nickfitz.co.uk/tests/javascript/get-id-v-dot.html (Script at http://www.nickfitz.co.uk/res/js/get-id-v-dot.js) Click the button, wait a few seconds, and you'll get three alerts, each showing the time in milliseconds for 100,000 runs. It's not very tidy, but the first result is the overhead of running the test, the second uses getElementById, and the third uses element property access with .; on Safari, Opera and Firefox (Mac) and IE 6 (Win) it shows that . is roughly one-and-a-half to two times *slower* than getElementById. I'll get the test page tidied up and write this up, with an attempt at explaining the results, real soon now; in the meantime I'm late for the pub :-) However you can go into work on Monday, point at your colleague and laugh maniacally while shouting U haz fail very loudly (or whatever the etiquette in your workplace permits) because (s)he's wrong :-D HTH, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Element suggestion requested
On 20 Sep 2007, at 20:55, Rick Lecoat wrote: On 20/9/07 (15:21) Nick said: Was there any particular reason not to have the h2 elements in the li elements, rather than placing them in a div? Um... a brain seizure of some sort I think. I somehow had it in my head that block-level items are not permitted inside list items, which is of course nonsense. But to be honest, even with the ability to put almost any tag inside an li, I still don't feel like a heading is the right one. These aren't headings, after all. And a span probably isn't the right one either, but I chose it because its semantically neutral. These values should have some weight given to them, but H2 implies a hierarchical structure that is not there. Agreed that a heading doesn't really make much sense in this context. Why not a p rather than a span? That goes some way to addressing the semantics of a list of statements, which is basically what this is. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Element suggestion requested
On 20 Sep 2007, at 11:56, Rick Lecoat wrote: On 19/9/07 (15:17) Kenny said: Yup. It's a list of values. Thanks for that Kenny. Even before posting the question I had started to code the 'Values' as a list, but then ran into difficulty styling it -- the vertically expandable box requires two images, and the li tag only provides one hook to hang them on. Adding a span got me part way there, but there were still problems with the width, so I resorted to re-coding each as value as an h2 in a div. Your post prompted me to throw that away and go back to the unordered list, and to finally solve the styling problem, so thanks again. Was there any particular reason not to have the h2 elements in the li elements, rather than placing them in a div? Regards, Nick. -- http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Speaking of alt tags . . .
tag. But I've
also been told that the tag should be alt= , NOT alt=,
because with
no spaces (or one) the screen reader will announce 'blank'
whereas with
two spaces it remains silent.
David Dorward has already posted the definitive answer to your questions, so
I won't repeat what he said. I just wanted to point that the term the
screen reader seems to imply that there is One True Screen Reader, which is
far from the case. There are many different screen readers, and their
behaviour varies, even among different versions of the same software. {car
analogy warning} Saying that the screen reader behaves in a certain way is
like saying The car does 0 - 60mph in 5.6 seconds; it may in fact be true,
but unless we know _which_ car is being spoken of, it is completely
uninformative.
So if somebody has told you that you should do something a certain way
because of the screen reader singular, you can be reasonably certain that
they don't actually understand what they're talking about, and can assess
the worth of their advice on that basis.
(Aside: It should also be borne in mind that screen readers aren't the only
assistive technologies out there, just as total blindness is not the only
disability. Accessibility isn't just about screen reader behaviour.)
Regards,
Nick.
--
Nick Fitzsimons
http://www.nickfitz.co.uk/
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] setting fontsize in body
On 3 Aug 2007, at 20:14:59, Patrick H. Lauke wrote: Nick Fitzsimons wrote: (Still falls foul of a minimum font-size set in the browser preferences, though.) I wouldn't say it falls foul. If a user has set a minimum size, then a page should heed that. It still *respects* minimum font-size settings. Yep, poor choice of words. I stand corrected :-) Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] setting fontsize in body
On 4 Aug 2007, at 11:55:42, Gunlaug Sørtun wrote: Tee G. Peng wrote: On Aug 3, 2007, at 8:19 PM, Philippe Wittenbergh wrote: Unless my copy is sick, the default is 9px Mine is 12px. I don't remember I ever altered the fontsize in Opera (9.22), as I only use this browser for testing. Monitor Screen resolution: 1680 x 1050. According to this... http://www.opera.com/support/usingopera/operaini/index.dml#userprefs ... the default 'minimum font size' is '6px' for win-versions and _'9px'_ for Mac-versions. Not the result I'm getting for the latest version, 9.22. On the Mac: 1. Existing install had a minimum font size of 9px, but I'm pretty sure I'd changed that myself when testing something a few months ago. 2. I trashed my Opera preferences and installed the latest version, and it has a minimum font size of 13px, which ties in with what I remember seeing previously. On a brand-new, never-run Windows XP SP 2 install (gotta love Parallels): download and run Opera, minimum font size is 9px. So it looks like somebody at Opera goofed, either in writing that document, or in not keeping it updated. HTH, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] setting fontsize in body
On 4 Aug 2007, at 17:08:37, Gunlaug Sørtun wrote: Just to check since there may also be another, so far pretty undocumented, variable at play here: - does anyone know if this 'minimum font size' value changes/differs with screen-DPI in Opera? It is a bit problematic if a browser has undocumented defaults/behaviors, as we cannot test based on knowledge then and the guessing game is no fun. On the other hand: such deviations shouldn't create any real problems if the methods we use take the potential variables into account, and browser-options aren't bugs designers should try to counter. On the standard 96dpi XP Pro, Opera has configured itself with: default font size 16px minimum font size 9px. Another Parallels virtual machine later: XP Pro SP2, never been used except for first boot, set to 120dpi, reboot to apply settings, install Opera 9.22. Result: default font size 20px - AHAH! minimum font size 9px. I'm now going to make my dinner and won't be thinking about font sizes for the rest of the weekend :-) Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] setting fontsize in body
On Fri, August 3, 2007 11:36 am, Rick Lecoat wrote: At 10:13 (London time), on 3/8/07, [EMAIL PROTECTED] said: Client sent me this link, kind of suggesting that 62.5% is the better approach because his client isn't happy that now the heading texts are too small and the paragraph texts are too big due to the changes I made. http://www.clagnut.com/blog/348/ One thing I would point out about clagnut's method (which I've been using recently, actually, but I'm looking for a better option) is that the 62.5% sizing (applied to Body) is only meant to provide a handy '1em = 10 pixels' baseline to make your subsequent, em-based, resizing calculations easier. It is NOT intended to be the size that text is set at, because 10 pixels is way too small for most people to read easily unless they are teenagers with 20/20 vision. Note also that it doesn't actually work, as I've previously mentioned on the list: http://www.archivist.incutio.com/viewlist/css-discuss/74993 IE ignores fractional components of percentages - or, as another way of looking at it, only uses the first two decimal places of em based sizes - which means that any subsequent use of ems for sizing parts of the page won't work properly. (The demo I link to in the above post is still there, if anybody wants to look.) Also, Opera has a default font size of, I think, 12px, and treats attempts to go below that and then scale back up slightly differently than IE or Firefox in the same situation. I can't quite remember all the ins and outs of that one, but could try to dig out the work I did on it the other year if anybody's interested. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] setting fontsize in body
On 3 Aug 2007, at 16:08:55, Rick Lecoat wrote:
At 12:41 (London time), on 3/8/07, [EMAIL PROTECTED] said:
Note also that it doesn't actually work
.../ snip /
IE ignores fractional components of percentages - or, as another
way of
looking at it, only uses the first two decimal places of em based
sizes -
which means that any subsequent use of ems for sizing parts of the
page
won't work properly.
Very interesting Nick, I wasn't aware of the decimal place
limitation in
IE. Another negative point racked up against the Clagnut ems method,
which is a shame because I liked the simple and elegant idea behind
it.
Looks like I'm still on the hunt for the definitive font-sizing
technique then.
When dealing with this the other year, I came up with this solution
requiring an additional div, which happened to be there anyway:
body {
font-size: 125%; /* bump it up to 20px, assuming browser starts
at 16px */
}
div#wrapper {
font-size: 50%; /* and back down to 10px */
}
and took it from there :-)
(Still falls foul of a minimum font-size set in the browser
preferences, though.)
Cheers,
Nick.
--
Nick Fitzsimons
http://www.nickfitz.co.uk/
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] IE7 and iframes
On Thu, July 26, 2007 1:49 am, Michael MD wrote: I'm trying to fix some pages that use iframes that are broken in IE7 are there any good tips for fixing broken iframes-related javascript in IE7? This is NOT a cross-domain problem. One good tip: when you ask for help, you should tell people what the problem is, not what it isn't ;-) We're not psychic, and just saying broken in IE7 tells us precisely nothing about the nature of the problems you are encountering. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Using target=_blank
On Tue, July 24, 2007 6:19 pm, [EMAIL PROTECTED] wrote: Sorry but I don't agree...to a point. As a web designer and user myself, I prefer opening another window IF it is to a different website that I am referring them to. That way the customer doesn't go wondering thru the other website and forget to come back to mine. Mine will always be open in the background to remind them (kind of like I'm the one they came to the dance with). If yours is the site they want, they will come back by using the back button. If they are going somewhere else never to return, there's every likelihood it is because your site was not precisely what they were looking for. Be glad you were able to help by offering them a useful link, and leave them to go their own way. There has never been one scrap of research published demonstrating any usability or business benefit from opening links in a new window to stop users wandering away from our site. However there has been plenty of uasability research showing that many people find it irritating and/or confusing, and that it is a hindrance for those using assistive technologies such as screen readers, or those who have mild cognitive impairment (such as an absent-minded elderly person). If there is any published research demonstrating a justifiable business case for irritating, confusing and hindering your customers as they go about their day, I would be fascinated to see it. But consider how annoying it is to be followed about by a pushy salesperson, and ask yourself if you are right to believe that acting in such a manner towards your visitors is an acceptable thing to do. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Safari Web Inspector
Hi all, Just thought people here might like to know that the WebKit team have just announced their new Web Inspector in nightly builds of Safari for Mac Windows: http://webkit.org/blog/108/yet-another-one-more-thing-a-new-web- inspector/ Just had a play, and it looks like it offers most of the goodies we've come to expect from Firebug, although Drosera (the JS debugger bundled with nightly builds) still seems to make WebKit suck up a lot of processor cycles... Oh, and although nightly builds aren't as stable as the public beta, they will run side-by-side with your current installation, making testing for the future while browsing in the present much easier. (That doesn't apply to Windows, obviously, although I assume the nightly will co-exist with the beta - can't be bothered to open up Windows and test, though.) Enjoy! Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Triggering POSTs with links?
On 20 Jun 2007, at 17:37:59, Richard Ishida wrote: Hmm. On the other hand.. It works fine in Firefox, Opera, Safari (Win), but not in IE :(( Grr. Have you specified the type attribute with value submit? Although the spec states that this is the default, IE defaults to the value button instead. Specifying the attribute should get it working in IE. OT: really enjoyed your presentation at @media in London the other week :-) HTH, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari 2.0?!
On 19 Jun 2007, at 20:39:44, Paul Collins wrote: I downloaded the beta for Safari 3 the other day, it looks nice. Unfortunately, someone has pointed out a problem with a site I'm building and they are using version 2.0. I can't replicate the problem in the new version!! So after searching Evolt and a few other places, I can't find the original version now! They only have version 1 on offer. Does anyone know how I can get back to version 2 - the current version?! PS - on OS X, of course. The beta download comes with an uninstall package to roll you back to your previous version of Safari. It's on the Safari3Beta.dmg you originally installed from. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Back to the Future
On 14 Jun 2007, at 10:01:43, Chris Taylor wrote: Things are going to get even more interesting as I'm just about to install Windows 3.11 on a virtual machine to test this stuff *for real*. I have tissues ready and waiting in case I cry. If you plan on using JavaScript then you'll be delighted to hear that it has its own set of additional bugs (both crashing and just weird) in 16 bit Windows (3.x). You may find some of these old netscape.devs- javascript newsgroup posts useful: http://groups.google.com/group/netscape.devs-javascript/search? group=netscape.devs-javascriptq=16+bitqt_g=Search+this+group Good luck, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Re: Use of Fieldsets other than in form?
On 5 Jun 2007, at 04:19:38, Lucien Stals wrote: I in fact did quote the entire sentence. Yes, but you then dismissed the words controls and labels as being irrelevant. For a comparison, the w3schools site defines fieldset as The fieldset element draws a box around its containing elements. And that's the complete sentence. Note no mention of form controls. I leave it to others to debate the authority of the w3schools site, and it's a debate worth having. It has no authority whatsoever, and is generally an abysmal resource. I realise that many of the people here take pleasure in the pedantic application of standards, They probably pedantically drive on the correct side of the road and pedantically stop at red lights, too. But I am a pragmatic coder and if I wish to group thematically related elements (*not* necessarily form controls), then I'm free to use the fieldset if I wish to. But there's then little point in communicating this fact to a list about Web Stanbdards, as you are clearly advocating something which is in breach of said standards. Sure a DIV would work. But a DIV is void of semantic. It's the refuge of the unimaginative who want to wrap everything in excess tags with no semantic meaning just to hang CSS off. That's not what the spec says; it describes div as a generic mechanism for adding structure to a document. It then gives an example of using div (and span) to provide structure to thematically- related information whose elements' semantics are not explicitly identifiable by other HTML elements: http://www.w3.org/TR/html4/struct/global.html#edef-DIV To me, a fieldset is obviously the correct semantic here. What is obvious about using it in a way that directly contradicts the defined purpose of it? But the original question wasn't about drawing a box. It was about how to group any sort of related information together. And I say a fieldset would work. It's not the only solution, but it's a valid one. And not just valid by the DTD. It's only valid by the DTD in the sense that the DTD is incapable of expressing all the constraints imposed upon the usage of HTML elements; those constraints are made explicit in the spec by such means as the sentence you originally quoted. I think it's semantically valid as well. It's semantically meaningless as a fieldset is meant to contain a thematically related set of fields, not a thematically related set of arbitrary textual information. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] layout/font site test - please
On 5 Jun 2007, at 12:09:44, Designer wrote: so the decent browsers work properly (even IE7!) This is a common misconception. IE7 _cannot_ resize text whose size is specified in pixels, in precisely the same way that IE6 can't. The use of the page zoom tool will enlarge or shrink it along with the other content of the page, but using the menu options to adjust text size won't work. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Re: Use of Fieldsets other than in form?
On 5 Jun 2007, at 14:57:44, Barney Carroll wrote: Nick Fitzsimons wrote: But there's then little point in communicating this fact to a list about Web Stanbdards, as you are clearly advocating something which is in breach of said standards. Steady on, Nick. If he wasn't here you wouldn't be able to tell him this - it's exactly the right place for Lucien to be. Yes, my apologies to Lucien and the list - that does come across as rather snarky, which wasn't my intention. (I misspelled Standards as well...) Blame it on a zealot becoming so wrapped up in pedantic argument that he fails to properly consider whether his words correctly convey his semantic intent :-) Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] layout/font site test - please
On 5 Jun 2007, at 19:15:39, Designer wrote: Nick Fitzsimons wrote: This is a common misconception. IE7 _cannot_ resize text whose size is specified in pixels, in precisely the same way that IE6 can't. The use of the page zoom tool will enlarge or shrink it along with the other content of the page, but using the menu options to adjust text size won't work. Regards, Nick. Paul Novitski wrote few days ago, to point out a method which resizes the images as well as the text on page zoom. (using ems for the images). Good idea. So, I'm now curious as to why you think (infer) that IE's zoom (which does exactly that) won't replace text resizing? The only point I was making is that it is a fallacy to suggest that IE 7 treats text sized in pixels any differently to IE 6; they've just changed the effect of certain hotkeys to use the new zoom feature, but the menu's text size options will still have no effect. This means that a user who wishes to resize their text and automatically goes for the menu options will be out of luck with the specific example given. As the original poster seemed to believe that IE 7 would not have a problem with his pixel-sized text, I was just pointing out that it in fact would. To me, the zoom feature of IE7 (or firefox, or Opera) means that you can resize a page constructed in pixels without hurting anyone. Doesn't it? You can, and I can; but with the specific CSS on which I was commenting, a user who expected to be able to use the traditional menu options would be out of luck. Most users never explore new features; they tend to just do what they were taught by somebody else. I'm not arguing that IE (and others') zoom features are a bad thing - just pointing out that IE is still broken in its text sizing. Lots of people seem to think that the new feature fixes the old bug, but it doesn't. Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] dl v table for form layout
On 31 May 2007, at 05:28:57, Blake wrote: In a way I could almost take Katrina's thinking a little further wrap each fieldset in an li tag as part of an unordered list of fieldsets, and insert an additional fieldset into each exisiting li. Like so... Keep it up and you'll get your page size back up to nested table levels ;-) Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] dl v table for form layout
On 30 May 2007, at 14:16:11, John Faulds wrote: Sorry to bring this up again but I've been thinking a bit more about this: a fieldset should be used to group related form controls and each fieldset should have a legend, but what if you have a form control that's not really related to anything else? Do you put it in a fieldset by itself? Then what do you do about the legend when in a lot of cases it'll simply be duplicating what's in the label? A div would be my advice. The fact that there is no grouping of multiple elements implies that both fieldset and legend would be redundant. A surrounding div combined with the label for the control may be all that is required. If for some reason it did seem meaningful to have a legend-equivalent as well as a label, use a heading of an appropriate level. If there is additional text, paragraphs could also be used, although they wouldn't be available in a screen reader that was in Forms Mode. Perhaps a screen reader user could be expected to have already listened to the form before switching to Forms Mode to complete it; either way, concise labels should do the trick. So, for example: fieldset legendGender/legend labelinput type=radio name=gender value=femaleFemale/ label labelinput type=radio name=gender value=maleMale/label labelinput type=radio name=gender value=otherOther/label /fieldset div h3Information you don't want/h3 p We would like to spam you mercilessly with information about stuff you don't care about. If you prefer not to receive such communications, please check the box below. /p labelinput type=checkbox name=spam value=Avaunt! ye knavesNo spam, please/label /div For the visually-obsessed, CSS could then be used to style the div and associated heading to match the neighbouring fieldsets. Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] need help with tabular interface
On 29 May 2007, at 02:10:02, Sander Aarts wrote: I'm glad the designers I work with know that rounded corners can be a real pain in the ass, so they always ask before implementing them in the design. I want your designers! ;-) -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] OT on list
On 29 May 2007, at 15:58:53, Stuart Foulstone wrote: Assistive technology off topic??? Photoshop and JAWS: sorry, Marvin, but that's just OT for this list. Can we get back to the on topic issues of Web Standards, perchance? Use of assistive technology with desktop applications doesn't really have anything to do with Web Standards, surely? Remember, screen readers aren't web browsers... Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: self-closing tags in HTML, was: [WSG] A CMS for POSH sites?
On 29 May 2007, at 16:14:53, Alastair Campbell wrote: On 5/29/07, David Dorward [EMAIL PROTECTED] wrote: Because, in an HTML document, an XHTML style img tag unambiguously means An image element followed by a greater than sign. I still can't see where it says that in the spec, do you need to know the SGML spec as well? Yes, HTML is an SGML application, as described in the spec: http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.1 Therefore a compliant parser must parse according to the rules of SGML. The spec does include an appendix: http://www.w3.org/TR/html4/appendix/notes.html#sgmlfeatures listing aspects of SGML that are poorly supported by existing user agents; however, that doesn't excuse or justify improper behaviour by parsers, and the entire appendix is informative, not normative. The specific SGML SHORTTAG construct under discusssion in this thread is included in the appendix at http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.7 Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] OT on list
On 29 May 2007, at 16:20:28, Barney Carroll wrote: It's worth making the point: Don't get intimidated by this - JAWS is a perfectly legitimate thing to discuss here. Only in connection with its use in conjunction with a web browser. Would you argue that a discussion of the use of Jaws with Microsoft Excel (which is, judging by the manufacturer's FAQs, one of its commonest uses) is related to Web Standards? Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: self-closing tags in HTML, was: [WSG] A CMS for POSH sites?
On 29 May 2007, at 17:32:08, Alastair Campbell wrote: It seems strange that the closing slash is taken as the close, rather than the greater than sign, is that in the HTML spec somewhere? Yes, in the SGML declaration. Which someone linked to earlier, and I still can't translate to see anything on forward slashes... is there actually an SGML spec? You'd have thought it would be linked to from here: http://www.w3.org/TR/html4/intro/sgmltut.html or googlable with SGML spec, but no such luck. The SGML spec is ISO 8879:1986, but being ISO, they charge a fortune for you to see it :-( The topic under discussion is, as I mentioned in my earlier post, mentioned in HTML 4.01 at http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.7 as being something with poor support in HTML user agents. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] address semantics
On 28 May 2007, at 11:34:52, Designer wrote: I want to put an address on a site, but I'm put off by the limitations of the address tag. (but attracted to the semantic value). address doesn't have the semantic value you think it has. From HTML 4.01: The ADDRESS element may be used by authors to supply contact information for a document or a major part of a document such as a form. http://www.w3.org/TR/html4/struct/global.html#edef-ADDRESS It's expressed even more succinctly in the table of elements: ADDRESS: information on author http://www.w3.org/TR/html4/index/elements.html So address should be used for providing contact information such as an email address or a link relating to the creator or owner of a document or part thereof, but not just for any old postal address that happens to appear on a web site. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] The use of asterisks in forms to indicate required fields
On 28 May 2007, at 03:42:55, Terrence Wood wrote: Then, Thierry Koblentz wrote: Some clients do not want this at all, they think it pollutes the visual. That's the trouble with this job: clients who won't listen to professional advice. It makes me wonder what they think they're paying for in the first place :-) I wonder how they treat their dentists... Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] The use of asterisks in forms to indicate required fields
On 26 May 2007, at 06:42:08, Thierry Koblentz wrote: Yes, the second title attribute is missing because of a post of yours in the thread Acronym tag usage :) :-) I think however that, if you adopt this approach, this may be one of those cases where it might make sense to expand the abbreviation on every occurrence. (As the number of qualifying modifiers in that sentence probably reveals, I'm not sure.) Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] semantic HTML for intro text
On 26 May 2007, at 18:04:38, Designer wrote: Presumably, p title=introduction and p id=introduction would do the trick also? Using the title attribute means pointing-device-users would get a tooltip saying introduction obscuring the text if they happened to have the cursor hovering over that region. Not good usability, IMHO. I occasionally come across sites that make extensive use of title, and 99 times out of 100 it's more of an impediment than a help. Even the supposed accessibility advantages are open to question: http://juicystudio.com/article/using-title-attribute.php I'd still vote for using a class, or an id if you can be certain it will only appear once a page. If the visual distinction in the required design actually does represent a semantically meaningful distinction between that paragraph and the others, rather than just being window dressing, then a pem... would probably be justifiable; I don't think that going all the way to strong is necessary. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] screen readers repeated legends (was dl v table for form layout)
On 25 May 2007, at 01:08:49, Rebecca Cox wrote: On 5/23/07, Nick Fitzsimons [EMAIL PROTECTED] wrote: As an aside, note that screen readers will read the legend of a fieldset before the label of every element in the fieldset, so legends should be kept short and sweet This is interesting, just wondered if you had any other info about this, which screen readers in particular and how customisable is this behaviour to a user (eg is there an option to disable the repetition of this info). Cheers Rebecca Hi, I got this from Ann McMeekin's presentation Accessibility: what not to do at the WSG London meetup back in February http:// muffinresearch.co.uk/wsg/280207.php. There's a podcast available at: http://muffinresearch.co.uk/wsg/audio/07/02/28/ann.mp3 I don't have an exhaustive knowledge of screen readers, but what I've gathered from listening to those who do is that: a) They tend to be highly configurable; b) 99.9% of users never change from the default settings. Maybe somebody with more experience in this area can chip in with more detailed info? Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] semantic HTML for intro text
On 25 May 2007, at 18:03:06, Paul Collins wrote: Hi all, Just marking up a page, the layout seems to require various tags, as far as I can gather, I need seperate tags for: - The intro heading (a H2) - The orange intro text (not sure what tag to add here) - a smaller, bold heading, same size as body text (probably a h3) - a quote (probably a blockquote tag) My question is, what would be the best semantic tags to use here, that will be picked up by assistive technology and validate for XHTML 1.0 Transitional. In particular, I want to know about the Orange intro text and the quote. Any suggestions would be great, I have posted a JPEG here: http://www.method.com.au/storage/sampleText.gif Assuming the page on which this will appear already has an h1: h2.../h2 p class=introduction.../p h3...h3 p.../p blockquotep.../p/blockquote p.../p and then apply things like the different font sizes weights, colours and spacing with CSS. If there will only ever be one introductory paragraph per page, then you could use p id=introduction instead. HTH, Nick, -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Jaws 8 MP3s - was Re: [WSG] dl v table for form layout
Hi all, To help with the whole forms/fieldsets/accessibility debate, here's some links to a couple of (edited) MP3 files of Jaws 8 reading Mike Cherim's accessible form example: http://green-beast.com/gbcf/ Virtual cursor mode: http://www.nickfitz.co.uk/tests/accessibility/audio/Jaws%208/Jaws- AccessibleForm-VirtualCursor.mp3 Forms mode: http://www.nickfitz.co.uk/tests/accessibility/audio/Jaws%208/Jaws- AccessibleForm-FormsMode.mp3 On 25 May 2007, at 20:09:03, Mike at Green-Beast.com wrote: I must say, forms mode was a LOT better. It *seems* that my claim of it being an accessible form is indeed true unless you heard something that I didn't. It seemed OK to me, although I'm not a screen reader user, just experimenting. I was mainly interested in testing what happened when there were nested fieldsets, and it seems that only the innermost fieldset's legend is spoken before a form control's label, so nested fieldsets aren't a problem for this one screen reader, at least. I will say this: My goodness it's fast reading. I had a hard time with comprehension due to the speed, but maybe that's adjustable and you turned it up a bit (?). Plus I'm not practiced in this sort of browsing. It is adjustable, but I haven't changed any of the default settings except for switching to the supposedly English accent from the default (American) one. From what I've been told, many experienced screen reader users set the voice much faster than the default - it's about the only setting people do change. Note that, in forms mode, I was just tabbing to the next field once the voice had said its piece, and edited out a couple of pauses where I got distracted by something on the telly :-) Thanks for going through the trouble of making these. Curious, will these be permanently available? If not, may I get copies of the recordings from you to post (with credit given of course). I'll post the links right on that page for the world to hear. I've got no plans to remove them, and will hopefully find time over the weekend to set up a page on my site linking to them. You're welcome to download them and host copies on your own site, as is anybody else who wants to. Anything to save my bandwidth :-) Cheers, Nick. - Original Message - From: Nick Fitzsimons [EMAIL PROTECTED] To: Mike at Green-Beast.com [EMAIL PROTECTED] Sent: Friday, May 25, 2007 2:48 PM Subject: Re: [WSG] dl v table for form layout On 24 May 2007, at 22:01:52, Mike at Green-Beast.com wrote: See a real (somewhat styled) example: http://green-beast.com/gbcf/ (Demo Form) Mike, I've taken the liberty of accessing your demo page using Jaws 8 with MSIE 6, first in virtual cursor mode, then in forms mode. I've then edited the audio down into two MP3 files, one for each mode. Are you OK with me posting these online, as I think they could be useful for people wanting to learn how screen readers handle forms (well, one screen reader)? If that's OK with you I'll post the links to the WSG list; apart from anything else I think many people will be rather surprised by the way the legend element is handled in forms mode :-) If you want a listen they're at: http://www.nickfitz.co.uk/tests/accessibility/audio/Jaws%208/Jaws- AccessibleForm-VirtualCursor.mp3 http://www.nickfitz.co.uk/tests/accessibility/audio/Jaws%208/Jaws- AccessibleForm-FormsMode.mp3 Cheers, Nick. - Nick Fitzsimons http://www.nickfitz.co.uk/ -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] The use of asterisks in forms to indicate required fields
On 26 May 2007, at 05:05:33, Thierry Koblentz wrote: What about marking up * used in forms with ABBR elements? pPlease fill fields marked with * (required field)./p label for=nameabbr title=required field*/abbr Name: ? php echo error(); ? input type=text id=name name=name value= / /label label for=emailabbr*/abbr Email: ?php echo error(); ? input type=text id=email name=email value= / /label It makes sense to me, assuming that the second abbr (the one for the email field) is missing a title attribute, and ought to be the same as the first one. (transposed from original position:) I saw Dan Cederholm's presentation at the @media conference in San Francisco yesterday. Have you asked Dan about it? He doesn't bite, as far as I've seen :-) Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Mocking up web interfaces
On 24 May 2007, at 00:22:42, Douglas Reith wrote: Hi there, Just a quick one - what do people most commonly mock up web site designs in? (Photoshop?) Also, if possible, Linux and GPL or similar would be great!! Cheers, Doug Being Just a Coder, my usual workflow is: 1. Receive Photoshop files created by client's graphic designer, who has no knowledge of web technologies, no understanding of usability, no interest in accessibility, and thinks everything is the same as print media; 2. Tear my hair out whilst ranting and raving about the ignorance and incompetence of these people; 3. Decide that I'm not going to be beaten by these b4st4rd5; 4. Rack my brains for days or weeks working out how to achieve the impossible; 5. Achieve the impossible; 6. Realise that I've learnt or invented a whole load of useful CSS and HTML techniques; 7. GOTO 1. Step 2 had to be toned down considerably when I was working in a studio with the designers, including the owner of the company, but generally this process has worked well for me for several years :-) Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Photo gallery markup semantics
On 22 May 2007, at 15:35:34, Jason Robb wrote: The main reason I even considered a table is because the anchors leave an empty space between the images. I've set up a test page here: http://bws.jasonrobb.com/content/ image-test.html What do you think is causing that extra space? How can I avoid/ remove it? Both anchors and images are inline elements, so the whitespace in your markup is regarded as a significant space. If you set the anchors to have display:block and float:left then the gap will disappear. You'll then want a clear:left on the div containing the second row. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] dl v table for form layout
On 22 May 2007, at 20:40:41, Mike at Green-Beast.com wrote: Steve Green wrote: No, a form is not a list of form controls [...] I agree. A form is not a list, nor is it tabular data. I know this was originally a demonstration to show the lesser of two evils, but evil is evil so less wrong still isn't right. What I don't understand is why there is this exploration of form layout structures to begin with when a form in of itself is it's own form layout structure. All the needed tools already exist. Why is a div needed, for instance, when the fieldset is already a container -- the proper container I might add -- for these form controls. While I agree that use of lists, tables or definition lists is mere abuse, a fieldset is for grouping thematically related controls and labels: http://www.w3.org/TR/html4/interact/forms.html#edef-FIELDSET So for example, the fields for forename and surname could be grouped together with a fieldset, but a separate fieldset should be used for those fields related to billing address, delivery address and so forth. Just bundling the entire contents of the form inside a fieldset because it stops the validator whining about the need for a block-level element is itself an abuse of the fieldset element. Consider a form that asks for name, address, sex and then has an additional requirements textarea. While the elements of each of the first three sections could usefully be grouped together with three separate fieldsets, the final textarea isn't in a group of elements; it stands alone, and the use of an element that defines a grouping of related items becomes meaningless. However the spec requires that it be enclosed in a block-level element, and this is when a semantically- neutral div would be useful. Oh, and what about the submit button - that needs to be wrapped in something block-level too, but for most forms is not part of a group of elements; a div is again perfectly appropriate here. As an aside, note that screen readers will read the legend of a fieldset before the label of every element in the fieldset, so legends should be kept short and sweet - for example the following HTML: fieldset legendHow did you hear about my donkey and its strange fate?/ legend label for=heardWebinput name=heard id=heardWeb type=radioOn the web/label label for=heardTvinput name=heard id=heardTv type=radioOn the TV/label label for=heardRadioinput name=heard id=heardRadio type=radioOn the radio/label label for=heardPaperinput name=heard id=heardPaper type=radioIn the newspaper/label label for=heardOtherinput name=heard id=heardOther type=radioOther/label /fieldset would be presented to a screen reader user as How did you hear about my donkey and its strange fate? On the web How did you hear about my donkey and its strange fate? On the TV How did you hear about my donkey and its strange fate? On the radio How did you hear about my donkey and its strange fate? In the newspaper How did you hear about my donkey and its strange fate? Other which is a lot of times to be asked the same question; so make your legend text as succinct as possible, yet still meaningful when it is used as a prefix in this manner. If a section of the form, properly enclosed in a fieldset, needs a chunk of explanatory text, then find something brief and meaningful for the legend - or even leave the legend empty - and present the explanatory text in a paragraph. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Photo gallery markup semantics
On 22 May 2007, at 22:32:06, John Faulds wrote: I don't really see the relationship between those thumbnails but your correct choice here is an ordered list, not a table. The thumbnail in the bottom right corner doesn't have any direct relationship with the thumbnail in the top right corner (which it would if it were tabular data), it only has a relationship with what comes before and what comes after, i.e. in the 'ordering' of the photos. Does it even have that relationship? Does it matter to anybody other than some twonk from merchandising whether the blue sweater comes before the red dress? If a list is to be used (and I don't disagree with the use of a list in this case) then it seems to me that an unordered list should be sufficient - unless the aforementioned twonk insists that it's *really* important that yellow clothes come before green ones. Although it might be important from an accessibility perspective that an unsighted user be able to say the third one on that page without having to count the preceding list items - hmm, now that's something to think about.. Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Photo gallery markup semantics
On 23 May 2007, at 02:15:30, Patrick H. Lauke wrote: Nick Fitzsimons wrote: Although it might be important from an accessibility perspective that an unsighted user be able to say the third one on that page without having to count the preceding list items - hmm, now that's something to think about.. Not quite sure how they'd say the third one without actually having counted, though...am I missing something? Or do you mean in situations where a sighted user and a blind user discuss the page? If that's the concern, then *any* CSS that visually changes position of things on screen would be a problem (just thinking about sighted users saying the X that comes before Y not realising that X was absolutely positioned above Y, for instance)...which I'd say is an edge case anyway. I'm assuming here that a screen reader imparts the additional information implied by the distinction between ol and ul, such as specifying Three rather than Bullet. I haven't checked, but I believe that is the case from previous tests. From that perspective, I was thinking in terms of the situation where a blind user, having heard the description of something they like, might find it easier to phone the company to place an order. If the screen reader said something like List item: Three: blue sweater instead of List item: Bullet: blue sweater, then rather than the user having to count and remember that the blue one was the third item description they heard on that page, they would be able to tell the person taking the order that the thing they want is the third one on the sweaters page. Sometimes people's interaction with web sites can lead to interaction with the rest of reality :-) It seems to me possible that the use of an ordered, as opposed to an unordered, list might offer an additional affordance to a blind user. Of course, that's just speculation on my part - but it could be something worth checking out in user testing. The next problem then arises when the oh-so-clever designer has abused CSS to make the seventh item appear in third place. I seem to recall a blind friend of mine bitching and whining (with excellent reason) about some similar usability nightmare in the past... something to do with being asked if he meant the one on the right or the left of the third row. It was impossible for him to determine what came from which row, or on what side it appeared, because the person on the phone saw the page with some too-clever-by-half CSS applied, and he just had SuperNova. FWIW, that's a good reason not to hide the numbers on an ordered list just to make things look nice. (And if anybody was wondering, blind people do have preferences in the colours they wear.) Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Photo gallery markup semantics
On 23 May 2007, at 02:19:42, John Faulds wrote: Does it even have that relationship? Does it matter to anybody other than some twonk from merchandising whether the blue sweater comes before the red dress? If a list is to be used (and I don't disagree with the use of a list in this case) then it seems to me that an unordered list should be sufficient - unless the aforementioned twonk insists that it's *really* important that yellow clothes come before green ones. As I said, I couldn't say for certain what the relationship might be, but my guess with the example given, as it's a photo gallery site, would be that the photographer/artist feels like the photos should be in a certain sequence, perhaps to facilitate the telling of a story through images. That's only a theory without any back-up info from the original poster, but I think illustrates that there could be occasions when adding an order to images might be important. I think I agree, as a result of certain ponderings on the context of this particular gallery being that of a fashion collection, and therefore having a pretty close relationship to the idea of presenting goods for sale. I've written about it more in my reply to Patrick Lauke, and I'm beginning to think that the accessibility aspect could be quite important here. Then again, I'm up very late :-) Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Site Check - Streaming Media
On 22 May 2007, at 02:31:29, Parker, Simi ((DPS)) wrote: Hi everyone I am investigating some potential issues with our live broadcasting service and if you use an O/S / browser / media player configuration other than Windows / Internet Explorer / Windows Media player, I would really appreciate your feedback and/or assistance. I would particularly welcome feedback from Macintosh and Linux users. The live broadcasting service is streamed from: http:// webcast.aph.gov.au/livebroadcasting/ The House is sitting for the next fortnight so there should be something for you to have a look at. I would like to know if you are able to see or not see the media being streamed and the configuration of software you are using eg: Mac OX, Safari and QuickTime. Hi Simi, Am I right in believing that this content is being streamed in Microsoft's proprietary WMV format? (No, I'm not going to go off on a rant about using proprietary technologies for information that should be freely available to all - well, not this time :-) Anyway, I'm using Mac OS X 10.4.9 (the latest version, fully updated) on an Intel MacBook, and I've installed Flip4Mac, as suggested on Microsoft's own site: http://www.microsoft.com/mac/otherproducts/otherproducts.aspx? pid=windowsmedia Flip4Mac has one major advantage over Microsoft's own Windows Media Player for Mac: it actually plays Windows Media content, which Windows Media Player for Mac has never managed to do so much as once, either on this machine or on my old-but-good PowerMac G4. I've checked using Safari 2.0.4 (419.3) and Firefox 1.5.0.11, both with full popup blocking configured (the browser's own, not any extensions). Both of them successfully opened up the media window when I clicked the Accept button on the Conditions of Access page, initialised the Flip4Mac plugin, and played the content (which, being the proceedings of some standing committee or other, was unremittingly tedious :-) Note that I haven't tested this on the PowerMac (non-Intel processor) - I reformatted that a while ago, and don't install fripperies like media players on it now as I use it as a development server. However, I seem to recall successfully using Flip4Mac there too some time in the past. Maybe others can give more detailed feedback on using it on PowerPC architectures. So if you need to suggest options to Mac users for ways to view the content, you should probably recommend installing Flip4Mac - or maybe give them the Microsoft link above, as recommending specific software appears to be regarded with fear and loathing by governmental bodies fearful of lawsuits (although they don't appear to have the same worries over recommending dangerous rubbish like Microsoft's browser for Windows...) Hope this helps, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Hack for all IE versions including 7
On 19 May 2007, at 05:05:14, Thierry Koblentz wrote: On Behalf Of Jermayn Parker This is what I find very useful and explained very simply: http://www.solidstategroup.com/page/1592 FWIW, I'd question #6 and #7 And I'd question 4, as it creates accessibility problems for users who don't use a pointing device. Also, the statement that the outline appears when you click is wrong: it appears when the link is focused. Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari for Linux
On 18 May 2007, at 13:13:32, Mordechai Peller wrote: On a related note, in KDE4, Konqueror I've read that they'll either be moving from KHTML to Webcore or offering either or both as options. Does anybody have anymore info on this? Currently, KHTML is probably better than Webcore in terms of CSS support; will this be a step back for Konqueror or a step forward for Safari? It depends on which version of WebCore they're planning to use. If, by the time they make the switch, there is a stable version including the enormous number of bug fixes and CSS enhancements that are currently only available in the nightly builds, then it will be a great step forward for both Konqueror and Safari. I really wish we didn't have to wait for Leopard before getting a stable version of Safari containing all the good stuff that's been fixed and added :-( Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] ive given up on css
On 16 May 2007, at 12:49:46, Robert O'Rourke wrote: Here's a link to put a smile on your face anyway, old school web design studio at it's best: http://www.wizwebz.co.uk ... (I kinda like it for some inexplicable reason) Ouch! Of course, you can implement a design from the classic web school in a standards-compliant way: http://csszengarden.com/?cssfile=http://www.brucelawson.co.uk/zen/ sample.css Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Acronym tag usage
On 12 May 2007, at 18:11:51, David Hucklesby wrote: If the OED says it, I'll buy it. Thanks, Nick! But be aware that common U.S. practice employs acronym for initialisms[1]. I must agree with the Yanks that inititalism does not roll easily off the tongue! [1] http://www.m-w.com/cgi-bin/dictionary?book=Dictionaryva=acronym Cordially, David Well, that's what happens when people don't follow the standard :-) -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Help needed
On 11 May 2007, at 05:52:58, John Faulds wrote:
You really only need a dimension on the anchors to overcome an IE/
Windows bug when they're set to display: block so you can either
use * html #nav a { height: 1% } or conditional comments. You can
probably ignore my other comment about the hasLayout issue because
I assumed it was an IE problem, but it's not.
If you want to triger hasLayout and you don't have to worry about IE
5.x, you're better off using zoom: 1; rather than mucking about
setting dimensions that IE will just ignore and then having to use
hacks to hide them from other browsers (including IE 7).
Regards,
Nick.
--
Nick Fitzsimons
http://www.nickfitz.co.uk/
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Acronym tag usage
On 11 May 2007, at 10:55:14, Mike at Green-Beast.com wrote: Of course I cannot effectively support this by looking it up on the web because the lines on this have been blurred significantly over time so the dictionaries are of little help. The OED seems pretty clear on the issue: abbreviation, noun: a shortened form of a word or phrase http://www.askoxford.com/concise_oed/abbreviation acronym, noun: a word formed from the initial letters of other words (e.g. laser, Aids) http://www.askoxford.com/concise_oed/acronym initialism, noun: an abbreviation consisting of initial letters pronounced separately (e.g. BBC) http://www.askoxford.com/concise_oed/initialism Note that, according to these definitions, an acronym is not considered to be an abbreviation at all - it is considered to be a word in its own right, which justifies the existence of the two separate tags. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Acronym tag usage
On 11 May 2007, at 09:56:54, [EMAIL PROTECTED] wrote: I'm not 100% sure this is the case, but what a screen reader _should_ do is to _read_ an acronym and to _spell out_ an abreviation. Even if that is not yet the case, it seems likely in the future, assuming that we all use the correct elements in the first place... Regards, Mike PS 'Initialism' isn't a tag - with good reason; it isn't even a proper english word! I don't see that this should be the case. For example, Ltd is a common UK abbreviation for the word Limited in the context of a Limited Liability Company, such as HyperGlobalMegaCorp Ltd. Another example would be Mr, which is an abbreviation of Mister. There are plenty more examples - in French, Mlle is an abbreviation of Mademoiselle. None of those should be spelled out, yet they are all abbreviations. Oh, and initialism is in the Oxford English Dictionary, which is generally regarded as the canonical source: http://www.askoxford.com/concise_oed/initialism Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Acronym tag usage
On 11 May 2007, at 13:10:28, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I don't see that this should be the case. For example, Ltd is a common UK abbreviation for the word Limited in the context of a Limited Liability Company, such as HyperGlobalMegaCorp Ltd. Another example would be Mr, which is an abbreviation of Mister. There are plenty more examples - in French, Mlle is an abbreviation of Mademoiselle. How would you expect a screen reader to speak these groups of characters? (Regardless of what tag they appear in.) I would certainly not expect an English-language based reader to keep a list of abreviations of all other foreign languages, so while a sighted user _may_ recognise Mlle and speak it out loud (I wouldn't - never learnt any French at school, fortunatly) it seems a very long leap for a screen reader. Regards, Mike Tricky one :-) I'm not sure whether screen readers have dictionaries of common abbreviations, although it appears that sometimes, even if they did, the Microsoft APIs would muck things up for them: http://www.freedomscientific.com/fs_support/BulletinView.cfm?QC=511 but, as that article shows, they - or at least Jaws, and I believe SuperNova - do allow for custom dictionaries; maybe a community effort could compile useful collections of such abbreviations for users to download. As far as the case of something like Mlle. is concerned, I would expect to mark it up as follows: abbr lang=fr title=MademoiselleMlle./abbr and I think one could argue (contrary to my earlier assertion) that, in this kind of case, the abbreviation should be marked up using abbr for every occurrence, as that would hopefully allow screen reader users a seamless listening experience. Once again, it looks like there are no hard and fast rules about how to handle these matters. Ah well, having to think about it is what makes it fun :-) Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Acronym tag usage
On 10 May 2007, at 15:46:42, [EMAIL PROTECTED] wrote: Since most web pages are skimmed rather than being read in a traditional, linear fashion, it makes sense to use the full tag and attributes on every occasion. The traditional, print-based method was to only expand the abbreviation/acronym on first use, to save space, but this does not apply to an attribute applied to a web page tag, which takes up zero visible space. On the other hand, screen-readers are generally configured by default to always read out the expansion of text marked up as an abbreviation (that is, the contents of the title attribute), so using abbr (or the non-standard acronym) repeatedly will force users of such assistive technologies to listen to the full version on every occurrence in the page. From what I've heard, this gets irritating pretty quickly, and could be seen as diminishing the accessibility of the page. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Acronym tag usage
On 10 May 2007, at 16:10:55, Nick Fitzsimons wrote: On the other hand, screen-readers are generally configured by default to always read out the expansion of text marked up as an abbreviation (that is, the contents of the title attribute), so using abbr (or the non-standard acronym) repeatedly will force users of such assistive technologies to listen to the full version on every occurrence in the page. From what I've heard, this gets irritating pretty quickly, and could be seen as diminishing the accessibility of the page. Apologies, when I said non-standard acronym, I really meant something to the effect of supported on IE 6, which abbr isn't. Not sure how my fingers twisted what my brain was saying - maybe I just think non-standard every time I think of IE ;-) Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Acronym tag usage
On 10 May 2007, at 16:08:49, russ - maxdesign wrote: Initialisms are subsets of abbreviations. So theoretically this should be marked up using the abbr element: abbr title= Metropolitan Statistical AreaM.S.A./abbr The problem is that the abbr is poorly supported by IE5 and IE6. This means you may have to (1) revert to using the acronym element, or (2) place a span inside your abbr element and style this instead or (3) use JavaScript: http://annevankesteren.nl/2003/08/improved-styling-abbr-in-ie If using JS is acceptable (and it will only exclude a tiny proportion of visitors to most sites), then you can force IE 6 (and probably 5.x) to correctly parse abbr such that it can be styled (there's no default styling) by executing the following line of code before the page is parsed - that is, either using inline script in the head, or an external script file containing this line: document.createElement(abbr); This causes IE to correctly make the contained text a child of the abbr element, and omit the creation of a DOM node called /abbr - I described this bug some time ago at http://www.nickfitz.co.uk/2005/05/17/obscure-internet-explorer- bugs-1-of-who-knows/. It seems as if the use of createElement makes IE assume that it had better act as if it understands the name of the created element, even though it doesn't. This is why the line of code must be executed before the abbr is parsed - in fact, I have a test case demonstrating that if the JS comes between two paragraphs each containing an abbr then the first will be incorrectly parsed and the second correctly parsed (in the sense of creating a valid DOM construct). I gave a presentation about this at BarCampLondon2, but haven't yet got around to blogging it - I'll get it written up over the weekend and post a link back here, to give those interested a fuller understanding of what appears to be going on in the bowels of the browser. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Acronym tag usage
On 10 May 2007, at 16:55:01, Thierry Koblentz wrote: From: Nick Fitzsimons On the other hand, screen-readers are generally configured by default to always read out the expansion of text marked up as an abbreviation (that is, the contents of the title attribute), so using abbr (or the non-standard acronym) repeatedly will force users of such assistive technologies to listen to the full version on every occurrence in the page. From what I've heard, this gets irritating pretty quickly, and could be seen as diminishing the accessibility of the page. Then I think it is a screen-reader issue as I believe there is no point to have this as default setting since documents are supposed to contain the expansion in plain text already... That's not what WCAG says: Specify the expansion of each abbreviation or acronym in a document where it first occurs. [Priority 3] http://www.w3.org/TR/WCAG10-TECHS/#tech-expand-abbr ... is followed by HTML Techniques: Acronyms and abbreviations which links to http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-abbr which says 'Checkpoints in this section: 4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs. [Priority 3] Mark up abbreviations and acronyms with ABBR and ACRONYM and use title to indicate the expansion' So the checkpoint is stating the the abbr or acronym element should be used for this purpose, _not_ that the abbreviation or acronym should be expanded _in_the_text_of_the_page_ (although that isn't necessarily a bad thing, even if it means a screen-reader user will hear the expansion twice - that's still better than hearing it every time it's used). Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] W3C validator bug?
Hi, Since I made a post whose title included double-quotes on my WordPress-powered site, the W3C's validator has been whining at me: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.nickfitz.co.uk%2F because the page now contains double-quote-delimited title attributes whose value, from the validator's point of view, includes double-quotes. However, the actual source contains the relevant numeric character references (#8220; and #8221;), not the quote characters themselves. From my reading of the relevant part of the spec: http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2 the words Authors may also use numeric character references to represent double quotes suggest that the validator is wrong to treat the quotes in the title attributes as quotes - it could be said to have parsed them too early, if you will. Does anybody agree that this is a bug in the validator (in which case I'll file a bug report), or am I missing something? Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] W3C validator bug?
On 2 May 2007, at 20:33:20, Kepler Gelotte wrote: However, the actual source contains the relevant numeric character references (#8220; and #8221;), not the quote characters themselves. Hi Nick, I think you are looking in the wrong place in your HTML source. You are correct that the double quote is an entity in the title, but the validator is saying the error occurred on line 137 which is the link to the comments section. The source there is: ... | a href=http://www.nickfitz.co.uk/2007/02/14/why-left-px-is- better-for-acc essibility-than-display-none/#comments title=Comment on Why left: -px; is Better For Accessibility Than display: none;12 Comments #187;/a/p There you can see the double quote is no longer an entity. The error seems to be in your version of Wordpress and not the validator. DOH! Yup, I was indeed looking in the wrong place and a hunt through the WP code shows that the post metadata displays the post title without passing it through the apply-filters() function. Thanks, Kepler; everybody else, sorry for the wild goose chase. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Windows Vista Style Buttons
On 29 Apr 2007, at 16:14:41, Sagnik Dey wrote: But a background image can't adjust to a varied length of Text :) But with a little bit of magic... http://www.alistapart.com/articles/slidingdoors/ http://www.alistapart.com/articles/slidingdoors2/ :-) HTH, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Valid and well-formed
On 27 Apr 2007, at 08:41:53, Katrina wrote: David Hammond suggests that validity is not well-formedness, in that a document can be well-formed and not valid, but could also be !!! valid and not well-formed. http://www.webdevout.net/articles/validity-and-well- formedness#validity_well_formedness It was my understanding that valid were a subset of well-formed documents, and therefore, by its very nature, valid documents were well-formed. I believe this is supported by the documentation from the W3C: http://www.w3.org/TR/REC-xml/#sec-documents suggest that in addition, the XML document is valid if it meets certain further constraints. That suggests to me that conformation to a specification is in addition to well-formed-ness, in order to be valid. snip Is David Hammond correct? Or is he relying on some errors of the validator to justify his arguments? It does seem to me that he is merely relying on the validator to say what's right, but as the validator results page says, Note: The Validator XML support has some limitations. The last two words of that sentence are a link to http:// openjade.sourceforge.net/doc/xml.htm which (among other things) states that a number of XML constraints are not enforced by the parser. In particular, it says that OpenSP does not enforce XML's rules on not continuing normal processing after an error, and I believe all DH has found is that this means that certain well- formedness errors will not be flagged by the validator. He says that they are perfectly valid from an SGML point of view but not well-formed. I think he believes that the validator only uses an SGML parser, but it will use an XML parser when appropriate (XHTML served with the correct MIME type). The claim of validity he makes is based on the assumption that the SGML parser has been used, but in fact an XML parser which fails to enforce all XML well-formedness constraints has been used. So, IMHO, you are correct to believe that the claim that a document can be valid but not well-formed is based on a misunderstanding of the type of parser used by the validator, and the limitations of that parser. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Disappearing positioned footer in IE7 - works in IE6
On 24 Apr 2007, at 13:07:42, al morris wrote: IE 7 now supports the *html hack, so the 'position: relative' style is being applied. IE7 doesn't support * html: http://blogs.msdn.com/ie/archive/2005/09/02/460115.aspx Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] handling accessible form
On 22 Apr 2007, at 01:07:15, Shaun wrote: My colleague came up with the idea of naming form elements in a certain way so we could determine what server side validation to use e.g. input name='firstname:test:required' etc.. would be a required text input of name firstname. However I think this would not make for a good label for attribute (for accessibility) 1. I assume I am right that for attributes on labels get read by screen readers and messing these up would be wrong The for attribute has the value of the id attribute of the associated control, not the name attribute. Despite Internet Explorer's inexplicable belief to the contrary, id and name are not the same thing. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] handling accessible form
On 22 Apr 2007, at 16:28:16, Patrick H. Lauke wrote: Nick Fitzsimons wrote: Despite Internet Explorer's inexplicable belief to the contrary, id and name are not the same thing. Care to elaborate on what the issues in IE are? Using getElementById(someValue) on IE will return an element that has a name attribute equal to someValue. If, for example, you have: input name=fred p id=fredBlah/p then document.getElementById(fred) will return the input, not the paragraph. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] input name and id
On 19 Apr 2007, at 12:03:22, liorean wrote: On 16/04/07, Nick Fitzsimons [EMAIL PROTECTED] wrote: Name and ID serve two different purposes. ID is used to identify the element's node in the document [1]. Name is used to identify the element's value in the form submission posted back to the server [2]. OTOH, according to the HTML 4.01 Strict DTD, name is #IMPLIED, not #REQUIRED, so the book is incorrect. [3] The book is correct. It's a question of HTML having rules that DTD can't represent. In this case, that input elements can be form controls or form functionality (i.e. type attribute has a value of submit or reset). The name attribute is required on form controls but not on form functionality. The DTD format doesn't allow this type of granularity however. A DTD is perfectly capable of specifying that an attribute is required: it uses the syntax #REQUIRED. The spec for the name attribute of the input element states that it is #IMPLIED, not #REQUIRED, therefore it is not correct to say that the name is required. The name is _necessary_ for a control to be a successful control, but the book is still wrong if it states that the attribute is _required_ by the spec. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] input name and id
On 16 Apr 2007, at 20:17:15, [EMAIL PROTECTED] wrote: The HTML XHTML definitive guide from O'Reilly states that NAME is a required attribute in INPUT. Can I just substitute ID for NAME and still adhere to web standards or is NAME really required? I'm coding for HTML 4.01 strict. Name and ID serve two different purposes. ID is used to identify the element's node in the document [1]. Name is used to identify the element's value in the form submission posted back to the server [2]. OTOH, according to the HTML 4.01 Strict DTD, name is #IMPLIED, not #REQUIRED, so the book is incorrect. [3] [1] http://www.w3.org/TR/html4/struct/global.html#adef-id [2] http://www.w3.org/TR/html4/interact/forms.html#control-name [3] http://www.w3.org/TR/html4/interact/forms.html#edef-INPUT Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessible Forms - empty labels (??)
On 14 Apr 2007, at 07:25:29, Stuart Foulstone wrote: Hi, Doesn't look like valid code to me. Stuart !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/ TR/html4/strict.dtdhtml head titleblah/title /head body form action= div label for=searchBox input type=text id=searchBox name=q button type=submitSearch/button /label /div /form /body NOW it's valid ;-) On Thu, April 12, 2007 2:07 pm, Nick Fitzsimons wrote: On 12 Apr 2007, at 13:34:06, Patrick Lauke wrote: I'm not making assumptions. I'm saying that, for sighted users, having a text input box with no visible label and a button that says Search immediately next to it is labelling enough. Surely label for=searchBox input type=text id=searchBox name=q button type=submitSearch/button /label would therefore keep everybody happy? (Or does it matter if focus is switched to the text field as the form is submitted - sounds like the kind of odd case that A Certain Browser might get unreasonably petulant about...) Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- Stuart Foulstone. http://www.bigeasyweb.co.uk BigEasy Web Design 69 Flockton Court Rockingham Street Sheffield S1 4EB Tel. 07751 413451 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessible Forms - empty labels (??)
On 12 Apr 2007, at 13:34:06, Patrick Lauke wrote: I'm not making assumptions. I'm saying that, for sighted users, having a text input box with no visible label and a button that says Search immediately next to it is labelling enough. Surely label for=searchBox input type=text id=searchBox name=q button type=submitSearch/button /label would therefore keep everybody happy? (Or does it matter if focus is switched to the text field as the form is submitted - sounds like the kind of odd case that A Certain Browser might get unreasonably petulant about...) Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Recommendations for books to take one to the next level
On 23 Mar 2007, at 02:48:54, Jermayn Parker wrote: - Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug Excellent book. Sorry but I woul dhave to disagree with you hear. I found the book boring, old information and overall uniformative and a waste of time and money. If your an intemediated web designer you should already know what he raises. Maybe if your a beginner, it could be good but apart from that I would not bother,, I must admit I'm surprised to hear that. With 10 years as a web applications developer under my belt, preceded by another fifteen years of software development including a stint at a human factors and usability research institute, I thought the book was well worth reading when I finally got around to it late last year. Still, one man's meat and so on :-) Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Recommendations for books to take one to the next level
On 22 Mar 2007, at 17:23:47, Mordechai Peller wrote: Some books which I've had my eye on include: - Prioritizing Web Usability by Jakob Nielsen , Hoa Loranger Well worth reading, although some would argue that Nielsen can be overly strict in his approach to web usability. - Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug Excellent book. - Building Accessible Websites by** Joe Clark The Bible, which must mean that Joe is Moses, the Prophets and the Apostles all rolled into one. - Web Accessibility: Web Standards and Regulatory Compliance by Jim Thatcher, Michael R. Burks, Christian Heilmann, Shawn Lawton Henry, Andrew Kirkpatrick, Patrick H. Lauke, Bruce Lawson, Bob Regan, Richard Rutter, Mark Urban, Cunthia D. Waddell I haven't yet had time to read this (although I've read the older edition), but at the WSG London Accessibility meetup a few weeks ago, Mike Davis http://www.isolani.co.uk/ (At least I think it was him; if not, sorry, Mike!) said that although much of it was good, some chapters were, in his opinion, flawed. He didn't say which ones, so you'll have to work that out for yourself :-) For CSS and HTML, nothing caught my eye; they all seemed to basic for what I'm looking for. Sure there are many good books out there and I'm sure I could learn something from many of them, but not enough from any one to justify the expense. On the other hand, there might be one I'm overlooking. Besides, while my motivations for this post are personal (I intend to purchase 2 or 3 in the coming days and others in the months to come), the more who can benefit, the better. Difficult to know what level of CSS you're starting from, but there's: Andy Budd's CSS Mastery http://www.cssmastery.com/ Andy Clarke's Transcending CSS - worth getting even if only to look at :-) http://www.transcendingcss.com/ Dan Cederholm's Bulletproof Web Design http://www.simplebits.com/ publications/bulletproof/ Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] centring and viewport size
On 21 Mar 2007, at 10:52:39, Designer wrote: David Hucklesby wrote: http://www.gunlaug.no/tos/alien/test_07_3810.html However, in this exercise ( a learning one!) I want the CSS to validate - and it won't if you use a MS expression to make IE conform. Whilst this is a learning thing, I do want: a) everything to validate b) it to work in all (OK, most :-) ) browsers. (Not asking much! :-)) Use an IE conditional comment [1] to feed the expression to IE, and all shall be well - or, at least, validate :-) Cheers, Nick. [1] http://msdn.microsoft.com/workshop/author/dhtml/overview/ ccomment_ovw.asp -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Using headers symantically
On 20 Mar 2007, at 20:23:59, Matthew Pennell wrote: On 3/20/07, Designer [EMAIL PROTECTED] wrote: h2Title/h2 psome text/p h4Sub-Title of Title/h4 pmore text/p h3Title/h3 psome text/p h4Sub-Title of Title/h4 pmore text/p And that seems fine to me. You can 'see' the structure by looking at the code, so it means (to me) that it's semantic. That's incorrectly nested I'm afraid. The spec says (somewhere) that headings have to be correctly nested, and that you can't miss out a heading level - so you can't jump from H2 to H4 without there being an H3 in between somewhere. Think of it as a tree of content - each section belongs to a parent section. Actually, all the spec says is: Some people consider skipping heading levels to be bad practice. They accept H1 H2 H1 while they do not accept H1 H3 H1 since the heading level H2 is skipped. http://www.w3.org/TR/html4/struct/global.html#h-7.5.5 Judging from section 4 http://www.w3.org/TR/html4/conform.html this should not be considered normative; therefore, the standard does _not_require that heading levels be properly nested - although I would agree that there are very few cases where it might make sense to skip a level. As has already been pointed out in this thread, presentation is no justification, as that is under the control of CSS. Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] site check - almost ready for prime time
On 19 Mar 2007, at 14:42:38, Bob Schwartz wrote: The test site at http://www.fotografics.it/fife/ has been refurbished to make it more standards compliant, before moving on to the accessibility layer I would appreciate it if you guys could check it out for any errors or wrong practices One thing I notice is that the links in the navigation have title attributes which, when they appear as a tooltip, obscure the contents of the submenus and of the menu items further down the page (I've looked in Safari and Firefox, BTW). Of course, when you move off the link the tooltip vanishes, but it reminded me of something that one of the speakers (I believe it was Anne McMeekin of the Royal National Institute for the Blind) mentioned at the WSG London Accessibility meetup a couple of weeks ago: a partially-sighted user might well have a screen magnification of as much as 32 times normal (or more), and the appearance of a big yellow tooltip box obscuring the actual content is usually a major hindrance to them. In this case, such a user might not even notice that a submenu (which could be partially off the right of their screen) had appeared, nor would they be able to scan down the main menu until the tooltip finally disappeared. As no screenreaders read title attributes by default (and no screenreader user ever changes the default setting, apparently) you aren't really deriving any benefit (at least in accessibility terms) from the title attributes, so they might as well go. Generally though I think it looks extremely good :-) Cheers, Nick. (Apologies if I've misrepresented what was said at the WSG meetup, but I believe I've remembered it correctly :-) -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] style sheets - best practices
On 15 Mar 2007, at 14:26:40, Barney Carroll wrote: Grant Novey wrote: Using the @import stylesheet rule is great if you only want your stylesheet rules to be picked up by most modern browsers. Netscape 4 and below and IE 4 and below do not support the @import rule. This allows you to target stylesheets to specific browser versions. Does that make sense? This is the only practical advice I've seen on the topic. A while back I read this article on the secret power of the rel property in links... The author went about listing examples of different objects you could link and different terms for what relevance they might have (hence rel values). No, rel means the relationship of the linkee to the linker as implied by the act of linking. [1] His enthusiasm was tangible, but he gave absolutely no indication of how this would improve any appreciable aspect of your page as far as user experience was concerned. Am I just being cynical or is it really just a bit unnecessary? You were maybe reading Paul Sowden's ALA article [2] about the capability, as specified in HTML 4.01 [3] (and thus XHTML 1.0) to specify persistent, preferred and alternate stylesheets using rel=stylesheet and rel=alternate stylesheet in conjunction with the title attribute. Firefox supports this, and I would assume that Opera does too. IE, of course, doesn't. For an example of its use, visit Jeremy Keith's http://adactio.com in Firefox, then look under the View menu; the Page Style submenu will allow you to choose the high contrast stylesheet which Jeremy has specified in his document using rel=alternate stylesheet. So, far from being a bit unnecessary, it can be invaluable for a reader whose poor eyesight means they can benefit from seeing a large text, high contrast version of the site. Of course, there's nothing to stop people from including such links when they have several skins for their site, and allowing the user to choose which one they want. [1] http://www.w3.org/TR/html401/struct/links.html#adef-rel [1] http://www.alistapart.com/articles/alternate/ [3] http://www.w3.org/TR/html401/present/styles.html#h-14.3.1 Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] target and accessibility
On 10 Mar 2007, at 19:18:00, Thierry Koblentz wrote: What about: a href=esim/btsa_pt2.htmlWhat the critics say spanabout XXX/span/a a href=mk/introduction_pt3.html What the critics say spanabout YYY/span/a Then you use your favorite method to hide the span elements. As long as your favourite method doesn't involve the use of display: none; or visibility:hidden, as they will hide the content from screenreaders :-) Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Talking about tabular data...
On 8 Mar 2007, at 19:09:52, Paul Novitski wrote: The HTML spec makes it explicitly clear that the relationship between term and description can be interpreted more broadly than merely terms and their definitions: Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words. [1] In a dialog, the speech does not define the speaker; rather, they mutually inform one another to constitute a data record of closely associated fields. I suggest that the DT/DD relationship is similar to the TH/TD relationship of head and datum. In my view, the spec is far from clear at that point: it states that it is a definition list, explains how it is to be used to mark up terms and their definitions, and then suddenly turns around and gives us carte blanche to do pretty much anything we like with it. Note that this is mentioned as being for example, so should IMHO be considered informative, not normative. In terms of the semantics of term and definition, it makes no sense at all. Also note that this example is not present in the current XHTML 2.0 Working Draft, which might reasonably be assumed to seek to clarify those areas of previous standards which have been found to be less than perfect expressions of the intent of the authors. As Jukka K. Korpela commented about this matter on the W3C's www-html list a couple of years ago, they name it a duck, and then say it can be used as a cow: Another application of a duck is for milking... [1] Regards, Nick. [1] http://lists.w3.org/Archives/Public/www-html/2005May/0111.html -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
