Re: [WSG] Deprecated "start" for lists confirmation
> Thanks for the responses so far! Does this mean that today's standard is to > not break a list apart ever??? No, it means when using strict doctypes the attribute is not allowed. If you need both attribute and validation use a transitional doctype or you might try using HTML5, where the start-attribute is reintroduced: http://dev.w3.org/html5/spec/Overview.html#the-ol-element Cheers, jens -- Jens Brueckmann http://www.yalf.de *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Another IE issue with CSS
2009/5/6 Lynette Smith : > Good afternoon > > http://www.westernwebdesign.com.au/zoobridal/bridegallery.html > > Pages at issue in IE are bridegallery.html and bridesmaidgallery.html. > Fine in FX and others. Good morning Lynette, I am loth to say that your pages do not work at all in Opera (9.63, Linux). This, and the IE problems are probably caused by the plethora of markup errors. You may want to take care of purge your source of any HTML errors before trying to adjust any CSS problems. Cheers, jens -- Jens Brueckmann http://www.yalf.de *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Firefox Ignoring Stylesheets
> <http://www.markboulton.co.uk/examples/guardian/> Your problem is neither markup-related nor script-related. It definitely stems from the wrong media type of the Style Sheets, as others have already pointed out. Test it yourself: http://cgi.w3.org/cgi-bin/headers?url=http%3A%2F%2Fwww.markboulton.co.uk%2Fexamples%2Fguardian%2Fcss%2Fscreen.css The media type is text/html instead of text/css Cheers, jens -- Jens Brueckmann http://www.yalf.de *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Facebook downgrading support for IE6
2008/9/2 Gregorio Espadas <[EMAIL PROTECTED]>: > I like the IE6Blocker from Chris Coyier, check it out at > http://css-tricks.com/ie-6-blocker-script/ In my opinion this is worst practice. First priority should be for a website to make the content available to as many people as possible. Browser discrimination is at least as bad as accessibility and usability violations. "At least" because the latter may be caused by lack of knowedge of some guidelines, whereas not being able to deliver a passable page to older browsers is sheer laziness or dumb imbecility. Apart from my rejection on principle, this method of user agent sniffing via javascript is prone to fail in many circumstances. The best way to target IE6 (or below) would be to use conditional comments. ONLY if a web application absolutely relies on certain javascript methods not available in old browsers may a user be warned about difficulties in using this application. In these cases, detection should be done by testing said methods, not by user agent sniffing. Cheers, jens -- Jens Brueckmann http://www.yalf.de *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Correct markup of fieldset
2008/8/8 Michael Horowitz <[EMAIL PROTECTED]>: > > I want to make sure I understand you are saying that input type really is > required to be under fieldset instead of directly under form Hi Michael, no, INPUT elements are not required to be inside FIELDSET elements. In (X)HTML documents with strict DTDs, the FORM element must not contain any inline elements as direct children. This means, an INPUT element, which is an inline element, must not be a child of a FORM element. It follows, INPUT elements must be children of block elements. Block elements are listet, e.g. in the HTML 4.01 strict DTD at http://www.w3.org/TR/html401/sgml/dtd.html#block Cheers, jens -- Jens Brueckmann http://www.yalf.de *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Correct markup of fieldset
2008/8/7 Paul Collins <[EMAIL PROTECTED]>: > > This is one I've never been sure of; should the submit button be in a > seperate fieldset, or should it even be in a fieldset at all because it is > not a group of fields; it's a button on it's own. > > For example: > > > > Search > > > > > > As opposed to: > > > > Search > > > > > Hi Paul, in strict (X)HTML documents, the FORM element must only contain block elements [1]. Therefore, an INPUT element as a direct child of FORM would be invalid for documents with strict DTDs. Using transitional DTDs, the FORM element may as well contain inline elements such as INPUT. Apart from considering the validity of the markup in question, the complexity of the form could guide one. In your example with a single text input field one might view the submit button to be part of this same fieldset. In more complex forms, e.g. a feedback form which requires input of name, e-mail, and a textarea for free text, the submit button would rather require its own FIELDSET or DIV or P parent element. Cheers, jens [1] http://www.w3.org/TR/html401/interact/forms.html#edef-FORM -- Jens Brueckmann http://www.yalf.de *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] S separators and TACG
2008/7/23 Designer <[EMAIL PROTECTED]>: > I've been examining what happens if you put something inside an end tag, > such as . The validator says: > > "name start character invalid: only S separators and TAGC allowed here." > TAGC means the "tag close" character, which is > The S Separator is the "whitespace separator", meaning e.g. SPACE or line break. Cheers, jens -- Jens Brueckmann http://www.yalf.de *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Marking up company logo
> I said it may explain ALA's approach, but that doesn't mean I like the idea > ;) > fwiw, I never use more than one H1 per document since I'm using it for site > title. imho, if H1 is used for site title it can't be used again in the > page. I agree. Two level-1 headings seem somewhat confusing to me. How about putting both logo and title in the heading? Something like Page Title This associates the title with the company. Anchor/image may be absolutely positioned with CSS, in unstyled pages the image is in line with the title and in UAs not displaying images the alternative text, the company name, precludes the title. For the title TAG, I recommend the opposite order: first Page Title, then Company Name. Many benefits - any disadvantages? Cheers, jens -- Jens Brueckmann http://www.yalf.de *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] [OT] Posting [was:Best way to hide form legends?]
> By that I meant someone who sees [...] > > -Original Message- > > I've got a search box [...] A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- Jens Brueckmann http://www.yalf.de *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Best way to hide form legends?
> I've got a search box and login area that I want to use a fieldset and > legend on for accessibility but I don't want to show the legend to normal > users. This might work .hidden { text-indent: -999em; padding: 0; } Cheers, jens -- Jens Brueckmann http://www.yalf.de *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Input tag - closing tag optional?
Hi Dusan, > It won't work in any other browser I know of as well. See this demo > case: > http://dusan.fora.si/blog/wp-content/uploads/2007/07/tags.html Your demo shows very well why serving XHTML as text/html is harmful. When the document's media type is changed, you will see the expected results, i.e. your document is rendered as application/xhtml+xml: http://www.lairx.de/071126/tags.xhtml Cheers, jens -- Jens Brueckmann http://www.yalf.de *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] WCAG conformance and checking
Hi Simon, > I realize no automated checking is foolproof...but are there any good > automated tools to assist in WCAG conformance checking? ( I hear "cynthia" > mentioned from time to time...any good/any details? Any others? > > Any good Firefox extensions/plug-ins? while some guidelines can be checked automatically, others have to be checked manually. Apart from Cynthia, which is ok, I would strongly recommend TAW³, which is available as an online service, a standalone version for download and as a Firefox extension. You will find it at http://www.tawdis.net/taw3/cms/en Cheers, jens -- Jens Brueckmann http://www.yalf.de *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Catch 22 list problem
> Next question: How would a custom DTD affect standards-compliance vz. > quirks mode. That is a subject that I have no knowledge about. > > > I prepared a short example at http://lairx.de/071011/numbering-lists.html > > Triggers strict mode in Firefox - what about MSIE, Opera, Safari, etc? Opera 9.23/Win32+Linux and MSIE 6 SP1 both render in strict mode as well. I do not know about Safari though. Cheers, jens -- Jens Brueckmann http://www.yalf.de *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Catch 22 list problem
Hi Lars, > A. is not allowed in strict HTML 4/XHTML 1.0, Spec says > "use CSS". > > B. I want to start at 3. > > C: CSS has no means to specify a start value! > But regardless of whom I should blame there is a problem to solve. I > would like to know which solution that you would use and why. there do exist counters in CSS, see http://www.w3.org/TR/CSS2/generate.html#counters but, as you might have guessed, they are not supported by Internet Explorer. As you already observed, list counters are rather content than presentation, so either CSS or JavaScript are somewhat questionable for achieving your aim. So personally, I would either ignore the validation problem or use a customized DTD. I prepared a short example at http://lairx.de/071011/numbering-lists.html It uses an extended DTD, where the VALUE attribute for the LI element and the START attribute for the OL element have been added. Furthermore a CSS example using automatic numbering is provided. Cheers, jens -- Jens Brueckmann http://www.yalf.de *** 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
> Blimey, this turned into quite a thread. But then the font sizing thing > always evokes passionate reactions I guess. I do admit the first time I read your initial post I cringed and screamed AAARGGGHLXX! ;-) > 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. Irrespective of your assumption about who would be more capable of resizing text I think you somehow missed my point. I will try and make myself more comprehendible. Given that the primary aim of a web page is to communicate information - here in the form of text. Larger text allows everybody to access this information instantly, whereas smaller text establishes a barrier for those, who are not able to read small text. People who prefer smaller text might not like your page with large text, but they can instantly access your information. People who require larger text can not instantly access information on a page with small text size. In short, text size is a question of preference versus requirement. Cheers, jens -- Jens Brueckmann http://www.yalf.de *** 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
Hi Rick, > 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 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. 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. Cheers, jens -- Jens Brueckmann http://www.yalf.de *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] setting fontsize in body
Hi Rick, > 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." does Jakob Nielsen's research count as creditable research? 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;" which then links to the famous "Let Users Control Font Size" at http://www.useit.com/alertbox/20020819.html Cheers, jens. -- Jens Brueckmann http://www.yalf.de *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] o & 0
> a font for the web that has a distinction between the > uppercase letter O and the number 0. > If such a font exist, which is it? Distinction - in which way? Have a look at Arial, uppercase letter O is nearly round while number 0 is distinctly oval. Cheers, jens -- Jens Brueckmann http://www.yalf.de ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **