RE: [WSG] Styling Text...
Speaking of plain text posts to this mailing list, I'm receiving an increasing number of posts which contain only a signature block. * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help * (I'm lucky when someone replies and includes the original text.) Is this because I'm not using a standard e-mail client? I'm using Lotus Notes 6.5.1 I suppose it cuts down on the amount of reading I have to do. Here's my (employer's) signature block ... = CAUTION: This message may contain both confidential and privileged information intended only for the addressee named above. If you are not the intended recipient any dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immediately, then destroy the original message. Any views expressed in this message are solely those of the individual sender, except where the sender specifically states them to be the views of Peregrine Semiconductor Australia. All care has been taken to screen this message and attachments for computer viruses, however, we accept no responsibility for viruses it may contain. Peregrine Semiconductor Australia Pty Ltd 8 Herb Elliott Ave., Homebush 2140. NSW Australia. Ph. +612 9763 4111 Fax. +612 9746 1501 = * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Styling Text... (Andy Budd Accessibility Quiz)
Geoff Deering wrote: That is a very very poor quiz, and shows the author does not understand WCAG1 very well at all. Actually, it shows more that he does not know how to form the proper questions. The quality of the questions and quiz aside, why do you think the author doesn't understand WCAG!? My impression was the opposite. Hi Geoff, How sweet. Obviously it was just meant to be a bit of fun, but I guess you always get one or two party poopers. I'm planning to post up my answers later this evening, so please feel free to come by my site and rip them/me apart in person. Andy Budd * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Styling Text... (Andy Budd Accessibility Quiz)
Andy, You might want to run those by me since I help develop the Web Content Accessibility Guidelines. Lee Roberts -Original Message- From: Andy Budd [mailto:[EMAIL PROTECTED] Sent: Monday, July 05, 2004 3:50 AM To: [EMAIL PROTECTED] Subject: Re: [WSG] Styling Text... (Andy Budd Accessibility Quiz) Geoff Deering wrote: That is a very very poor quiz, and shows the author does not understand WCAG1 very well at all. Actually, it shows more that he does not know how to form the proper questions. The quality of the questions and quiz aside, why do you think the author doesn't understand WCAG!? My impression was the opposite. Hi Geoff, How sweet. Obviously it was just meant to be a bit of fun, but I guess you always get one or two party poopers. I'm planning to post up my answers later this evening, so please feel free to come by my site and rip them/me apart in person. Andy Budd * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help * * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Styling Text... (Andy Budd Accessibility Quiz)
Title: RE: [WSG] Styling Text... (Andy Budd Accessibility Quiz) If you don't have anything constructive to say, don't say anything at all (please) -Original Message- From: Andy Budd [mailto:[EMAIL PROTECTED]] Sent: Monday, July 05, 2004 3:50 AM To: [EMAIL PROTECTED] Subject: Re: [WSG] Styling Text... (Andy Budd Accessibility Quiz) Geoff Deering wrote: That is a very very poor quiz, and shows the author does not understand WCAG1 very well at all. Actually, it shows more that he does not know how to form the proper questions. The quality of the questions and quiz aside, why do you think the author doesn't understand WCAG!? My impression was the opposite.
CLOSED Re: [WSG] Styling Text... (Andy Budd Accessibility Quiz)
Hi all WCAG is on topic -please discuss all you want, but address the topic, not the person. The list is here to provide a constructive discussion on web standards and accessibility. If you want to be destructive or have a beef with the author, don't do it here as your subscription will be removed. Regards James http://webstandardsgroup.org/mail/guidelines.cfm That is a very very poor quiz, and shows the author does not understand WCAG1 very well at all. Actually, it shows more that he does not know how to form the proper questions. --- The quality of the questions and quiz aside, why do you think the author doesn't understand WCAG!? My impression was the opposite. * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Styling Text...
On 7/3/04 11:38 PM Geoff Deering [EMAIL PROTECTED] sent this out: It is better practice to stop using such elements, especially when there are other elements that serve the same purpose, but are more semantically correct and accessible. Would someone please post a URL to a rousing, thorough, authoritative article re: semantically correct coding? TIA Rick Faaberg * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Styling Text...
Geoff Deering wrote: Yes, correct for XHTML1.x, but I can't see it in your reference to http://www.w3.org/TR/xhtml2/mod-inline-text.html#sec_9.12. All the font style elements have been removed in XHTML2. The reference was in regards to sub and sup which currently are valid XHTML2 without any signs to the contrary. It is better practice to stop using such elements, especially when there are other elements that serve the same purpose, but are more semantically correct and accessible I agree with the exception of sub and sup which I agree with the draft in that they have semantic value. You can code your XHTML1.x to be compatible with XHTML2, which when it becomes a recommendation and supported, will mean minimum maintenance by oneself and reap the benefits of future and backward compatibility. Agreed, but I not sure why you would need to switch. As I see it, the worst that will happen is that a future browser won't have a default style for b and i. I often have trouble dealing with the inconsistency of the various W3C specifications, as the W3C does itself. I tend to focus more on the WAI specifications because they (to me) are more refined in this area, and teach on better practices. Except the main topic is validity; accessibility is only secondary. It amazes me that this type of thing has been kept in when there is there is such a strong movement towards semantic and separating structure and presentation. IIRC, it was felt that b and i had some semantic value. I disagree. A similar discussion is now taking place in regards to br and hn. Personally, as I see it, the difference between l and br is one of focus: What's important, that the preceding and following text should be viewed as distinct lines, or gut not the same line. It's a subtle difference, but a difference none the less. * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Styling Text...
-Original Message- From: Mordechai Peller Geoff Deering wrote: It is better practice to stop using such elements, especially when there are other elements that serve the same purpose, but are more semantically correct and accessible I agree with the exception of sub and sup which I agree with the draft in that they have semantic value. They are not part of the Font Style Elements, they are part of the Special Inline Elements. But this shows how even the W3C specs can be misleading, cause FONT is part of the Special Inline Elements, yet B, I, U etc are Font Style Elements. Yes, I agree they have semantic meaning and value. You can code your XHTML1.x to be compatible with XHTML2, which when it becomes a recommendation and supported, will mean minimum maintenance by oneself and reap the benefits of future and backward compatibility. Agreed, but I not sure why you would need to switch. As I see it, the worst that will happen is that a future browser won't have a default style for b and i. For a number of reasons. User-agents that render to a valid DTD render faster and more accurately if the document is valid. If it references a DTD and it is not valid, when it hits the first invalid declaration it jumps back to quirks mode, once it does that, it back to best guess (which many do amazingly well, all considered... just goes to show they can do better). The more you can follow the STRICT philosophy, of separating structure from presentation the more you flexibility in your design and deployment methods, and you get the above advantages. This is also good discipline if you have to start working with generating structure and presentation from XML and XSLT based tools. It also aids you so you don't have to code different front ends for different devices. I often have trouble dealing with the inconsistency of the various W3C specifications, as the W3C does itself. I tend to focus more on the WAI specifications because they (to me) are more refined in this area, and teach on better practices. Except the main topic is validity; accessibility is only secondary. If you take that approach then the structure of you markup may be valid, but semantically meaningless to people using other devices, and others parsers. b and i have no meaning in a screen reader. So the ROI of all your efforts, kind of falls short when you consider you have put in this much great effort to get this far. If you read the accessibility material, those people really know the semantic power of markup better than the average developer. There's a huge knowledge base there. It amazes me that this type of thing has been kept in when there is there is such a strong movement towards semantic and separating structure and presentation. IIRC, it was felt that b and i had some semantic value. I disagree. A similar discussion is now taking place in regards to br and hn. Personally, as I see it, the difference between l and br is one of focus: What's important, that the preceding and following text should be viewed as distinct lines, or gut not the same line. It's a subtle difference, but a difference none the less. b and i are purely visual, they have no semantic meaning when rendered into speech of braille, etc. Geoff * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Styling Text... (Sematics)
-Original Message- From: Rick Faaberg On 7/3/04 11:38 PM Geoff Deering [EMAIL PROTECTED] sent this out: It is better practice to stop using such elements, especially when there are other elements that serve the same purpose, but are more semantically correct and accessible. Would someone please post a URL to a rousing, thorough, authoritative article re: semantically correct coding? http://www.oasis-open.org/docbook/documentation/reference/html/ch01.html#S1- BASIC-CONCEPTS http://www.brainstormsandraves.com/archives/2003/10/07/semantics/ Hope that helps a bit. Don't confuse it with http://www.w3.org/2001/sw/, which has the same, but different context. What I mean is that Semantic Web, in that context, is looking at the same problem with a different plan of attack. But my problem with that is that the only practical way to deliver RDF and OWL is to have your content in XML anyway, and if that is the case, then you should be able to deliver more semantically rich content, but HTML is not as semantically rich a container as RDF and OWL. The W3C are making it exceedingly difficult for the average developer to produce semantically compliant web sites. Seems the only way to do it is with CMSs or from XML Frameworks and Application Servers like Cocoon. Basically, the life of the web developer just become more challenging. Geoff * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Styling Text...
Geoff Deering wrote: They are not part of the "Font Style Elements", they are part of the "Special Inline Elements". But this shows how even the W3C specs can be misleading, cause FONT is part of the Special Inline Elements", yet B, I, U etc are "Font Style Elements". I've done some digging, and I think I've found the source of some of our confusion; in part we're both right and in part we're both wrong. For starters, the HTML4.01 Font style elements include the TT, I, B, BIG, SMALL, STRIKE, S, and U elements, of which only U, S, and STRIKE are deprecated. (FWIW, I partly disagree with deprecating STRIKE, since it's a way of conveying negation.) For the rest: "The following HTML elements specify font information. Although they are not all deprecated, their use is discouraged in favor of style sheets." Now lets skip ahead to XHTML1.0 Modularization and XHTML1.1. Here you have the Presentation Module, which includes the b, big, hr, i, small, sub, sup, and tt elements, which aren't deprecated, and the Legacy Module, which includes some various attributes and the basefont, center, dir, font, isindex, menu, s, strike, and u elements, all of which have been deprecated. As of XHTML1.1, the Legacy Module has been dropped. Moving ahead still further to the future XHTML2, most of the Presentation Module elements have thus far been dropped except for sub, sup, and hr. The newly formed Inline Text Module includes both sub and sup, as well as a bunch of other elements. The hr element has been added to the Block Text Module, but is under consideration for either removing or renaming. Agreed, but I not sure why you would need to switch. As I see it, the worst that will happen is that a future browser won't have a default style for b and i. For a number of reasons. User-agents that render to a valid DTD render faster and more accurately if the document is valid. Both b and i are in, and will forever be in, the DTD for XHTML1.1. If that's your DOCTYPE, then they are valid. The more you can follow the STRICT philosophy, of separating structure from presentation the more you flexibility in your design and deployment methods, and you get the above advantages. If you mean "STRICT" as a proper noun, I disagree because it's part of the XHTML1.0 STRICT DTD. If, on the other hand, you mean "STRICT" as an adjective, then I totally agree. One problem with all caps is that there is a loss of semantic meaning; a common problem with presentational mark-up. This is also good discipline if you have to start working with generating structure and presentation from XML and XSLT based tools. You can do that even with XHTML1.0 Transitional. Except the main topic is validity; accessibility is only secondary. If you take that approach then the structure of you markup may be valid, but semantically meaningless to people using other devices, If I "take that approach" then I'm staying consistent with the topic of this thread. If you go back ant look at various comments I injected into my replies, you will see that I don't support the use of b and i, despite that they are valid. If you read the accessibility material, those people really know the semantic power of markup better than the average developer. There's a huge knowledge base there. Depends on which material you're talking about; they're not all of equal quality. I have a suggestion, go take Andy Budd's Quick Accessibility Quiz and we'll see who scores better. I will admit, after reading the WAI guideline I would have rephrased some of my answers, but Andy was prohibiting that when I took it. I don't know if I got all five correct, but I'm sure I got at least four right. (However, I've been certain and wrong before, so we'll see.) IIRC, it was felt that b and i had some semantic value. I disagree. snip/ b and i are purely visual, they have no semantic meaning when rendered into speech of braille, etc. So then we're in agreement here.
RE: [WSG] Styling Text...
-Original Message-From: Mordechai Peller Geoff Deering wrote: They are not part of the "Font Style Elements", they are part of the "Special Inline Elements". But this shows how even the W3C specs can be misleading, cause FONT is part of the Special Inline Elements", yet B, I, U etc are "Font Style Elements". I've done some digging, and I think I've found the source of some of our confusion; in part we're both right and in part we're both wrong.For starters, the HTML4.01 Font style elements include the TT, I, B, BIG, SMALL, STRIKE, S, and U elements, of which only U, S, and STRIKE are deprecated. (FWIW, I partly disagree with deprecating STRIKE, since it's a way of conveying negation.) For the rest: "The following HTML elements specify font information. Although they are not all deprecated, their use is discouraged in favor of style sheets."Now lets skip ahead to XHTML1.0 Modularization and XHTML1.1. Here you have the Presentation Module, which includes the b, big, hr, i, small, sub, sup, and tt elements, which aren't deprecated, and the Legacy Module, which includes some various attributes and the basefont, center, dir, font, isindex, menu, s, strike, and u elements, all of which have been deprecated. As of XHTML1.1, the Legacy Module has been dropped.Moving ahead still further to the future XHTML2, most of the Presentation Module elements have thus far been dropped except for sub, sup, and hr. The newly formed Inline Text Module includes both sub and sup, as well as a bunch of other elements. The hr element has been added to the Block Text Module, but is under consideration for either removing or renaming. Agreed, but I not sure why you would need to switch. As I see it, the worst that will happen is that a future browser won't have a default style for b and i. For a number of reasons. User-agents that render to a valid DTD render faster and more accurately if the document is valid. Both b and i are in, and will forever be in, the DTD for XHTML1.1. If that's your DOCTYPE, then they are valid. I have no disagreement with this at all. What I am saying is if you develop a large site, that is very well designed and engineered, then, when XHTML2 comes out there are found to be HUGE benefits for using it (this is just hypothetical), then what is the cost justification for then bringing the site up to date, when there were techniques and strategies for future proofing? What I am saying is it is better right now to drop tags like b and i because they are useless to screen readers and a waste of time for future compatibility, when other tags are more appropriate strong and em. That's my point. The more you can follow the STRICT philosophy, of separating structure from presentation the more you flexibility in your design and deployment methods, and you get the above advantages. If you mean "STRICT" as a proper noun, I disagree because it's part of the XHTML1.0 STRICT DTD. If, on the other hand, you mean "STRICT" as an adjective, then I totally agree. One problem with all caps is that there is a loss of semantic meaning; a common problem with presentational mark-up. What I am saying is the basic philosophy behind the STRICT DTD is separation of structure and presentation, and that that approach has a ROI in content management and deployment, especially when sites have to be redesigned and regenerated. This is also good discipline if you have to start working with generating structure and presentation from XML and XSLT based tools. You can do that even with XHTML1.0 Transitional. On large projects, Strict will always be more efficient and have a better ROI overa number of SDLCs. Except the main topic is validity; accessibility is only secondary.If you take that approach then the structure of you markup may be valid, but semantically meaningless to people using other devices, If I "take that approach" then I'm staying consistent with the topic of this thread. If you go back ant look at various comments I injected into my replies, you will see that I don't support the use of b and i, despite that they are valid. And all I said was as far as their semantic value, and their future deprecation, they are not worth using. If you read the accessibility material, those people really know the semantic power of markup better than the average developer. There's a huge knowledge base there. Depends on which material you're talking about; they're not all of equal quality. I have a suggestion, go take Andy Budd's Quick Accessibility Quiz and we'll see who scores better. I will admit, after reading the WAI guideline I would have rephrased some of my answers, but Andy was prohibiting that when I took it. I don't know if I got all five correct, but I'm sure I got at least four right. (However, I've
Re: [WSG] Styling Text...
Geoff Deering wrote: I have no disagreement with this at all. What I am saying is if you develop a large site, that is very well designed and engineered, then, when XHTML2 comes out there are found to be HUGE benefits for using it (this is just hypothetical), then what is the cost justification for then bringing the site up to date, when there were techniques and strategies for future proofing? What I am saying is it is better right now to drop tags like b and i because they are useless to screen readers and a waste of time for future compatibility, when other tags are more appropriate strong and em. That's my point. With XSLT, making the change shouldn't be difficult; that's one of the advantages of XHTML. But then I'd be careful with strong if I were you. They're thinking of giving strong the ax. If you mean "STRICT" as a proper noun, I disagree because it's part of the XHTML1.0 STRICT DTD. If, on the other hand, you mean "STRICT" as an adjective, then I totally agree. One problem with all caps is that there is a loss of semantic meaning; a common problem with presentational mark-up. What I am saying is the basic philosophy behind the STRICT DTD is separation of structure and presentation, and that that approach has a ROI in content management and deployment, especially when sites have to be redesigned and regenerated. Once a DTD is finalized, the philosophies which went into creating it cease being relevant. Philosophy is a matter of grays; a collection of rules for a computer to follow are black and white. Where philosophy can come into play is in how to follow those rules, including, as in this case, which to ignore. The tools has been provided (the DTD); what can and can not be done with it is not open to debate. How to use it is where the question lies. And I believe it's there that we can find agreement. You can do that even with XHTML1.0 Transitional. On large projects, Strict will always be more efficient and have a better ROI overa number of SDLCs. I wasn't saying what is best; just what's possible. That is a very verypoor quiz, and shows the author does not understand WCAG1 very well at all. Actually, it shows more that he does not know how to form the proper questions. The quality of the questions and quiz aside, why do you think the author doesn't understand WCAG!? My impression was the opposite.
RE: [WSG] Styling Text...
-Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Mordechai PellerSent: Monday, 5 July 2004 9:54 AMTo: [EMAIL PROTECTED]Subject: Re: [WSG] Styling Text...Geoff Deering wrote: I have no disagreement with this at all. What I am saying is if you develop a large site, that is very well designed and engineered, then, when XHTML2 comes out there are found to be HUGE benefits for using it (this is just hypothetical), then what is the cost justification for then bringing the site up to date, when there were techniques and strategies for future proofing? What I am saying is it is better right now to drop tags like b and i because they are useless to screen readers and a waste of time for future compatibility, when other tags are more appropriate strong and em. That's my point.With XSLT, making the change shouldn't be difficult; that's one of the advantages of XHTML. But then I'd be careful with strong if I were you. They're thinking of giving strong the ax. If you mean "STRICT" as a proper noun, I disagree because it's part of the XHTML1.0 STRICT DTD. If, on the other hand, you mean "STRICT" as an adjective, then I totally agree. One problem with all caps is that there is a loss of semantic meaning; a common problem with presentational mark-up. What I am saying is the basic philosophy behind the STRICT DTD is separation of structure and presentation, and that that approach has a ROI in content management and deployment, especially when sites have to be redesigned and regenerated.Once a DTD is finalized, the philosophies which went into creating it cease being relevant. Philosophy is a matter of grays; a collection of rules for a computer to follow are black and white. Where philosophy can come into play is in how to follow those rules, including, as in this case, which to ignore. The tools has been provided (the DTD); what can and can not be done with it is not open to debate. How to use it is where the question lies. And I believe it's there that we can find agreement. You can do that even with XHTML1.0 Transitional. On large projects, Strict will always be more efficient and have a better ROI overa number of SDLCs. I wasn't saying what is best; just what's possible. That is a very verypoor quiz, and shows the author does not understand WCAG1 very well at all. Actually, it shows more that he does not know how to form the proper questions. The quality of the questions and quiz aside, why do you think the author doesn't understand WCAG!? My impression was the opposite.
RE: [WSG] Styling Text... (Andy Budd Accessibility Quiz)
Re http://www.andybudd.com/archives/2004/07/quick_accessibility_quiz_now_with_prizes/index.php Q1. There is no correct answer offered by Andy. For starters, to comply with WAI-A youneed tocomply with all WCAG1 Priority 1 Checkpoints, for WAI-AA youneed tocomply with all WCAG P1 and 2 checkpoints, and to comply with WAI-AAA you need to comply with all WCAG P1,2 3 checkpoints. So complying with just one checkpoint within Priority 1 does not mean you comply with WAI-A at all. Q1.a is addressed incorrectly, Andy's question is ambiguous http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-text-equivalent Q1.b This is plain false Q1.c This is also a misrepresentation. There is no such requirement. Take a close look at the real requirement. http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-color-convey Q2.a You are incorrect if you choose this answer Q2.b That's one checkpoint towards WAI-AA, but you need all the rest of WCAG1 P1 2 as well (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-relative-units) Q2.c This is a false statement. (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-avoid-deprecated) Q2.d False Do I need to go any further? Geoff -Original Message-From: Mordechai Peller That is a very verypoor quiz, and shows the author does not understand WCAG1 very well at all. Actually, it shows more that he does not know how to form the proper questions.The quality of the questions and quiz aside, why do you think the author doesn't understand WCAG!? My impression was the opposite.
RE: [WSG] Styling Text...
Do notcount onseeing STRONG removed. There is a purpose for it. B and I are still used in current versions. However, B and I have been removed from all future versions of XHTML. EM is not being removed or questioned. So, why do you think STRONG will be removed? Just because there is a note doesn't mean anything. Lee Roberts From: Mordechai Peller [mailto:[EMAIL PROTECTED] Sent: Sunday, July 04, 2004 5:54 PMTo: [EMAIL PROTECTED]Subject: Re: [WSG] Styling Text... Geoff Deering wrote: I have no disagreement with this at all. What I am saying is if you develop a large site, that is very well designed and engineered, then, when XHTML2 comes out there are found to be HUGE benefits for using it (this is just hypothetical), then what is the cost justification for then bringing the site up to date, when there were techniques and strategies for future proofing? What I am saying is it is better right now to drop tags like b and i because they are useless to screen readers and a waste of time for future compatibility, when other tags are more appropriate strong and em. That's my point.With XSLT, making the change shouldn't be difficult; that's one of the advantages of XHTML. But then I'd be careful with strong if I were you. They're thinking of giving strong the ax. If you mean "STRICT" as a proper noun, I disagree because it's part of the XHTML1.0 STRICT DTD. If, on the other hand, you mean "STRICT" as an adjective, then I totally agree. One problem with all caps is that there is a loss of semantic meaning; a common problem with presentational mark-up. What I am saying is the basic philosophy behind the STRICT DTD is separation of structure and presentation, and that that approach has a ROI in content management and deployment, especially when sites have to be redesigned and regenerated.Once a DTD is finalized, the philosophies which went into creating it cease being relevant. Philosophy is a matter of grays; a collection of rules for a computer to follow are black and white. Where philosophy can come into play is in how to follow those rules, including, as in this case, which to ignore. The tools has been provided (the DTD); what can and can not be done with it is not open to debate. How to use it is where the question lies. And I believe it's there that we can find agreement. You can do that even with XHTML1.0 Transitional. On large projects, Strict will always be more efficient and have a better ROI overa number of SDLCs. I wasn't saying what is best; just what's possible. That is a very verypoor quiz, and shows the author does not understand WCAG1 very well at all. Actually, it shows more that he does not know how to form the proper questions.The quality of the questions and quiz aside, why do you think the author doesn't understand WCAG!? My impression was the opposite.
Re: [WSG] Styling Text...
Chris Stratford wrote: Since BUI etc... are all outlawed and now depreciated... How do you style your inner P text? [snip] Actualy, they haven't changed since html 4. Read all about it here: http://www.w3.org/TR/html401/index/elements.html A small summary of the important inline elements: Semantic elements === em : Indicates emphasis. strong : Indicates stronger emphasis. cite : Contains a citation or a reference to other sources. dfn : Indicates that this is the defining instance of the enclosed term. code : Designates a fragment of computer code. samp : Designates sample output from programs, scripts, etc. kbd : Indicates text to be entered by the user. var : Indicates an instance of a variable or program argument. abbr : Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass., etc.). acronym : Indicates an acronym (e.g., WAC, radar, etc.). Visual elements = tt : Renders as teletype or monospaced text. i: Renders as italic text style. b: Renders as bold text style. big : Renders text in a large font. small: Renders text in a small font. strike and s : *Deprecated*. Render strike-through style text. u: *Deprecated*. Renders underlined text. Strike, s and u are the only deprecated ones. Use the right element/tag for the job at hand. -- Kristof * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Styling Text...
-Original Message- From: Rick Faaberg On 7/2/04 7:31 PM Chris Stratford [EMAIL PROTECTED] sent this out: I am just writing because I have been wondering if there is a better way of styling text. Since BUI etc... are all outlawed and now depreciated... How do you style your inner P text? And here I thought someone just the other day said BUI were still okay (not depricated). It depends which DTD you are referencing as to whether they are deprecated or not, but U is definitely deprecated in everything from HTML4 onwards. And B and I are deprecated for future compatibility because they belong in Font Style Elements, which are all deprecated, as CSS should be used for these. STRONG and EM are Phrase Elements, so if a user agent is following the specifications properly, when a screen reader reads a B of an I Element it wouldn't do anything, but when it reads STRONG and EM, it should indicate their inflection or meaning. So the visual display qualities are the same, but to none visual agents, because of the Element type, they are understood differently. If you are in the habit of hand coding with B and I and find STRONG and EM long hand, just code B and I, but make sure you have and use a tool like HTML Tidy to transform them on save (http://tidy.sourceforge.net/). You'll find it built into many tools as well. JTidy is even an important component of Cocoon XML Publishing. Geoff * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Styling Text...
Geoff Deering wrote: It depends which DTD you are referencing as to whether they are deprecated or not, but U is definitely deprecated in everything from HTML4 onwards. And B and I are deprecated for future compatibility because they belong in "Font Style Elements", which are all deprecated, as CSS should be used for these. You may want to recheck your facts. InChanges from XHTML 1.0 Strict it states: "Most significant is the removal of features that were deprecated." Since b and i are still there, it must mean that they weren't deprecated. Also, sub and sup are current;y valid XHTML2 with no listed plans to either deprecate or remove (http://www.w3.org/TR/xhtml2/mod-inline-text.html#sec_9.12.). I do happen to agree that b and i shouldn't be used, but they are still 100% valid XHTML1.1.
[WSG] Styling Text...
Hey WSG,
I am just writing because I have been wondering if there is a better
way of styling text.
Since BUI etc... are all outlawed and now
depreciated...
How do you style your inner P text?
At the moment, when I have a paragraph and I want to bold a word, i
use: span class="bold"
And in the stylesheet I have a series of:
.bold{font-weight:bold;}
.underline{text-decoration:underline;}
.italic{font-style:italic;}
So a bold italic word which is also underlined is just: span
class="bold italic underline"word/span
I am sure that there is a better way because this method is becomming
SOOOooo so very verbose!
An example, it used to be b/b 7 characters for bold,
now is span class="bold"/span 26 Characters...
Dont think I dont know about em's etc... but how about italic
etc...?
I know the idea of stylesheets is to have styles that are specific for
the purpose...
But what if I just want to have underlined text, or just italic, or
bold, just generic bold,underlined,italic text??
Say if I were to code a BBCODE system into my Blog etc... for myself.
What would I use to keep it standards compliant?
Thanks for the help!
I hope its not too confusing!
:S
- Chris Stratford
RE: [WSG] Styling Text...
G'day Use strong instead of b Use em instead of i Don't underline text - it will look like a link and confuse people So a bold italic word which is also underlined is just: span class=bold italic underlineword/span Try strongemWord/em/strong Or if you use the combination a lot, set up the em element to have bold italic text in (graphical/text) browsers. The problem with b and i is that it's presentational. strong and em on the other hand have semantic meaning (especially when using assistive technology like text-to-speech converters). Regards -- Bert Doorn, Better Web Design www.betterwebdesign.com.au Fast-loading, user-friendly websites * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
Re: [WSG] Styling Text...
Hi Chris
B U I are not exactly outlawed.
You can still use it, and I do believe b and i are perfectly valid in
XHTML - I use them myself.
Someone would have to check the underline though - I'm of the opinion
text should never be underlined unless it is a link.
Natalie :)
- Original Message -
From: Chris Stratford [EMAIL PROTECTED]
Date: Sat, 03 Jul 2004 12:31:37 +1000
Subject: [WSG] Styling Text...
To: [EMAIL PROTECTED]
Hey WSG,
I am just writing because I have been wondering if there is a better
way of styling text.
Since BUI etc... are all outlawed and now depreciated...
How do you style your inner P text?
At the moment, when I have a paragraph and I want to bold a word, i
use: span class=bold
And in the stylesheet I have a series of:
.bold{font-weight:bold;}
.underline{text-decoration:underline;}
.italic{font-style:italic;}
So a bold italic word which is also underlined is just: span
class=bold italic underlineword/span
I am sure that there is a better way because this method is becomming
SOOOooo so very verbose!
An example, it used to be b/b 7 characters for bold, now is span
class=bold/span 26 Characters...
Dont think I dont know about em's etc... but how about italic etc...?
I know the idea of stylesheets is to have styles that are specific for
the purpose...
But what if I just want to have underlined text, or just italic, or
bold, just generic bold,underlined,italic text??
Say if I were to code a BBCODE system into my Blog etc... for myself.
What would I use to keep it standards compliant?
Thanks for the help!
I hope its not too confusing!
:S
- Chris Stratford
*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
*
Re: [WSG] Styling Text...
On 7/2/04 7:31 PM Chris Stratford [EMAIL PROTECTED] sent this out: I am just writing because I have been wondering if there is a better way of styling text. Since BUI etc... are all outlawed and now depreciated... How do you style your inner P text? And here I thought someone just the other day said BUI were still okay (not depricated). Rick Faaberg * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
