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
I ask because I know visually impaired folks have been using the web since way before css became widespread, and one of my sites was recognised by RNIB as an accessible site, even though it was html 3.2 (it was just designed properly... ;) )
like
<h1>title</h1>
<div id="toplinks">links to main sections of site</div><p>lots of paragraphs</p>
<ul>
<li>and bulleted</li>
<li>lists</li>
</ul>
<h2>Next section of document</h2>
<p>more content etc</p>
<div id="nav">
<ul>
<li>nav links</li>
<li>here...</li>
</ul>
</div>
<div id="footer">
copyright stuff here</div>
Otherwise with table based layouts and lots of ciml's 'tag soup' you end up with a document that takes a lot of practice to navigate and work out the importance and order of elements.
Remember that if the device they use to view you doc on doesn't render tables then the 'flow' of your doc is worth sweet F.A.
Nick
This won't prevent the likes of <p style=" font-size: 24px; ">Main Heading</p> or <img ... alt="Link" />, but it will help to bring people towards "just design[ing] properly".
As a solid foundation based upon validating code, and true separation of style and content, XHTML is ideally suited to intergrate all aspects required to ensure accessibility in accordance to the WAI and Section 508 recommendations.
The commitment shown by web developers to the higher standards required by XHTML is self-evident. The phrase "I don't care if it's valid as long as it works..." is not likely to be heard here. Not with this family of DTDs.
- papabaer
Mike, there is a vast difference between authoring in XHTML (and saving as .htm or .html) and saving an XHTML document using an .xhtml extension: that is where compatibilty issues with older browsers occur.
No, there's a vast difference between serving a file as "text/html" and serving a file as "application/xhtml+xml". The former tells a browser to parse the file as HTML while the latter tells the browser to parse the file as XML. Right now, a significant number of people using XHTML on the Web are serving it as HTML and expecting the browser to magically deduce the file is XML by reading the leading bits of the file. (And MSIE doesn't even get that right.)
That's bad MIME and it's detrimental towards any real XML parsers roaming the Web, because they'll either miss XHTML files flagged as HTML, or be forced to wade through millions of legacy files just to find the real XHTML. Misidentifying XHTML files as legacy HTML is hindering the XMLization of the World Wide Web, not helping it.
On the flip side, labeling XHTML as proper XML locks out any legacy browser that can't be "taught" to handle new content-types. Considering that most "XHTML developers" aren't doing anything that they couldn't do in HTML, they would be disenfranchising a considerable number of users in the name of mere trendiness.
MIME is not a trivial issue. It's one of the fundamental protocols of the modern Internet, and refusal to deal with those issues is a short-sighted strategy that will have implications for years to come. Developers who don't have an awareness of exactly what they're risking when they mess with the HTML/XML divide aren't being professional, and they're being irresponsible when they give pithy advice like "the future is XHTML" without warning newbies that the future is more complicated than it looks.
I'm not quite sure why you might feel "condescended to..."
You must have missed Nick_W's ill-considered remark that not using XHTML is "pure laziness or incompetance". That was offensive to everyone who actually reads specifications and chooses not to ignore MIME considerations.
I'm sticking to my standards-following, big-picture, interoperability-worshipping guns: use XHTML if you're actually going to use it as XML. Otherwise, stick to HTML.
Crescendo says:
I've been writing in XHTML for about a year now. It forces you to be strict with your code, which is good for getting pages work in Netscape. (Miss a tag out in a table and it can crash.)
Argh! That's a browser hang-up, not a language feature. All browser crash on something; establishing coding practices based on browser quirks is wrong. Period. Coding well is a big picture thing: You do it for the principles of accessibility and interoperability, not because "Mozilla likes it", or some such nonsense.
Nick_W says:
Much of it is more in the structure of the markup. xhtml strict+ enforces the use and makes authors markup content in a way that can be more easily interpreted by differeing media such as screen readers.
Poppycock, hogwash, and FUD. The HTML Strict DTD is just as structurally-oriented as XHTML Strict, it was just underutilized by pixel-pushing designers because they obsessed over visuals. I've got hundreds of HTML pages on my site that are every bit as well-structured as your examples, and have been since they were originally written. (And some of them were originally written in HTML 2.0 or HTML 3.0.)
XHTML 1.0 hasn't seriously changed the structural logic of HTML, or even added any accessibility features. Pixel-pushers just notice them more in XHTML because XHTML and CSS are trendy right now, and Microsoft made the insane decision to force buggy CSS on legacy pages through browser-sniffing.
XHTML 1.1 is a different beast, but it's an XML beast, and authors shouldn't be using it unless they're serving it to XML-enabled readers, and willing to deal with all the complications that entails.
It is not splitting hairs to say that seperating style and content through XHTML & CSS is a very big change from how it "used to be..." Don't mistake "trendiness" for enthusiam expressed at a methodology that allows clearer focus on two very unique components of page authoring: coding and presentation.
The accessibilty benefits come from returning to a purer form of page structure, not the convoluted mess that grew out of complex table-based layouts. While a simple HTML document can be just a structurally sound and elegant as an XHTML document, it is the addition of CSS and XHTML's insistance on seperation of style and content that allows complex rendered presentations to retain simple, straight forward document coding. The design and layout are not dependent upon the page code. CSS takes care of that.
Further, CSS provides a means to provide alternative styles suitable for all accessibiltiy enhanced browsers as well as multiple devices. XHTML 1.1 or Modular XHTML is structured to further define subsets of of markup to address functionallity in the oncoming array of web-enabled devices without carrying additional overhead.
The W3C states very clearly the intent of XHTML, which is reformulating HTML as XML. The W3C also states that it is a transitional and migratory process. It certainly will not happen overnight.
Personally, I admire those willing to work out the problems, deal with yet undiscovered issues and help contribute to the knowledge base. Are there some who will wait to benefit from the work and commitment of others? Of course, that's human nature.
Learning is not passive. It takes commitment followed by action, followed by assimilation and evaluation. Bumps in the road? Sure... but they will be dealt with. Forge ahead! ;)
Much of it is more in the structure of the markup. xhtml strict+ enforces the use and makes authors markup content in a way that can be more easily interpreted by differeing media such as screen readers.
Poppycock, hogwash, and FUD. The HTML Strict DTD is just as structurally-oriented as XHTML Strict, it was just underutilized by pixel-pushing designers because they obsessed over visuals. I've got hundreds of HTML pages on my site that are every bit as well-structured as your examples, and have been since they were originally written.
Not quite. Several tags in HTML have been reinterpreted for XHTML to make them accessible for screen readers, PDAs etc. The tags LINK, IMG, BR, META and more do not have closing tags. So a program wishing to convert an HTML file via XML into something new would stop dead.
In order to cope, the tags have been changed as we know to include false endings (via a slash) so an XML parser can process them.
This is great because it satisfies two camps - the old school HTML 4 guys who can still view their files in desktop browsers, and the new school XML guys who want to use XSL or CSS to process the file in new and exciting ways.
The problem for developers is the mass of new standards (all beginning with "X") that keep arising. Have you heard about the new one? It's called X++, and is a programming language where all the code is written as XML. Check out [scottandrew.com ] for the news.
Poppycock, hogwash, and FUD. The HTML Strict DTD is just as structurally-oriented as XHTML Strict
I never said otherwise.
I think you're taking this all a little to heart mike. It's an interesting topic but not one worth getting upset over.
Nick
What extra accessibility do you get from strict html/xhtml + css?
I ask because I know visually impaired folks have been using the web since way before css became widespread, and one of my sites was recognised by RNIB as an accessible site, even though it was html 3.2
What the stylesheets do is permit all the folks who want a fancy look to achieve it without interfering with the accessibility. (Not to mention all the customers who want to "see something" for their money!)
Also, using stylesheets and strict html lets the users employ their own stylesheets. For example, if you code with <em> and <strong> instead of <i> and <b>, a talking browser can use a louder or more emphatic tone.
And - on the great day when the majority of browsers display CSS positioning correctly - we'll be able to code navigation on the bottom, for the blind users, yet display it on the top, for the sighted users. This is a vision of elegant design that makes me drool...
Not quite. Several tags in HTML have been reinterpreted for XHTML to make them accessible for screen readers, PDAs etc. The tags LINK, IMG, BR, META and more do not have closing tags. So a program wishing to convert an HTML file via XML into something new would stop dead.
XHTML is no more accessible to screen readers or PDAs than html.
If you're already downloading and doing transforms on a html page it is trivially easy to re-write the tags you mention at run time - you do not need to use xhtml.
vmcknight says:
Also, using stylesheets and strict html lets the users employ their own stylesheets. For example, if you code with <em> and <strong> instead of <i> and <b>, a talking browser can use a louder or more emphatic tone.
This is not the way current screen readers work. It does not make sense to use one screen reader for starting and moving around your OS, then stopping it to start your separate, talking browser.
Even if it did, it's trivial to emphasise <b> and <i> if you're already doing <em> and <strong>. But you don't want to do that because this "feature" would annoy the hell out of any visually impaired person - it would be turned off real quick... The main use for bold text is to facilitate visual page scanning. Screen reader users do the same thing by skipping around the page links. I don't think there is an effective use for italic text, other than artistic.
If you are concerned about accessibility try speaking to folks who actually use accessibility features, don't go on what the w3c says happens in utopia land!
BTW why is the w3c so out of touch? And why has everyone started unquestioningly following what they say in the past few years? Before that everyone just seemed to accept that they were a bit useless ;)
