Re: [WSG] Is XHTML harmful?
Geoff; But still, strictly speaking, an XML based document is bound to be more semantically correct because it is well formed. Why? Are the semantics of the following deferent? ul liIce cream/li liSprinkles/li /ul ... ul liIce cream liSprinkles /ul SGML and XML are metalanguage facilities for defining markup languages. Markup languages defined by SGML and XML declare formal features for syntax, but have no mechanisms for formally expressing semantics. http://xml.coverpages.org/semantics.html ASFAIK the semantics of both HTML4.01 and XHTML1.0 are described here: http://www.w3.org/TR/html401/. e.g. A heading element briefly describes the topic of the section it introduces. http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h -7.5.5 XHTML is designed to be as much like HTML as possible. It has the same 'semantics' as HTML http://www.westciv.com/style_master/house/good_oil/xhtml/ This means that the CSS can be applied without fear of the parser misunderstanding where a declaration could have finished. There is no possibility of any guess work in xhtml as it is well formed. This may or may not be an obvious problem. But I would not be surprised to see complex designs misrendered when transformed from xhtml to html4 with all optional ending tags taken out. Why would you want to take them out? What I am saying is that with XHTML the designers knows this won't happen, given the correctness of the parser. You appear to be saying that CSS is not compatible with HTML4 because HTML parsers can only guess at its structure if optional end tags are not used and therefore parsers are likely to render CSS rules incorrectly even though the document may be valid. I assume that what you mean by guess is: Apply error correcting algorithms to ambiguous markup. Does this correctly summarise what you are saying ? Now go into the area of accessibility, how are you going to tell all sorts of user agents and devices the full semantic meaning of the markup. What about when aural.css becomes mature? Will complex document in HTML4 be as exact as those following XML syntax? Yes, if you write it against the DTD and follow accessibility guidelines. There is no difference between the semantics or the accessibility of HTML4.1 and XHTML1.0. You may be right, but I don't agree. It's only a small difference, but it is there. Where is this difference defined, is there a term for it? In my view, you cannot fully mark up documents with a trusted explicit semantic fullness without and XML definition. The border here might be small, but it's small enough for one definition to allow for best of interpretation and the other an explicit interpretation. Well-formedness has nothing to do with semantics. You're missing the point. Closing tags is being completely accurate with punctuation, where markup is the punctuation. Not closing tags CAN lead to ambiguity. In XHTML there is no syntax ambiguity, in HTML4 there are possibilities. It may not happen when validating against the doctype. That is not the problem. The problem is the CSS container, it's boundaries are often not certain. If you think you need this punctuation then use it. I've stated before, optional end tags are optional, use them to your heart's content (most people do). However absent optional end tags are implied - closed by the following or enclosing block as defined here http://www.w3.org/TR/REC-html40/intro/sgmltut.html#h-3.2.1 and elsewhere. If you have written HTML well, there is no ambiguity and no guessing is required by conforming HTML parsers. Valid, well written HTML is not tag soup. It's probably worth naming the elements in question: HTML, HEAD, BODY, P, LI, DT, DD, OPTION, COLGROUP, THEAD, TFOOT, TBODY, TR, TH, TD. Four of those elements have optional Start Tags as well as optional End Tags (and go straight to punctuation hell presumably :). To see how your browser's parser handles a TBODY element with an omitted Start Tag and an omitted End Tag point it here. (you need a browser with DOM scripting to see its parsed code - latest IE, Moz, Safari Op should be fine) http://www.webx.com.au/code/tbodycount/ For good measure I've applied a background colour (baby blue) to this element (the one with no start tag or end tag) using CSS. Lucky guess or just applying rules defined by HTML4? Except for the reasons give by Peter Ottrey the only technical reason for using XHTML is that you need the XML (this being the only technical difference between HTML4.1 and XHTML 1.0 ). Any other reason simply comes done to a matter of personal preference. I don't agree with that. This is the same as HTML 4 Strict except for changes due to the differences between XML and SGML. http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd aslo http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd
Re: [WSG] Is XHTML harmful?
Dean; Then there is the whole Web Applications trend. Again, HTML and XHTML are pretty much the same in functionality here, but if I'm using an application on the Web then I want to make sure it is well-formed and well-structured. I don't want a typo by a web developer (such as leaving off an end tag) to cause my credit card to be debited twice. This company would need to work on their coding standards enforcement and QA test and deployment procedures before they re-code that app, I don't think XHTML will save them :) To ask the question the other way around, what are the real benefits of using HTML over XHTML? I'm interested to hear the reasons (and I'm sure they are valid). My environment can't output XML. Dean, can I ask you why hasn't the W3C depreciated HTML? Do they intend too? Why/Why not? Should we also be asking the question: Why has XHTML take-up been so sluggish. http://lists.xml.org/archives/xml-dev/200407/msg00061.html Chris. ** 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] Is XHTML harmful?
Paul Connolley wrote: Geoff Deering wrote: I am talking about CSS applied to HTML and the rendering of the CSS as applied to the parsing of the document. But still, strictly speaking, an XML based document is bound to be more semantically correct because it is well formed. This means that the CSS can be applied without fear of the parser misunderstanding where a declaration could have finished. There is no possibility of any guess work in xhtml as it is well formed. You are talking about two distinctly different parsers. XHTML is a XML subset, HTML is an SGML subset. For example: In XHTML: ul liOne item/li liSecond item liThird item/li /ul This will throw an error because it is bad XML In HTML it will not. With the SGML parser it knows that when it arrives at a new li it is the beginning of a new list item. The same would apply, for example, to a p paragraph. Surely you don't believe that it would render pThis paragraph pThis other paragraph as a paragraph within a paragraph. You need to revise your understandings. HTML is NOT XML. Admittedly, XHTML contains inheritance to certain HTML objects but it is wholly a XML subset. You shouldn't try to argue about parsing when they are parsed by two different types of engines. But that is entirely my point. You're missing the point. Closing tags is being completely accurate with punctuation, where markup is the punctuation. Not closing tags CAN lead to ambiguity. In XHTML there is no syntax ambiguity, in HTML4 there are possibilities. It may not happen when validating against the doctype. Once again you are arguing for ambiguity. It is wrong to assume this. SGML allows for the omission of end tags because it follows a different ruleset That's exactly the point I am trying to make. - 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] Is XHTML harmful?
What Dean says so well here are also the reasons I prefer XML defined markup, and I don't think it negates the arguments that others have been expressing here for HTML. I think each on of them have valid points. But it seems to me that there are more reasons to use an XML based vocabulary than have previously been put forward. I also agree with him about writing parsers and their performances based on stricter or looser rule sets. I also try to see XML vocabularies as having a richer and more accurate rule set to express the content they encapsulate. I dream of a true semantic web were I can find content from searches that are based on arguments and phrases that are derived from clean document tree analysis of content. Even if we have those documents out there, current search methods and technology are far too primitive to understand that. Not that the search engine engineers are dumb, it's just that for all the content out there, there are only small portions of it that can be stored and analysed semantically, so there is not much point in doing that regarding ROI. And I don't agree with a lot of the way the W3C are handling the semantic web. - Geoff Deering Dean Jackson wrote: Friday, 8 October 2004 2:23 PM On 7 Oct 2004, at 02:09, Vlad Alexander (XStandard) wrote: Hi Kim, Ian Hickson is _not_ saying XHTML is harmful, he is saying that serving up XHTML with the wrong MIME type is bad. That's right. It's probably not the best title for the document, but my feeling is that people using the ... considered harmful approach are typically looking more for attention than for examination. Nevertheless, it's still an interesting read. Today, the real benefits of XHTML are on the production side. Say your CMS has 1000 documents and you need to change the class name of a div tag in all 1000 documents. If your content is in XHTML, you can use XML related technologies like DOM or XSLT to process all 1000 documents quickly and accurately because XHTML can be processed by XML parsers. I agree. Using XHTML over HTML brings some benefits that are hard to measure. The way I think of it is that XHTML allows more people to use your content in ways that you didn't originally expect. For example, at W3C we extract a lot of semantic info from our XHTML pages: building calendars, issue lists, relationships between pages, etc. This could all be done using HTML, but XHTML makes it easier (much wider range of tools in the XML world). The same goes for modifying pages. I have a huge range of tools available to do a site wide change with XHTML, and these tools are interoperable because they conform to the XML specification. If my Web guy gets hit by a truck, then I can call up another developer and assume that her XML skills will be enough to do the job (even though she may not be familiar with the tools). Then there is the whole Web Applications trend. Again, HTML and XHTML are pretty much the same in functionality here, but if I'm using an application on the Web then I want to make sure it is well-formed and well-structured. I don't want a typo by a web developer (such as leaving off an end tag) to cause my credit card to be debited twice. That's an extreme example, but in the general case, would you really run an application on your desktop that you were not sure was compiled correctly (or had millions of compiler warnings)? Allowing sloppy markup in applications is a security risk IMHO. On the design front, if you are thumping your head against a wall trying to wonder why the page is off by three pixels, wouldn't you like to rule out as much as possible in order to reduce the number of places you look for the bug? In most cases, this is easier with XHTML - you can check the document and then focus on the CSS. While the existing browsers are parsing and rendering HTML faster than XHTML, then you can serve XHTML 1.0 as HTML. I'm not sure exactly why HTML parsing/rendering is faster than XHTML, since in general it is much easier to right a high-performance parser for a strict language than a less strict one (and HTML also carries years and years of quirks to handle). Maybe it is just that the HTML code has been around for so long that it is highly optimized. Let's hope the desktop browsers will move into 2001 soon ;) To ask the question the other way around, what are the real benefits of using HTML over XHTML? I'm interested to hear the reasons (and I'm sure they are valid). Dean ** 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] Is XHTML harmful?
Geoff Deering wrote: I am talking about CSS applied to HTML and the rendering of the CSS as applied to the parsing of the document. But still, strictly speaking, an XML based document is bound to be more semantically correct because it is well formed. This means that the CSS can be applied without fear of the parser misunderstanding where a declaration could have finished. [Snip] Paul Connolley wrote: You are talking about two distinctly different parsers. XHTML is a XML subset, HTML is an SGML subset. For example: [Snip example] In HTML it will not. With the SGML parser it knows that when it arrives at a new li it is the beginning of a new list item. The same would apply, for example, to a p paragraph. [Snip] You shouldn't try to argue about parsing when they are parsed by two different types of engines. But that is entirely my point. No. Your points: - Rendering of CSS when applied to a document - XML being more semantic because it is well formed - Parsers misunderstanding element declarations Well-formedness is, in this context, a XML concept. A SGML document (hence a HTML) is well formed whether you omit an end tag or not. I repeat, an SGML parser will not be confused when presented by two paragraphs which are not closed yet adjacent. CSS rules follow almost entirely exactly apart from a number of exceptions. This is what I believe you were referring to. It is wrong to confuse people about missing end tags as it is not the issue when it comes to rendering CSS. I'm a huge advocate of XHTML. I use it everyday in semantic design but I never tell anyone that HTML is less semantic because that is poppytosh. XML and SGML specifications are as semantic as you decide to make them. I know people who create perfectly valid XHTML but their pages make no use of headings, lists, blockquotes or the like. Valid but not semantic. -- Paul Connolley SQL/Systems Programmer Egocentric - http://egocentric.co.uk ** 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] Is XHTML harmful?
Please forgive any ignorance on my part... So I can copy the guts of an XHTML document in all it's splendor with br /s et all and paste it into an HTML document and all is dandy? Tom Livingston Senior Multimedia Artist mlinc.com Get FireFox http://spreadfirefox.com/community/?q=affiliatesid=0t=1 On Oct 6, 2004, at 11:25 PM, Chris Bentley wrote: There is no difference between the semantics or the accessibility of HTML4.1 and XHTML1.0. ** 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] Is XHTML harmful?
Chris Bentley wrote: Are there any parsers out there you explicitly trust to get it right every time? I don't. I know of one, http://validator.w3.org/. Are you say though that User Agents are generally better/fast at parsing/rendering valid XHTML than they are valid HTML? No, that is not what I meant at all. I'm talking about the parser and rendering engine in user agents. No, you are missing the point. Maybe you need to go back and study parser logic rendering markup a bit more. They may well do, but they are still guessing if there are no end tags. I'm much more happy to explicitly declare my design than have parsers guessing at what I've designed, the performance trade off is not so great. I like to write valid markup too, and if your HTML is valid (written against the DTD) then the parser doesn't have to guess anything, I don't see your point as to why valid XHTML is technically better than than valid HTML. I am talking about CSS applied to HTML and the rendering of the CSS as applied to the parsing of the document. But still, strictly speaking, an XML based document is bound to be more semantically correct because it is well formed. This means that the CSS can be applied without fear of the parser misunderstanding where a declaration could have finished. There is no possibility of any guess work in xhtml as it is well formed. This may or may not be an obvious problem. But I would not be surprised to see complex designs misrendered when transformed from xhtml to html4 with all optional ending tags taken out. What I am saying is that with XHTML the designers knows this won't happen, given the correctness of the parser. Now go into the area of accessibility, how are you going to tell all sorts of user agents and devices the full semantic meaning of the markup. What about when aural.css becomes mature? Will complex document in HTML4 be as exact as those following XML syntax? Yes, if you write it against the DTD and follow accessibility guidelines. There is no difference between the semantics or the accessibility of HTML4.1 and XHTML1.0. You may be right, but I don't agree. It's only a small difference, but it is there. In my view, you cannot fully mark up documents with a trusted explicit semantic fullness without and XML definition. The border here might be small, but it's small enough for one definition to allow for best of interpretation and the other an explicit interpretation. Well-formedness has nothing to do with semantics. You're missing the point. Closing tags is being completely accurate with punctuation, where markup is the punctuation. Not closing tags CAN lead to ambiguity. In XHTML there is no syntax ambiguity, in HTML4 there are possibilities. It may not happen when validating against the doctype. That is not the problem. The problem is the CSS container, it's boundaries are often not certain. Except for the reasons give by Peter Ottrey the only technical reason for using XHTML is that you need the XML (this being the only technical difference between HTML4.1 and XHTML 1.0 ). Any other reason simply comes done to a matter of personal preference. I don't agree with that. - 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] Is XHTML harmful?
Hi Tom, Yes - the markup will validate as HTML. Here is an example: http://xstandard.com/html4.htm Validate it using: http://validator.w3.org/check?uri=http%3A%2F%2Fxstandard.com%2Fhtml4.htm Check out an article I wrote about this a while back: http://www.4guysfromrolla.com/webtech/120303-1.shtml Regards, -Vlad http://xstandard.com - Original Message - From: Tom Livingston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 07, 2004 10:28 AM Subject: Re: [WSG] Is XHTML harmful? Please forgive any ignorance on my part... So I can copy the guts of an XHTML document in all it's splendor with br /s et all and paste it into an HTML document and all is dandy? Tom Livingston Senior Multimedia Artist mlinc.com Get FireFox http://spreadfirefox.com/community/?q=affiliatesid=0t=1 On Oct 6, 2004, at 11:25 PM, Chris Bentley wrote: There is no difference between the semantics or the accessibility of HTML4.1 and XHTML1.0. ** 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] Is XHTML harmful?
On 7 Oct 2004, at 02:09, Vlad Alexander (XStandard) wrote: Hi Kim, Ian Hickson is _not_ saying XHTML is harmful, he is saying that serving up XHTML with the wrong MIME type is bad. That's right. It's probably not the best title for the document, but my feeling is that people using the ... considered harmful approach are typically looking more for attention than for examination. Nevertheless, it's still an interesting read. Today, the real benefits of XHTML are on the production side. Say your CMS has 1000 documents and you need to change the class name of a div tag in all 1000 documents. If your content is in XHTML, you can use XML related technologies like DOM or XSLT to process all 1000 documents quickly and accurately because XHTML can be processed by XML parsers. I agree. Using XHTML over HTML brings some benefits that are hard to measure. The way I think of it is that XHTML allows more people to use your content in ways that you didn't originally expect. For example, at W3C we extract a lot of semantic info from our XHTML pages: building calendars, issue lists, relationships between pages, etc. This could all be done using HTML, but XHTML makes it easier (much wider range of tools in the XML world). The same goes for modifying pages. I have a huge range of tools available to do a site wide change with XHTML, and these tools are interoperable because they conform to the XML specification. If my Web guy gets hit by a truck, then I can call up another developer and assume that her XML skills will be enough to do the job (even though she may not be familiar with the tools). Then there is the whole Web Applications trend. Again, HTML and XHTML are pretty much the same in functionality here, but if I'm using an application on the Web then I want to make sure it is well-formed and well-structured. I don't want a typo by a web developer (such as leaving off an end tag) to cause my credit card to be debited twice. That's an extreme example, but in the general case, would you really run an application on your desktop that you were not sure was compiled correctly (or had millions of compiler warnings)? Allowing sloppy markup in applications is a security risk IMHO. On the design front, if you are thumping your head against a wall trying to wonder why the page is off by three pixels, wouldn't you like to rule out as much as possible in order to reduce the number of places you look for the bug? In most cases, this is easier with XHTML - you can check the document and then focus on the CSS. While the existing browsers are parsing and rendering HTML faster than XHTML, then you can serve XHTML 1.0 as HTML. I'm not sure exactly why HTML parsing/rendering is faster than XHTML, since in general it is much easier to right a high-performance parser for a strict language than a less strict one (and HTML also carries years and years of quirks to handle). Maybe it is just that the HTML code has been around for so long that it is highly optimized. Let's hope the desktop browsers will move into 2001 soon ;) To ask the question the other way around, what are the real benefits of using HTML over XHTML? I'm interested to hear the reasons (and I'm sure they are valid). Dean From: Kim Kruse [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 10:53 AM Subject: [WSG] Is XHTML harmful? Hi, First of all... I'm sorry if this is off topic. I've been telling people (the few who asked me and through my website) to use (valid) xhtml because it a W3C recommendation, it's device independent, (valid) xhtml can be processed by an XML parser, better accessibility, less code, faster processing of code in modern browsers, forward compatibility etc. I guess that's the standard opinion on xhtml or am I completely of track here? After I participated in a discussion over at the Project Seven newsgroup I'm having doubts! The reason is some very well put arguments from among others, Al Sparber. One of the arguments was less code. Not even close to html 4.01 (See sample 1 below), html 4.01 is also device independent AFAIK. Xhtml is not being processed faster than html 4. Actually there should be no real reason to use xhtml unless you're using xml. _Sample 1 - html:_ !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; html head meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 titleUntitled Document/title /head body pHello World. pimg src=img.gif width=10 height=10 alt=some description /body /html _Sample 1 - xhtml:_ !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; head meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 / titleUntitled Document/title /head body pHello World./p pimg src=img.gif width=10 height=10 alt=some description //p /body /html Now what really worries me is this article http://hixie.ch/advocacy/xhtml where
Re: [WSG] Is XHTML harmful?
Kim Kruse wrote: Hi, First of all... I'm sorry if this is off topic. I've been telling people (the few who asked me and through my website) to use (valid) xhtml because it a W3C recommendation, it's device independent, (valid) xhtml can be processed by an XML parser, better accessibility, less code, faster processing of code in modern browsers, forward compatibility etc. I guess that's the standard opinion on xhtml or am I completely of track here? Hi Kim, that's a hot issue in the web standards world. Basically, i think the main points can be presented as: XHTML real, present and unique features: - Ready for XML parsing - Ready for mixing with other XML syntaxes, such MathML. The canonical example being is Jaques Distler's weblog. XHTML not-so-clear feature: - Forward-compatibility. Some say it's a legit advantage over HTML, some say, since valid HTML is so easily tranformed into valid XHTML, it's a draw. XHTML myths: - Faster loads. - More accesible 'per se' than Strict HTML. It's not. XHTML problems: - The mime-type issues. - Zero-tolerance for markup errors (if served with the right mime-type) So, if you've done your homework and take an informed decision, it pretty much comes down to a matter of project requirements + personal taste. Some people see the point in using XHTML, regardless the problems. Some people don't. Myself, i'm sticking with HTML 4.01 Strict, until necessity or the will to experiment force me otherwise. Check this http://annevankesteren.nl/archives/2004/08/xhtml for a much more useful explanation than mine :) HTH - Manuel trabaja para Simplelógica: apariencia, experiencia y comunicación en la web. http://simplelogica.net # (+34) 985 22 12 65 escribe en Logicola http://simplelogica.net/logicola/ ** 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] Is XHTML harmful?
Hi Kim, Ian Hickson is _not_ saying XHTML is harmful, he is saying that serving up XHTML with the wrong MIME type is bad. At an academic level, he has a point. On a practical level, this does not concern most of us because all current (modern) user agents (browsers, crawlers, gadgets, etc) will process XHTML if it is served-up as HTML. But do try to user the correct MIME type when you can. Here is the definitive word on this topic: http://www.w3.org/International/articles/serving-xhtml/ To summarize this article, it says XHTML 1.0 can be served as HTML or XML. Today, the real benefits of XHTML are on the production side. Say your CMS has 1000 documents and you need to change the class name of a div tag in all 1000 documents. If your content is in XHTML, you can use XML related technologies like DOM or XSLT to process all 1000 documents quickly and accurately because XHTML can be processed by XML parsers. Regards, -Vlad Alexander XStandard Development Team http://xstandard.com - Original Message - From: Kim Kruse [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 10:53 AM Subject: [WSG] Is XHTML harmful? Hi, First of all... I'm sorry if this is off topic. I've been telling people (the few who asked me and through my website) to use (valid) xhtml because it a W3C recommendation, it's device independent, (valid) xhtml can be processed by an XML parser, better accessibility, less code, faster processing of code in modern browsers, forward compatibility etc. I guess that's the standard opinion on xhtml or am I completely of track here? After I participated in a discussion over at the Project Seven newsgroup I'm having doubts! The reason is some very well put arguments from among others, Al Sparber. One of the arguments was less code. Not even close to html 4.01 (See sample 1 below), html 4.01 is also device independent AFAIK. Xhtml is not being processed faster than html 4. Actually there should be no real reason to use xhtml unless you're using xml. _Sample 1 - html:_ !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; html head meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 titleUntitled Document/title /head body pHello World. pimg src=img.gif width=10 height=10 alt=some description /body /html _Sample 1 - xhtml:_ !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; head meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 / titleUntitled Document/title /head body pHello World./p pimg src=img.gif width=10 height=10 alt=some description //p /body /html Now what really worries me is this article http://hixie.ch/advocacy/xhtml where xhtml is being considered harmfull. Is it harmful ? Now I would like to know what your arguments would be for using xhtml. Not that I can't think for myself... but I'm in doubt if I'm going in the right direction. I would really like to hear your opinions on this matter. Kim ** 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] Is XHTML harmful?
In message [EMAIL PROTECTED], Manuel González Noriega [EMAIL PROTECTED] writes XHTML problems: - Zero-tolerance for markup errors Surely that is a benefit rather than a problem? -- Chris Hughes http://www.epicure.demon.co.uk ** 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] Is XHTML harmful?
Chris Hughes wrote: In message [EMAIL PROTECTED], Manuel González Noriega [EMAIL PROTECTED] writes XHTML problems: - Zero-tolerance for markup errors Surely that is a benefit rather than a problem? Again, higly subjective: it's neat for marchine-parsing but IMHO it's overkill to learn that you've made a teenyweeny mistake in your blog post markup by watching the bloody thing crash before your eyes As i said, it probably comes down to what are your use cases. I stand on the camp of those who think that in the vast majority of the real-world use cases today, XHTML is not necessary. Besides, HTML 4.01 Strict has a vintage/retro look that's really cool :o) ** 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] Is XHTML harmful?
Again, higly subjective: it's neat for marchine-parsing but IMHO it's overkill to learn that you've made a teenyweeny mistake in your blog post markup by watching the bloody thing crash before your eyes Yet with each crash and burn of your blog and each little mistake you fix the more and more aware of those little mistakes you become and the cleaner your code becomes. Sure it's a pain when you forget a simple bit of markup but more often than not it's easily fixed. -- Clayton Lengel-Zigich http://www.lengelzigich.com ** 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] Is XHTML harmful?
Clayton Lengel-Zigich wrote: Again, higly subjective: it's neat for marchine-parsing but IMHO it's overkill to learn that you've made a teenyweeny mistake in your blog post markup by watching the bloody thing crash before your eyes Yet with each crash and burn of your blog and each little mistake you fix the more and more aware of those little mistakes you become and the cleaner your code becomes. Sure it's a pain when you forget a simple bit of markup but more often than not it's easily fixed. Often, markup errors, like natural language errors, are most likely typos than anything else. Therefore, i don't really learn anything from them and they are just a PITAs I see your point, of course and i still think it's a matter of specific scenarios + personal taste ** 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] Is XHTML harmful?
All code of every web page should be validated. Any errors need to be corrected. If your typo is in a tag, then it could produce undesirable results. We should all make sure our code on every web page we create has no errors, whether simple typos or forgotten closing tags; whether we use HTML or XHTML. If you live by this standard, then XHTML is a viable coding option. Best, Shane Helm On Oct 6, 2004, at 12:46 PM, Manuel González Noriega wrote: Clayton Lengel-Zigich wrote: Again, higly subjective: it's neat for marchine-parsing but IMHO it's overkill to learn that you've made a teenyweeny mistake in your blog post markup by watching the bloody thing crash before your eyes Yet with each crash and burn of your blog and each little mistake you fix the more and more aware of those little mistakes you become and the cleaner your code becomes. Sure it's a pain when you forget a simple bit of markup but more often than not it's easily fixed. Often, markup errors, like natural language errors, are most likely typos than anything else. Therefore, i don't really learn anything from them and they are just a PITAs I see your point, of course and i still think it's a matter of specific scenarios + personal taste ** 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] Is XHTML harmful?
Manuel González Noriega wrote: Often, markup errors, like natural language errors, are most likely typos than anything else. Therefore, i don't really learn anything from them You learn that you should validate anything before making it live (just like you'd spell-check and proofread anything before going to publication in the print world, for instance). ;) Patrick _ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ** 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] Is XHTML harmful?
-Original Message- Shane Helm - he say: All code of every web page should be validated. Any errors need to be corrected. If your typo is in a tag, then it could produce undesirable results. We should all make sure our code on every web page we create has no errors, whether simple typos or forgotten closing tags; whether we use HTML or XHTML. Best, Shane Helm Quite so. I'm ashamed to say I built several web sites without validating anything. I worked on the basis that if it looked ok in IE and perhaps Netscape, and didn't look too bad in the mac we had at the next desk, that was ok. Anyone else who has something different was on their own. Lots of luck, pal. Since I've learned more about web standards and accessibility I've had occasion to rebuild one of those sites, and I built it to XHML1.0Strict. I'm not sure if using XHTML was better, or just because I validated the code, but the new version of the site is faster, smaller, better, laid out better, the code all works. It's easier to maintain. Far faster to find the place in a page that needs work than it did before. Perhaps it's got nothing to do with XHTML per se, but because I coded to a much more stringent standard, I did a better job of it. It was frustrating at first, seeing all those errors coming up, and the nasty ole validator being picky and splitting hairs over a non-supported attribute here or a forgotten / there but the end result is a much better job, and now I am much more disciplined in the code I write. The tighter discipline on my own coding habits means I get more pages right first time now than I did before. Benefit: faster results of higher quality than before. Maybe XHTML has nothing to do with it, maybe it does. But the overall effect is a big improvement all around for me. I reckon validating makes good sense from many points of view. Cheers Mike Kear Windsor, NSW, Australia AFP Webworks http://afpwebworks.com .com,.net,.org domains from AUD$20/Year ** 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] Is XHTML harmful?
Shane Helm wrote: All code of every web page should be validated. Any errors need to be corrected. If your typo is in a tag, then it could produce undesirable results. We should all make sure our code on every web page we create has no errors, whether simple typos or forgotten closing tags; whether we use HTML or XHTML. If you live by this standard, then XHTML is a viable coding option. I pretty much agree, but, generally speaking, if a change to the markup is made on Friday, and it is somehow invalid, i'd rather have it as is until the Monday validation than showing a terrible fatal error yellow screen to users during the weekend. And keep in mind than i'm thinking more about user submitted input, which is much more wild and frequent than any webpage lifecycle. Anyhow, I'm a semantic and valid HTML freak, so i'm already converted :o) But, as I said, I don't really see the point of XHTML for general information delivery today. ** 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] Is XHTML harmful?
Shane Helm wrote: I have also become a better and cleaner coder since I switched to XHTML CSS. Table-less layout rules! But, to clarify: there's nothing, absolutely nothing at all, stopping you from going all CSS-driven, table-less, separation of content and presentation, etc in HTML 4 - just as it's still perfectly feasible to do a completely table-driven layout even in XHTML 1.1. These two quite separate issues should not be confused, or made synonymous (similar to the xhtml is better for accessibility myth) Patrick _ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ** 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] Is XHTML harmful?
Patrick H. Lauke wrote: Manuel González Noriega wrote: Often, markup errors, like natural language errors, are most likely typos than anything else. Therefore, i don't really learn anything from them You learn that you should validate anything before making it live (just like you'd spell-check and proofread anything before going to publication in the print world, for instance). ;) Spll chckres? Whats' taht? :o) Seriously, I don't want to come across as a lousy coding apologist, I just was pointing that error-handling was one of the main differences between XHTML and HTML (if XHTML is served correctly) . I'm all for obsessive validation, but nowdays I'm more for obsessive validation against the HTML Doctype. I wanna share a link, found via Bloglines, that's very pro-XHTML. How fair and balanced is that? http://www.kurafire.net/articles/case-for-xhtml -- Manuel trabaja para Simplelógica: apariencia, experiencia y comunicación en la web. http://simplelogica.net # (+34) 985 22 12 65 escribe en Logicola http://simplelogica.net/logicola/ ** 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] Is XHTML harmful?
Can anyone explain what this means in that article? * A CSS stylesheet written for an HTML4 document is interpreted slightly differently in an XHTML context (e.g. the body element is not magical in XHTML In what ways might body be magical? Have You Validated Your Code? John Horner(+612 / 02) 9333 2110 Senior Developer, ABC Online http://www.abc.net.au/ ** 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] Is XHTML harmful?
One that I know, but there may be more: in HTML, body is the size of the entire viewport, even if it's empty. In XHTML, it's just like any other block level elements and takes on the dimensions of its content (and if you float everything in the body, it effectively is 0 pixels high). If you define a background colour just in the body, in XHTML it may not cover the entire viewport of your browser if the content is shorter than the viewport itself...so you should apply background colour etc to the HTML element instead Patrick John Horner wrote: Can anyone explain what this means in that article? * A CSS stylesheet written for an HTML4 document is interpreted slightly differently in an XHTML context (e.g. the body element is not magical in XHTML In what ways might body be magical? Have You Validated Your Code? John Horner(+612 / 02) 9333 2110 Senior Developer, ABC Online http://www.abc.net.au/ ** 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·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ** 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] Is XHTML harmful?
there were a couple of threads about this issue at WEB4LIB recently. subject = Moving from HTML4.01 to XML subject = to X or not to X the consensus was generally mixed, as it is here. one of my gurus bow said: paste Moving from any flavor of HTML to the corresponding flavor of XHTML is a pretty minor syntax change. The failure of IE to handle XHTML's official MIME content type is a non-negligible issue, but a good server environment should be able to send either application/xhtml+html or text/html based on the browser's Accept headers. Moving from either Transitional version to the corresponding Strict version is where you really get the benefits from distilling your markup down to clean structure. Again IMO, there's little advantage to moving from HTML to XHTML unless you either need to use other XML applications or editors, or you just want to play with XHTML. /paste but it was also pointed out paste Note that a strict interpretation of the WAI WCAG 1.0 guidelines would indicate that you MUST use XHTML 1.0 if you intent to comply with WAI AA guidelines. See http://www.w3.org/TR/WAI-WEBCONTENT/ Checkpoints: 11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported. [Priority 2] /paste if anyone wants to investigate further, the WEB4LIB searchable archives are at http://sunsite.berkeley.edu/Web4Lib/archive.html vicki ** 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] Is XHTML harmful?
Every modern browser, including Mozilla and Safari, is much worse at XHTML than at HTML. People tend to foolishly gloss over the transition from one to the other, thinking that code you write for one will just work when you switch to XHTML. That simply isnt true. If you look at XHTML in both Mozilla and Safari and compare it to HTML, youll see that its slower, non-incremental, and generally buggier than HTML. David Hyatt http://weblogs.mozillazine.org/hyatt/archives/2004_07.html#005928 Chris. ** 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] Is XHTML harmful?
Hmmm... but it was also pointed out paste Note that a strict interpretation of the WAI WCAG 1.0 guidelines would indicate that you MUST use XHTML 1.0 if you intent to comply with WAI AA guidelines. See http://www.w3.org/TR/WAI-WEBCONTENT/ Um, no. Not MUST at all. This is misinterpreting the facts. Checkpoints: 11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported. [Priority 2] /paste I would think that IE's non support of the correct mime type means that when supported fails, and as for appropriate, that's a judgement call based on personal preference. HTML 4.01 is still entirely appropriate for general content mark-up and IS the latest version of HTML. What they mean here is that HTML 4.0 is not appropriate, (and it's debateable whether HTML 3.2 is either... By version do they mean the language or the subset? HTML 3.2 is the latest version of HTML 3) XHTML did not replace HTML or it would have been called HTML 5.0. P ** 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] Is XHTML harmful?
Kim wrote: Now I would like to know what your arguments would be for using xhtml.Hi everyone,have heard and understand all the good responses on this question. As usual the decision can vary depending on your needs.I'd like to offer one reason why it has been a good decision for us here at Fairfax Digital (or potentially the better known smh.com.au [1] theage.com.au sites).When we proposed and pushed the idea of using css for layouts, it was (and still is) a radical change for many parts of the business and the way the sites are developed. Many hands work on our sites. We still run into lots of problems with markup errors due to that amount of content that comes from different areas/hands. The fact is we have many people within the organisation that are still coding ala 1998 style. missing /p tags, or no p tags, no headings, unclosed tags, lists using br's, unencoded entities, etc etc. probably every sin in the book.When we started spreading the message of CSS and standards internally we knew that if it succeeded it would take a long time then stick for a long time. We have lts of sites that often don't get a code revamp for years. Hence we wanted a plan that had some legs.The reason we chose xHTML had a lot to do with speading the message that xHTML stands for. ie: tidy, lean, valid code etc. yeah i know its a lot more than that but for these people, thats the point that concerns them. We needed to get people realising that its important to close your tags, its important to make your tags lower case, its important to use a hx tag for a heading. (yeah its probably a heading 'element', not tag, but you know what i mean ;-)So when we 'sold' the CSS concept internally, we 'sold' xHTML along with it, and everything that goes along with it to focus attention on better coding practices.So yeah, that may sound crazy for some, but its a real world situation for us, and its something that has seen massive benefits. Its working. The xHTML doctype and standards mode (as opposed to quirks mode) is helping to focus attention internally on the need for better markup. We aint perfect, but its a big organisation and these things take time. Product managers (who have no idea what CSS even stands for) now want to know if their new design will use xHTML and sprites. funny, but true.I'm glad we jumped in though and am comfortable with our stance on the subject. If we waited till our sites were valid before doing anything, I fear we would never even get into the game. [1] I did a preso at a WSG meet a while ago on the redesign of this site using css, heres the link if yr interestedhttp://webstandardsgroup.org/go/resource210.cfm cheers,petePeter OtteryHead of DesignFairfax DigitalLevel 3 Wharf 7 Pirrama RoadPyrmont NSW 2009www.fairfaxdigital.com.au
RE: [WSG] Is XHTML harmful?
... as for appropriate, that's a judgement call based on personal preference. mm.. he also did add: Note that I personally think it is unfortunate that the WAI WCAG guidelines mandate this. (I appreciate that the word 'appropriate' could be interpreted as a get-out - but I would argue that XHTML is appropriate for the task of document markup). XHTML did not replace HTML or it would have been called HTML 5.0. indeed. agreed. i guess his addy is in the archives, if u'd like to take it up with him :) kind regards Peter, vicki. ** 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] Is XHTML harmful?
I think there are valid arguments for both sides of this. This is also where I agree with the approach of the Apache/Cocoon advocates in that you serve up the solution which be suits the user agent. As standards developers we are working in an imperfect world and it's what frustrates us all. What I feel actually saves the HTML argument, in this case, is that browsers actually have very very intelligent parsers in them. It takes a lot of work to handle the thousands of cases that quirksmode can throw up. Thankfully that also works in our favour when we slip up on our own validation. If you took all the quirksmode logic out of the parser in the browser and it only did valid DTDs for HTML4 and XHTML, and spat the dummy like SGML and XML parsers when it found invalid markup, and where all documents were valid, I bet you that out of all the designs the XHTML would render more accurately. The reason being that if you are not closing all your tags it can become a guessing game for the parser where the CSS declaration may end in various parts of the document. It always strikes me that when using HTML4 you are at the mercy of the arbitoriness of the parser. I know there doesn't seem to be any obvious problems, but just the basics of parsing seem to leave you with the feeling it is inherently there. That to me is the main reason to use XHTML over HTML in this argument. - 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] Is XHTML harmful?
On 07/10/2004, at 9:45 AM, Peter Firminger wrote: (and it's debateable whether HTML 3.2 is either... By version do they mean the language or the subset? HTML 3.2 is the latest version of HTML 3) I suspect that they mean HTML4. From the HTML 4 rec W3C recommends that authors produce HTML 4 documents instead of HTML 3.2 documents http://www.w3.org/TR/html401/(under Status of this document) Also as HTML 3 did not include these elements: ABBR, ACRONYM, BDO, COL, COLGROUP, FIELDSET LABEL, LEGEND, NOFRAMES, OPTGROUP, TBODY, TFOOT, THEAD and the attributes SUMMARY and LONGDESC and extension of the TITLE attribute, it is unlikely that WAI would be happy with its use. (although I'm just guessing) http://www.w3.org/TR/html401/appendix/changes.html#h-A.3 Chris ** 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] Is XHTML harmful?
On 07/10/2004, at 10:07 AM, Geoff Deering wrote: The reason being that if you are not closing all your tags it can become a guessing game for the parser where the CSS declaration may end in various parts of the document. It always strikes me that when using HTML4 you are at the mercy of the arbitoriness of the parser. There is nothing to stop us writing well-formed HTML. Elements which have optional closing tags are just that - optional. It also strikes me that if you are writing HTML 4 against the DTD then Parsers will have no difficulty guessing where blocks end, optional end tags or not. Have you have ever pulled the render tree out of IE6 and seen what happens to lovely well-formed XHTML?.. It's parser strips out the optional closing tags and changes elements to upper case. The CSS still renders as expected. (as expected on IE not by the rec :) David Hyatt (quoted in my previous post) seems to say that current browsers can render HTML faster and have fewer problems rendering it than with XML. While I'd prefer him to fix it, there it is. Brendan Eich also seems to support Hayatt's assertions about this in this interview, http://www.itconversations.com/shows/detail156.html Are there references with some authority which support the other case; That XHTML parsing is better and faster? Cheers, Chris ** 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] Is XHTML harmful?
Manuel González Noriega wrote: You learn that you should validate anything before making it live (just like you'd spell-check and proofread anything before going to publication in the print world, for instance). ;) Hmmm... I started writing a reply a few hours ago and events overtook me. Still, I think I have a few points to add that haven't been made yet On use of validation: valid code is not difficult. Maybe it is because I came to this from programming, but I have zero difficulties in writing valid code. These days I hardly validate at all. Just a validation of the entire site as part of the final testing before going live. As Manuel said, it is just like using a spell-checker The other point I wished to make refers to the oft-mentioned user error can stuff my whole page argument. The problem there consists of a lack of appropriate programming. If you have a CMS, it should check all user input - for spelling, grammar (very hard to implement), and validity. If your CMS doesn't do this, why use it? The obvious answer is because no CMS does this. But they damn well should! (If you know of one that does, please send me a message off-list, I'd love to hear about it) Prepping a server to deliver XHTML 1.1 to browsers that can cope and HTML 4.01 to the rest takes a lot of effort and know-how in the first place. I believe the best way to do it is programmatically. If you're capable of that (or you have a programming gimp who is), then set up some automatic validation for user input and you're set Peter Ottery wrote: So when we 'sold' the CSS concept internally, we 'sold' xHTML along with it, and everything that goes along with it to focus attention on better coding practices. Pete, I'm assuming from your comments that you aim for valid code by changing institutional practices rather than programmatically? I don't have a problem with that. It is great if you can do it. My problem lies in that I've never had a client who could write even bad HTML. I rely on WYSIWYG for user input and that requires cleaning A further point: The school I work at teaches solely XHTML 1.0 Strict to the students (the staff get a tutorial to work through on MS Frontpage, but that is a whole different problem). Why do we do that? Because it teaches better technique, and because being capable of writing well-formed XHTML might even be important by the time they are out in the workforce doing something. Once they know how to write valid XHTML 1.0 Strict, it isn't too hard to raise the bar to XHTML 1.1 or to transfer to HTML 4.01. Teaching them XHTML 1.0 Strict leaves them with the choice of where to go when they are doing their own thing ** 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] Is XHTML harmful?
On 07/10/2004, at 10:07 AM, Geoff Deering wrote: The reason being that if you are not closing all your tags it can become a guessing game for the parser where the CSS declaration may end in various parts of the document. It always strikes me that when using HTML4 you are at the mercy of the arbitoriness of the parser. There is nothing to stop us writing well-formed HTML. Elements which have optional closing tags are just that - optional. I agree with everything you have said, but.. in complex designs, take out the end tags and that's exactly what you leave the parser to do... guess. Are there any parsers out there you explicitly trust to get it right every time? I don't. They may well do, but they are still guessing if there are no end tags. I'm much more happy to explicitly declare my design than have parsers guessing at what I've designed, the performance trade off is not so great. Now go into the area of accessibility, how are you going to tell all sorts of user agents and devices the full semantic meaning of the markup. What about when aural.css becomes mature? Will complex document in HTML4 be as exact as those following XML syntax? In my view, you cannot fully mark up documents with a trusted explicit semantic fullness without and XML definition. The border here might be small, but it's small enough for one definition to allow for best of interpretation and the other an explicit interpretation. - Geoff Deering ** 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] Is XHTML harmful?
Title: RE: [WSG] Is XHTML harmful? Lachlan wrote: On use of validation: valid code is not difficult. Pete, I'm assuming from your comments that you aim for valid code by changing institutional practices rather than programmatically? Agreed on both. The reality in big organisations is developers have a long list of things to do and correcting code that may not be causing a problem for the business right now, today, in $ terms, usually doesn't get a high priority on that list. and pages consequently sit there, invalid. Of course its the purpose of this list and all of us on it to re/educate people/clients, highlight the benefits, reverse that practice so we get this thing right. pete
Re: [WSG] Is XHTML harmful?
Are there any parsers out there you explicitly trust to get it right every time? I don't. I know of one, http://validator.w3.org/. Are you say though that User Agents are generally better/fast at parsing/rendering valid XHTML than they are valid HTML? They may well do, but they are still guessing if there are no end tags. I'm much more happy to explicitly declare my design than have parsers guessing at what I've designed, the performance trade off is not so great. I like to write valid markup too, and if your HTML is valid (written against the DTD) then the parser doesn't have to guess anything, I don't see your point as to why valid XHTML is technically better than than valid HTML. Now go into the area of accessibility, how are you going to tell all sorts of user agents and devices the full semantic meaning of the markup. What about when aural.css becomes mature? Will complex document in HTML4 be as exact as those following XML syntax? Yes, if you write it against the DTD and follow accessibility guidelines. There is no difference between the semantics or the accessibility of HTML4.1 and XHTML1.0. In my view, you cannot fully mark up documents with a trusted explicit semantic fullness without and XML definition. The border here might be small, but it's small enough for one definition to allow for best of interpretation and the other an explicit interpretation. Well-formedness has nothing to do with semantics. Except for the reasons give by Peter Ottrey the only technical reason for using XHTML is that you need the XML (this being the only technical difference between HTML4.1 and XHTML 1.0 ). Any other reason simply comes done to a matter of personal preference. Chris. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
