W3C Considering An HTML 5 414
An anonymous reader writes "When the decision was initially made to move in the direction of XHTML, instead of a new version of HTML proper, it seemed like a good idea. Years later and the widespread adoption of CSS (among other things) has proven that things don't always develop the way we expect. As a result, HTML 5 has been revived by the W3C. After some lobbying and continued work by the Web Hypertext Application Technology Working Group, the old web markup language is getting an official face-lift. A post to the Webforefront blog explains the history behind the initial decision to move to XHTML, and why things are so different in the here and now."
hmm. (Score:4, Interesting)
or will some browsers go their own way with "extensions" and "implementations" specific to their own system like last time.
Re:Absolutely right (Score:5, Interesting)
Re:Absolutely right (Score:3, Interesting)
- It's made of many people, period. Some of them do not work for any tech firms.
- If the primary (or even subsidiary) interest in updating standards was to sell more copies of Dreamweaver and other similar products, then why would there be free updates to Dreamweaver extensions to reflect standards changes? Also, the majority of the industry is not coding in Dreamweaver, so there's no chokehold on the business here.
- Sorry, no point-and-click HTML generator makes "perfectly good HTML". Many do a decent job, but it will never be as efficient as straight code and thorough knowledge of the standards.
In closing, if the W3C's purpose was to bolster commercial software sales, they sure are going about it in the most ineffective way possible.Re:The Author is Not Completely Wrong (Score:3, Interesting)
Intersting! That makes me a bit more hopeful for the standard. The whole idea is to move towards the "semantic web": say what you want, and render it in the most accessible ways possible. More and more sites and services are being presented in both a standard and mobile format, as well as several handicapped-accessible formats. More choices is a good thing.
What I'm not seeing (perhaps because I haven't read the standard yet, or thought it through enough) is what HTML brings to the table that XHTML can't. Why bother with allowing the HTML mimetype, if it has no advantages other than it's what was done in the past?
As a standard, HTML4 has failed (Score:4, Interesting)
Also look how hard and painful it is to implement a 3 column liquid layout with just HTML and CSS. Compare this to XUL's grid, vbox and hbox (yes, I know there are now CSS selectors in Firefox, Opera and Safari to do that)
Fact is, HTML is based on a page/document model, whereas, nowadays, HTML "pages" are most of the time "screens", part of an application. The idea to separate content and layout is nice, but the thing is, most content in pure-ist HTML+CSS is basically a bunch of div's and span's. It isn't much semantically richer than tablesoup.
IMHO, if I were to redesign HTML today, it would look a lot like Xul, with XBL2 and microformats on top.
Client side include please! (Score:4, Interesting)
Server side includes are very nice, except that they require a server!
Client side includes have the potential to be much nicer! Two quick reasons: the first is when (X)HTML is used on (for example) CDs or similar, there isn't a server, and trying to make each page the same either requires fucking around with templates and software, or else using forms...; the second is it would work the same was as having external CSS, saves on download time, allows parts of the page to be downloaded only once and so on. (This second point would also make it really easy to offer different versions of the same page, include header and footer, and don't for example.)
I know that JavaScript client side includes exist. They, however, are a kludge. They need JavaScript for one!, they might not work on all browsers, they might not be standard and so on. No thanks.
A simple client side include that worked on the client side the same way the PHP include does, and I'll be happy.
Re:Absolutely right (Score:3, Interesting)
Re:Absolutely right (Score:5, Interesting)
Actually, it was originally from Apple Safari. Apple invented it for their desktop widget thingys. Opera and Mozilla have both embraced it with open arms.
I agree. I absolutely love this feature! Unfortunately, it's only implemented by Firefox at the moment. I was hoping that it would show up in Safari 3.0 so that richer iPhone applications could be written, but it was not to be. The feature request [webkit.org] is still sitting out there with no assigned implementer. I'm tempted to dive into Webkit and maybe see if I can add it.
date tag? (Score:5, Interesting)
There are so many things that could be included in the html language if it weren't for the purists - dates, columns, real collapsable tree controls, counters, AJAXified controls that work without all the crap you have to do today to detect browsers... but no, the purists say "you can do it in this (incredible convoluted) css" or "you can implement this in javascript" (cue long convoluted "obvious" solution).
Geeks are notorious for generalising and making everything nice and orthogonal, but they often forget that sometimes it's worth having something that makes life easier 90% of the time, even if it's technically possible to reduce it to a set of other constructs that already exist.
Remember lisp, nobody uses it for real-world programming even though it's incredibly powerful. No, we use other languages that have lots of useless and redundant and inflexible syntax that makes the act of everyday programming easier and more straightforward most of the time. Are these inferior languages as powerful, expressive and all-encompassing as lisp? No. Are they easier for 99% of mere mortals to comprehend and use? Yes. If we had tags for controls that reflected the more dynamic nature of the Web today, even if many of those tags could be implemented in javascript, it would make pages smaller and faster 90% of the time (you could still implement it yourself if you really needed additional functionality).
But, as usual, the purists are in control. We're not supposed to use tables for arranging pages; no, we have to use CSS to do that. So now we have a bunch of pages that don't render properly. But do they admit that it was a bad idea? No, it's the browsers' faults for crappy implementations. I don't get it, this religious mindset that says "You must do it one way, our way is the only way". "The TABLE tag is for tabular data only, don't use it for arranging the page". What crap. The table tag is amazingly useful, it works in all browsers, and no I don't mind in the least typing TR and TD everywhere. It's simple and it works. Yes, it's more verbose perhaps than the CSS version but at least it works in all browsers and doesn't end up with overlapping crappy text all over the place.
Re:Absolutely right (Score:3, Interesting)
It's written "WHATWG" by the way, for the same reason you don't write UspTo. But that's not important.
WHATWG are the group that pitched W3C to consider HTML5. W3C's HTML5 isn't based on anything right now since it doesn't exist yet. It may include in some form some HTML5 features, but don't delude yourself that W3C will beat the heck out of it, until it's a tortured mix of their XHTML2 standard and WHATWG's HTML5.
Re:Client side include please! (Score:3, Interesting)
Re:Absolutely right (Score:5, Interesting)
Re:date tag? (Score:4, Interesting)
Unless your reader is blind or visually impaired, and using a screen reader, in which case your page will blow up spectacularly. Or if they try to access your page via a mobile phone browser. Etc., etc.
Attention all web developers: please read this [diveintoac...bility.org] and think about how broad the range of web users truly is.
(Oh, and if you don't give a flying fark about blind people or phones -- moving your style instructions from the HTML into CSS files will cut down on the total volume of info your users have to download by an order of magnitude, reducing your bandwidth costs.)
Adoption more important than technology (Score:3, Interesting)
It has failed to deliver adoption. We can argue about why (IE's lack of support, no compelling features), but the fact remains that a standard is worthless unless it actually becomes, you know, standard. Standardization is less a technical matter than a social one. Most of HTML's value derives not from its technical strengths, but from its ubiquity.
To date, the new way of distributing content that you cite has not succeeded. XML was advertised as a solution to interoperability, but in reality it solved the easy problems - e.g. syntax, not the hard ones - e.g. agreement about meaning. XHTML's ambition to mix multiple XML vocabularies in a single document is worthy (and in the longer term worth pursuing), but the subset of vocabularies that would be widespread enough to matter would be small.
What HTML 5 offers, and what XHTML did not deliver, is further agreement about meaning. It provides standard ways to do what people are already doing. For example, it specifies unambiguous ways to mark up navigation menus and time. These are small things, but small things matter. Look at HTML's declarative links - also a small thing: they have made possible applications like Google (imagine if links were all scripted instead!).
Meanwhile, HTML 5 can be serialized as XML. Why not simply make it XHTML 5? Again, we can argue about the relative benefits, but the best answer is that it would be a barrier to adoption - and thus to the central benefit of standardization.
Despite all of this, I certainly wouldn't call XHTML a failure. If you consider it outside the browser it is very useful (for server processing, embedding in Atom, etc.). In the medium to long term, it seems likely to gain in popularity. At this point, though, it is clear that non-XML HTML serialization is not going to go away. I think there are good (social) reasons for that; regardless, making that HTML better is a good thing.
Instead of HTML 5, we need XHTML design process v2 (Score:2, Interesting)
I've already gained immense advantages by using XHTML in my apps,
and I see it XHTML+CSS combo is much better supported than HTML+CSS.
The only problem is with XHTML design process, that is painfully slow,
with unnecessary emphasis on 'modularity'.
Just give me a concise specs of XHTML 2.0, CSS 3.0 so that they'll include
editing. But to do this, W3C would have say bluntly that the problem with XHTML
was with the process and people, not with the technical side. (The same happened
with never-completed CSS 3.0 and rarely-fully-implemented XForms.)
Re:Absolutely right (Score:4, Interesting)
Unfortunately there seems to be a lot of crazyness in there too. XHTML 1.1 went some way towards reducing the redundency of some tags. For example, the object tag replaces embed, iframe, etc with a single unified tag to handle all embedded objects (not sure why they didn't ditch img at the same time.
HTML 5, on the other hand, seems to be keeping object but also reviving iframe and embed. Meanwhile they are introducing a load of tags to do the same job - video, audio, etc. This is crazyness since it means you have to revise the markup language every time someone invents a new type of embedded object, whereas just using a single object tag for everything means your browser can determine the type of content from the MIME content type of the object and render it if supported.
I would prefer to see new features going into XHTML rather than HTML. However, XHTML does need a modification IMHO: the spec states that XHTML which isn't well formed must not be rendered - I think it would be better to require the browser display a page saying something along the lines of "this page is broken, click this button to try and fix it - it may not render correctly". Forcing web developers into writing well formed code is a Good Thing, but the end user needs a way of trying to render the page anyway if the developer did muppet it up.
The trick to making bad web developers write good code is to make sure the people who are paying them know that they are bad developers - presenting a page stating that fact is a good way to do that.
I don't believe the spec can (or should) define how to handle broken code in the specific sense - defining the handling for every corner case is impossible and would make the spec far too complex. Much better to just say "you present an error, give the user the option to fix it and then fix it up as best you can (how to do this is outside the scope of the spec)".
Re:Absolutely right (Score:3, Interesting)
Or "Browser makers ignore standard; make own" (Score:3, Interesting)
One of the goals was to make sure that all the players had a voice, not just the browser vendors.
Well, everybody got together and decided to design something that had clear semantics, well-defined behavior, and was modular. CSS came out of this, and XHTML came out of this. Netscape didn't like CSS, so Microsoft did. Then Netscape capitulated on CSS, then it folded.
Then nothing happened. For a long, long time. (You may recall this period.)
Opera was founded by Hakon Lie Waum, and it found a great niche market in embedded browsers, but getting there required it to be "IE5 bug compatible," at a tremendous engineering effort.
Then a bunch of other companies came along and started making browsers and tools and middleware and all sorts of stuff that implemented the plethora of W3C modules, and started to target enterprise customers and mobile phone vendors with products implementing XHTML Basic (which replaced WAP/WML in short order), SVG (which made Flash be stillborn in the phone market), XForms (which appeals mostly now to vendors who can control the middleware, but gives them the AJAX advantage without browser dependence). It became clear to the now old-guard browser vendors that if they didn't do something to enshrine "IE5 bug compatibility" in HTML, it was going to be subsumed by new, easier to implement standards, probably starting from the cell phone and enterprise markets, but pushing out into full consumer/open web markets from there.
So, they created a crisis by starting their own parallel standards group and threatening W3C. The keep this threat up, and use the same kind of populist appeal and divisiveness we see in US politics to stir up hatred and polarization, all the while keeping the parallel work on the forefront.
All I can say at this point is that you should be prepared for JavaScript to become the language of expression on the web, with markup languages being reduced to a graphics library for scribbling on screens.