Slashdot Mirror
HTML to be 'Incrementally Evolved'
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."
You know, that's a good idea
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.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
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.
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.
// TODO: Insert Cool Sig
tag and a single line feed into a
p le.tld/image.gif[/url][/img]
u e-7][b][color=blue]μ-(b)-7[/b][/url][/color]
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.exam
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-Bl
I had more examples, but the power just flashed out here a moment ago, and I lost them.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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.
Tarsnap: Online backups for the truly paranoid
The W3C position is that Google, for example, should not be required to enjoy or research the web. Their view is that the web pages themselves should provide the context and relevency information that Google is doing. They want discrete, well formated information that's reletively unchanging. Another example is Wikipedia. The current version is a data base app with a webpage front end. The W3C would perfer to see the site as discrete pages so every page is a complete indexable document just like a book. Tim especially is much like RMS in his views that information should be "free", and freely accessbble.. the user should figure out how THEY want it, not be told.
The current trend of web apps as database front ends is what corperate customers and server vendors want because it provides more control.. more than that the actual inforation is locked up so you have to have "permission" to view it. Many of the W3C specs are kind of designed to sabotage that approach which only complicates matters. They need to get closer to web app designers versus acedemic content providers.