Why You Should Use XHTML 657
Da_Slayer writes "The w3's HTML group has released the 6th public working draft for XHTML 2.0. XHTML 2 is a general-purpose markup language designed for representing documents for a wide range of purposes across the Web. Meaning it is to be used for document structuring which is why it does not have presentation elements. The draft is located at w3's website. Also they have a FAQ about why you should use XHTML over HTML. It goes into specifics about embedding MathML, SVG, etc... and has links to tools and resources to help convert existing html documents to xhtml. One of those resources is a document on XML events and its advantages over the onclick style of event handling."
File this in the Irony category (Score:3, Insightful)
Re:File this in the Irony category (Score:2, Informative)
There were two good articles on alistapart.com [alistapart.com] about bringing /. up to code.
one [alistapart.com] and two [alistapart.com]
Inertia is an ugly thing.Re:File this in the Irony category (Score:3, Informative)
There's a big difference between converting a staticly-saved page to XHTML and patching up Slashcode to generate the same. The latter would have to be done to make Slashdot use XHTML, and it's a lot more work.
Still, CmdrTaco expressed interest in patches, if anyone would like to provide them.
Re:File this in the Irony category (Score:2)
...blaw, blaw, blaw...
Really, what does the state of Slashcode have to do with running a story on the needs and status of XHTML? Anything at all? Not really.
Re:File this in the Irony category (Score:4, Informative)
XHTML and XML?? (Score:3, Funny)
Re:XHTML and XML?? (Score:2, Informative)
Re:XHTML and XML?? (Score:2, Informative)
Comment removed (Score:5, Informative)
Re:XHTML and XML?? (Score:3, Informative)
Re:XHTML and XML?? (Score:5, Insightful)
Pardon me, but I feel you're not being didactic enough in your answer (even though I totally agree with you), and since this issue is a pet peeve of mine, and I really want the message to be heard, I'll take the liberty on expanding on your arguments. I hope you'll forgive my rudeness :-)
So, why do we need a strict language that will barf at the first syntax error ? Well, it's simple : the current situation is a huge mess. No, wait, it's a *HUGE* mess. Currently, anyone can cobble up some shoddy webpages with some lame software (hint : it starts with "Front" and ends with "page") and slap them up on his Web space. Few will test their pages with more than one browser (namely, Internet Exploder), and even less will think of the implications of their design outside browser-land. What about search engines ? Speech synthesizers ? Intelligent agents who would like to quickly get a summary of the site to syndicate it ? All these systems have to be geared towards correcting user and software-generated mistakes to provide useful results. This demands more sophisticated engineering, render the software more complex, and is an incredible waste of resources. It also ensures that no two User Agents (be them browsers or something else) will have the same idea of a given HTML document. Thus, it renders the job of Web programmers (like yours truly) more difficult, and sometimes just insane (think Netscape 4.x). Another waste of resource, induced by the necessity to circumvent problems in UAs, themselves induced by their necessity to circumvent mistakes in the original code. It's a vicious circle that cannot be stopped, but for a shift to a more sound model. That's exactly what the W3C is promoting.
Also, I would like to debunk one persistent myth, viz. the idea that laymen would no longer be able to write Web pages when everybody will have switched to send data with a application/xhtml+xml MIME type. Let's be serious one moment : Joe Sixpack doesn't type HTML. Period. Good ol' Joe uses a WYSIWYG authoring tool (like the aforementioned abysmal failure from Seattle). I'm totally confident that these authoring tool will be updated to include support for XHTML, and even for semantic markup. So, Joe will be all of a sudden writing valid pages, without even noticing it. As for the people who write HTML in Vi, I assume they're knowledgeable enough to go read the documentation (I was, and I sure am not the sharpest knife in the drawer[*]), so there's still no problem.
That's it. I hope you'll see there are indeed reasons to move over to a more rational way of creating Web documents, and I encourage you to try out XHTML, CSS styling, and to validate your pages. Have fun !
[*] No, I'm totally unrelated to Ken Brown or AdTI :-)
Re:XHTML and XML?? (Score:4, Interesting)
First off, Ma and Pa Kettle haven't cranked out their own web page in notepad since about '97 or so. Nowadays they use FrontPage for that which produces something akin to code soup.
Secondly I don't understand why new syntax precludes anyone. Learning new things is not difficult. I write valid XHTML 1 code by hand, it isn't very hard, in fact its much easier to control the elements than it used to be, and produce nice looking sites that downgrade nicely for people using broken (IE) browsers.
It makes everyone's life easier if there is a standard that is followed. You don't expect a programming language to know what to do with invalid syntax do you? Why should your data language be any different?
Re:XHTML and XML?? (Score:5, Insightful)
YES.
We should get ALL langauge compilers to ignore simple little syntax errors.
Why should we need a semi-colon to end a statement. The line feed should be enough.
Why should we need a closing brace. Cannot the compier SEE that it is the end of a block simply because the indenting is different?
!
The real problem is that people have been getting away with sloppy HTML. No closing TD, TR, TABLE tags because, hey, the browser allows it, and it works. Don't close italics in a TD cell? No problem!
MS started this mess when they had IE ignore HTML syntax errors. Netscape (at the time) was still strict. Suddenly many pages would not work in Netscape that worked in IE. This was perceived to be a Netscape problem, where in reality it was the coders problem.
Would YOU blame a compiler for trapping syntax errors? Of course not. So why should we allow sloppy HTML??
The funny thing is... (Score:3, Interesting)
...there are many languages out there which follow these rules, and humans always tend to hate them.
Why should we need a semi-colon to end a statement. The line feed should be enough. Well, that's the way it was in assembly language and shell scripting, but people bitched and moaned, and statement-separators have been a part of both kinds of language ever since.
Why should we need a closing brace. Cannot the compier SEE that it is the end of a block simply because the indenting is different? And yet
Re:XHTML and XML?? (Score:3, Interesting)
Second, I think we can all agree that--despite the "L" in XML and XHTML that these are not programming languages but markup languages. While there are clever things that can be done to markup, especially with XSLT and XSL:FO, markup languages are not procedural--and therefore not programming lanuguages--the way C++, Basic, o
Re:XHTML and XML?? (Score:3, Insightful)
This is 2004, not 1996. Most amateur web "designers" today and even many (more than you would imagine) professionals (those who are paid) never look at the HTML. "Ma and pa" are using FrontPage or some other WYSIWYG application to create web pages. It is the job of Microsoft and other software companies to make their web page-creating apps generate markup that complies with the new rules.
Re:XHTML and XML?? (Score:3, Informative)
Basically as long as HTML follows the syntax structure of SGML correctly it is considered valid, but XHTML must follow the rules of XML correctly in order to be valid.
Re:XHTML and XML?? (Score:5, Interesting)
The grandparent might also interested in the following:
XHTML is implemented in XML. So XHTML is to XML as OpenOffice.org's writer format is to XML. (Or as HTML is to SGML, or as this post is to English.)
People often say somthing is XML when it is really implemented in XML. Using that (misleading) terminology XHTML is XML.
-Peter
Re:XHTML and XML?? (Score:3, Informative)
I always thought it was a good way to think of the relationship.
Re:XHTML and XML?? (Score:3, Funny)
Perl I believe
RegardselFarto
Re:XHTML and XML?? (Score:5, Informative)
XHTML applies the rules of XML to HTML. For instance you can have one root node, you have to close all tags, attributes have to have single or double quotes around their values, etc.
Writing something that parses XHTML is a LOT simpler than writing something that parses HTML. It's also easier to confirm you've written it properly (using schemas for instance, which are also written in XML
Re:XHTML and XML?? (Score:4, Informative)
I'll tell you why it's easier to parse XHTML than HTML: if you're sure you've got well-formed XHTML data, then ALL you need to "parse" XHTML (that is, get it in a document tree format) is an XML parser, which someone else has conveniently written. Compare this with parsing HTML, which requires hacks to compensate for HTML's looser rules (i.e., elements like <p> and <br> which don't need to be closed off, etc.).
Now rendering XHTML is another story altogether, but there is no doubt that parsing XHTML is FAR easier than parsing HTML.
Re:XHTML and XML?? (Score:5, Informative)
You have to wonder... (Score:5, Interesting)
Re:You have to wonder... (Score:2, Interesting)
Now, the question is will Microsoft's various tools that generate HTML be able to generate valid XHTML. Considering the quality of HTML that Microsoft Word generates, I suspect it will have trouble meeting *any* standard.
Re:...in fact, you have to wonder... (Score:3, Insightful)
Hopefully, we will do what we're already doing in many places: let them use a markup generation tool; let them use templates; let them use a content-management system.
on slashdot? (Score:5, Insightful)
Re:on slashdot? (Score:5, Insightful)
Grr.
Re:on slashdot? (Score:5, Informative)
For those who didn't RTFA the parent post had, it restructures
* Savings per day without caching the CSS files: ~3.15 GB bandwidth
* Savings per day with caching the CSS files: ~14 GB bandwidth
And the traffic figure they used was from June 2000. Do the math.
Re:on slashdot? (Score:3, Insightful)
Sure, that's a lot of bandwidth, but not in dollar terms.
Large sites pay less than a dollar per gigabyte xfer'd. So, /. would save less than 5 grand per year. That's a lot of money to me and you, but maybe not to the guy(s) who don't want to overhaul a big site that's "not broken".
--
Re:on slashdot? (Score:5, Insightful)
Efficiencies (Score:3, Interesting)
Now maybe your preferred geeky thing is minimizing bandwidth over the short term.
And maybe others' geeky things include minimizing over a longer term.
I could spend $10K in time to save $5K/year in expenses, or $10K on some other effort that will have a better long term payoff.
The "editors" here ARE in fact geeks, and they know what they are doing behind the scenes, which you do not. Maybe you should assume they have some idea of what
Re:on slashdot? (Score:4, Insightful)
However, It sounds like are working on getting slashdot to be more standards compliant. [slashdot.org]
Re:on slashdot? (Score:4, Informative)
Re:The CmdrTaco Response (Score:2)
It isn't like a puppy is killed every time a GB of OSDN bandwidth is wasted.
Funny quote (Score:5, Informative)
Re:Funny quote (Score:4, Informative)
Of course, I'd like to see what the people who call Google a great, loving, standards-obeying company would say to the fact that Google can't handle application/xhtml+xml either?
Before I added a special-case hack to send my pages go Google as text/html (thus violating the W3C mime-type recommendation), Google would not read the content of my pages, and would offer to show an "HTML version" of my XHTML which was actually blank.
Because HTML is ancient... (Score:3, Funny)
No, XHMTL is broken (Score:3, Interesting)
Now we have XHTML and CSS. Neither of these are easy to learn. Neither of them is easy to use. Less technical people are incapable of using either. This is great for job security for webmas
Re:No, XHMTL is broken (Score:2)
Am I the only one who can see value in an HTML '5' that would clean up the problems with HTML 4.01, and add some easy-to-use ideas from CSS?
Re:No, XHMTL is broken (Score:3, Interesting)
Re:No, XHMTL is broken (Score:4, Interesting)
HTML is NOT easy. Writing a valid HTML documenta 20-30 lines long by hand is possible, but for any non-trivial page it is near impossible. (that there are no good HTML editors is besides the point). Any website containing more then 1 page should use some kind of automation to create HTML, be that continiously generated dynamic pages, or generating the HTML once per change. Spreading the rumor that HTML is easy to learn and that anyone can, and should, use HTML is a disservice to humanity.
If you are a non-technical person, or even a technical person whose job is not specificly HTML creation software writing, then you should not generate HTML by hand. Use some kind of CMS. Use some HTML editor. Use Docbook and "compile" HTML.
Why are Wiki's popular? Because they use a markup language that actually is easy, one that is hard to screw up.
Please, pleae, please, dont continue to spread the lie that HTML is easy enough for anyone to learn.
Boo-Hoo, Poor Newbies (Score:3, Insightful)
We also have C, Perl, Fortran, Lisp, and so on and so on and so on... and they are all difficult to use. You actually have to sit down, open a book, read, learn, and think. Can somebody tell me why XHTML should be anything different?
First of all, XHTML is easily recognizable to anyone who knows HTML. I don't know where you get off saying it's harder than HTML. As for CSS, it's a hell of a lot easier than messing with tens if not hundreds
Re:No, XHMTL is broken (Score:3, Informative)
HTML 4 was worse for the average guy than previous i
Is this really going to happen? (Score:5, Interesting)
I have to wonder if 2.0 is going to catch on. Internet Explorer isn't likely to support it any time soon, and nobody wants to code two versions of every web application.
Still, good FAQ on that site. I learned some details that had been hazy.
Mozilla composer (Score:4, Insightful)
/. should lead the way (Score:5, Interesting)
Re:/. should lead the way (Score:3, Informative)
*Savings per day without caching the CSS files: ~3.15 GB bandwidth
* Savings per day with caching the CSS files: ~14 GB bandwidth
Most Slashdot visitors would have the CSS file cached, so we could ballpark the daily savings at ~10 GB bandwidth. A high volume of bandwidth from an ISP could be anywhere from $1 - $5 cost per
Why You Should Use XHTML 2.0 ???? (Score:5, Informative)
Something better would be to use pure XML for creating content and then let the browser apply a CSS to present the content.
See Mozilla + CSS + XML = Structured + Formatted Content [xml-dev.com] for more info.
Re:Why You Should Use XHTML 2.0 ???? (Score:4, Interesting)
No, that would be very much worse. The whole point of a publically specified XML application like XHTML is that everybody understand what the element types mean. If you go around inventing your own element types, nobody will no what you mean. Google understands <h1> as being more important than normal text. It won't understand <my-fancy-heading> in the same way.
Re:Why You Should Use XHTML 2.0 ???? (Score:2)
Re:Why You Should Use XHTML 2.0 ???? (Score:4, Insightful)
Since they use practically identical tags and are structured in the same way, a well written (ie compliant) HTML 4 page will comply to XHTML with a change of doctype and a few minor tweaks (<br> to <br
Anyone who is in any way competent with HTML can switch to XHTML with no problem. In fact, for less technical people, XHTML will be easier to understand as the reams of presentation code will have been shifted to the CSS file, making the underlying (X)HTML easier to read and understand document structure.
If I'm completely off base about where you're coming from, please enlighten me.
Stuart
Re:Why You Should Use XHTML 2.0 ???? (Score:2)
CSS Zen Garden [csszengarden.com]
So Slow ... (Score:3, Interesting)
Is it my imagination or are XSLT transforms very slow. I know this will depend on what engine you use to transform, but during the course of designing a website for a friend I tried several Java based transforms to go from XML to an XHTML page.
Why are these operations so slow - I thought XML (and therefore XHTML) was supposed to be straight forward and easy to parse.
In my limited experience XHTMLs benefits seem to be "weakened" by parsers/transformers that are still a bit away from maturity (speed-wise).
(Hint: if anyone knows a lean, mean transformer nows the time...)
XML on web sites sucks (Score:4, Informative)
I'll go out on a limb and say that using XML as the document format for web site production is a terrible idea. XML is a great data exchange language between systems, but it's insanely inefficient for use within a single system. All of XML's positive attributes (self documenting, robust, extensible, supports encodings, validation, use XSLT to do transforms between arbitrary XML representations of data, etc.) are all important between loosely coupled systems. But those issues don't occur within a single system, and the overhead of using XML is immense. It's orders of magnitude faster to query a datbase directly than to parse XML, transform, etc.
Re:XML on web sites sucks (Score:4, Insightful)
XHTML is still completely valid on its own. It's a HELL of a lot easier to validate for one thing. Ever looked at the sourcecode to HTML validators?
Re:XML on web sites sucks (Score:2)
But keep in mind that the industry heavyweights who back these standards are all in the business of selling you hardware.
IBM, Sun, etc see a slow app as an opportunity to sell computers. If you can lower the cost to produce applications significantly by using XML, you can afford to buy more computers from IBM, HP, Dell, Sunc, etc.
Re:So Slow ... (Score:2)
If that isn't suitable for religious, other reasons, then I believe that Saxon is now fairly fast provided you can keep it in memory; being Java based, start up times can be a bit pants.
Beyond that, you might need to take care with how you write you XSL as this can impact performance, and also your XSLT transformer might provide a way to store "compiled" XSLT's (MSXML does).
I dont know... (Score:3, Interesting)
<p src="map.png"><span src="map.gif">Exit from station...</span></p>
seems a bit too... anal? or purist/academic at best.
I suppose it's a moot point if MS/Macromedia/Adobe comes out with a great XHTML2.0 WYSIWYG editor, then 95% of the developers out there wouldn't even care...
IMG is valid in XHTML (Score:2)
Re:I dont know... (Score:2, Insightful)
I've given people introductory "crash courses" in HTML before, and they often go something like this: "A tag is used to format content. Except for the img tag. That one IS content. And you should always close your tags. Except the img tag. It stands alone because it's an object not a formatting tag."
Not terr
Re:I dont know... (Score:2)
The examples you gave are not equivalent. The equivalent of: />
...is:
<img src="foo.png" alt="foo"
<p src="foo.png">foo</p>
The complicated example you gave is merely an example of how you can provide multiple fallbacks.
The history of IMG (Score:3, Interesting)
Now that every browser anyone would dream of using supports IMG in some form, even if it's just replacing the element with the contents of the ALT element, it's easy to forget about its heritage and not correctly shame the creators of this, one-broken-always-broken element.
IMG was added to Mosaic back in the day, and after it was implemented it was submitted for peer review. The "peers" correctly noted that the use of an 'alt' attribute to handle browsers which cannot display the image is inadequate becaus
Standards work now (Score:3, Insightful)
Now, Safari, Mozilla and Opera support about 98% of CSS-1 and parts of CSS-2, so it becomes possible to actually develop a working web site without spending 10 hours of testing and debugging (yes, debugging HTML) for every one hour of actual development.
Re:Standards work now (Score:2)
It's always the way. (Score:5, Informative)
Re:It's always the way. (Score:2)
The thing that I find takes the most time
Ugh (Score:2, Insightful)
Now you have to figure out what Doctype to set, learn CSS, enter some sort of weird workaround for IE, etc... Worse, HTML used to be fairly forgiving for the author so Newbies could get a decent page without spending hours and hours trying to figure out
Re:Ugh (Score:3, Insightful)
Not to mention accessibility. The vast majority of sites out there are all but completely useless to the blind, or those who require very large print, or who are browsing on PDAs, cellphones, or other small devices.
The new standards are a Good Thing, and if that means gramma can't
Re:Ugh (Score:3, Insightful)
I know the pages won't be very accessable, but the kind of people who need th
Re:Ugh (Score:4, Interesting)
It's not that hard to do.
1: add the doctype at the top.
2: always close your tags.
3: check you work with a validator.
html tidy will also identify and clean up any mistakes.
Re:Ugh (Score:4, Insightful)
Do remember that web development these days cannot rely on simple static text?
Do you realize that with HTML/XHTML editing tools around these days, it doesn't matter?
Right tool for the job, my friend. A text editor is for writing static text. HTML/XHTML tools are used for making web pages and interfaces.
Just because there's "doc types and CSS" out there doesn't mean you have to use them - go ahead and write crappy looking pages in notepad, just becasue you can. But if you are going to do proper, standard, stylish web development that is a good experience for the user, you may need to know some of this stuff.
Clearly you aren't a web developer.
Oh, pu-lease! (Score:3, Insightful)
Do remember that web development these days cannot rely on simple static text?
Do you realize that with HTML/XHTML editing tools around these days, it doesn't matter?
Right tool for the job, my friend. A text editor is for writing static text. HTML/XHTML tools are used for making web pages and interfaces.
Oh please.
Do I remember? Yeah, I've been coding HTML by hand since 1995, and my pages looked pretty messy back then. But it wasn't the HTML -
Re:Ugh (Score:4, Insightful)
Clearly you aren't a web developer.
Most of the web developers I know (and I know a lot) started out using tools like Dreamweaver and GoLive etc, which now output decent XHTML, but now they are starting to move toward XHTML and CSS in their designs (which are some [csszengarden.com] of [stopdesign.com] the [hicksdesign.co.uk] best [mikeindustries.com] on the net, might I add), and they're switching to using text editors exclusively for writing the code, plus your standard graphics programs for the images. I do the same.
The great thing about XHTML is that is separates the content from the design, which in turn makes your code beautiful and easy to write and maintain. I was looking at an XHTML page I had written the other day, and I thought, gee, I could just put this up as plain text and people would still understand it. It was free of all that contextual crap (tables, font tags, one-pixel spacer images) that heavily-designed HTML pages of two years ago were full of. So no, a text editor is not just for writing static text. I use mine for every aspect of the design process, though, admittedly ConTEXT [context.cx] is not notepad, it's pretty close. And I would contest that the sites I develop aren't crappy looking.
You may be able to design sites with a tailored WYSIWYG HTML editor, but you usally have little control over how everything fits together, and it results in messy code that is hard to understand. If that works for you, then fine, great. All I can say is that you better "know some of this stuff" and how to do it without your XHTML editor -- learn it in notepad -- and then, once you see what was output by your editor, and if you have any respect for the XHTML standard and the ideals that the W3C had in mind when they thought of it, I have a feeling you won't go back.
Re:Ugh (Score:3, Insightful)
HTML being forgiving is a bad thing. Sure, it's easier for the average person to crank out a homepage, but without strict standards, we ended up with a myriad of browser incompatibilities and mountains of sloppy coding that can't be parsed correctly.
XML and XHTML
Re:Ugh (Score:2)
Re:Ugh (Score:4, Interesting)
XML vs. XHTML vs. HTML (Score:2, Informative)
XHTML is the next iteration of HTML. It is more formal and more strict, and (hopefully) more consistent. From http://www.w3schools.com/xhtml/xhtml_html.asp:
XHTML vs. HTML:
XML:
XML is not really parallel to XHTML/HTML. It is more useful for defining data containers and storing data. It is another step along the path to separ
Re:XML vs. XHTML vs. HTML (Score:2, Informative)
Not sure this is not entirely true. Technically, a strictly conforming XHTML document is an XML document. If you think of an XHTML document like a hierarchy (which is in fact what it is in the Document Object Model), it becomes clear that a website is made up of data and data containers. This is my interpretation of it at least.
You are right that HTML and XML are really not parallel, though, other
But can it resist commercialization? (Score:5, Insightful)
That's what they said about HTML in 1992. Look what happened to it when it got popular: bastardized so badly with presentation elements that it lost almost all of its structuring features. Remember <fig>? It was obsoleted before it even made it out of draft status because commercial browser vendors (*cough* Netscape *cough*) pushed <img align> on everyone instead, because it was quick and easy. That's just one example. Who's to say this new XHTML won't be spoiled the same way? We could say "Use HTML if precise control over layout is needed" but back in the HTML days, we were saying "use PDF if precise control is needed" and we were ignored, and HTML was destroyed so badly that XHTML is now needed to fill the role HTML had to abandon.
What's to prevent lather/rinse/repeat?
What's to prevent lather/rinse/repeat? Nothing. (Score:3, Insightful)
"Structured documents" for public distribution usually don't work. The problem is that the costs of tagging are incurred by different people than those who benefit from it. Unless you have some enforcement agency that makes people tag their data
WYSIWYG Implementation (Score:4, Insightful)
Most web developers don't need it (Score:5, Insightful)
The only version of XHTML that is suitable for transmission as text/html is XHTML 1.0 following Appendix C. XHTML transmitted in this fashion doesn't have any of the benefits of mixed namespaces, stricter parsing, etc.
You get these benefits when you serve XHTML as application/xhtml+xml, and your visitors use browsers that support those features (such visitors are extremely rare - SVG isn't even in main Mozilla builds yet). But many legacy user-agents require text/html. Search engines would probably be the most important ones.
So unless you are willing to set up content-negotiation, sending different document types to different browsers, and unless you have a niche market that use browsers that understand these new features, you really aren't going to get anything from XHTML. Not for a few years, anyway.
Why you shouldn't use XHTML (yet) (Score:2)
Sending XHTML as text/html Considered Harmful [hixie.ch]
Besides which, XHTML 1.1 and 2.0 aren't even vaguely backward-compatible.
extra quotes (Score:3, Funny)
<img src=logo.gif width=10 height=10>
XHTML:
<img src="logo.gif" width="10" height="10">
I hate those extra quotes. Why is this progress!?
XHTML/CSS is picking up steam... (Score:4, Interesting)
There's really not much to it:
Firefox's WebDeveloper extension [mozdev.org] makes XHTML/CSS validation (among other funcs) so easy that there's no excuse to be lazy about it.
--
Warning: not for real web designers! (Score:5, Funny)
Meaning it is to be used for document structuring which is why it does not have presentation elements.
What! No <blink> tag?? No
No way I using it!11!1 I'm a serious web designer!
(This comment looks best at 717x913 resolution, using Internet Explorer for the security holes and that essential <marquee> tag. Page designed in Microsoft Word, because that HTML stuff makes my head swim. Enhanced with buggy JavaScript we stole off some Russian porn site, to resize your browser window, make its controls inaccessible, ensure the "security" of our images by disabling right-click, and to reject any browsers other than Netscape 4.72 and IE 5.5. Please bookmark this comment and come back when we've made the entire comment one big Flash animation completely inaccessible to anyone not running Flash or running Flash but on dial-up. PS: we appreciate your business.)
A Case for the use of XHTML (Score:4, Insightful)
HTML versus XML and the related set of schemas, including XHTML, can be compared to building with Lego versus real construction materials. HTML comes out of the realm of the old web where everyone and their uncle can be a so-called "web designer", a title anyone in the industry knows to actually refer to a graphic artist who draws buttons and banners. Coding in HTML revolves around nudging table cells by a few pixels this way or that way and hoping that all falls in place on that old piece of crap browser that half of the customers of your company are still using for some reason. HTML can be written by a 5-year-old. Some see this as an advantage, those who use it professionally can't see it as anything but a shame. I've known my fair share of web developers, being one myself, and the number of them who know anyhing about actual software development is probably less than one percent of the total.
XML, and all the web-related schemas and standards like XHTML, on the other hand, provide you with an ability to present very complex business domains over the internet. Anyone wno knows anything about programming will say that jumbling all your data, along with it's structure, along with it's presentation is a terrible way to write software. The new standards allow one to keep data separate (XML), structure separate (XHTML), and presentation separate (CSS). While it's admittedly more complex than the regular HTML it lets you do so much more with your data. Switch stylesheets and bam, your site looks completely different. Switch XSL stylesheets and you can serve the same data in completely different ways on a PC, a PDA, or a mobile phone.
Lastly I want to bring up that web clients are often used as front ends for company intranets and while it's going to be a while until web developers (and consumers!!!) will be able to enjoy the benefits of the move to XML on www those benefits can already be reaped in the controlled environment of your company intranet.
Displaying XHTML (Score:3, Interesting)
The problem I've found with fully using XHTML+CSS for web pages is that it is not possible to layout pages that will scale accurately as the font size is increased. So much for accessibility!
I wonder why it was decided that it would be useful for text that doesn't fit, to run-over other text and elements on the same page.
It would be better if we could tell the browser that when elements expand the other parts of the page must move out of the way.
- Brian.
CGI.pm (Score:4, Informative)
Ah portability..
Tranesterification (Score:4, Insightful)
Since many sites are using crappy HTML they want to spice up they tend to use equally crappy JavaScript to add little stylistic features. I think many people are surprised when they hit up a CSS tutorial and figure out they can replace their stylistic JavaScript with CSS and have much better performing web pages.
I'd love to see more sites using XHTML, even transitional XHTML, with CSS for styling and layout purposes. Documents end up much more flexible and quite a bit smaller. It is also easier for end users to override the page's CSS with their own to either make elements more legible or friendlier for their output device (PDA, cell phone, screen reader).
Coders of CMS engines: Please use sane template systems so it is easier for your poor end users to make their pages better comply with web standards. Also don't wrap stuff in tables, not everyone uses tables to lay out their pages! Presentation logic is fine and dandy but don't hard code layout elements, let the users decide! Thank You.
Time Stands Still for W3C (Score:3, Interesting)
Don't get me wrong-- they're doing the right thing, but it's as if they could shout at the top of their lungs that MathML and SVG should be standard and no one will care. Oh wait, nobody does. How many browsers support either "out of the box?" If you were to add up their market share it would be in the single digits.
It's time we just realize, as web developers and designers, that we are stuck with a horribly inefficient means to share information that is worsened by the lackluster industry movement required for change in the way we get at that information.
I'd say this is a new thing, but it's not. Look at any industry and the same thing always occurs.
Re:W3C useless (Score:2, Insightful)
Re:why you *should* use XHTML (Score:3, Informative)
I code valid XHTML nearly everday as a freakin' hobby. There's 3 useful things I've come to know:
Re:why you should NOT use XHTML (Score:3, Interesting)
Know any other programming languages that can do a completely understandable and arguably human readable 'hello world' like that? Yeah, I know there are probably a few. But that's not hard, man, I'm sorry. The doctype tag is the hardest par
Re:OK, ya got me (Score:3, Informative)
Allow me to illustrate the important difference between HTML and XHTML: the <i> tag vs. the <em> tag. They do the same thing, right? Wrong! They only look the same on a web page, in a normal visual web browser. But that's not all that XHTML is for -- imagine an audio web browser, for the blind. How is it going to know what to do
Re:Oh God, not again... (Score:3, Informative)
The id and name attributes aren't meant to be the same. The name attribute is used for naming form controls, and (for example) this means that all radio buttons that are meant to be part of the same set all have the same name. Since the id attribute is meant to contain a unique identifier, making them the same would mean either [a] making it impossible to group
Re:Has anyone tried coding a site in pure XHTML/CS (Score:3, Interesting)
Have you ever work on the website of another person, company, project using table for design ? It sis totally impossible to maintain it without losing much time.
Now about the goal of a website, it is not to look good but to provide information. Now if it look beautiful too it is better. But information is the main point and accessibility - I mean information for everybody (blind persons, persons using their mobile pho
Re:Has anyone tried coding a site in pure XHTML/CS (Score:3, Insightful)
No they don't, they can throw off screen readers which (rightly so) expect tabular data to be in tables.
Every site I've done in the past few months has been completely xhtml and css based. Sure, the first few times took a bit longer than before, but what I find now is that it takes me less time than it used to for a table based layout! Plus, if the client comes back a few months later wanting a redesign it's much easier because my content is separa
Re:Has anyone tried coding a site in pure XHTML/CS (Score:3, Insightful)
Get Firefox and install the Web Developer extension. It has a feature called View Style Information. Turn it on and your mouse becomes a crosshair. Click on an element and you can see exactly which CSS rules apply to that element.