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.
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.
- 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.
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.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
Why? At this point in time, name one tangible benefit XHTML offers that well-formed HTML doesn't for "everyone".
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.
XHTML is mostly HTML formulated as an XML document. Combined with CSS, HTML relies no more on embedded presentation than XHTML with CSS.
The problem with XHTML is that it came at a time when computer scientists had taken the wheel from the programmers. Just take a look at the specification of XHTML and try to remember how you learned HTML. If the web had started with an HTML specification that looked like the XHTML specification, then I don't know what we would be using today, but I know what we wouldn't be using: HTML.