Re: [WSG] w3c mobile validator and html5?
On 12 Dec 2011, at 21:18, Phil Archer wrote: Hi Nancy, On 12/12/2011 20:25, Nancy Johnson wrote: I have been moving image sizing to the style sheet and not left inline.. NNo!!! That's one thing that the mobile checker is definitely good for - stopping this bad practice of using CSS to define the size of an image and, even worse, using CSS to resize the image. W3C Best Practice: http://www.w3.org/TR/mobile-bp/#IMAGES_SPECIFY_SIZE My take on it: http://philarcher.org/diary/2011/phpimageadaptation/ That’s a great article Phil, so thanks for sharing. As somebody who is completely unversed in PHP, however, I was having a hard time figuring out how all the pieces fit together. Do they end up as one PHP file? or as a collection of PHP files that call each other? And how does the connect with the HTML markup? Any chance that you can you expand upon your explanation for PHP no-nothings like me? The article is fantastic on detail, but I think I need help forming an overview. Thanks, and warmest regards; -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: SPAM-MED: Re: [WSG] Flash replace Javascript in Future?
On 20 Oct 2008, at 10:26, kevin mcmonagle wrote: micheal md wrote: I tend to avoid using anything that needs flash player 9 where possible and so far I haven't found anything I needed to do that really needed actionscript 3 How about flv? IIRC flv came in with Flash 8 -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Code for Firefox, hack for IE
On 1 Sep 2008, at 12:27, Ben Buchanan wrote: I use basically the same approach, but I code for Opera; checking in Firefox and Safari. Then hack for IE at the end. On very large builds I do the occasional check for IE as well just to make sure things haven't gone really badly wrong in IE in some unpredictable way. Same here, more or less. My coding environment is Coda on a Mac, which provides a constant webkit-based preview on the fly. That pretty much takes care of Safari (mac). Then I make frequent checks in FF and Opera to make sure that there are no inconsistencies, with FF probably taking priority over Opera because of its handy development add-ons. Lastly, I make occasional trips to IE 6/7/8 to check out that browser's own 'exciting' take on things. These tend to be required more frequently in the early stages of page construction when the basic structure is being laid down. That is the time that I most commonly run afoul of IE bugs and/or Trident idiosyncrasies. I try to correct these as I go rather than waiting until the end because otherwise it can be much harder to trace the root of a problem. On 1 Sep 2008, at 13:30, willdonovan wrote: I find that if I'm attempting to make the site cross browser, try not to make the CSS too complicated. I agree. Keeping the CSS simple and thus maintaining the page in 'standards mode' means that many of the IE box model problems can be avoided. Unless I have an overly complex page design I can generally avoid most IE hacks altogether (although I still add in things like display:inline for floated content) -- Rick Lecoat www.sharkattack.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Lawsuits for inaccessible websites
On 21 Aug 2008, at 17:56, Jon Warner wrote: If I hosted a party, of course I would do my best to accommodate everyone's needs but to receive a court summons several days later because i had not installed a wheelchair ramp, for example, is surely wrong. The wheelchair ramp analogy, whilst not perfect, is a useful one I think. To refer to the example you used, I don't see that anyone would expect you to install a wheelchair ramp for the sake of a one-off private party (although if you invited your wheelchair-using friends they might get a bit p**sed off if you hadn't catered for them). I guess the equivalent of that on the internet is a personal site or blog which, whilst existing on the public internet, makes no attempt to provide content aimed at the wider public, and is simply a vanity site of one sort or another. However, a site that provides a service to the wider public (be that in the form of information, professional debate, selling a product or service, or anything else like that), then the analogous 'real world' experience would be that of a shop or library or seminar venue not installing a ramp, and that of course is a very different situation because the service provided has an implied invitation to the public as a whole. To use your party analogy, the private party would be a nightclub open to all-comers; whether they have to pay to enjoy the service is immaterial, the implied invitation to the public is there. In the vanity site situation I guess that the more personal the site content the harder it would be to bring discrimination case (though I / suppose/ that someone could argue -- just -- that they were desperately interested in what you had for breakfast and that since the site is on the public internet they have a right to be able to access it); with the second situation, however, the 'service offered to the public' aspect means that the potential for a law suit is very clear. Just my take. -- Rick Lecoat www.sharkattack.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Tables for product=price list
On 11 Aug 2008, at 11:48, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: a list could usually be said to be synonymous with a 'single column table' and conversely, a data table is a set of parallel lists - they are both special cases of each other. I think that Michael has hit the nail on the head here -- there is a blurry line between certain types of lists and tables. One could also argue that a definition list is a sort of simple table (2 column? tho DTs can have several definitions). I would say that the nature of a table implies cross-referencing (ie. the rows and columns interrelate to provide the correct data), and I let this be my guide. If the columns and rows *don't* interrelate then it's just a collection of lists. -- Rick Lecoat www.sharkattack.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Semantic markup of a byline date/time
On 17 Jul 2008, at 10:06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I may be wrong, but your use of cite looks the wrong way around - surely a citation should point at a document? If it's a cite _attribute_, then yes, it should point at a document. But a cite element, as I understand it, marks up a piece of attribution text, and so can simply be the name of a person, or whatever. Eg. blockquote pSome article text blah blah blah/p pwritten by citeHarold Lloyd/cite/p /blockquote -- Rick Lecoat www.sharkattack.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: SPAM-LOW: Re: [WSG] list links
On 11 Jul 2008, at 12:16, kevin mcmonagle wrote: Hi, Is it possible to target specific classes in a list to apply different background image to the different links in a list nav? tried everything i could think of but cant get it to work. something like: #navlist li .furniture a or applying the different images to the anchors instead of the lis? tried but no use... Hi Kevin; Sure. But take care where you attach your classes with reference to how you structure your CSS. If (as it sounds) you are attaching the class to the list item, then your CSS should be: #navlist li.furniture a not #navlist li .furniture a Note the removal of the space; li.furniture refers to a list item that has the class 'funiture'; li .furniture refers to some other element with a class=furniture *that is contained within* a list item. HTH -- Rick Lecoat www.sharkattack.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] columns with matching vertical alignment
On 10 Jul 2008, at 11:15, Elizabeth Spiegel wrote: The problem with this approach is what happens when you re-size text – in the example below it only takes one level of enlargement to have text overlapping. That might not be the case if you set your container height in ems. But still, basing design on a fixed amount of text is asking for trouble if you ask me. What if you need more text later on? -- Rick Lecoat www.sharkattack.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] list links
On 10 Jul 2008, at 14:25, kevin mcmonagle wrote: im doing a list with a background image and some text. how can an make the whole li area hot and not just the text. i forgot how to do that The main thing is to make sure that the list item is set to display: block. -- Rick Lecoat www.sharkattack.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] list links
On 10 Jul 2008, at 15:12, kevin mcmonagle wrote:
I had tried that rick but i was putting the padding in the li not
the li a.
Do i still need to make li's block elements for ie?
Sorry Kevin, I meant to say that the a *inside* the li should be
set to display: block. list items are block level by default.
However, with reference to the IE part of your question, you might
need some jiggery-pokery if you run into the IE bug where it inserts
gaps between list items that contain block elements. The workaround is
add two rules one after the other:
li a {display: inline-block;}
li a {display: block;}
See Berea street for further info:
http://tinyurl.com/ts8ye
Sorry for the bum steer earlier.
--
Rick Lecoat
www.sharkattack.co.uk
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] To stretch an image within a div ??
On 8 Jul 2008, at 10:24, Joseph Ortenzi wrote: No application can create extra pixels where only one existed. At best, they can interpolate what a pixel _might need to be_ by being very clever about the pixels surroundings and using sophisticated filters and techniques, but it is an educated guess at best. There is no such thing as enlarging in Photoshop or any other digital, pixel-based application. I think we're actually saying the same thing in different ways Joe. Probably I didn't explain myself very well. And I certainly wasn't trying to imply that Photoshop can give you perfect enlargements, but I think we're splitting hairs over the meaning of 'enlargement'. And now it's my turn to take minor issue: if you enlarge an image in Photoshop (eg. Image Image Size) then in fact Photoshop *does* create new pixels. There's no way around it; if you go from 10 x 10 pixels to 20 x 20 then Photoshop has created 300 new pixels. And the image *is* larger in terms of pixel dimensions. However, what you say is true: the *contents* of those newly created pixels is entirely guesswork on the part of the software, extrapolated from the original data. So the image is degraded. My point however, was that the less-than-perfect enlargement that you get from Photoshop's interpolation algorithms is still way better than the process of stretching an image in the browser with no interpolation at all. Sorry, this is drifting OT, so I'll shut up. -- Rick Lecoat www.sharkattack.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Browsers and Zooming
On 3 Jul 2008, at 22:16, Al Sparber wrote: When a block of text exceeds the viewport width, that means horizontal scrolling for *each line* - a royal PITA. I kid of think you are speaking for yourself ;-) Well, he's speaking for me as well. Al, do you really *not* find having to continuously scroll back and forth horizontally (because the width of the text block is wider than the viewport) to be an annoyance? If so then okay, but I do not believe that you are typical in this regard. -- Rick Lecoat www.sharkattack.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Browsers and Zooming
On 3 Jul 2008, at 23:01, Felix Miata wrote: When you measure the whole design in characters, or fractions thereof, resolution does not matter. [...snip...] When a design is _properly_ made using character measurements, users don't need to zoom. Hi Felix; Assuming that I'm not misunderstanding you, then I'm not sure I agree. What you are describing sounds like an em-based design, and if the width of your design is specified in ems then it will still have a defined width -- it's just that the on-screen width is defined by the combination of the default text size [1] and the user's monitor setup. Assuming the user doesn't change the latter, then changes to text size *will* change the on-screen width of the design since that measurement is proportionally tied to the text size. And if the resultant on-screen width of the design exceeds the viewport size then you get our friend the horizontal scrollbar. However, you're already on-record as being extremely well versed in the intricacies of text size vs monitor resolutions, which makes me think that I might have misunderstood what you meant by [measuring] the whole design in characters. I have assumed that you are referring to an elastic design; if not then please set me straight. Best regards; -- Rick Lecoat www.sharkattack.co.uk [1] irrespective of whether that's set by the designer or the user *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Browsers and Zooming
On 3 Jul 2008, at 14:55, Mark Stickley wrote: I wonder what a partially sighted user would thing of these 'improvements'. Would they be glad that now they can see images a little easier and the layout seems to break less or would they be annoyed at the sudden appearance of a horizontal scrollbar? Yes, a similar criticism has been levelled at Elastic layouts -- that when you enlarge the text the layout grows with it, which may not be what the user wants (when horizontal scrolling ensues). The line which made this clear to me was Georg's: wanting or having a need for larger text, doesn't mean one has or want a larger screen and/or browser-window. I've recently redesigned my own site in an elastic format, but I'm now wondering maybe that was not the best choice. It's actually only a temporary redesign so I'll have the opportunity to revisit the decision soon. I wonder to what extent the browser vendors sought feedback re. the pros and cons of zooming, because certainly Georg's comment would seem to apply to zooming as much as it did elastic/em-based layouts. -- Rick Lecoat www.sharkattack.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] flash navigation - Devils advocate
On 25 Jun 2008, at 00:35, kevin mcmonagle wrote: Using swf object 2.0 embeded swfs as an xhtml sites primary navigation - what are the liabilities? Assuming SWFObject 2 is like SWFObject 1 it writes your Flash file into a named Div. This div can (and should) hold alternative/falback content, which in this case should clearly be a fully-functioning html/ css navigation system. If the visitor has Flash then the Flash swf replaces the alternative content. If they don't (or if they don't have javascript turned on) then they'll get the fallback content, which should also suffice for search engines. (Of course, don't make your fallback navigation javascript-dependant). If you don't provide a fallback then all the pitfalls that Patrick lists are, of course, applicable. And whether the SWFObject system plays nicely with all combinations of assistive technology is another issue, but one that I can't answer. I seem to recall reading that SWFObject 2 has an alternative method of implementation that doesn't require javascript (v1 only had the javascript option) but I've not toyed with it since version 1 so I can't confirm. -- Rick Lecoat www.sharkattack.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] flash navigation - Devils advocate
On 25 Jun 2008, at 11:49, Matijs wrote: Regardless of whether you stick alternative navigation in the div that's going to be replaced, I've personally found using Flash for navigation about the worst use of Flash possible. Are you sure that you cannot achieve what you want by using HTML with some enhancements thrown in by javascript? Yes, I wasn't really advocating using Flash for navigation, just noting the options. HTML and javascript would be preferable, no doubt, especially since the visitor would probably need javascript turned on in order to use the SWFObject option anyway. -- Rick Lecoat www.sharkattack.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] HTML special characters coding
On 17 Jun 2008, at 23:46, Patrick H. Lauke wrote: Beyond the inbuilt entities I tend to just use the characters directly in the markup and specify UTF-8 encoding. Has been working reasonably well in all modern browsers. On 18 Jun 2008, at 00:19, Andrew Cunningham wrote: Use amp; nbsp; lt; and gt; All other characters should be actual characters. So, that would seem to be the consensus. Well, how fascinating; you learn something new every day on this list, and in this case it's making me feel really stupid because I've been encoding every non-standard character. Admittedly I'm using Coda to write my markup and that app has a vry handy 'Encode entities' function that, when combined with a keyboard shortcut, simplifies it enormously. But it seems that maybe I'm just making unnecessary work for myself. I've been doing it that way thus far because I learned (during my 'teach yourself hand-written html/css' stage) that it was the 'correct' way to do it. Is this a case where the correct way is actually unnecessary? So let me see if I have this right: as long as my page declares an encoding (I use UTF-8) I don't need to encode the entities, I can just type them straight into the markup. Is that correct? Will it validate? (I normally use an xhtml 1.0 strict doctype). -- Rick Lecoat www.sharkattack.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Semantic coding of posted in
On 13 Jun 2008, at 04:05, Jason Ray wrote: Definition lists are for definitions, which this is not. Not necessarily so. The W3C gives character dialogue as an example usage of a DL http://www.w3.org/TR/html401/struct/lists.html#h-10.3 which seems to encourage finding less literal uses for it -- and plenty of designers use the tag to semantically group collections of semantically-connected text chunks/images etc in all manner of creative ways. -- Rick Lecoat www.sharkattack.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Semantic coding of posted in
On 13 Jun 2008, at 12:07, Robert O'Rourke wrote: Where's the character dialogue example? Just above the heading for '10.3.1 Visual rendering of lists' -- Rick Lecoat www.sharkattack.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] MA in web development
On 12 Jun 2008, at 13:40, Joseph Ortenzi wrote: A good course teaches you to fish, to borrow from the ancient adage. therefore html 4/5 is a non-issue. Therefore any current course would include the complete understanding of BOTH current and emerging standards and any good student and practitioner will constantly be remaining aware of progress. As for web _design_, this ALREADY includes: information architecture, wireframing, user-centred design research and implementation, prototyping accessibility and usability, as well as colour, layout, aesthetics. design is not just appearance, it is also engineering, architecture and usability. Hear hear. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Help setting current menu state on level2 menus
On 10 Jun 2008, at 05:55, Gunlaug Sørtun wrote: Testing with regular browser-option well beyond what normal users will expose your work to, will save you from having to deal with user-introduced problems later on. On a related note (testing in IE win), I try and remember when doing my IE/Win testing to test both in 'regular' mode (default text sizes) and accessibility 'brute test' mode (ignore font sizes on page, set text to largest). This involves quite a bit of irksome preference- switching back and forth on a regular basis. I was wondering if anyone had developed a script or something to automate these changes to settings with a single click? -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Help With Hover
On 5 Jun 2008, at 20:25, Prisca schmarsow wrote:
the jumping happens because you are applying padding only on hover
for all your links, essentially adding to their size...
This is not ideal, in my humble opinion, as your text also shifts on
rollover...
If you however applied your padding to the main link itself - and
only applied the additional rules to the hover state - that will
eliminate all shifting
My method for eliminating the text jumping when a hover state on an
inline text link needs padding is to give all the link states padding
as Prisca suggested, but _also_ give them a negative margin-left
equalling the padding amount. This brings the text of the link back to
its original position.
eg.
a {padding: 0.5em; margin-left: -0.5em;}
a:hover, a:focus {background-color: whatever;}
--
Rick Lecoat
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Marking up company logo
On 3 Jun 2008, at 07:04, Matijs wrote: How about: titleThe Times/title h1Homepage/h1 h2There's water on mars/h2 titleThe Times/title h1Financial stuff/h1 h2Redmond stock going down further/h2 etc... Where would one fit in a company logo? Wouldn't a background image be best? And if so, where? My understanding of the title tag is that it is the title of the page, not the name of the site, and ideally every page should have a different title (at least from an SEO point of view) appropriate to its content -- so the above examples are not ideal IMHO. Re. logos as background images, that leaves anyone viewing the page without styles turned on out in the cold as far as seeing the company logo is concerned. Dan Cederholm uses a method whereby the logo is both a background image *and* a regular img tag, depending on whether you have styles on or off. That's my preferred technique. I just put the logo image in a div id=logo and keep the H1 for the page's own title. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Marking up company logo
On 3 Jun 2008, at 12:29, Paul Collins wrote: Once you have it in the title tag, does it matter whether you have the logo in a H1 or not? Should you have something different between the title and main heading? I would think that this starts to enter the realm of information that is machine-read vs that which is human-read. When I open a web page I don't tend to look much at the browser's title bar; I look at the page content itself. (The title bar comes more into play when I'm switching between tabs). Google, on the other hand, pays a great deal of attention to the title bar -- or, rather, the title tag that populates it. It also looks at the page content as well, of course. I think that as long as you avoid excessive duplication (ie. start keyword stuffing) there is no problem having some duplication of content between your title and main heading; humans and machines will each view both blocks of information to some degree, but will place different emphasis on one or the other. I would guess that screen readers will fall somewhere between the two in terms of how useful they find title vs. the page's main heading. But that's pure supposition, so don't take my word for it. Plenty of very knowledgeable people on this list can fill in those blanks. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Marking up company logo
On 3 Jun 2008, at 12:55, Darren West wrote: I do feel this is all rather subjective and depends on what you're building, that is until you consider SEO; which I feel flies in the face of Web Standards I agree that much of this stuff is, inevitably, subjective. Web standards gives us a good framework to work to, but within that there are always numerous ways to skin the same cat (yes, it's a very unlucky cat). Re. SEO, I think that it can work just fine alongside web standards -- in moderation; as soon as you get too SEO-crazed you risk starting to erode the web standards 'purity' (if that doesn't sound too fascist) in order to accommodate some pro-Google trick or another. The root of Google's webmaster guidelines can be summarised as just create your page for humans to read without difficulty and don't obsess about trying to manipulate our search engine, and really that's not so far from web standards, is it? -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Marking up company logo
On 29 May 2008, at 05:32, Jens-Uwe Korff wrote: We used to have lots of logos in h1s too, and after a thorough SEO discussion we changed that to a p. Out of curiosity, is a logo img at the top of the page more semantically correct when wrapped in a p than when it's just on it's own (ie. not wrapped in anything other than, say, a 'header' div)? -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Alt versus Title Attribute
On 28 May 2008, at 11:31, Gunlaug Sørtun wrote: Me too. IE/win shows title-text on images when such exists, otherwise it shows the alt-text if such exists. For this reason I quite often use a null-value title attribute alongside filled-in alt text, simply because I don't *want* tooltips in my pages. This means that the alt text is there for those who need/ want it, but image-savvy users aren't pestered by yellow text boxes popping up every time they happen to mouse over an image. Is this (eg: img src=bb.jpg alt=Big Ben clocktower in London title= / something that the panel would condone or condemn? -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Alt versus Title Attribute
On 28 May 2008, at 12:53, Darren West wrote: There is the argument that you are changing the behaviour of IE, however wrong it is, it could be what users expect. I agree that that's an argument. But the counter-argument, to my mind, is that I'm *correcting* the behaviour of IE through markup and css (well, ok, not css in this case) to bring it into line with standards compliant browsers, which is what we, ad web designers/developers regularly do when working around the old IE box model, etc. I don't want my alt text showing up as tooltips in IE, period, so tweaking the markup to correct IE's implementation would appear to be the logical choice, especially since it does not break the semantics of the page. On the other hand, I would be interested to hear of any problems that my method creates for screen readers. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Alt versus Title Attribute
On 28 May 2008, at 13:39, Darren West wrote: Rick, what email client are you using? how do you get the 'on 28 may darren wrote ...' and the border-left on the quote? Cheers Darren Drifting OT now, but it's plain old Apple Mail. The border-left, as you call it, is just Mail's way of indicating quoted material. If I remember correctly from many years bck, Eudora did it the ame ay, though personally I prefer the traditional carat (). Happy to chat about email clients but probably best to take it off- list, lest wrath be incurred. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] possible to make absolute position moves down with fontsize resize?
On 17 May 2008, at 06:03, David Hucklesby wrote: For some reason, sizing nearly everything in pixels is viewed as easy and efficient. I find I have to be super-careful when using fixed pixel sizes for anything, given the many and varied ways that this or that browser or operating system affects text sizes. Agreed. I tend to try and specify *everything* in ems these days (having established a practical font side on the Body tag); the result is a nicely elastic design that is almost guaranteed not to break with text resizing, as everything scales along with the text. (Bitmap images are the only hurdle really -- choose between (a) Images don't resize with the other stuff, (b) images resize but lose definition v.quickly, or (c) images keep their definition but the user is made to download extra image data they may never need). Oh, I sometimes substitute a percentage unit for ems with respect to page structure -- a column set to 60% width is more self-explanatory than a column set to 44.5ems inside a 74em wrapper. This mixing of ems and percentages has never led to any problems AFAIK. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] [OT] users - IT literate?
On 16 May 2008, at 06:50, Matthew Pennell wrote: In my experience, a large proportion of computer/web users struggle to understand online concepts that we expert users take for granted. Many regular surfers have no idea how to interact with a scroll bar - and there are lots of people who don't know how the address bar of their browser works! Matthew, my experience tallies with yours. At least half of the people I work with (I mean clients, not co-workers) are not very IT-savvy at all. It brings to mind the Blackadder line: I am one of these people who are quite happy to wear cotton, but have no idea how it works. In some extreme cases this seems to extend to an almost willful ignorance, as if they feel that learning how to operate their computer would somehow diminish them. It is certainly true that the older the client the more likely this seems to be -- although I would certainly not generalise too much as I know plenty of completely computer- literate 'silver surfers'. I find it frustrating when they stubbornly refuse to learn what the most basic controls are on their browser, but unless it has a negative impact on the project I generally ignore it. In any case the evidence would suggest that it is a generational thing, and that should come as no surprise. As someone born at the back end of the 60s, I can understand it, because I personally find the more leading edge web technologies hard to keep up with - much more so than, say, people 15 years my junior who live and breathe that stuff. It's a matter of degree, I guess. People absorb information at a fundamental level early in their lives, and I think that beyond a certain age they stop absorbing it quite so easily and have to work at *learning* it. That includes information about current technology. If a new technology comes out when you're in your 40s it's probably going to be harder for you to pick it up than for your 16 year old nephew. The old chestnut about adults having to get their kids to programme the VCR for them are clichés, sure, but based on a lot of truth. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Footer problem!
On 15 May 2008, at 12:05, james wrote: This is probably a real easy thing to do, how ever i cannot get it to stay in the same position through each page. James, sorry if I'm missing something very obvious here but I think you need to be more specific about what you want the footer to be doing. Just sitting nicely underneath your main content? Or anchored to the bottom of the browser window at all times? Or something else? -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Definition lists for testimonials
On 5 May 2008, at 19:04, Thierry Koblentz wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Lecoat Sent: Monday, May 05, 2008 8:26 AM To: wsg@webstandardsgroup.org Subject: [WSG] Definition lists for testimonials Hi, I need to mark up a list of client testimonials. At first I was going to do it with a UL but then I thought about the multi-part nature of each 'item' (Client's quote, client's name, client's company) and figured that a definition list might be a better option. My only reservation about that is the fact that by using the established structure: dl dt client's quote /dt dd client's name /dd dd client's company /dd /dl I think you're missing an important element: blockquote but then it won't be allowed in a DT Hi, just returning to this issue. Thierry, I had actually com to the same blockquote conclusion, and my solution last week to a list of testimonials was this: div#testimonials ul li blockquote p p.clientName p.clientCompany /blockquote /li li blockquote p p.clientName p.clientCompany /blockquote /li /ul /div (that's simplified, obviously). I'm going back over my markup to see if I can streamline it, and I'm wondering if the ul/li structure is needed. On the one hand it *is* semantically a list -- it's a list of testimonials after all. On the other hand a series of blockquotes wrapped in a div is much neater and less busy. My question to the panel is: do you think that the unordered list markup is required semantically? Cheers; -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Definition lists for testimonials
On 13 May 2008, at 17:56, Joseph Ortenzi wrote: how about using the blockquote cite attribute? http://brainstormsandraves.com/articles/semantics/structure/ They mention using cite for a url (or email link) and title for the details. seems to be compliant to me... Hi Joseph; Thanks for your reply. Maybe I'm mis-reading your post but it sounds as if you are suggesting that I use cite and title to replace the p.clientName and p.clientCompany tags. The problem with that, as I see it, is that the cite attribute is supposed to point to an online source URL, and only one or two of these testimonials have a relevant URL to link to. Secondly, even if the title attribute is appropriate for the client's name and company, then by embedding that information in the title attribute it is effectively hidden apart from on mouse- over -- not much use to keyboard using visitors. I think that if I'm reading a testimonial I expect to see the originator's name and credentials clearly at the bottom, rather than hidden inside the code waiting for a mouse over. On the other hand, if I misinterpreted your post and you were suggesting using the attributes *in addition* to the structure that I already had, then I agree completely, with the caveat that some of the blockquotes would have to have (null) cite attributes. Bear in mind that the markup I jotted down was a highly simplified version of the actual code. Lastly, when you said seems to be compliant to me were you referring to the brainstormsandraves example you gave me, or where you referring to my markup? And if so, which version (ie. with the ul or without)? Thanks again; -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Embed a flash file 100%
On 13 May 2008, at 11:39, jay wrote: If you make the height:100% then it is 100% of the parent - since your flash file does not stretch to the that height the background shows which you have declared as white: var so = new SWFObject(main.swf, main, 100%, 100%, 8, #ff); -- You need to either make the background black or set the height of #flashcontent to the height of the flash content. On 13 May 2008, at 17:49, Laert Jansen wrote: the problem isn´t the color of that areais that that area shouldn´t exist..I left it white on purpose just to show the area apart from the rest... Leart; What Jay was saying (I think) is that your SWFObject setup is coded to go full screen. Your flash file (778 x 560 px) will scale to fit but only with it's original height:width ratio. So unless your browser viewport is precisely the same ratio of heigh to width as the flash file, you will get 'dead space' either top and bottom or on each side. Like if you watch a widescreen film on a traditional-size (4:3) TV, you get black bands top and bottom. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Definition lists for testimonials
On 13 May 2008, at 19:48, Mike at Green-Beast.com wrote: Don't forget the cite element too. If a source isn't online you wouldn't use the cite attribute, but the element will still help with proper attribution. Mike, you're bang on the money: I had indeed completely forgotten about the cite element, and it's just the tool for the job here. And thanks for confirming what I already suspected -- that the list was over-egging the pudding. Peculiarly, I immediately (in shame) went to O'Reilly's 'HTML XHTML - The Definitive Guide' to refresh my memory about the cite element and discovered that it appears to not be listed in the index at all. Attribute: yes, element: no. Weird. Thanks again, and to everyone else who responded. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Embed a flash file 100%
On 10 May 2008, at 05:05, Rahul Gonsalves wrote: Have you looked at SWFObject [1]? It has worked well for me in the past. +1 for SWFObject here, with the disclaimer that it's moved on in recent months and I've not had occasion to use the updated version. But I always found its earlier incarnation excellent, especially since it provides a plain HTML fallback for anybody who doesn't have Flash or who doesn't have Javascript active (that also provides a way to make the text from your flash files available to search engines, at least for smallish sites). I believe that the newer version provides an alternative implementation method that removes the JS reliance, but I could be wrong about that. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Older Browsers
On 8 May 2008, at 22:50, Michael Horowitz wrote: I don't think it is worth the time an effort to support old browsers like IE 5. Agreed. I go back as far as IE6 because last time I checked my site logs just over 44% of IE users were using that version (with just over 55% using v7). IE5 accounted for less than 0.5% of even the IE users, let alone all browsers. Once a browser drops below the 1% mark it's done and dusted IMO, although I'm more forgiving when the browser is a fairly modern one (Opera totals only 0.77% in my recent logs, but I'd still test in it because it's a modern beast deserving of some respect). I don't support IE5, any more than I support WWII radios. Both are obsolete technology -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] alt text and titles for linked images
Hi, I'm just finishing up a footer for a site need to include a couple of 'membership badges', y'know the kind of thing: a GIF denoting membership of a trade body, with the image linked to the body's website. This creates several attributes which could be seen either as complimentary or conflicting/redundant, depending on your viewpoint. Firstly there is the image's alt attribute, then there is the image's (optional) title. Then the a tag itself can have a title attribute. The image's title I'm leaving as null, simply to prevent IE using alt text as a tooltip. That leaves alt, and the link's title. Both feel like they should be something along the lines of Company X is a member of This Organisation, but I'm wary of giving essentially the same information twice, in which case it just becomes noise. Anyone have any suggestions? -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] alt text and titles for linked images
On 9 May 2008, at 23:00, Krystian - Sunlust wrote: Hi Rick, I would give title to the link as the name of the organisation, since the link leads there, and then the alt of the image as this company is a member of the organization, because that's the reason that you show this image and that's it's meaning. Thanks Krystian, that makes sense. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Definition lists for testimonials
Hi, I need to mark up a list of client testimonials. At first I was going to do it with a UL but then I thought about the multi-part nature of each 'item' (Client's quote, client's name, client's company) and figured that a definition list might be a better option. My only reservation about that is the fact that by using the established structure: dl dt client's quote /dt dd client's name /dd dd client's company /dd /dl ...the 'term' will be way longer than the two 'definitions'. But clearly the client name and company name should come after the quotation. Is this actually un-semantic or is it just slightly counter-intuitive? Can a DT be 10 times the length of its DDs? Alternatively, should I be looking at a blockquote/paragraph combination instead? (that doesn't feel as elegant because it lacks the self-contained nature of a DT/DD set). Suggestions welcome. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] WCAG 2 implementation site
On 11 Mar 2008, at 22:38, Matt Fellows wrote: I also like the way you have not gone with the basic skip to content link and gone with a quick skip to menu, I have been advocating a similar approach that integrates access key's into these menu's as well. Is there a reason for not using 'accesskey' at all? Matt; I recall reading somewhere that 'accesskey' is often considered more hindrance than benefit because there are no standardised keys for specific functions and it inevitably ends up conflicting with regular browser shortcuts that keyboard users or screenreader users are likely to wish to utilise. I don't know whether that is the general consensus or not, nor can I say whether that was Mike's reason for not using acesskey, but it makes sense to me. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] multiple css style sheets
On 27 Feb 2008, at 16:55, Michael Horowitz wrote:
Just inherited a site and saw pages with multiple style sheets. Is
there a reason for that and how does the browser determine what to
use if there is a conflict
Michael, I assume that you mean that the page referenced several
external stylesheets using multiple link tags?
I /believe/ that the browser simple loads them one after the other in
the order that they appear in the source (unless the stylesheet's rel
is marked up as being 'alternate'), with one stylesheet being
appended to the end of the previous one. In effect the browser sees
one big stylesheet.
As for conflict resolution, my understanding is that the normal rules
of CSS inheritance apply.
Eg.
You have source:
link rel=stylesheet type=text/css href=styles_A.css /
link rel=stylesheet type=text/css href=styles_B.css /
link rel=stylesheet type=text/css href=styles_C.css /
In the CSS:
styles_A contains the rule:
body { background-color: white}
...and...
styles_B contains the rule:
body { background-color: red}
then the page's background colour would, rather unpleasantly, be red.
I think that's right...
--
Rick Lecoat
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] books
On 19 Feb 2008, at 06:58, Naveen Bhaskar Menon wrote: Anybody can suggest me some good books Among the books that live on my desk (as opposed to the less-honoured position on the bookcase) are: Web Standards Solutions by Dan Cederholm; Bulletproof Web Design by Dan Cederholm; CSS: The Definitive Guide by Eric Meyer; CSS Mastery: Advanced Web Standards Solutions by Andy Budd others; HTML Mastery by Paul Haine; Web Accessibility by Jim Thatcher others and Don't Make Me Think by Steve Krug I haven't delved into javascript yet so I don't have any recommendations there. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Acronym element
On 9/1/08 (20:18) dwain said: i was mistaken earlier saying cynthia says remarked on having to have the title attribute on the abbr element. after i added titles to the abbr element i didn't get the error. Dwain, I didn't quite follow that. You initially reported that Cynthia gave an error telling you to add titles to the abbr tags. You added them and the error went away. In what way was your initial report mistaken? Surely this is what one would expect to happen? Or am I missing/misreading something? -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Idiot's guide to JavaScript
On 27/11/07 (23:43) Al said: I also caution the original questioner to be wary of buzzwords like Dom Scripting and Web 2.0 Fear not, Al, I take buzzwords like that with a large pinch of salt. In choosing to refer to Jeremy Keith's book DOM Scripting: Web Design with JavaScript and the Document Object Model I was influenced not by fashionable phrases du jour but by the near-unanimous praise that it seems to garner, both here on the list and elsewhere. I likewise agree that absolutes can be problematic, and I am instinctively wary of dogmatism, in any form. My objective here is to teach myself Javascript in a way consistent with web standards and whatever is deemed 'best practice' at this point. Whilst I would partially agree with what Breton Slivka said (I have no belief in the concept that knowledge can corrupt, and that somehow innaccurate information will poison your mind) my own experience is that it is better, if possible, to something the 'right' way (or at least one of several 'right' ways) than to learn something in a 'make do' way and potentially have to unlearn a lot of less-then-perfect techniques and practices at a later date. I find un-learning hard to do, and I'll avoid having to do so if I can. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Idiot's guide to JavaScript
On 15/11/07 (11:15) Ross said: As a general rule of thumb if you are looking for online tutorials and examples that are teaching good modern JavaScript go find another one if it tells you to use things like: document.write inline event handlers (like onclick) browser sniffing This is quite a simple list but a good one to get started with! Sorry to return to this thread so late in the day, but I'm just at the point of perhaps trying my hand at Javascript for the first time (never been a programmer, aside from a bit of simplistic Actionscript) and remembered reading this thread so I thought I'd give it another once-over. Ross's warnings about avoiding old school techniques are well taken; the problem I have is that I know so completely and utterly nothing about Javascript at this stage that I can't even judge from the book that I have whether they are advocating these techniques or not. The book in question is the 6th edition of Visual Quickstart Guide: JavaScript and Ajax; I bought it a few months back in anticipation of dipping my toes in the JS ocean, but in light of the best practice discussions in this thread I don't want to waste my time on the 'wrong' book. Now, I could wade through it and try to learn enough to decipher precisely what it is advocating, but that could take a while. So I thought, as a first port of call, I'd ask the list and see if anyone here has any experience with this book and can advise me of whether or not it falls foul of the crimes that Ross points out. In summary, then, does anyone recommend me hanging onto Visual Quickstart Guide: JavaScript and Ajax (6th Ed.) or should I just ditch it and buy Jeremy Keith's Dom Scripting book instead? (Just trying to save myself some time is all) TIA... -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Idiot's guide to JavaScript
On 27/11/07 (13:17) James said: Hi Rick, I can't comment on the Visual Quickstart book as I haven't read it, but having only just started really looking at Javascript myself, I can vouch for Jeremy Keith's book being very good indeed. I have found it very easy to read (each chapter takes about 20-30 minutes to go through properly) and it has meant I have been able to implement unobtrusive DOM scripting to enhance pages and solve problems I've had hanging around for ages. I would suggest that even if the Visual Quickstart book is good, that it may be worth spending the time with the Keith book too. Hope that helps, James Thanks James, that's really helpful. I think I already know that I'm going to be buying Jeremy Keith's book, truth be told (having been looking at a bunch of reviews of it on Amazon etc since I posted to the list). Still, if anyone has an opinion on the Visual Quickstart book as well, I'd be interested to hear it, just so I know whether it's worth glancing at *at all*. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] SIte Maps?
On 22/11/07 (00:32) Lea said: But some people prefer to have a quick squiz at the sitemap to see the totality of what the site contains. People are all different. Your navigation can be fine, and their mindset just wants to look at things differently. I agree. I am a user who quite likes site maps, especially on larger (eg. enterprise-scale) sites where it might need a few clicks to get to the location I want. This holds true even if the navigation is perfectly okay; I like having the option of seeing an overview. If I'm in a large shopping mall the sign posts pointing me to different locations (toilets, food hall, car park, etc -- not necessarily in that order!) might work very well, but it is still useful, to me at least, to find one of those big floorplan maps with a You Are Here arrow that gives me the wider picture. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 17/10/07 (13:55) I, myself, said: can anyone tell me what is the best accessible way (if any) of encoding a mailto: link? I want to make the email addresses on a site usable to screen reader users, but don't want them harvested by spambots. Javascripted solutions seem like they would create a headache for screen readers, and any plain text equivalent presented in the name of accessibility would simply be harvested instead. And I prefer to avoid jscript if I can anyway. Is there a way out what seems, to my inexperienced eyes, like a catch-22 situation? Just by way of an update on this issue, there was an interesting related article on A List Apart a couple of days ago by Roel Van Gils. http://www.alistapart.com/articles/gracefulemailobfuscation -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] POSH article question
On 2/11/07 (14:24) David said: p lang=enWe say yes, but the French say span lang='fr'Oui/ span/p Yes, David, I thought of the lang attribute about 3 seconds after I'd posted my reply, and in that particular example it is of course the perfect solution. Tom, if you use a span with a class assigned then you are able to imply semantic intention by the name that you give to the class. Hence class=foreignWord is better than class=italicised because although a machine will not pick up the meaning (since foreignWord is defined by me, not an official spec), someone looking at the code will. Seeing ibonjour/i they would know it was italicised but not necessarily know why. IMO that means that semantic class names are better than plain bold or italic. But there may be times when there is no semantic meaning to convey at all, in which case b and i are there to be used. HTH -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] POSH article question
On 2/11/07 (12:36) Tom said:
Another question though... do you have an example of proper, semantic
use of strong vs b? Is it just just a tag to allow you to style
your own visual emphasis? How about strong vs. em - what's the
semantic difference?
Don't have any convenient links to send you, Tom, but let me see if I
can give a verbal example.
When you say just a tag to allow you to style your own visual
emphasis, then THAT is when you should use a b or i. An example
might be a foreign language word -- traditionally styled in italics. The
word (probably) does not require any semantic emphasis per se -- ie. you
are not giving it any enhanced meaning -- and so you would not use the
em tag but you DO want to give it a visual-only enhancement to make it
render in italics.
The key here is that a device that reads your page by looking at the
code (eg a screen reader or a search engine) should *not* be led to
infer that the word has been emphasised -- because it hasn't, it's just
been italicised so that devices that read the page by looking at the
rendered version (eg. our eyes) can make assumptions based upon our
cultural context (hmm... words in italics are often plucked from
another language).
And I'm starting to get overly-wordy here, sorry.
Of course, if there was a tag for 'foreign language word' then the best
choice (for the example above) would be to use that -- but there isn't.
Perhaps the most semantic solution in the above example would be to wrap
the word in a span with a class assigned, like so:
HTML:
p We say yes, but the French say span class=foreignWordOui/
span/p
CSS:
.foreignWord {font-style: italic;}
Lastly: strong is a more emphatic version of em. As I understand it.
And the above guidelines would apply equally to the bold/strong debate.
Rule of thumb: think to yourself, regardless of how it *looks* on the
screen, what does the text I'm marking up *mean*?
If I'm off base here I'm sure others will correct me.
Best regards;
--
Rick Lecoat
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Site check requested :: Lecoat
On 31/10/07 (14:19) David said: Rick, It is working far better than when you wrote for a check a week or so ago. It is, imo, a little daunting to arrive on it at 116.5 dpi-- the font start point (at which one might begin to scale the fonts) for the content text is very tiny; and, the value contrast a little weak. I am not so sure the top links are really necessary as this is a keyboard function for most experienced users. And whether the coda information should be the same font-size as the content text is yet another matter of opinion, as is whether it should be there in the first place (I think I'd opt for deleting everything but privacy). Some IE users, myself among them, run all versions of that browser in accessibility mode at text-size largest with font-sizes ignored-- your page /may/ wish to accommodate same. Best, Thanks for that David. Plenty of good points, and nothing that I disagree with. Currently, this is a site that slightly falls between two stools; I'm updating it away from tables-based layout but since the client hasn't actually requested any sort of redesign (I'm doing it as a surprise goodwill gesture), I'm trying to keep the look and feel as close as I can to the original, even if I no longer consider that 'look' to be necessarily the best solution. So type sizes, if I was redesigning from scratch, would indeed be larger, and some colours might be different. And I wouldn't use a semi- fixed height design, that's for sure. Certainly, this is not an accessibility-perfect site, and I fully accept that. It's more of an exercise for me -- practise, if you like, for someone just getting on the web standards bus, just learning about elastic layouts, and just making the jump from GoLive to the world of hand-coded-from-the-ground-up. I was interested by your comment about the 'top' links; I find them useful on sites even as a fully-abled mouse-using web user, especially where there is lots of scrolling going on. But then I've never really been a big user of the page-down and home/end keys on the keyboard (techniques that I suspect are possibly more common amongst people who use word processor software on a regular basis -- just my speculation) so you may well be right about the redundancy of those links. I'm going to remove the Access keys I think; since I put them in place I've read quite a lot of stuff to the effect that they are generally more trouble than they're worth. BTW, I don't know when you viewed the site in Explorer, but if it was between this morning and this afternoon it was in a hell of a state, due to a change I'd made; I had not realised that Explorer ignores media- specific @import commands, eg: @import url(styles.css) screen; So for much of today the site was looking, well, unstyled in IE. That's fixed now but I'm not sure how to specify media types when most of my stylesheets are referenced by @import rules from inside a single stylesheet called import.css. If I assign a media type to import.css, will that propogate down to the stylesheets that are imported within it? -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Site check requested
On 30/10/07 (13:38) willdonovan said: I loaded up your page, facinated by your achievement for a semantic structure 'Fascinated' is one of those worryingly ambiguous terms... ;-) it looks good, however I'm getting validation errors for the DOC type, the img tag and trimming empty on 2 span tags, Did you get the same? Thanks for the check-over William; weirdly I'm not getting those validation errors, either from Web Developer Toolbar or the W3C validator itself. What is particularly odd about that is that I thought that I *did* have one glitch to fix (brought on by a change made to the page since I originally posted the URL to the group), but it has apparently evaporated into the ether. Very odd. The mystery error was indeed on the img tag, and stemmed from the fact that I misunderstood how a longdesc attribute works -- I had put regular text in there like an alt attribute, whereas I believe that it should be a URL pointing to a descriptive document. (My description -- a repetition of the text displayed in the animated gif -- was a few characters too long for a regular alt text). The wrongly conceived longdesc is still in place, however, so I don't know why the validation error has vanished, unless the original error report was a mistake. Are you using a different validator to me? http://tinyurl.com/2y7pnf -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Site check requested
On 30/10/07 (14:09) JonMarc said: Rick, the site looks good. visually i would maybe slow down your animated gif a bit, or include the company name or slogan or something and have it stop after going through once or maybe looping just a couple of times and fall to rest on the name/slogan/whatever. it's a bit fast and i found the constant movement to be a slight distraction. just a thought. And a perfectly good thought, at that. In this case I'm trying to keep the look and feel of the site as close as CSS will allow to the existing tables-based version that the client likes (and has been living with for a couple of years), so I'm leaving as many elements unchanged as possible, and that will include the gif speed, at least for now. Also, the speed of the gif does vary according to the computer it's being viewed on; high spec machines will let it whizz through its frames, but on some machines (eg girlfriend's iBook) it crawls past. looks outstanding for a first effort! Ah, now THAT just made my day. Thank you. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] CSS display: none has SEO impact?
On 30/10/07 (23:52) John said: This might prove useful - http://www.seomoz.org/blog/guide-to-hidden-text My understanding is that yes, SEs do view some use of CSS dubiously, but it's also been my understanding that it only applies to inline CSS (not external stylesheets) and as an added safety measure, you can always add your CSS directory to your robots.txt. Very interesting article, thanks for the heads-up John. About a year ago I tried hard to get a definitive answer out of a particular SEO forum's denizens with regard to whether Google was able to trawl through external style sheets or not; nobody was able to provide one. So the question is still open for me, and I'm curious; what is your source of information for thinking that the big G only looks at inline CSS? Cheers; -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Encoded mailto links
Hi, can anyone tell me what is the best accessible way (if any) of encoding a mailto: link? I want to make the email addresses on a site usable to screen reader users, but don't want them harvested by spambots. Javascripted solutions seem like they would create a headache for screen readers, and any plain text equivalent presented in the name of accessibility would simply be harvested instead. And I prefer to avoid jscript if I can anyway. Is there a way out what seems, to my inexperienced eyes, like a catch-22 situation? Cheers; -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 17/10/07 (14:16) Patrick said: Fix your spam issues at the mail server + mail client end, not at the web page end, would be my advice. David said: I, long ago, gave up trying. Methods are either highly ineffective, or block out users you want as well as spam bots. I take the view that email addresses are going to end up on spam lists eventually no matter what I do, and just run spam filtering software. So the general consensus would seem to be forgeddabowdit. I wondered if that would be the result, but I'm surprised that there isn't a workaround -- only because almost everything else that I thought would be impossible some clever person has found a way to do. To join with Andrew Maben, however, I'd be curious to know whether spambots decode encoded entity text, eg: 'user' becomes '#117;#115;#101;#114;' (ignore quote marks). I assume that they can read them perfectly easily -- browsers can, after all -- but it'd be good to know for sure. Same question for screen readers. -- Rick Lecoat *** 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/10/07 (15:20) Chris said: Well I guess now I really think about it you can't solve it as you could append an email address to the DOM from an obfuscated javascript function and that would likely solve the problem but it's not an accessible solution. For screen readers you need to have the email address in the HTML code and whether it's encoded or not it's accessible to harvesters. Therefore theres no solution, so as Patrick said, Fix your spam issues at the mail server + mail client end Fair enough. One less item on the 'things to clarify' list; thanks everyone. (Of course, I rarely have control over the client's mail server, still less their email client. I suppose that becomes their problem). -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 17/10/07 (15:33) Or said: Why not simply display the email address as a simple mailto only when the browser is a screen reader? If you mean by CSS (display: none -- or similar -- for aural media types), I'm not sure that would work because AFAIk spambots just look through the source code of the page for mailto links. The fact that the text is hidden when it gets to the browser is neither here nor there, surely? If you are talking about actually hiding markup from certain agent types, I'd certainly like to know your method. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 17/10/07 (16:20) Patrick said: Screen readers run on top of normal browsers like IE of Firefox Ah, I did *not* know that -- I thought that they were a sort of self- contained browser themselves. Thanks for that heads-up. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Site check requested
Hi; I'm recreating a table-based site that I did a few years back, rebuilding it (hopefully) to web standards and making it as accessible as I can. Currently it's one static page and the links largely don't go anywhere, but I would appreciate feedback from the list before I proceed with more pages. http://sandbox.sharkattack.co.uk/novaRebuild/working.html It's really my first stab at a semantic markup, fully-CSS, accessible site; it's also my first ever attempt at an elastic layout, so be merciful. Many thanks! -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] source order
On 13/10/07 (09:21) JonMarc said: with all the skips and jump tos and methods for pulling links and whatnots, i wonder how many people using screen readers ever make it down there to the footer/copyright/whatever-else-you-put-there Remember that screen reader applications can commonly call up a handy list of all the links on a page, so those in the copyright section would also be presented in that list (albeit probably at the end of the list) without the user necessarily needing to 'read' their way down to them. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] source order
On 10/10/07 (23:03) russ said: ../ snip /.. However, most people would agree that: 1. consistency across the site is the most important thing (changing the source order on different pages could cause a great deal of confusion). 2. if navigation comes before content, skip links are valuable for certain types of users. But for less experienced screen reader users, it seems clear that many are likely to find skip links a useful device for moving directly to specific sections of the page. An endless debate. And this is before opening up the other aspect of the debate... How source order affects Google rank :) Thanks to everyone for your thoughts on this. Oh, and as many correctly guessed, the article to which I was obliquely referring was indeed http://usability.com.au/resources/source- order.cfm -- I meant to cite the URL in the original post but it slipped through the net. There are merits to both sides of the debate, but after thinking it through and in light of the opinions offered here, I think that I'm going to go with the following principles: 1. Navigation before content in cases where navigation is modest (say, half a dozen items or so). 2. Content first in those cases where navigation is more voluminous and less clear cut (eg blogs, where there might be blogrolls or archive link lists of considerable length). (Georg: the article you cited was primarily discussing blogs rather than 'regular' sites. It made some interesting points though). 3. Skip links to permit jumping to content areas (main content and sidebar): definitely, and visible too as they can useful to mobile users. 4. The Google ranking issue is a tricky one, but the official google line is always 'design for humans, not robots', and if making your site as accessible as possible isn't designing for humans then I don't know what is. (Interestingly, a screenreader might be considered almost a grey area between 'human' and 'robot'). 5. And finally, as Russ pointed out, consistency is vital, but that is true of any site design, whether accessible or not. Thanks again to all who threw in their 2 cents. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] source order
Hi there; I'm currently laying down the markup for a site and have been pondering whether to put page content above navigation in the source. I often read that this is a good idea, and that makes perfect sense to me as long as there are skip links so that people can reach the navigation easily, but I recently read an article at usability.com.au that would seem to indicate that few users of screen readers expect this to be the case. Is there a prevailing wisdom in this matter? Content first? Or navigation first? Cheers; -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Element suggestion requested
On 21/9/07 (10:39) Nick said: 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. I the end, Nick, I plumped for a strong tag; it gives some semantic weight to the list item without implying a hierarchical structure. It's semantically ambiguous content, really, and I suspect that several tags *could* be pressed into service, so I'm not going to worry about it too much. I think that the most important aspect was defining it as a list; the secondary tag (strong) is less important IMHO. Also, this is destined for an intranet CMS that seems to view semantics and web standards largely as curiosities from the future to be marvelled over and then entirely ignored. Still, that's no reason for me not make the effort. (Their limited set up pull-down formatting options lacks blockquote yet still includes MENU. Ugh). Thanks to everyone for your invaluable for your suggestions. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Element suggestion requested
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. -- Rick Lecoat *** 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/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. Maybe a strong tag to replace the span? -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] magazine
On 20/9/07 (20:57) Rafael said: I'm looking for a good offline (printed version) magazine to stay tune with the latest news about Web 2.0, Javascript, Ajax, CSS and Web Standarts. Do you have any ideas? I get Web Designer (Imagine Publishing) and .Net (Future Publishing). I find both to be really good sources of information. Much of their content is way beyond my knowledge, which I take to be a good sign -- magazines I can grow into, so to speak. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Element suggestion requested
Hi all. I've got a site which you can see a static screenshot of here http:// www.clients.sharkattack.co.uk/quicklook.jpg (actually it's a screenshot of the photoshop file -- the site is still being coded) The item(s) I'm currently marking up is/are the 'Values' boxes in the right hand column, and I'm not really sure what element to use for the text. An h2 or something would convey the fact that they are considered important, but doesn't quite feel sematically 'right'. Whereas using a p makes it seem like just another bit of text like any other. Maybe they are a 'list' of values, and a ul/li would be best. Anyone have any suggestions? TIA -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] How many of us are public and how many private?
On 12/9/07 (06:17) John said: So I wonder, how many people on this list are in the commercial sector and how many are in the non-profit / public / government / education sector? I'm a one-man design studio (can't quite stand the 'boutique' label ;-) and as such I work for whoever brings their business my way, provided they are not a walking ethical outrage. So that makes me a commercial operation, albeit that my biggest web client is a public sector entity here in the UK. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessible Open Source CMS
On 12/9/07 (14:55) Bruce said: These and related are as accessible as their programmers make them. I find them all difficult to configure for the reason that one is limited my mambots, modules, plugins, etc which are made to add functions and wysiwyg editors. All the code in the templates (if they can be found even) is integrated into the core and is difficult at best to edit. I find even wordpress editing out code I add to templates and becoming increasingly unusable. Expression Engine on the other hand is as accessible and Standards based as YOU make it. The templates are in the open and stand alone in the sense they aren't wrapped around the core programming and they will output anything put in them. All the xhtml code is right there and not dependent on other core programming or functions. Of course, Expression Engine isn't a freely available Open Source solution, you need to stump up the readies for it. But I recently did a bit of reading in order to find a CMS that could handle (initially) a basic blog and (later) whatever I wanted to throw at it, whilst being both web standards-friendly and design-malleable, and I also decided to opt for Expression Engine. I've barely had a chance to scratch the surface yet (other projects keep getting in the way -- curse those fee- paying clients!) but so far I've not seen anything that makes me regret my choice. And there is a free cut-down version available for those who's budgets are tighter. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Font sizing: top down or bottom up
On 10/9/07 (14:27) Felix said: http://mrmazda.no-ip.com/auth/access-lipservice . To be fair, Felix, I never said that the sites advocating default text sizes *should* be highly designed; I merely noted the irony that they were not, given that they were telling designers how to size type. The link above reminded me to raise one of your points again, because it struck me as counter-intuitive. No doubt I misinterpreted your reasoning, so perhaps you could help me out with a bit of clarification. The bit in question is this: Do you suppose most web authors are using little old computer displays to do their work 40 hours per week. Not likely, is it? No, as a group, they have fine equipment, typically using displays much larger than average, 21 or larger in many cases. So, their concept of how big is big enough is further skewed smaller than average. You appear to be saying that the larger screens used by designers tempt them to err on the smaller side when sizing type. But larger screens generally mean higher resolutions, with a given type size (say 14px) therefore appearing smaller on a bigger screen than it would on a smaller one. Eg. 12px type looks much bigger (physicallly) at 800x600 than it does at 1600x1200. Indeed, it's an argument that you have used yourself in favour of increasing type size; as screens evolve their native resolution increases and so the same (nominal) type specification looks progressively smaller with each generation of screen. All perfectly logical. *Except* that it seems to me that when something looks smaller, the natural tendency -- even for freaky, bizarre, bad-in-the-head designers -- is to make things larger to compensate. Surely, the logical follow-through of stating that designers use larger, higher-resolution screens than the average, should be that they are therefore more inclined to make their type larger? Yet you appear to argue the opposite. Can you clarify this point, because it's been bugging me. Cheers. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Font sizing: top down or bottom up
On 7/9/07 (07:50) Tony said: I've been using CSS for seven years or more and I'm trying to adopt best practice in a pragmatic way, which means I can't deliver my clients sites with excessively large fonts - they are trying to design interfaces that look attractive and create income for their business. I'm trying to ensure the sites they get are as accessible as possible, we have to meet somewhere in the middle. On a side note, I can't help but notice that almost every site that has been cited as a reference for reasons why default text size should not be tampered with has a very minimal level of 'design styling'. For example: http://psychology.wichita.edu/surl/usabilitynews/2S/font.htm http://www.useit.com/alertbox/20020819.html http://mrmazda.no-ip.com/auth/bigdefaults.html http://www.xs4all.nl/~sbpoley/webmatters/essence.html Now, I'm not going to dispute that these are very accessible sites from a type-size perspective. And, yes, they present their information without unnecessary distraction. But I can also guarantee that if I took a 'design' like that of any of those sites to a client, said client would be out the door and off to my competitors faster than I could say Accessibility. Maybe it's just coincidence. But none of those sites telling me that I can create perfectly nice-looking, commercially viable designs using default text sizes have actually put their design-money where their mouth is. *That does not make the points they raise wrong*, but it means that it feels a bit like having my dress sense criticised by someone wearing a dirty t-shirt and torn sweat pants. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Font sizing: top down or bottom up
On 7/9/07 (11:50) Rahul said: Try the Chelsea Creek Studio: http://chelseacreekstudio.com/ I particularly like this one: http://chelseacreekstudio.com/ca/site/gustave/index.html Yes, both fine designs. (I was simply pulling my example sites from the list of those that had been proffered up-thread as information sources about default sizes being best). It is possible, and I don't see why it shouldn't be possible to work with larger text-sizes and yet arrive at an aesthetic solution. I agree that it should be (and clearly is) possible to create reasonably aesthetically pleasing [1] designs using default text sizes. I found it ironic, however, that the sites telling me to use default sizes failed so spectacularly to provide an aesthetically pleasing solution [2] themselves. Do forgive me if I have missed the point completely No, you hit it bang on I think. Thanks for your views! -- Rick Lecoat [1] A very subjective judgement call, of course. [2] Again, that's subjective. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Font sizing: top down or bottom up
On 7/9/07 (07:50) Tony said: and talking of UI, why are we fighting for 16px fonts in browsers when most UI text is much smaller? I believe that the reasoning here draws a distinction between UI elements and 'content'. UI elements become familiar through their unchanging nature (every time I pull down the Image menu in photoshop it looks the same as last time, unless I've upgrade photoshop inbetween). Content, by contrast, is by nature unfamiliar. The more familiar the text in question, the less help the reader requires. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Font sizing: top down or bottom up
On 6/9/07 (09:08) Jens said: I would like to point out that text in a web page is usually not there merely for a design purpose but for communicating some information. No arguments here. If the consensus amongst the visiting user-base is that the information is lost or hard to access on account of small text sizes then the design has certainly failed in its job. That said, it surely is more aggravating for a reader to first have to make a text readable before being able to access some information. This means, a bigger initial text size makes reading or scanning a page for information easier and is more polite towards the reader. Someone who prefers small text size will be able to read bigger text whereas someone who prefers bigger text will not be able to read small text. Again, a perfectly valid point. However, to mix my own argument into yours (if I may)... Someone who prefers small text size will be able to read bigger text... but may not know how to reduce it to their preferred size. Whereas someone who prefers bigger text will not be able to read small text... but is perhaps more likely to be aware of how to enlarge it to suit their needs. But now I'm repeating myself, so I think I'll shut up for a while (apart from a couple of other replies). Blimey, this turned into quite a thread. But then the font sizing thing always evokes passionate reactions I guess. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Font sizing: top down or bottom up
On 5/9/07 (01:18) Felix said: I believe I've already explained up thread that they do, in _web_designers_as_a_group_ having a personal skew/bias/preference in favor of things small generally, part of the nature of the kind of detail-oriented people who gravitate into web design. You mentioned that before, along with the fact that you have no actual hard evidence of it but that the statement is born out of your own observations. Nevertheless, you want me to accept it as part of your argument. That's fine, I have no problem with that, and in fact I'm fairly sure that your point is true. When I made the observation that I do not believe that most people's default settings are *chosen* but just happen to be whatever came out of the box, that was also based upon my own observations and anecdotal evidence. However, you dismiss my opinion/personal experience with glib links to 'Proof By Assertion' and seemingly just refuse to even consider the notion. You make some good points in your posts, Felix, and in fact I find myself coming around to the 100% default camp (after all, I never started this thread with any axe to grind) but I find it difficult to give your arguments the credit that they are perhaps due whilst you won't permit others the same debating strategies that you employ yourself. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Font sizing: top down or bottom up
On 6/9/07 (16:41) Jens said: I do admit the first time I read your initial post I cringed and screamed AAARGGGHLXX! ;-) Yeah, fair enough, and I knew that many would share your reaction. But the question in the original post was one that I really had divided opinions about and wanted to hear other people's thoughts. the ensuing melee has perhaps not convinced me entirely either way, but has nudged me in one direction over another, so it's been valid (for me at least), and thank you to all who participated. Irrespective of your assumption about who would be more capable of resizing text I think you somehow missed my point. No, I understood you. I just wanted to try throwing it back with a bit of personal spin and see what you made of it. When you say: People who require larger text can not instantly access information on a page with small text size I don't particularly disagree with you. I would, however, be /very/ interested to find out how many of the people who require 'larger' text (eg. people who find the cited 'small-text' sites -- yahoo, NY Times, etc -- hard to read) already have their browsers set up to make the necessary corrections, either by setting a large minimum font size, or by clicking the 'Ignore font sizes set by page' box (that's just an IE thing I think). I think that information would be enlightening. The issue of whether an unchanged default setting, except when left as it is by deliberate choice, should be considered a 'user preference' in the context of most people have their preferred size set to 16px has not really been decided for me, but maybe it's like trying to prove a negative. Certainly plenty of others on this list are satisfied that it should be considered so in the absence of evidence to the contrary, and maybe I'll have to leave it at that. Or start saving up to commission a massive study. Nah. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Font sizing: top down or bottom up
On 6/9/07 (17:58) Tony said: we're in a catch 22 as I see it. if the browser manufacturers make the defaults smaller, then a lot of web sites break. If you don't adjust the font size at all it looks bigger than expected to *most* users - and if the client is looking at their site compared to everyone else they also expect it to look similar, not have massive fonts. perhaps the wise and good on his list would make it blindingly obvious which is the best and most pragmatic way to set font-size to conform to the norm - i.e. smaller than the default *without* messing up the minority of web users who have changed the defaults in their browser. which I think is the crux of the matter, since in the absence of hard evidence all our feelings on who has set what and what they think to the norm is pointless. I'd like a foolproof way of pleasing my client, without upsetting anyone. is there a way? Tony, next time I think I'll get you to write my original post. Clarity. I like clarity. ;-) -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Font sizing: top down or bottom up
on a page-by page basis using browser controls. 6. Does this not make a stronger case for a 'Bottom Up' approach to text sizing, where the designer specifies whatever type size he feels makes the site look and feel the way he/she wants it to? Designing a page with clunky 16px height type in mind feels to me like a 'lowest common denominator' approach, especially when my gut instinct tells me that the 'corrective measures' (ie. scaling text to get the page to a level agreeable to the specific viewer) are far less likely to occur if I design with larger text than if I design with smaller text. Would a Bottom Up approach not have more chance of giving everybody what they want to see? If you're still reading by this point, thank you. I look forward to hearing everybody's opinions! -- Rick Lecoat [1] I am not talking about the merits of general accessibility coding -- alt and title attributes, semantic (x)html, table headers/scope, avoiding px/pt units, etc, which are all essential components of any accessible design. I'm *just* talking about baseline type sizes. [2] The more 'visual design' a page has applied to it, the more likely this is to be true -- a page that simply displays the text of a research paper often has no text size specified at all, whilst a typical designer's page will specify text sizes in quite some detail [3] I fully accept that this is not everybody's viewpoint. I don't even know if it is a majority viewpoint. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Font sizing: top down or bottom up
On 5/9/07 (15:18) Patrick said: What usually gets me with this conversation is: assuming users actually do actively change their font size to their preferred one, they'll still be visiting sites other than yours. If they indeed found that the majority of other sites out there have undersized the text, they would then have set the default sizes to be bigger on their browser. What happens then if your correct site is displayed on their browser? Would it not be overcompensating then? The principle is sound, but in practice it doesn't take into account the fact that the oh so hard done by users would already have coping strategies / settings in place to deal with their general web browsing, which could go counter to the assumed they'll have it set to their preferred size (since, assuming that they did set the size, it wouldn't be preferred, but enlarged to compensate for small font sizes generally employed). Thanks for your reply, Patrick; You're right, it's a very 'chicken and egg' situation. In the ideal world every site would have content text set to a base size of 100%, and every user would have their browser tuned to their own preferred text size. But clearly that's not the world that we currently inhabit. How best to navigate this situation to achieve the great real-world results is what I hope this topic will help me work out. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Font sizing: top down or bottom up
On 5/9/07 (15:21) Felix said: However, this brings us back to the fact that for many people the browser default text size of 16px is too large Who made this a fact? Okay, perhaps some sloppy writing on my part; I tried to be clear all through my original post that I was presenting my own ideas/enquiries, not handing down facts. Perhaps I should have written: However, this brings us back to the fact that for SOME people the browser default text size of 16px is too large ...'some' being myself, at least a few other (non-design) friends of mine, and anyone else who feels the same way. 'Many' is subjective, I grant you. (The 'proof by assertion' link was perhaps a little condescending?) 1-user presumptively is the one in position to determine what works best Yes they are in position to choose what works for them, but they appear not to do so. Anecdotal evidence from people who've conducted usability testing seems to indicate that the majority or web users are unaware that they are in a position to make any adjustments in this area. The possible exception, as I suggested, being those with accessibility 'issues' since they have more to gain by being acquainted with their browsers' text sizing capabilities. 2-the effort that went into choosing, and continuing to choose, particular defaults by the browser suppliers I have no hard information about how much investigation the browser vendors carried out prior to choosing the default text sizes. I'd like to know more about the process they went through, though, I imagine that it would be quite illuminating. If you do have any such info, please share. It's the right thing do do, because anything else is a anarchistic and rude. Anarchistic? Rude? Hmm. I'm just asking questions here. It's starting to get a bit confrontational. Just to bring it back to earth, the nub of the point I was trying to make is that simply this: If *somebody* is going to be doing some resizing of text when they view the page, doesn't it make more sense to design in such a way that the person more likely to want to resize is the person more likely to know how to? -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Font sizing: top down or bottom up
On 5/9/07 (20:15) Felix said:
The point of pointing that page was the repetition factor, that people
eventually believe as fact anything sufficiently repeated, whether
proven true or otherwise. In web development circles, the defaults are
too big is a mantra that is not even close to a proven fact
That was, in part, why I started this thread; I felt (and still feel)
that the notion of you MUST design for 100% of your users' default text
size because that is their preferred text size was becoming a mantra.
People sometimes repeated it dogmatically, without really thinking about
it. Dogmatism worries me.
The idea that maybe people are not *choosing* these defaults seems
increasingly deemed to be a heresy, and anybody who dares to think gee,
I actually prefer the look of this page with slightly smaller type
risks being thoroughly pilloried as an artsy-fartsy-designer-type
completely divorced from the real world. That worries me too, because
it's dismissive.
I'm not saying that the {font-size:100%} argument is wrong, but I am
saying that treating it as dogma is probably not the thing to do. If we
didn't keep asking questions and revisiting these things, then we'd
probably still be creating table-based layouts, right?
--
Rick Lecoat
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Font sizing: top down or bottom up
On 5/9/07 (21:17) Rimantas said: That was, in part, why I started this thread; I felt (and still feel) that the notion of you MUST design for 100% of your users' default text size because that is their preferred text size was becoming a mantra. And that is only an assumption. Default font size was chosen by browser vendors, not users. Not many know they can change it. Even less who know do it. My point exactly. (Felix argues that the browser vendors arrived at their default size after long and careful research, but AFAIK said research remains hearsay). To restate my earlier point (hopefully with greater clarity): No matter what you do, people will look at a page and (probably) either say the type is too big or the type is too small. In either case they can adjust it accordingly, except that those who want to make it smaller (eg. those without accessibility issues) are *perhaps* less likely to know how to. And *perhaps* that's one argument for designing with smaller type as a baseline. I could be way off base of course, but that's why I want to thrash it out here, amongst the wisdom of my peers. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Font sizing: top down or bottom up
On 5/9/07 (22:43) Felix said: 4-Not all web users are morons to whom the implicit meaning of Personal Computer (PC) is lost. Personal means under and subject to the control and personalization of the computers they own and/or use. That most don't go beyond setting of desktop wallpaper and screensaver in personalizing is no reason to assume that any change you make that affects what they see is likely to be better for them than if you didn't. That you like smaller fonts than the defaults is no reason to assume they do too. There is a very wide gulf between a) saying that many (perhaps even the majority) of web users are unaware that changing the default text size is an option and b) saying those people are morons. Conversely, not being a moron does /not/ imply that the person has changed their defaults. I can think of a large number people just within my (non-IT professional) friends and family who would have no idea about tinkering with their browser settings in that way. Are they morons? Of course not. But the fact remains that they have never adjusted their defaults. That you like smaller fonts than the defaults is no reason to assume they do too. Correct. Nor is it a reason to assume that they do not. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] IE, alpha transparency and sliding doors...
/Slightly/ off-thread, but... On 21/8/07 (04:02) Joseph said: Safari will sometimes show a different hue of your color than other browsers will when .png images set as backgrounds. I believe that this is a product of PNGs containing a built-in gamma profile; many browsers ignore it (as they ignore other colour profile info) but Safari (and maybe some others?) adjust the colour render accordingly, meaning that the image is displayed with a slightly different gamma to 'non-gamma' elements (eg. GIFs and background colours set in HTML/CSS). A solution to this is reported to be GammaSlamma http://tinyurl.com/ yuchvh which strips out the gamma information. I say 'reportedly' because although I've downloaded it and plan to give it a whirl, I have not, as yet, had opportunity to try it out. But just thought in case it helps anybody. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] When is invalid CSS okay?
This is probably one of those questions that divides the audience (no, it doesn't involve brussel sprouts), but here goes: As exponents of web standards, we all know that one of the bedrock basics is that our code should validate -- both (x)html and css. But we also know that IE(win) is something of a recalcitrant beast and must occasionally be spanked into order with some hacks and/or conditionally commented stylesheets. And sometimes the workarounds required are non-valid CSS. So, is it considered 'okay', in a web standards sense, to have a non- valid bug-fixes stylesheet working alongside your perfect, pristine, uiber-valid main stylesheet? To give an example, if I were to have an IE-specific stylesheet with a lot of stuff like filter: alpha(opacity=50) in it -- which, a quick Google check informs me, does not validate -- would that be seen as a breach of web standards? Perhaps this whole issue is me getting too focused on the nitty gritty, but I'm in the process of moving from 'old-school' to web standards and am trying very hard to get it 'right'. This is just one of the goal posts that I'd like to clearly identify. Thanks. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] When is invalid CSS okay?
On 22/8/07 (12:12) [EMAIL PROTECTED] said: Are you serving up your hacked stylesheet to everyone, or just to those crippled by IE? The latter is far more acceptable than the former, in my opinion. Just the victims of IE. I'm of the opinion that hacks -- ie. workarounds exploiting browser bugs and loopholes in css implementation -- are an inferior solution compared to serving valid browser-specific css via conditional commenting, simply because the bugs and loopholes can get fixed or closed at any time, potentially breaking hack-based css. Cond.comments, on the other hand, are an official M$-approved technique and as such should be around for the foreseeable future. But sometimes the CSS that needs to go into the Conditionally Commented stylesheet isn't valid -- IE's filters being a prime example. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] When is invalid CSS okay?
On 22/8/07 (12:12) Georg said: It is considered bad, but necessary and therefore acceptable by most web designers/developers. That's what I thought, Georg, but it's good to hear it confirmed -- seeing as how we don't live in that 'ideal world' that I keep hearing so much about. 'Conditional comments' for IE versions provides us with a practical separation-solution, but the hiding-effect (that the validator can't see the separate and non-valid workaround) doesn't make the non-valid workaround more valid. Thus, my personal preference is *not* to use 'conditional comments' unless there's no other way to achieve separation and prevent other _browsers_ from being disturbed by the non-valid workarounds. I see no point in hiding my sins, although I daily hide lots of IE garbage as a result of the separation-process itself. I fully agree that separating the non-valid 'fixes' stylesheet from the main one does not make it any more valid. However, I'm curious about why your personal preference is for NOT using Conditional Comments; you seem to equate them with trying to hide embarrassing non-valid code, and I'm sure that some designers might use them for that. I'm certainly not trying to hide anything by using CCs (to be honest, I have a hard enough time convincing clients that valid code is even a benefit to them, so they aren't going to care if my IE stylesheet doesn't validate if, indeed, they even understand the concept). I use them primarily because they segue nicely into my deep-seated anal retention (everything subdivided and in its own file). Best... -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] When is invalid CSS okay?
On 22/8/07 (12:57) Barney said: ? Invalid *ML will force browsers into defective behaviour. If your markup isn't written according to the very clear spec, the browser has to make assumptions. Different browsers make different assumptions at different times - you are leaving yourself open to all sorts of trouble. Don't do it! ? Invalid CSS is written because *perfectly valid CSS*, especially in ambitious designs, *will cause different browsers to behave in different ways*. In complete opposite to invalid markup, invalid CSS often has to be used to secure consistent behaviour accross circumstances. Absolutely. Just to be clear, then, I was talking specifically about invalid CSS, not (X)HTML. The markup MUST validate, as you say. Otherwise it doesn't go out the door. PS: I just read your post regarding the danger of hacks getting fixed. I re-read that post of mine and it might have sounded like I was wagging an admonishing finger at anyone who uses hacks rather than Cond.Comments. Nothing could be farther from the truth. If I can solve a problem equally well using either technique then I'd rather go the CC route rather than doing the style-hiding/applying in the stream of the main CSS file via hacks... but that's a personal preference. And it's a recent preference, too -- in the past I've sure used my share of hacks in an all-in-one CSS file. So no finger wagging here. One thing's for sure: I'm here to learn, not preach. Best regards; -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] When is invalid CSS okay?
On 22/8/07 (14:41) Georg said: The real reason for me to not use 'CC' for separation, is that the versioning goes on on HTML level and adds unnecessary garbage to every single page. That's a very good point. And, I was about to follow it up with I wish there was a way to use conditional comments inside CSS when I read further down your message and discovered that you'd answered it for me. Cheers. In fact, once I read it I suddenly remembered (doh!) that I used something very similar a few months ago, but had completely forgotten about it: @import url(allBrowsersStyle.css); /* The following (non-valid) import rule will be seen by IE (Win) 5-7*/ @import ieWin-fixes.css; The IEWin5-7 import hack was culled from this page: http://imfo.ru/csstest/css_hacks/import.php I must be tired. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] IE, alpha transparency and sliding doors...
On 22/8/07 (20:15) Andrew said: I may be mistaken here, but I think the gunk can be dispensed with by using Save For Web rather than simply Save or Save As. I believe that a PNG's gamma information is retained in a Save For Web operation -- certainly I've seen colour casts in PNGs that I've used in web pages (eg. a flat hex colour in a PNG placed beside the same hex colour specified in the CSS), the PNG having been saved for web in Photoshop (I can't always be bothered going via ImageReady). Other things such embedded icon information /are/ removed, however, and can mean considerable savings in file size. Although it may be gunk on the web, this information is essential to achieving consistent high quality in print. Indeed, primarily colour profiles. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Standards and Blogs
Hi; Does anyone have any views regarding the best blogging tool (server- side, not hosted) from a web-standards perspective? I'm looking at setting up a business blog at the moment and although I'm wading through 'Blog Design Solutions' by Andy Budd et al I'm still not certain which one to settle on -- Movable Type, Experession Engine and Wordpress all have their pros and cons, but I'd like the blog pages to be as standards- friendly as possible (I assume that they are never going to be completely so on account of the blog-specific template tags and such). If one has never gone down the blog route before it's all a bit daunting and techno-befuddling, so any advice is welcome. Many thanks as always. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Standards and Blogs
On 13/8/07 (11:57) John said: I've only used Expression Engine and Wordpress but they'll output whatever HTML you put into your templates so how standards-friendly is entirely up to the user and there is no limitations imposed by the CMS. That's good to know John, thanks. I was concerned that the blogging scripts might be churning out hideous (X)HTML that makes us all bleed from the ears. I was also originally working on the assumption that no blog page will validate on account of the template tags, but then it occurred to me that the tags get replaced with regular text in the actual served page, so there should be no problem. Is that correct? (As you can tell, I'm starting to get mildly out of my regular territory here...) -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Standards and Blogs
On 13/8/07 (13:01) Christian said:
You can even make a Wordpress blog (and probably the others) output
valid HTML 4 instead of XHTML. Tutorial:
http://www.christianmontoya.com/2006/02/13/serve-your-weblog-as-html-401/
That's a really useful tutorial Christian, thanks.
One question though: On your tutorial page, you appear to put some PHP
code above the doctype in order to remove any instance of self-closing
tags. Specifically:
That's all you need. The full header looks like this:
?php
function fix_code($buffer) {
return (str_replace( /, , $buffer));
}
ob_start(fix_code);
?
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN
http://www.w3.org/TR/html4/strict.dtd;
html lang=en
Does this not throw Explorer into quirks mode? I was under the
impression that anything (other than whitespace, maybe) before the
doctype had this effect.
Is PHP code an exception to this rule? or am I way off base here?
--
Rick Lecoat
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Standards and Blogs
On 13/8/07 (15:27) minim said: Rick, PHP shouldn't affect IE at all because it gets calculated on the server, so by the time the page gets to the browser, it's 100% HTML/XHTML/whatever - no PHP is seen on the client-side at all. Cheers, C A ha. Good to know. Thanks. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] setting fontsize in body
At 23:09 (London time), on 3/8/07, [EMAIL PROTECTED] said: The only reasonable current assumption is that the users' defaults are exactly as they want and/or need them to be. Assuming otherwise with anything other than medium, 1em or 100% in body flowing through to main content unaltered could somehow be any improvement is thus an inexcusably rude imposition. http://mrmazda.no-ip.com/auth/bigdefaults.html I fully understand and appreciate the above argument, and the link provided makes a strong and persuasive case. No question about that. However, I always get a nagging doubt whenever this issue is raised. Because whilst the argument for leaving default text sizing at 100% of the browser's default size, and for not making assumptions about the user's settings, is a good one, it does /itself/ make the assumption that the default has been chosen /proactively/ by the user. In other words, the user has looked at text displayed using the default text size and thought That's just right for me or That's not right for me, I'll change it in my browser settings. And I always wonder how many people, particularly the older generation who (without wanting to generalise too much) may not be quite as tech- savvy as their kids, actually have no idea that the default text size can even be adjusted, and possibly look at browser-default text and think That text looks a bit big and clunking. But I assume that there's nothing I can do about except use the text resizing control in IE. What I'm asking is: Do we /know/ that the majority of people have their default text set according to their requirements, or is it possible that a large number of those people (particularly those people who will most benefit from an accessibly designed site) are simply viewing pages at default size because, to put it bluntly, they don't know that there's any other way? Now, I'm NOT saying that this /is/ the case. I'm really not. But I'd love to know if there is any research data on this subject because, whilst I'm all for using default sizing if it really IS about respecting the viewer's choices, it would be a shame if it turned out that all we were really supporting was a lack of awareness of browser settings and forcing people to look at slightly uglier pages than they might otherwise want or need to. I'm not convinced by my own argument, I'm just throwing the idea out there for discussion, is all. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Please help! CSS/IE Link Color Problem
At 19:23 (London time), on 4/8/07, [EMAIL PROTECTED] said: In the light of the pseudoclass and class having the same name and smart-alec browsers trying to correct perceived errors, could this then be a case of misinterpretation by IE6? Might it not be better to avoid using 'reserved' words for class/id names in case this sort of thing happened (I guess a test would be, if the class name were changed, does IE6 still not recognise the issue)? It's not something I've ever encountered myself, just wondering... I agree with this; although I don't know if it is the root of Cole's problem, I would always try and avoid using reserved names for other purposes (in this case, as noted, you've given your class the same name as an existing pseudoclass that most browsers (not IE) will recognise and act on automatically. Whilst it's true that it /shouldn't/ make any difference (in an ideal, bug-free world) because .active and :active are /technically/ different, I would say 'why take the chance'? Cole: Try renaming your css class to a non-reserved word like 'activated', update the markup accordingly, and see if it helps. It might not, but at least then you'll know that your problem is definitely NOT caused by using a reserved name, and can cross it off the list of suspects. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] setting fontsize in body
At 12:13 (London time), on 7/8/07, [EMAIL PROTECTED] said: does Jakob Nielsen's research count as creditable research? Absolutely, of course. I would like to draw your attention to his Alertbox column, where he repeatedly states that tiny text is one of the worst design mistakes. To quote from his Top Ten Web Design Mistakes of 2005 at http://www.useit.com/alertbox/designmistakes.html : Bad fonts won the vote by a landslide, getting almost twice as many votes as the #2 mistake. About two-thirds of the voters complained about small font sizes or frozen font sizes; And nobody could make a case for type that is to small to read being acceptable. No me, certainly. But I just wondered how accurate the idea that 'type that is smaller than the user's specified browser default is too small to for that user to read' really is? Because we don't know that they /did/ specify it. The browser vendor probably specified it. At the same time, however, I also accede to David Dorward's point that browsers go through much usability testing before release. Of course, if we are to trust that usability testing to provide an accurate gauge of what the majority of people consider a comfortable reading size, then the fact that different browsers specify different default sizes slightly undermines that. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
