Forum Moderators: open
I'd like to know how many of you have made that complete jump. I'd like to know why or why not you made your decision. Lets keep in mind also that a lot of authoring programs are not XHTML ready. Unless you have one let me know. What are your thoughts regarding this issue of XHTML and its partner CSS2. One can not work without the other. So the standards say. What is your point of view on this?
Nu1
[big]Anything less than XHTML 1 Transitional is just pure laziness or incompetence.[/big]
Only my opinion of course but hey, that's what makes this a great place to hang out: Lot's of opinions ;)
Nick
Just haven't felt the need yet. Probably will come back to bite me some day. However, there are just so many sites that are just plain vanilla HTML, I can't forsee any necessary change anytime soon as far as browsers or search engine rankings go.
XHTML can cetainly exist without CSS, if you truly undestand the concept behind separation of content and presentational styling, it apparent that styles need not be applied at all! XHTML delivers page elements and CSS provides the style information. A well formed, properly structured XHTML document is totally functional on its own.
I've always believed that one of the "hidden" benefits for web developers pursuing XHTML is that it teaches "by necessity" logical page & document structure.
Once freed from the constraints of table-based layouts, web pages are much easier to visualize for what they are: documents.
Then, using CSS, we have the option to customize the presentation. This is the real beauty of the XHTML & CSS relationship! This is what separation of style from content IS all about!
Try it once and you'll never go back.
The great thing about XHTML advocacy is that it's encouraging a whole bunch of people to take HTML seriously, and to treat it less like tag soup. Whether there's an 'X' in front of it or not, and whether it validates according to the rules of SGML or XML isn't of any consequence, IMO.
xhtml transitional is okay if you're starting out but xhtml 1.1 is the way to go.
Also, if the doc is marked up in xml then in the future you'll be able to do all kinds of wonderful things with it with xslt and xpath etc. (you can do some of this now in v6 browsers or with php/asp)
Nick
I also do see the point of CSS but here again their is that what if the browser does not support it type of issue. I realize that making a browser compatible site is the solution and that XHTML the standard that we should all be following but CSS is still not fully supported by the group of browsers on the market.
Nothing is fully supported by all browsers
So what?
Same game, different rules, but standards compliance will win out in the long run as monolithic browsers die out and the v7 browsers take compliance a step further.
Nick
To really appreciate the essence and full power of XMTML, you need to look at the latest recommendations and [url="http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/xhtml-modularization.html"]The Modularization of XHTML[/url].
The modularization of XHTML refers to the task of specifying well-defined sets of XHTML elements that can be combined and extended by document authors, document type architects, other XML standards specifications, and application and product designers to make it economically feasible for content developers to deliver content on a greater number and diversity of platforms.[url="http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/xhtml-modularization.html#s_intro_xhtml_mods"]Why Modularize?[/url]
Over the last couple of years, many specialized markets have begun looking to HTML as a content language. There is a great movement toward using HTML across increasingly diverse computing platforms. Currently there is activity to move HTML onto mobile devices (hand held computers, portable phones, etc.), television devices (digital televisions, TV-based Web browsers, etc.), and appliances (fixed function devices). Each of these devices has different requirements and constraints.
Modularizing XHTML provides a means for product designers to specify which elements are supported by a device using standard building blocks and standard methods for specifying which building blocks are used. These modules serve as "points of conformance" for the content community. The content community can now target the installed base that supports a certain collection of modules, rather than worry about the installed base that supports this or that permutation of XHTML elements. The use of standards is critical for modularized XHTML to be successful on a large scale. It is not economically feasible for content developers to tailor content to each and every permutation of XHTML elements. By specifying a standard, either software processes can autonomously tailor content to a device, or the device can automatically load the software required to process a module.
Two years from now there will still be people struggling to manage content & presentation; they will also wonder why they are having a hard time ranking well in search engines and they will also wonder why their site logs show 95% NN4 - all of the few remaining users.
XHTML is the path to cross-device coding.
- papabaer :)
[edited by: papabaer at 7:20 pm (utc) on June 27, 2002]
There's a potential speed advantage from using lower case tag names because they can compress better than mixed case tag names, but the unambiguous SGML rules about the optional quoting of attributes can save a few bytes anyway.
More seriously, namespaces and schema may well become useful, but as I currently use CMS approaches rather than XSLT I don't have a benefit. The conversion from valid HTML to valid XHTML for static sites is not a significant problem.
This brings us back to the main benefit in XHTML advocacy; it's encouraging a new generation to consider structured markup. They didn't take any notice of the crusty old "structured markup" brigade when we advocaded sticking to the rules and purpose of SGML based HTML; let's hope they listen to the cooler generation X(HTML). ;)
Nick_W:
> ...standards compliance will win out in the long run as monolithic browsers die out and the v7 browsers take compliance a step further.
Absolutely. The amusing thing is this progress started so long ago. Remember "4 Reasons to Validate your HTML"? That was back in 1998.
The previous focus was on lining up table cells; document structure was often sacrificed if even considered at all. Astute web developers COULD achieve both layout and good document structure, but their examples are most often overlooked by newbies whose sole understanding of HTML is that of a LAYOUT language - which of course, it is not!
XHTML + CSS presents strong lessons and guidelines. All the "grey areas" are effectively eliminated.
I'd like to know how many of you have made that complete jump.
I have.
Lets keep in mind also that a lot of authoring programs are not XHTML ready. Unless you have one let me know.
Homesite 5 has pretty good XHTML support (does that mean that Dreamweaver MX does too? I dunno.).
If you already know HTML 4.0, then XHTML is not hard at all. [w3.org...] describes the differences.
What compelling reasons are there to take on the "X" factor?
It's easy to learn, simplifies your markup, has improved seperation of form from content, insures the best forward and backward compatability for user agents, and because all the cool kids are doing it ;).
Plus, if you are doing anything at all with XML/XSLT, then it is the only way to go.
Thanks for the tip on homesite.
And thanks to all for the very educational responses.
Off I go to fully jump on XHTML. :)
Especially for those people who hadn't eliminated them in 1997 when HTML 4.0 Strict was formally recommended. :)
OK, I'm exaggerating. There were some changes for HTML 4.01 Strict, XHTML 1.0 Strict and XHTML 1.1 but they were small and conversion is trivial.
I consider myself lazy for still opting for Transitional quite often (or rather, allowing its use), but I wouldn't care if my staff wrote in XML or SGML, it's just too easy to convert.
There are more important aspects to 'seeing the light' of separate structure and content. I get far more annoyed about ".red { color: #FF0000; }" instead of ".important { color: #FF0000; background: #FFFFFF none; }" than I ever could about which DocType is used. (The former commits two important crimes against the Web, but that's for another thread...)
<added>Please, no one think I'm trying to put people off XHTML. I just think that people should think about why they're doing what they're doing. I fear that modularisation may be a bad thing, but that's no reason not to benefit from XML.</added>
First I converted my (valid) HTML 4.01 pages to XHTML Transistional, which is more or less a search&replace thing.
Validated.
Next step was to convert to XHTML Strict. Now this is a bit harder as some things are not allowed that I liked (like the target attribute in links), but anyhow, it was only a matter of time.
For my static sites, this was not really a must, at least not for now. But it was also fun and even cleaned up the code a bit. It might've made me and my sites ready for the future.
<added>The site in my profile is not yet in XHTML Strict (but Transitional), but I am working on it and it will go live soon.</added>
Why not switch? It doesn't hurt, it's fun, and xml is the way to go. You don't want to be like Don Quichote fighting against windmills, do you ;).
Then, go read [w3.org...] to find out why that happened. If you still don't understand what happened, you're not ready for XHTML.
I've been writing DTD-valid HTML since 1995. I don't need to be condescended to by XHTML-worshipping late-comers who are probably using the wrong content-type anyway. MIME is one of the few standards that might actually be more important to the Web than HTML, because it's the key to a multimedia Internet.
Saving an XHTML authored document using an .htm or .html extention and served as an Internet media type text/html does not cause rendering problems since the mime type is compatible with the extentions.
I'm not surprised IE6 has problems interpreting the .xhtml page you mentioned, since MSIE is known for "standards compliance issues." Neither Opera, Mozilla or NS6/7 has any such problems rendering the page since they were built with Web Standards considerations.
I'm not quite sure why you might feel "condescended to..." when all I see is evidence of concerned, professional Web Developers seeking to extend their knowledge in an open and mutually respectful forum.
- papabaer
There's not much difference between it and well-written HTML. Basically a case of using quotes for all attributes, making sure all tags are closed, even single ones like break and link, which need a space and a slash at the end. (Eg: <br /> ). (The space makes sure it works in Netscape 4 still.)
Here's a link listing the differences: [wdvl.com ]
The real reason for doing this is that an XHTML document is actually XML! Bit of a shock eh? So it can then be read by another system and processed properly. (Eg: converted to WAP.) So moving to XHTML gets you ready for working with XML, which is the way forward (but that's another thread.)
You don't have to convert to XHTML, as HTML will always exist (as the language used for desktop PC browsers). But I would advise doing so if you're serious about web design.
BTW, I believe even Front Page 2000 can save as XHTML. :)
[nypl.org...]
It's something you need to be aware of!
[big]Only kidding...[/big]
Nick
I think that the note referenced by mbauser is more important than just the file extensions; after all there is no reason not to send HTML content as www.example.com/example.jpg (apart from a buggy browser). XHTML 1.1 "SHOULD NOT" be sent as text/html. Even HTML compatible XHTML "SHOULD" be sent as application/xhtml+xml.
I don't mean to shout, just the words have special meanings. Indeed, RFC 2119 [ietf.org] seems to tell me that because HTML4 "MAY" be used for text/html, a user agent "MUST be prepared to interoperate with" it, "though perhaps with reduced functionality". Please check both documents for you may not agree with my interpretation.
Considering the practical for a brief moment; not only are UA's of the future required to accept HTML4 when requesting text/html content, they will accept it because there is so much of it. I still maintain that the benefits are in the mind of the document author, but that they are very real and important benefits.
Nick_W:
> Only kidding...
But Nick, I think it is the cool factor that causes a view of "xhtml transitional is okay if you're starting out but xhtml 1.1 is the way to go" instead of "Any Strict version is okay if you're starting out but xhtml 1.1 is the way to go".
In other words, it's the separation of style from structure that is important, rather than the parent language. Also, from a future-proofing point of view it is more practical to worry about Strictness than parent language.
It is much, much easier to convert from HTML 4 Transitional to XHTML 1.0 Transitional or from HTML 4 Strict to XHTML 1.0 Strict (or XHTML 1.1) than it is to convert from HTML 4 Transitional to HTML 4 Strict or from XHTML 1.0 Transitional to XHTML 1.0 Strict (or XHTML 1.1).
Let's see if this is corrected in IE6.5 (later this summer?), since XHTML is not going away, and is being adopted by a growing number of developers, M$ will have to address the issue. I hope... ;)
XHTML Compatiblity guidelines: [w3.org...]
This forum is frequented by dedicated professionals who are already preparing for the next stage of development. But the fact is, a significant proportion of the online content is being created by small businesspeople who want (or need) to do it themselves, and who do not have the time it takes to learn every new standard that is implemented. I would argue that an *overwhelming* percentage of content creation falls into that category.
In my opinion, if future releases of IE and Netscape are not completely backwards compatible, fully embracing HTML as it currently exists, then it will be a disaster. Imagine many many millions of websites that do not load, and the impact that will have on the average user. The analogy would be going into a bookstore, and every other book you picked up was blank. Eventually, you'd stop going to that store - it would be too frustrating.
So it is my hope that the browsers will embrace XHTML, but will make allowances for all the pages that are created using standard HTML.
But since I do not know what is being planned, my question is... does anyone know what level of compliance will be required?
Accessibility and backwards compatibility are the key, and browser makers know this.
Not only because of all the small/hobby sites that don't use strict xhtml/whatever (like Linus Torvald's homepage, and, er, Google, Amazon, etc :) ) but it would mean problems accessing archived sites/pages eg via waybackmachine.
It's in everybody's interest to keep browsers backwards compatible - how annoying is it when MS change the .doc format? - which imho suggests that deprecated/transitional html is more forwards compatible than the (still changing) xhtml+css combo.
The problem with IE was that Microsoft decided to use file extensions. This is absolutely the wrong thing to do. Imagine /overview/, which could be /overview/index.html or /overview/index.xhtml; or /overview.php, which could be XHTML 1.1, HTML 2 or plain text. It's the application/xhtml+xml content-type that should be recognised, but there's no real hurry as almost no one uses it.
Reno, mass market browsers will slurp tag soup for some time to come. Those that don't in the future should receive valid HTML 4 just as happily as XHTML 1.0 via a simple conversion.
mattur:
> ...which imho suggests that deprecated/transitional html is more forwards compatible than the (still changing) xhtml+css combo.
If you need the maximum proportion of people to see your layout and colour scheme, then yes transitional has more chance of that. If you need accessibility for the maximum proportion of people then no, but you would want to stick to HTML 4 or XHTML 1.0 with a text/html content type and follow the compatibility guidelines.
Confused? You are not alone.
