Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

HTML to be 'Incrementally Evolved'

CowboyNeal posted more than 7 years ago | from the new-and-improved dept.

359

MrDrBob writes "It has been decided that HTML is going to be incrementally updated, as the W3C believe that their efforts with XHTML are going unnoticed or unused by many websites out there. HTML is going to be worked on in parallel with XHTML (but with no dependencies), with the W3C trying to evolve HTML to a point where it's easier and logical for everybody to transition to XHTML. However, their work is still going to attempt to improve HTML in itself, with work on forms moving towards transitioning into XForms, but bearing in mind the work done by Webforms. In addition, the W3C's HTML validator is going to get improved, with Tim Berners-Lee wanting it to 'check (even) more stuff, be (even) more helpful, and prioritize carefully its errors, warning and mild chidings'. This looks like a nice step forward for the W3C, and will hopefully leave all the squabbling and procrastination behind."

Sorry! There are no comments related to the filter you selected.

hi (-1, Troll)

Anonymous Coward | more than 7 years ago | (#16622504)

have yourself a nice cup of ye ole frosty piss!

Please upgrade BLINK (5, Funny)

LiquidCoooled (634315) | more than 7 years ago | (#16622510)

We cannot have new HTML without upgrading the best part of the web.

Example of server side blink [blartwendo.com]

Wonderful!?

Re:Please upgrade BLINK (3, Funny)

Anonymous Coward | more than 7 years ago | (#16622540)

Server side blink's nothing. I want blink integrated into the database engine used for data storage. Imagine MySQL having blinkingtext field type. Wouldn't it rock?

Or maybe we should have blinking characters added to Unicode?

I'm sure these would be nice innovations that Microsoft could include in post-Vista Windows versions.

Re:Please upgrade BLINK (0)

Anonymous Coward | more than 7 years ago | (#16622650)

"Note: if you did not see the blinking text above, it means that your browser is not compliant with the Web 2.1 standards. An easy way of checking whether your browser is standards compliant is to check whether the installation files for your browser were smaller than 50MB, or the run-time memory usage is less than 300MB. If this is the case, you should download a more recent browser to get the full Web 2.1 experience."

50MB browser install, 300MB ram. Yah, sure.

I run Opera 8.54. The main directory is 3.5MB. There is one plug-in for TIFF at 650KB. The entire install is 5.6MB.

My web experience is fine. I have no plans to upgrade to Web 2.1

Re:Please upgrade BLINK (1)

thePowerOfGrayskull (905905) | more than 7 years ago | (#16622672)

Way to go with the sense of humor!

Re:Please upgrade BLINK (0)

Anonymous Coward | more than 7 years ago | (#16622782)

Some people have sticks up their asses. Can you tell which ones? :)

Re:Please upgrade BLINK (2, Funny)

drpimp (900837) | more than 7 years ago | (#16622798)

My IE 4.01 came with Windows and the blink doesn't work. It was much larger installation than 300MB and it still doesn't work. Please explain!!!

Re:Please upgrade BLINK (1)

ObsessiveMathsFreak (773371) | more than 7 years ago | (#16622874)

I once came across a page composed entirely of blink tags. The doctors say its getting better, but I still get headaches sometimes.

Re:Please upgrade BLINK (1)

LiquidCoooled (634315) | more than 7 years ago | (#16623136)

For future reference:

WARNING:
Do not stare at BLINK text with remaining eye.

This will change nothing (0)

Anonymous Coward | more than 7 years ago | (#16622538)

Yea, I'm sure that changing which policy it's all listed under will change what all of the lazy web developers and their authoring tools will produce right away

This is a response to the WHATWG and Hoehrmann (3, Informative)

YA_Python_dev (885173) | more than 7 years ago | (#16622968)

I believe that this is a response to the actions of the WHATWG (Web Hypertext Application Technology Working Group) [whatwg.org] (X)HTML 5 [whatwg.org] and to Bjoern Hoehrmann leaving the W3C QA [w3.org] .

So it's not a new pie-in-the-sky idea like XForms or XHTML2, but something much more likely to be useful to web developers that need to work in a world where IE is (still) the biggest fish.

Kansas will ban this (0, Funny)

Anonymous Coward | more than 7 years ago | (#16622562)

Because we all know God created HTML in 6 days, and evolution is impossible. ;-)

HTML is broken (1, Insightful)

Anonymous Coward | more than 7 years ago | (#16622568)

HTML should go in a direction where content and form are truly separated. Have a document (or part of a document) mark the content in a purely logical fashion (like XML) and another document (or another part of the document) describe a presentation and which parts of the content to use where in that presentation.

HTML relies too much on the order of the content for presentation. It should be more like the workflow in a DTP program: Add a text box to the layout, then fill it with text.

Re:HTML is broken (2, Interesting)

sqlrob (173498) | more than 7 years ago | (#16622686)

Re:HTML is broken (2, Interesting)

Anonymous Coward | more than 7 years ago | (#16622888)

I know CSS, but that's a far cry from what I want. I want something like "box1.top=page.top+header.height*1.1; box1.height=box2.height=auto; flow=box1,box2; flow.src=http://domain/document.xml#article.text.m ain", if you understand what I mean. CSS relies too much on the position of the element in the document. This leads to the static layouts that you see everywhere today. Once you've positioned something "out of flow", only its children can be positioned in relation to that element.

More focus on standard the most will ignore. (3, Insightful)

macurmudgeon (900466) | more than 7 years ago | (#16622578)

What practical effect will this have? As long as browsers will render junk (X)HTML most people won't bother with an updated standard any more than they do the present one. Learning any proper coding system is work. What's the incentive other than pride in the craft? Firefox, IE, etc. make learning standards optional, which is just another word for more work.

Re:More focus on standard the most will ignore. (2, Insightful)

MrDrBob (851356) | more than 7 years ago | (#16622624)

I think the way the W3C are going to try and go about it means that they'll gradually upgrade HTML so that there will eventually be a clear and simple transition path to XHTML, and therefore more websites will make the jump into the land of order.

Re:More focus on standard the most will ignore. (0)

Anonymous Coward | more than 7 years ago | (#16623216)

"there will eventually be a clear and simple transition path to XHTML, and therefore more websites will make the jump into the land of order."

How many transition paths do we need? Isn't XHTML suppose to be a transition path to XML? And arguably what's been holding back XHTML+CSS so far is likely IE6. But nevertheless, when it comes to commercial web site development, standards are out the window. These sites will mix and match all standards for their desired effect and what works for the many HTTP user agents.

Another transition standard means another 8 years before IE7 adopts it and we would be in the same boat as today with XHTML, IMHO.

 

Re:More focus on standard the most will ignore. (1)

arose (644256) | more than 7 years ago | (#16623366)

A Waste of Time (4, Insightful)

ImustDIE (689509) | more than 7 years ago | (#16622592)

I don't really see how this will improve the chances of their standards being adopted. It's not exactly like the leap from html to xhtml is all that confusing as is. This will just be even more confusing. Good luck getting all of the major browsers to support all of these incremental changes when they can't even keep up with the standards suggested years ago.

Re:A Waste of Time (3, Insightful)

baadger (764884) | more than 7 years ago | (#16623408)

Agreed. I don't see how incremental changes is going to do anything but produce more versions of legacy HTML to worry about in X years time when everyone should be using XHTML already.

There are plenty of other things the W3C could work on. How about they spend some time extending 'forms' (which are essentially just embedded controls) to incorporate more complex widgets like embedded video viewers or audio players? I'm sick of being a Linux user and hitting pages that use some strange flash/activex player system or something thats sized in a pop up explicitly for Windows Media Player's browser plug in.

They wouldn't actually have to produce anything using native widgets, just a set of standards regarding embedded video player sizes (and perhaps basic layout formats) that implementors could follow, and suggest a standard for styling this via CSS and controlling it via javascript.

The web is more than just hypertext now, people expect media, but as it stands theres a dozen different ways to embed things like video it into a web page unlike images and the old faithful <img> tag. I say if it can work for images it can work for video and sound, and even flash and we can do away with alot of this activex and netscape embedded junk.

Back on getting people to move to XHTML, I blame schools, the various courses i've been on that mention HTML still talk of it as a series of tag's in vaguely the right order rather than explaining the concept of XML, nesting or CSS.

WHY XHTML are going unnoticed ? (0)

unity100 (970058) | more than 7 years ago | (#16622602)

The answer is - we DONT need it.

Thats as simple as it is.

As it is, html serves its purpose. Neither the visitors nor developers need more from html.

It is a problem with such groups like w3c that they have a baseless belief that even something that people are satisfied with needs tampering with.

You know who needs it (-1, Flamebait)

krell (896769) | more than 7 years ago | (#16622776)

Who really needs this? The only ones who are excited are likely the adslingers, looking for a new way to slide, pop, fade, or otherwise "extense" advertising windows at us.

What a stupid comment (1, Interesting)

Anonymous Coward | more than 7 years ago | (#16622934)

he only ones who are excited are likely the adslingers, looking for a new way to slide, pop, fade, or otherwise "extense" advertising windows at us.


What difference does it make if an ad is served using well formed markup?

Being forced to use well formed markup has the potential to stop some of the more scummy tricks advertisers use. It also forces them to employ people who understand document structure and these people would generally be opposed to obnoxious ads.

A solution in search of a problem? (0)

Anonymous Coward | more than 7 years ago | (#16622778)

You mean some standards committee somewhere pulled a solution in search of a problem out of its collective rectal database?

No! Can't happen! :-P

Re:WHY XHTML are going unnoticed ? (4, Insightful)

CRCulver (715279) | more than 7 years ago | (#16622796)

As it is, html serves its purpose. Neither the visitors nor developers need more from html.

HTML doesn't serve its purpose, because it doesn't mandate a lack of separation between content and style. For one, that means that it's difficult to process HTML pages with semantic tools. One of my favourite recent reads has been Visualising the Semantic Web [amazon.com] ed. Geroimenko and Chen (Springer Verlag, 2005), which shows the rich possibilities of extracting information and transforming it, such as into a graphical display, or reorganizing it. This is all a cinch with any valid XHTML Strict page, but as long as we're stuck in HTML 4.01, these abilities will never be widely available to us.

Furthermore, creators of accessibility software are constantly marching uphill. Just yesterday the BBC had a report [bbc.co.uk] on how hard it is for blind users to use most plain HTML websites.

Re:WHY XHTML are going unnoticed ? (1)

unity100 (970058) | more than 7 years ago | (#16622924)

accessibility concerns i believe has to stop at a certain level.

What does redesigning the whole world over again for 10% of the population sound like ?

It sounds like overdoing it for me.

Re:WHY XHTML are going unnoticed ? (1)

CRCulver (715279) | more than 7 years ago | (#16622948)

Making buildings accessible during any further development is already mandated by law in the United States. Extending this requirement to websites is reasonable.

Re:WHY XHTML are going unnoticed ? (0, Troll)

daviddennis (10926) | more than 7 years ago | (#16623422)

Just because it's the law doesn't mean it's good law.

I see people redesigning everything for wheelchairs, but the number of times I've actually seen people with wheelchairs USING them I can count on the fingers of two hands, in a decade of watching.

Wheelchair ramps and handicapped parking are great for hospitals, a stupid waste of effort and money for everything else.

And I think the same thing about accessiblity for HTML, especially when it's rammed down people's throats with all this politically correct garbage saying we're all disabled at heart.

People who are disabled, retarded, ADD, stupid, etc, etc, get all the special treatment in our society and those with brains get nothing. The "Exceptional Child" in education courses is the dumb child, not the smart one - and you can guess who gets all the attention.

I think it's just plain, well, dumb for a society to act this way.

D

Re:WHY XHTML are going unnoticed ? (3, Informative)

oyenstikker (536040) | more than 7 years ago | (#16623012)

If your web site is part of a federal contract, it has to be compliant.
http://en.wikipedia.org/wiki/Section_508 [wikipedia.org]

Re:WHY XHTML are going unnoticed ? (2, Interesting)

psykocrime (61037) | more than 7 years ago | (#16623034)

For one, that means that it's difficult to process HTML pages with semantic tools. One of my favourite recent reads has been Visualising the Semantic Web [amazon.com] ed. Geroimenko and Chen (Springer Verlag, 2005), which shows the rich possibilities of extracting information and transforming it, such as into a graphical display, or reorganizing it. This is all a cinch with any valid XHTML Strict page, but as long as we're stuck in HTML 4.01, these abilities will never be widely available to us.

Well said. This is exactly why we need XHTML.

Re:WHY XHTML are going unnoticed ? (2, Interesting)

cperciva (102828) | more than 7 years ago | (#16623132)

HTML doesn't serve its purpose, because it doesn't mandate a lack of separation between content and style.

Maybe HTML doesn't serve your purposes, but it certainly serves my purposes.

Personally, I couldn't care less about fuzzy concepts like the separation of content and style; I just want to be able to write webpages in nano which look decent to most visitors.

Re:WHY XHTML are going unnoticed ? (1)

CRCulver (715279) | more than 7 years ago | (#16623290)

Personally, I couldn't care less about fuzzy concepts like the separation of content and style; I just want to be able to write webpages in nano which look decent to most visitors.

You don't need anything more than a simple text editor like nano to write XHTML, either. And if you even know how to use nano, then the usual excuse that it's too difficult to close tags after you open them (the only big hassle in XHTML) probably doesn't apply.

Re:WHY XHTML are going unnoticed ? (0)

Anonymous Coward | more than 7 years ago | (#16622804)

Incorrect! I know TONS of webmasters who would use xhtml, but shitty IE6 and even 7 doesn't support the MIME type.

Re:WHY XHTML are going unnoticed ? (2, Insightful)

JebusIsLord (566856) | more than 7 years ago | (#16622918)

xhtml 1.0 doesn't need the xml mimetype, only 1.1 does. The IE7 team's rationale is that they don't want to support the mime type until the xml renderer is capable of processing xhtml properly. Just "accepting" the xml mimetype and then using the html engine is cludgy, and I agree with him. But yeah: IE7 doesn't support xhtml 1.1. This is still planned for later (IE8?)

Re:WHY XHTML are going unnoticed ? (1)

YA_Python_dev (885173) | more than 7 years ago | (#16623074)

Yeah, technically the XHTML 1.0 spec allows to send documents with the text/html mime type, but please don't do it! [hixie.ch]

If you care about standards and want something readable by IE (which isn't always necessary), then better HTML 4 Strict than some XHTML Transitional sent as text/html (Gecko uses Standards Mode for the former and Quirks Mode for the latter).

Re:WHY XHTML are going unnoticed ? (1)

JebusIsLord (566856) | more than 7 years ago | (#16623176)

I don't think their argument in that link is any stronger than "if you use the text mimetype, and then switch to the xml mimetype later, you'll get mad at xhtml. Therefore don't use xhtml".

The W3C page suggests that the xml mimetype is preferred, but that text is acceptible. I'd still argue that writing strict (and good!) xhtml 1.0 for now makes the transition later to 1.1 easier. If you write html 4.01 now, you'll have a slightly longer climb.

Re:WHY XHTML are going unnoticed ? (0)

Anonymous Coward | more than 7 years ago | (#16623252)

Rubbish, XHTML1 was designed to be backwards compatible with HTML4, there is no MIME type issue. My servers switch the MIME type according to the accept header, browsers accepting XHTML get XML and other UA's get HTML all with a HTTP-Vary. Identical content and no problems reported on production sites for years.

Hixies stance strikes me as one of those occassional kooky viewpoints we all have about things we're involved with.

Re:WHY XHTML are going unnoticed ? (1)

YA_Python_dev (885173) | more than 7 years ago | (#16623446)

Identical content and no problems reported on production sites for years.

I'm pretty sure that you can't show me a single example of a page that validates as both XHTML and HTML, so you are sending invalid content under at least one of the mime types. And you are discriminating against non-IE users, because all the XML parsers currently used require the full data, while HTML parsers start parsing (and displaying) the page as soon as they can. And don't tell me "no problems reported": web browsers can display almost any crap you can put together, if you use standard DOCTYPEs and/or XHTML mimetype try validating your pages first.

Re:WHY XHTML are going unnoticed ? (0)

Anonymous Coward | more than 7 years ago | (#16622878)

Define "we"

"We" need xhtml, "we" pull web pages into XML parse trees all the time as part of our jobs. "We" have been doing XHTML1-strict since 1999. That is where "we" stand and the reason "we" stick with XHTML1 is because it is widely accessible. It allows for serving as text/html to legacy browsers(eg: IE7), including text mode browsers like lynx. "We" are very happy with XHTML1 strict.

Thank "you" very much!

Re:WHY XHTML are going unnoticed ? (1)

unity100 (970058) | more than 7 years ago | (#16622988)

we - 'not you', 'us' the other 'we'. there are numerous ways of pulling content and putting it online in an interactive manner.

Re:WHY XHTML are going unnoticed ? (0)

Anonymous Coward | more than 7 years ago | (#16623078)

there are numerous ways of pulling content and putting it online in an interactive manner.


Numerous ways of generating an XML-like parse tree from arbitrary web content? Are you volunteering to maintain a tag soup parser or just talking utter bullshit?

Re:WHY XHTML are going unnoticed ? (1)

psykocrime (61037) | more than 7 years ago | (#16622998)

"We" need xhtml, "we" pull web pages into XML parse trees all the time as part of our jobs.

Exactly. It makes life simpler when HTML is actually XHTML as we can use common, standard APIs and parsers and
get predictable, deterministic results. Accepting kludgey, broken, badly formed HTML and trying to parse it
is a much worse proposition than getting well formed XML.

Re:WHY XHTML are going unnoticed ? (1)

Hatta (162192) | more than 7 years ago | (#16622906)

The answer is - we DONT need it.

Honestly, I don't see the need for anything beyond HTML 3.2. All this new crap does is get in the way.

Re:WHY XHTML are going unnoticed ? (1)

Bluelive (608914) | more than 7 years ago | (#16622912)

As a developer you soon notice that treating html as xml is an easy way to make generation easier and with less bugs.

Re:WHY XHTML are going unnoticed ? (1)

TheRaven64 (641858) | more than 7 years ago | (#16622990)

Not only that, but you can easily mix XML dialects in the same file. You can put XHTML, MathML and SVG in the same document, and then have them all exposed through the same DOM tree to your scripting. Sounds like a good reason for XHTML to me...

Re:WHY XHTML are going unnoticed ? (0)

Anonymous Coward | more than 7 years ago | (#16623120)

Good point, I'd much prefer to see the W3C concentrate on compound documents rather than HTML or more stupidity of the XHTML2 variety.

Re:WHY XHTML are going unnoticed ? (1)

smallpaul (65919) | more than 7 years ago | (#16623014)

As it is, html serves its purpose

That's a ridiculously short-sighted assertion along the lines of: "The world only needs five computers" and "nobody will ever need more than 640 K of RAM." The Web is the most important application development platform in the history of computing and HTML still lacks some form and navigation widgets that were common on graphical platforms 15 years ago. These limitations mean that sites are full of accessibility and security-destroying Javscript.

Re:WHY XHTML are going unnoticed ? (0)

unity100 (970058) | more than 7 years ago | (#16623320)

yes. definitely. we need more widgets.

i tell you, nobody needs widgets.

visitors come to a site, they check if it directly has what they looking for for only 8 seconds, if they find it, they get it and go. and they want the link to what they want to be in easy huge form, be it a big button or huge text link, thats that. theres no need of widgets in this.

Re:WHY XHTML are going unnoticed ? (1)

s2jcpete (989386) | more than 7 years ago | (#16623172)

I take it you are not a programmer? Have you ever tried to parse a website for content? With HTML you are stuck with REGEX or some such hack, xml is simple, you run it through an xml parser and bam, you have a complete DOM tree.

Re:WHY XHTML are going unnoticed ? (1)

unity100 (970058) | more than 7 years ago | (#16623430)

i am a developer and i have ben hired to do many parsings of remote sites. I did it with php, and wrote my own routines based on the requirements. i never needed a whole standard changed to do a parsing.

Re:WHY XHTML are going unnoticed ? (1)

tonigonenstein (912347) | more than 7 years ago | (#16623188)

Exactly. Assembly works, why bother with so called "high level" languages?

Re:WHY XHTML are going unnoticed ? (3, Insightful)

hritcu (871613) | more than 7 years ago | (#16623324)

It is a problem with such groups like w3c that they have a baseless belief that even something that people are satisfied with needs tampering with.
My opinion is also that is their quest to "evolve" their standards, the W3C is starting to become an obstacle for their adoption. It is evident that it is impossible to make something a true standard (adopted by the wide majority), when you make it a moving target at the same time. So the W3C should concentrate on making higher quality standards, rather than releasing poor standards often (like they do now!). "Release early, release often!" is good practice for (open source) developers, not for standard bodies!

let's create another group (1)

aitan (948581) | more than 7 years ago | (#16622604)

I welcome the idea that at last the W3C has get down from their high views and realize that most of the web is HTML and unless the web browsers are able to understand new markups the web developers can't use them. So instead of forcing everyone to dump everything they know the right approach is to fix existing problems in the current specs and move them forward to such ideal world step by step.

But I don't like the tone of the message itself as it refers to the WHATWG:

An issue was the formation of the breakaway WHAT WG, which attracted reviewers though it did not have a process or specific accountability measures itself.
As the WG is currently formed by developers from 3 of the 4 browsers engines, it would be a real disaster to ignore all they current work

Looking forward to more crashing browsers (1)

krell (896769) | more than 7 years ago | (#16622606)

Looking forward to more crashing browsers and garbled pages due to the new stuff. There's a LOT that can be done with standard HTML, even if it is tedious to do so, without turning it from something elegant into a whopper of a monster.

Re:Looking forward to more crashing browsers (1)

NamShubCMX (595740) | more than 7 years ago | (#16623242)

I believe there would be LESS crash if browsers would support *just* XHTML, instead of providing fixes for all the broken code out there.
Of course 90% of the web would stop working too, for better or for worse.

Advantages? (1)

debilo (612116) | more than 7 years ago | (#16622614)

I'm not a web designer. I do know, however, the difference between HTML and XHTML (Wikipedia can be so incredibly useful [wikipedia.org] ), but I don't quite understand the advantages of XHTML over HTML. Wikipedia notes this:
Whereas HTML is an application of SGML, a very flexible markup language, XHTML is an application of XML, a more restrictive subset of SGML. Because they need to be well-formed (syntactically correct), XHTML documents allow for automated processing to be performed using a standard XML library--unlike HTML, which requires a relatively complex, lenient, and generally custom parser (though an SGML parser library could possibly be used).
To laymen like me, this sounds rather cryptic. Could any of you web gurus please elaborate, and/or list other advantages of XHTML?

Re:Advantages? (2, Informative)

Ford Prefect (8777) | more than 7 years ago | (#16622700)

To laymen like me, this sounds rather cryptic. Could any of you web gurus please elaborate, and/or list other advantages of XHTML?

With it being XML, it's easier to read with other tools - using an XML library makes it trivially easy to write code to turn an XHTML web-page into a highly structured, tree-like associative array which contains everything the original page contains.

In layman-speak - instead of mashing through the 'view source' equivalent (one big string), it becomes a mightily detailed tree, with every section of the page as another branch, twig or leaf. And to keep with the arboreal metaphor - when one has finished with one's web-page topiary, pruning or grafting, it's really easy to convert it back into XHTML - without losing anything in the process.

Re:Advantages? (1)

MrDrBob (851356) | more than 7 years ago | (#16622710)

Basically, XHTML is a lot more regular and strict in what is allowed than HTML, so mistakes can more easily be found by automated parsers (e.g. browsers), and can be whined about. HTML is very lax in this respect, so when a browser encounters an error, it generally tries to work around it. This means that different browsers can render the same page different ways.

Additionally, XHTML forces content to be separate from style, unlike HTML. In a nutshell, this enables web developers to easily apply a uniform style across a website, and doesn't allow them to fall into the trap of redefining a standard appearance for each page.

Re:Advantages? (2, Interesting)

MBCook (132727) | more than 7 years ago | (#16622714)

XHTML is VERY strict. That makes it very easy to parse. But that same facet makes it very tough to write by hand. What I mean is that with HTML you've got all your tags, but many people don't write them correctly. How often do you write a closing P tag? Do you close your IMG tags like you should (<IMG SRC=... />)? Most people don't. If you did that in XHTML, you're page would be wrong and if the browser is in strict mode, things die with an error. Improper nesting can also cause this (<P>Some <B>stuff</P> things </B>).

This adds serious complexity for some people. While Dreamweaver can easily handle that, can you imagine what it would take to make /. XHTML? You would have to write little bits to parse out every comment and story submission that's in HTML and then output it into valid XHTML. That's a TON of work. Otherwise, one single error and /. could stop rendering at all (if the browser does what, IIRC, it should).

However, the fact that tags are always opened/closed correctly, always nested correctly, etc makes XHTML very easy to parse for a computer. This would make things like screen reading, data scraping, automatic transformations (like with XSLT), much easier.

Re:Advantages? (1)

Kijori (897770) | more than 7 years ago | (#16623004)

You don't have to convert the HTML into XHTML, you're right, that is difficult to do correctly. All you have to do is validate the comments as XHTML and if they don't pass, output them as plain text not HTML.

Re:Advantages? (4, Insightful)

jesuscyborg (903402) | more than 7 years ago | (#16623326)

But that same facet makes it very tough to write by hand. What I mean is that with HTML you've got all your tags [...]
Funny, I always thought the hard part of writing XHTML wasn't actually closing my tags, but figuring out how to separate content and style enough to keep Berners-Lee happy, have it be easy to drop in new and totally different styles down the road, have it actually look good, but still keep my sanity.

Re:Advantages? (1)

Aewyn (836766) | more than 7 years ago | (#16623442)

What I mean is that with HTML you've got all your tags, but many people don't write them correctly. How often do you write a closing P tag? Do you close your IMG tags like you should (<IMG SRC=... />)? Most people don't.

Actually, in HTML, closing tags are optional for P elements, and forbidden for empty elements such as IMG. The empty element shorthand (<img src="..." alt="..." />) should only be used for XHTML.

Writing correct XHTML by hand is no harder than writing correct HTML. As for comments with markup, I wouldn't let them through unchecked regardless of the markup language. Typically only a subset of elements is allowed in comments anyway, so it seems unlikely that it should be that hard to switch to XHTML.

Re:Advantages? (2, Informative)

metalhed77 (250273) | more than 7 years ago | (#16622768)

The advantage of XHTML is that it's easier for machines (and developers) to process and work with after it's written. Additionally it supports emerging useful new standards such as XForms, and other XML processing tools.

The disadvantage of XHTML is that it's harder to write initially and has stricter rules. Most people write broken HTML 4 transitional pages that, quite honestly, work fine for their audience (web only).

Parsing HTML is a bitch, working with it is, quite simply difficult. Additionally XHTML supports embedding other XML formats than XHTML within it, like MathML (an way to display formatted math equations) SVG (XML Vector Graphics) and any other arbitrary XML based format in an easy to understand way via namespacing.

There's a whole suite of tools built around XML (XPath and XSLT for example) that enable one to deal with MathML and SVG as easily as XHTML. It makes things simpler.

XHTML is, however, a lot harder to write. HTML tolerates a lot of errors, XHTML technically tolerates none, though browsers usually overlook this.

For my job, where I have to create sometimes copious amounts of HTML that will be seen only by IE or Firefox on windows or a mac, and often times be deleted within a few months, I just write HTML4 transitional and don't really worry about validating. I test both browsers and leave it at that.

For my personal site, or shit that I have extra time to do I write XHTML because I like to make neat, clean things, but honestly there's never a tangible payoff from it for most applications.

I will say this however, people who know XHTML are the people who know how to really write a web page. The people who've never heard of it are the ones that are a bitch to work with and slow you down with their ugly ass tag soup pages with no CSS.

Advantages $$$ (1)

Original Replica (908688) | more than 7 years ago | (#16623294)

"XHTML is, however, a lot harder to write. HTML tolerates a lot of errors, XHTML technically tolerates none, though browsers usually overlook this.
It sounds like the adoption of XHTML is in the best interest of the professional IT community. As a more arcane and precise skill set, you will get fewer amateurs, easier maintenace, and be able to charge more for your services.

XHTML (1.0) is easy (1)

Animaether (411575) | more than 7 years ago | (#16623370)

For 99% of the websites, all you need to know as 'the difference from HTML' is: http://www.w3schools.com/xhtml/xhtml_html.asp [w3schools.com]

That is for XHTML 1.0, though. XHTML 1.1, and the remaining 1% of websites which go deep into further XHTML functionality are a different matter.

Re:Advantages? (1)

El_Muerte_TDS (592157) | more than 7 years ago | (#16622790)

One of the advantages is that you could use Xslt to convert an XHTML document in something else (like LaTeX, RTF, ...).

Re:Advantages? (1)

Richard W.M. Jones (591125) | more than 7 years ago | (#16622852)

One of the advantages is that you could use XSLT to convert an XHTML document in something else (like LaTeX, RTF, ...).

XSLT is possibly the most horrible language to use for transforming documents. Languages such as CDuce [cduce.org] are years ahead.

Rich.

Re:Advantages? (0)

Anonymous Coward | more than 7 years ago | (#16622830)

Basically, the rules for HTML are loose and internally inconsistent. As such, writing a program to get meaningful information from an HTML webpage is more difficult and more complex, requiring more code and a larger (in disk space) program to do it.

XHTML being more restricted means that the rules are easier to program into a parser, so it can be more lightweight, faster, etc. In addition, since the rules are theoretically simpler, it should be easier for browser writers to maintain standards compliance, unlike the current situation where IE, Firefox, Opera, Safari and the rest all render the same web pages in different ways. The downside being that the people writing the XHTML in the first place have to be more careful about their style or they can run afoul of the language rules.

The problem with XHTML... (1)

VGPowerlord (621254) | more than 7 years ago | (#16622642)

The problem with XHTML is that if your code isn't absolutely perfect, the parser dies with (usually) unhelpful error messages.

This "feature" makes it unsuitable for sites that allow users to add content.

Re:The problem with XHTML... (3, Insightful)

tepples (727027) | more than 7 years ago | (#16622718)

[The requirement that the entire document be well-formed] makes it unsuitable for sites that allow users to add content.

Then make sure that the content added by the user is well-formed before adding it to the site.

Re:The problem with XHTML... (1)

VGPowerlord (621254) | more than 7 years ago | (#16622806)

Then make sure that the content added by the user is well-formed before adding it to the site.

Please, by all means write a forum BBCode parser that outputs valid XHTML that works under the application/xml+html mime-type.

It's easier said than done, as you have to track every open and close tag and rewrite them if the user gets them in the wrong order or omits one.

Re:The problem with XHTML... (1)

tepples (727027) | more than 7 years ago | (#16622822)

Please, by all means write a forum BBCode parser that outputs valid XHTML that works under the application/xml+html mime-type.

In what language do you want bbcode2xhtml? And do you have test cases of what kind of input it should accept?

Re:The problem with XHTML... (2, Interesting)

VGPowerlord (621254) | more than 7 years ago | (#16623058)

First of all, there's a few issues with how BBCode is normally parsed. Most forum systems I've seen automatically convert two line feeds into a <p> tag and a single line feed into a <br> tag. For obvious reasons, this behavior needs to be addressed in the parser.

As for language, I don't really care, but it'd have to be able to sort out things like:

Missing close tags:
[url=http://www.slashdot.org/][b]Cool slashdot article!!![/url]

Out of order properties (the img open and close tags should not be converted to HTML because its input is invalid, but the url's input is valid and should be parsed)
[img][url=http://www.example.tld/]http://www.examp le.tld/image.gif[/url][/img]

Lists (I'll let you figure out how this one should look):
[list=a]
[*][url]http://www.example.tld[/url]
[*][img]http://www.example.tld/image.gif[/img]
[list]
[*]Coffee

Out of order close tags (close tags should be reordered properly):
[url=http://www.example.tld/faq/momal.shtml#Mu-Blu e-7][b][color=blue]&#956;-(b)-7[/b][/url][/color]

I had more examples, but the power just flashed out here a moment ago, and I lost them.

Re:The problem with XHTML... (2, Insightful)

vidarh (309115) | more than 7 years ago | (#16622854)

It's a lot easier than you think to support the kind of feature sets most forums supports. I've written parsers to do more or less that (but accepting actual HTML tags) in both C++ and PHP, and it's quite straightforward. A very basic tag parser plus a stack of open tags and a lookup table to determine when to automatically close tags (to prevent tags that shouldn't enclose content, like "img" from enclosing anything following it at the same level, is really all you need. A few hundred lines at most in a reasonably high level language.

I've done parsers that "scrub" HTML for constructs that might cause security risks or mess up the site layout too, that had to accept almost all "sane" html, and even that isn't particularly hard, though quite a bit more work.

Re:The problem with XHTML... (1)

Richard W.M. Jones (591125) | more than 7 years ago | (#16622902)

Please, by all means write a forum BBCode parser that outputs valid XHTML that works under the application/xml+html mime-type.

The wiki I wrote [merjis.com] does something analogous to that. (Not BBcode, but MediaWiki-ish markup which is similar). It's not really so hard for a competent programmer.

Rich.

Re:The problem with XHTML... (1)

N3Roaster (888781) | more than 7 years ago | (#16622978)

Most things that are easier said than done, but the problem you describe is old and very well understood. Such a parser could easily be an assignment in a beginner programming class.

bbcode is an insignificant greasy little hack! (0)

Anonymous Coward | more than 7 years ago | (#16623008)

You want a library to validate the XML and validating XML parsers are common as muck. Easy to check tags and attribs too.

Re:The problem with XHTML... (0)

Anonymous Coward | more than 7 years ago | (#16622724)

No, it makes it unsuitable for sites that don't validate user submitted content. Something that you should be doing anyway.

Re:The problem with XHTML... (1)

MrDrBob (851356) | more than 7 years ago | (#16622736)

I would argue that it means such sites have to be more careful with what they allow users to submit. I think this is probably a good thing, as it means that there would be fewer occasions where users could place XSS attack code on sites.

Re:The problem with XHTML... (0)

Anonymous Coward | more than 7 years ago | (#16623146)

Apparently you're still living in an ideal world. Firefox, IE, and other browsers are more than happy to render improperly-coded XHTML.

I don't get this at all (1)

melonman (608440) | more than 7 years ago | (#16622644)

Why are webmasters who are currently ignoring XHTML going to be any more interested in Yet Another Dialect of HTML? At least XHTML has some advantages (like being a well-defined standard, being well-formed XML, and therefore being able to use it with XML technologies such as XSLT). It's not as if W3C provides the tools used by the non-conforming webmaster or anything. As long as there are significant numbers of sites that use bad HTML, and tools that produce more bad HTML, browsers will continue to parse bad HTML, and the pressure for people who don't care about standards to follow standards will remain slight. Come to think of it, even XSLT provides "un-XMLing" features when in HTML mode. If W3C announced a deal with Microsoft and Adobe to phase out bad HTML "features" from their website creation tools, there might be a chance of changing something...

Re:I don't get this at all (1)

MrDrBob (851356) | more than 7 years ago | (#16622770)

Why are webmasters who are currently ignoring XHTML going to be any more interested in Yet Another Dialect of HTML?

I suppose because it would be easier for them to upgrade their sites, as it was easy to upgrade from HTML 3 to HTML 4.

If W3C announced a deal with Microsoft and Adobe to phase out bad HTML "features" from their website creation tools, there might be a chance of changing something...

That would be good, but I think Microsoft's new Expressions suite is actually quite good (all valid, as far as I've heard), and Dreamweaver gets better every time I use it, although I don't think either of them are perfect.

Coalition of the Working (1)

Doc Ruby (173196) | more than 7 years ago | (#16622832)

The W3C should release updated "HTML" specs only with both reference code for parsing, any state-setting, and any rendering, and validator with UI to test HTML for compliance.

UA makers should be able to submit to the W3C new proposed specs with both reference code and validator.

HTML versions should be date/timestamped, and validated between UA and server.

That kind of open, but moderated and encapsulated process will help ensure new specs are not only workable, but distributed to all UA makers (and programmers targeting them) uniformly. UA makers can produce their own code, as long as their HTML validates and the state/rendering results are consistent with the reference results.

A faster, more open, more comprehensive process. More uniform upgrades, more compliant/working websites, less programmers targeting specific browsers "because they work".

HTML vs XHTML (2, Insightful)

cgenman (325138) | more than 7 years ago | (#16622884)

HTML at the moment is solid, robust, and gets the job done. As it has evolved it has gained additional features and power at each step, including CSS integration, better javascripting, DHTML, etc, thus leading at every step to a better end-user experience.

XHTML for all practical purposes, is HTML but with more errors. With XHTML, you get the power of being told that you have to put an end tag on all
  tags. And, umm, not a lot else. The benefits of switching to XHTML are mostly theoretical.

The W3C needs to break the focus on validation, and get back to trying to work with developers and users to get what THEY want into specifications. It sounds like they realized that XHTML will not overtake HTML any time soon, and that they need to provide some sort of reason or reasons to make that change.

Re:HTML vs XHTML (0)

Anonymous Coward | more than 7 years ago | (#16623016)

XHTML is stricter (hence the "more errors") because it is also well-formed XML. Therefore the same parser used for parsing XML is used to parse XHTML, which makes things a lot easier for developers. It also means XHTML can be treated as though it were XML, allowing one to, for example, translate it using XSL.

This contrasts with the HTML parser, which is different for every browser and has to account for all kinds of peculiar mistakes, hacks, and quirks. This has been somewhat remedied by forcing the parser to operate in one of a handful of standards-compliant modes (HTML 4.01, for example), but you still end up needing a separate HTML parser and lose the benefits of dealing with a well-formed XML document.

Re:HTML vs XHTML (1)

TheRaven64 (641858) | more than 7 years ago | (#16623064)

The benefits of switching to XHTML are mostly theoretical.

I found the benefit of being able to easily embed MathML into my XHTML documents to be quite practical. MathML is a pain to write, but fortunately there are good LaTeX to MathML translators around.

Re:HTML vs XHTML (1)

Shados (741919) | more than 7 years ago | (#16623434)

Yeah, that is my issue with the W3C. They honestly live in a world of unicorn and little pink imps.
Too busy seeing XHTML/CSS has the -core- of everything and anything, they forget that we're not 10 years ago, and that developers actualy could care less about the theorical integrity of their apps, they just want it to work, and be maintainable. And sorry, needing 15 divs wrapped around a single element to get it positioned the way I want it to does NOT make it easier to maintain. Having a formatting spec that is almost impossible to implement in a wysiwyg editor does NOT add value to my app (since I have to hire more qualified people to do seemingly simple things). The good part about XHTML is how it makes for some cleaner code (case sensitive, closing tags, etc). The rest can honestly go to hell. For a lot of us, the presentation layer is only 1 layer out of 10+ in our apps. We don't feel like spending 50% of our time on it.

becasue we dont care (3, Insightful)

grapeape (137008) | more than 7 years ago | (#16622896)

HTML has been and continues to be "Good Enough". If there were some truly compelling reason to upgrade to something else most already would have. When image tags were introduced, people abandoned lynx rather quickly, the same goes for transparent gif support, CSS, etc. Its nice to try to bring order or whatever the goal of xhtml is but frankly if its got the ability to slap some text on page, embed and image and throw in a pretty background its good enough for most people, they know it, they are comfortable with it and they arent going to change without a really compelling reason.

Evolved? (1)

solevita (967690) | more than 7 years ago | (#16622928)

Not in the mid-west; God designed their HTML.

MS (1)

Skiron (735617) | more than 7 years ago | (#16622932)

I am sure Microsoft have their own view on this, so bollocks to standards.

evolution of languages has to be gentle (1, Interesting)

e**(i pi)-1 (462311) | more than 7 years ago | (#16622940)

Any change of language is risky. They often go bad because language architects are not the same people than developers, the writers, the authors or the educators who actually create stuff with it. Whether for programming languages, web languages or spoken languages: developers, authors, educators, readers and users suffer, if things go too fast.
  • programming language writers love the process of creating something so much that they don't care about the consequences. Example: Pascal. It was a wonderful language. It worked well. It was easy to use also with low level stuff. Wirth developed Modula, then Oberon. These were so radical changes that Pascal was killed.
  • Small changes can be devastating. Example: why does XHTML backslashes in hr or br tags. These are completely unnecessary requirements. XHML did not take off because who would want to wade through thousands of pages in HTML written during the last decade and make those changes?
  • Too hasty evolution can be a disaster: Example: I'm convinced that it was the accelerated evolution of Java which essentially killed it as a valuable tool for the web. What language architects often are note aware of are the existing resources, books, libraries. In the case of Java, applets written only a few years ago suddenly would no more compile because of depreciated language. Suppose a educator created a Java applet 8 years ago. She has long moved on to other projects. The language changes. The tool is lost. We can see that in many examples, where Java applets work different on different browsers and operating systems. In the case of Java for the web, Flash has taken over. Now Adobe might make the same error again, and evolve it too fast. Sorry: a flash 13 plugin needed.
  • The German language reform is an other example of intellectual arrogance. It produced a lot of controversy [raecht-schreibung.de] . Language architects have to take into account the huge library of existing books, textbooks etc, which become obsolete or awkward after a change of language.
Evolution of languages is nothing bad. But it has to happen so gently that one can adapt and in such a way that old things are still readable and that porting of most existing material to the new level can be realized in time.

HTML 4.01 is good enough (1)

Espectr0 (577637) | more than 7 years ago | (#16623026)

I use HTML 4.01 Transitional in my pages. Why? I am the only developer, so i develop my pages semantically and leave the layout to CSS.

So why not use strict? It is illegal in strict to have a target attribute in anchors, for example. No iframes (if used wisely, they can be intuitive)

XHTML doesn't give me enough reasons to migrate, although i did use it for my old thesis project.

Mod parent up --- lack of iframe blocks Strict use (3, Informative)

Denyer (717613) | more than 7 years ago | (#16623368)

Without iframes (currently supported by IE, Firefox and Opera, at least) 4.01 Strict isn't workable for most sites that rely on third-party content for advertising -- eg, ads from Amazon. And that's a large chunk of the web.

Wrong way around (1)

SillyNickName4me (760022) | more than 7 years ago | (#16623070)

People use HTML (not always in the way it is supposed to be used of course..), and people generally don't use xhtml

There are 2 ways to deal with this if this isn't what you want..

1. Make HTML even more crappy and hope people stop using it (they will, in favor of the older less crappy version of course)
2. Make using XHTML easier and more attractive.

I don't see how you accomplish 2. by changing HTML

Erm... (1)

DarthChris (960471) | more than 7 years ago | (#16623088)

This may seem like a stupid question, but how else did we go from HTML 1.0 to 4.01 without the standard being 'incrementally evolved'?

Think before choosing XHTML ... (2, Informative)

boywanders (1019526) | more than 7 years ago | (#16623106)

One of the best texts I've read on this subject can be found here... http://www.hixie.ch/advocacy/xhtml [hixie.ch]

Hixie needs to revise that document (0)

Anonymous Coward | more than 7 years ago | (#16623390)

Try reading the recc [w3.org] or RFC 3236 [ietf.org] sometime. There's no problem serving XHTML to clients advertising the appropriate MIME string via accept. It's treated as XML otherwise it's served as text/html and treated as HTML.

That's the way XHTML was designed, the only problem here exists within Hixies head.

Very Simple (4, Insightful)

Fnkmaster (89084) | more than 7 years ago | (#16623220)

Develop a few *actual* applications where the XML-compliance of XHTML is actually useful in an observable way, and everybody will start producing XHTML compliant code for new websites, lest they be left out from a new revolution on the web.

As long as the benefits are just hypothetical (with XHTML somebody could develop useful parsing applications based on commodity XML parsers), try actually developing some such apps that generate real, observable value today, and you'll start convincing people who don't care about standards for their own sake.

I do generally try to stick to XHTML 1.0, since I care about standards and ease of parsing, but the majority of people don't, and they are the target audience the W3C needs to work on convincing.

Improvements to the validator sound good (1)

rduke15 (721841) | more than 7 years ago | (#16623288)

I'm looking forward to improvements to the validators. Especially a better differentiation between different types of errors.

When troubleshooting old web pages, it is quite annoying to have to wade through hundreds of 'required attribute "ALT" not specified.' or 'there is no attribute "HEIGHT".' to find the real cause of problems, like 'document type does not allow element "TABLE" here; missing one of "TH", "TD" start-tag.'.

Also, when trying to explain to clients why their old web site is crap and needs to be redesigned before it becomes practical to do small changes, a link to the validator page could be useful. We could say something like "see, it is full of bugs; we need to repair the chassis before we can start the paint job". But for that, I would rather show a link to a page with 10 bad structural errors, than to a page with 200 'required attribute "ALT" not specified.' which will not be taken seriously.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?