Slashdot Log In
W3C Considering An HTML 5
Posted by
Zonk
on Fri Jul 20, 2007 07:36 AM
from the party-like-its-1999 dept.
from the party-like-its-1999 dept.
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."
Related Stories
[+]
W3C Publishes First Public Working Draft of HTML 5 310 comments
Lachlan Hunt writes "Today W3C announced that the HTML Working Group has published the first public working draft of HTML 5 — A vocabulary and associated APIs for HTML and XHTML. It's been over 9 months since the working group began in March 2007 and this long awaited milestone has finally been achieved. '"HTML is of course a very important standard," said Tim Berners-Lee, author of the first version of HTML and W3C Director. "I am glad to see that the community of developers, including browser vendors, is working together to create the best possible path for the Web..." Some of the most interesting new features for authors are APIs for drawing two-dimensional graphics, embedding and controlling audio and video content, maintaining persistent client-side data storage, and for enabling users to edit documents and parts of documents interactively.' An updated draft of HTML 5 differences from HTML 4 has also been published to help guide you through the changes."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Absolutely right (Score:5, Insightful)
Or are the W3C just trying to justify their existence?
Re:Absolutely right (Score:5, Funny)
Parent
Re:Absolutely right (Score:5, Funny)
Parent
Re:Absolutely right (Score:4, Insightful)
That shall be coding to a standard defined by a vendor infested committee where each representative has been obsessed to ensure that all of their bugs are standardised as "this is not a bug, it is a feature".
As a result the implementations will remain as quirky as they are now. At best. At worst...
Parent
Re:Absolutely right (Score:5, Insightful)
It's actually incredibly sensible, and is a very practical and natural extension of what we're doing with HTML now.
It has very little to do with browser bugs, or even web sites per-se. It's more about adding features to more naturally support web 'apps'.
Read up on it, it actually makes a lot of sense.
I just hope it can make some progress, but given that it was started by Mozilla, Apple and Opera, the people making the best browsers out there, it may actually have a chance of being supported.
Parent
Re:Absolutely right (Score:4, Funny)
The result is that browsers will show you the finger if you don't code to the standard.
Parent
Re:Absolutely right (Score:5, Informative)
That is incorrect: the HTML5 parsing algorithm [whatwg.org] never just stops and returns an error message (like in XML) - it specifies how every single stream of bytes is parsed into a DOM, with error-correction where necessary, in a way that tries hard to be compatible with the ~10^11 existing HTML pages on the web (which, in most cases, means being compatible with the behaviour of IE6).
Almost all the content on the web today is invalid HTML, and it's never going to go away, which is why the browser developers have been pushing for a specification that describes how to handle invalid content instead of pretending it's not important.
Parent
Re:Absolutely right (Score:5, Informative)
I'm a participant in the HTML Working Group [w3.org] and I can tell you that this is incorrect. You're thinking of XHTML2, not HTML 5. XHTML2 has the XML parser strictness and pages will fail to display if they're not well-formed. HTML 5 is going the complete opposite direction, assuming that people will code poorly and defining failure modes for browser vendors to follow when that happens.
Parent
Re:Absolutely right (Score:5, Insightful)
I would plead for a higher standard that would require strict compliance to well-formed rules that would lead to better overall web governance, security, and standards that benefit the authors and readers. I'm really fed up with not being able to use my favorite browser for everything because the code is broken on one browser brand or version, or because one browser vendor simply wants to make their own rules.
Let's do this generation of standards right. Make the coders comply with strict, well-formed rules or make them pay the price.
Parent
Re:Absolutely right (Score:5, Informative)
The working group is open to the public [hixie.ch] and costs nothing to join. If you don't like the state of HTML, come over and help make it better.
Parent
Re:Absolutely right (Score:4, Insightful)
And therefore copy and paste doesn't work. This kind of crap is exactly why I hate the web!
Parent
Re:Absolutely right (Score:5, Insightful)
Imagine if web browsers were anal retentive and refused to display anything with the slightest syntax error. Imagine if your blog suddenly became undisplayable because commenter number 32 input some broken HTML, and your not-quite-perfect blog software didn't quite know how to launder it. Imagine that the slightest syntax error from Google Analytics, Google AdWords, or anything else you embed into your site could make your site completely unavailable.
I know it's not satisfying, but being permissive on the web really is the best policy, as long as the results of the permissiveness are well-defined (which is what HTML5 does).
Parent
Re:Absolutely right (Score:5, Interesting)
Parent
Re:Absolutely right (Score:5, Insightful)
More likely, the developer will stop using technology that makes their life harder, and will stick with invalid HTML4 and Flash and Silverlight and all the other possibilities, which defeats the aim of improving interoperability on the web.
Also, browsers have bugs. What happens when a user tests in one browser which accidentally accepts their invalid code, without noticing that other browsers don't? (Possible answer: other browsers will have to start accepting that invalid code too, else their users will stop using that browser and start using the one that can actually display the web. And since the specification would only say how to handle valid code, the other browsers will have to reverse-engineer each other to get mostly-compatible behaviour for invalid code, which results in a mess of incompatibilities - that is what has happened for HTML4, and is what HTML5 is trying to fix by defining how all invalid content must be handled in a way that is sufficiently compatible with the existing behaviour (and existing bugs) of browsers.)
Also, most content is generated dynamically, so you can't simply test the page before you upload it. Server-side code has bugs, and draconian error handling does not make things easy to fix [diveintomark.org].
Parent
Re:Absolutely right (Score:4, Insightful)
Oh, wait. They don't.
Parent
Re:Absolutely right (Score:5, Interesting)
Parent
Re:Absolutely right (Score:5, Insightful)
Excuse me, but it must be pointed out.
When you start talking standards and you gather a group of browser/client makers to discuss new standards, you really do need to have the giant on the block represented. Otherwise, you get a set of standards that run the real possibility of being ignored, or worse, supplanted by the giant's idea.
When the combined numbers of the "others" don't even come close to trumping the giant's numbers, you are heading to failure. In this case MS, like it or not, is the giant. The easiest way to stop this crazy, "IE only partially implements html x.0/css x.1/xhtml x.x" crap is to involve them.
Of course, this is just crazy talk, right. Oh heavens, we might actually run into the problem of MS taking over the standard. You know what, when you have a formation marching down the street, and 70% are on one heel beat, and the other 30% are out of step with the 70% and aren't even in step with themselves, its the 30% that need to get with the beat.
Failure to accept this is only going to widen the gulf, unless MS, through largesse or coincidence follows the new standard.
Parent
Re:Absolutely right (Score:5, Informative)
That being said, Chris Wilson (at least) talks the talk, and IE 7 was a (small) step in the right direction.
The more important, and encouraging, signal imo is MS hiring Standardista Molly Holzschlag. Given her history, I think we can expect more and better from MS on this front in the future.
Parent
Re:Absolutely right (Score:4, Informative)
Parent
Re: (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:Absolutely right (Score:5, Informative)
Well seeing as it's starting from their work I rather suspect it will include the bulk of it, because it's highly interdependent.
Then again you seem to have an axe to grind with the W3c, so don't let me stop you..
Parent
Re:Absolutely right (Score:5, Informative)
Don't believe me? Here are the two standards. Compare:
WHATWG HTML5 [whatwg.org]
W3C HTML5 [w3.org]
Save for some slight divergences as the WHATWG's standard is updated, they're exactly the same.
Parent
Re:Absolutely right (Score:5, Informative)
That's a bit cynical, don't you think?
HTML5 is the result of the hard work done by the Web Hypertext Application Technology Working Group [whatwg.org] (WHATWG). The WHATWG is composed of members from all browser makers, with the occasional public comment thrown in for good measure. As a result, the group has been removing or reducing the ambiguity about implementing the various standards (especially the parser!) and have added features that bring HTML up to a true application platform. Their work is represented in web browsers every time someone uses the Canvas tag, Audio object, Storage API, and other modern features.
The WHATWG was formed because the W3C was seen as too slow to execute such new technologies. Now that the WHATWG specs are stablizing, the W3C has taken a dump of the WHATWG HTML 5 standard and proposed it for ratification under W3C bylaws. This has several advantages over the WHATWG standardization, not the least of which is extracting patent waivers from companies like Apple who technically "own" some of the technologies behind the WHATWG standards.
Note that the HTML5 group at the W3C is a bit different from most. In an attempt to remain as open as the WHATWG, they are accepting just about anyone as an "invited expert" to provide input and comments on the standards process. This is a huge departure from the way that most W3C standards are handled, and is probably a good choice for a standard as comprehensive and complex as HTML5.
Parent
Re: (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.
Parent
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)".
Parent
Re: (Score:3, Interesting)
Re: (Score:3, Funny)
I dunno, I sure have bought a lot of copies of Notepad in the last ten years!
Re:Absolutely right (Score:4, Insightful)
The "rules" are stupid. Do you know how hard it is to make a 3-column or 4-column content site using CSS 1.0? Is it even possible? Yet I can "break" the rules, use table cells as layout, and accomplish the same thing in seconds.
Web developers would use the standards if the standards reflected the reality of their job and *made it easier*. In the same way software developers use APIs because the APIs *make their job easier*. (You don't have to worry about what monitor a window is on, you just call 'RefreshWindow' or whatever and it happens. CSS *should* have had a "style='3 column'" from the start.)
Parent
Regress is the New Standard for Progress (Score:5, Insightful)
Don't you need power to be hardline? (Score:4, Insightful)
Second, I wonder about this "hardline" approach. Who made the W3C gods of the internet? I mean, things need to be standardized, but they refused to do their job and standardize, and guess what, the industry got together and made another standardization board which was mentioned in the OP. The W3C can't hardline anything... they just format the direction we're going... they don't choose it, the industry does that.
Go ahead, think I'm wrong, think the W3C should just stick it to all those web developers and browser companies that have spent years working around the group that is supposed to make their lives easier. The W3C is a paper tiger... they are completely at the mercy of everyone else. They can't hardline anything, much less something which was being standardized without them anyway.
Parent
Re:Regress is the New Standard for Progress (Score:4, Insightful)
Why would anyone in their right mind spend time updating from HTML 4 to XHTML 1.1 when there is no visible benefit and a LOT of pain.
HTML 5 FINALLY introduces features that web developers NEED. Things like native client side validation, canvas and menu elements. These are things that we have been crying out for years but W3C disappeared up their own self-validating a**es. If they had introduced these features into XHTML then I am sure it would have been adopted by browsers and developers alike.
The lack of support from a certain vendor would not have mattered because they would have been pressurized into supporting the standard by the >10% share of browsers that would support it.
P.S. Posting in good 'ol plain text
Parent
Re: (Score:3, Insightful)
Even with client side validation you would still have to validate it server side anyway unless you are a crap developer.
I would rather have xhtml then go back to the mess that html was with its styling embedding directly into the tags and I know that if its allowed its going to happen. Some day I am going to get the tag soup code
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: (Score:3, Funny)
are they going to enforce all the current browsers to support it fully and correctly as well? or will some browsers go their own way with "extensions" and "implementations" specific to their own system like every time.
Fixed.
No, the W3C has no authority or ability to enforce it. Browsers will do what they do. Hopefully, what they do is at least in the general neighborhood of the standards. Rules were made to be broken, and Web Standards were made to be bastardized by incompatible browsers.
Cry for relevency (Score:3, Insightful)
They can't let HTML die. The W3C would become irrelevant quickly if they stopped tweaking the language. Finally, even nomral users and web surfers have started to use HTML in web forums and MySpace (to usually garish effect, but still. XHTML just doesn't have the portability and ease of use that HTML did for things like forums.
Take Fark for instance. After years and years, a critical mass of people are finally learning a, b, u, i, big, super, img, and other standard tags, most of which just don't work the same or at all under XHTML.
Sadly, many useful old tags probably won't work in HTML 5, or not in any useful fashion. The W3C will most certainly mess with the language to bring it in line with XHTML conventions. They've already taken target="_blank" from us, what other useful gizmos are they going to futz with this time, bookmarks? You can pry my octothorpe from my cold, carpel-tunnel hands.
Sure, CSS is damn useful and nobody generally liked frames. However, everything else about HTML was fine circa 1995. Maybe I'm being an old codger who still writes HTML pages without fancy crap like Frontpage, but I'm getting tired of their self-important crap. Breaking useful conventions just makes trying to communicate on the web that much harder. But, every time I tag font or add target="_blank", I do think about the W3C. Maybe that was just their goal all along.
Re:Cry for relevency (Score:5, Informative)
Um, what? Seriously, the b, u, i and big tags are _exactly the same_ in XHTML. There was never a super element in HTML 4, it's just sup, and it's unchanged. The a tag does everything from HTML 4 the same way in XHTML. The only difference in it is that it's allowed extra attributes.
Out of all of those things, the only one that's changed at all is the img tag, and that's only in two places - first, in XHTML you are required to provide an alt= attribute (instead of just strongly recommended like in HTML 4), and second, you have to close the tag properly, with a
Frames are also still part of the XHTML spec.
The font tag however, is gone and won't be missed any more than the blink tag was, by anyone other than frontpage (which absolutely loves adding thirty or so font tags in a row setting and unsetting the color 'white' from the text.
Parent
Re:Cry for relevency (Score:4, Informative)
I think a reason that XHTML has not taken off is due to its unforgiving strictness. From what I understand, if you make a single mistake in XHTML the page will not work and for that reason it is not intended to be handwritten. But with HTML you often have different ways of achieving the same effect, such as with centering.
Actually, one of the reason many people have picked up on XHTML is because it's a lot "cleaner" than "good" ol' HTML 4, the strict rules are one of the reasons for this, in XHTML you're not allowed to do stupid shit like "<i>foo and <b>bar</i> are both words</b>". And writing XHTML by hand is much easier than relying on some horrible WYSIWYG tool's generated code.
This is the reason for the continuing appeal of HTML: its simplicity. My understanding that XHTML requires is that document formatting be separate from the content of the document. Yet sometimes is so much simpler to use a CENTER tag versus having to mark a section of text with a customized tag and then go into a style sheet to center a single section of text.
Actually, formatting should be kept separate from the content for several very good reasons. Maintainability is a biggie as anyone who's ever had to redesign a static HTML website riddled with <font> tags. Extra points if it was made using a WYSIWYG tool that uses three or for tags when you only need one...
Anyway, I for one hope that XHTML is path we stay on. And I think the main problem that XHTML+CSS has had is Internet Explorer and its craptastic handling of CSS (still crappy in IE7 although it's gotten slightly better).
/Mikael
Parent
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.
Just what we need (Score:4, Funny)
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: (Score:3, Interesting)
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: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.)
Parent
The Author is Not Completely Wrong (Score:5, Informative)
Parent
Re:The Author is Not Completely Wrong (Score:5, Informative)
http://blog.whatwg.org/html-vs-xhtml [whatwg.org]
Parent
Re: (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.
Re: (Score:3, Insightful)
Re:A clean slate again (Score:4, Insightful)
The funny part of that is, Netscape was a re-write of Mosaic by the people who made it in the first place. They did Mosaic as a school project, and then said to themselves, "You know, we could probably make money with this, if we fixed all the things we did wrong!" Mosaic was kept by the University it was written at, then spun off to a company named spyglass, which was bought by Microsoft, and re-named to IE. Thus, Mosaic started the web revolution, Netscape was a side-track, and then Mosaic came back under a different name, with much wealthier owners who could afford more coders to work on it. Netscape of course, tried to keep up with the feature creep, but with less financial backing, and less people working on it, their code soon turned into an un-manageable mess (which is why it was completely scrapped and re-written from scratch for Firefox) - just goes to show that for large projects, maybe those project managers really do serve a purpose.
That of course, is where the problem with browser compatibility really came in - Microsoft wanted more more more features, and they wanted them now now now! So they pushed their developers for speed instead of sanity/security/stability, and that resulted in dumbness like allowing ActiveX to be embedded inside of web pages, and the completely screwball syntax for adding filters to CSS code. Admittedly, some of the things that were added were good, and some were useful (the BGSOUND tag for example, is much easier to control from javascript than the EMBED tag), but the vast majority of the "new features" introduced to IE this way were either pointless, needlessly convoluted for the developer, or just plain harmful. (As the many people who had their bank accounts raided by ActiveX malware, or their computer's power turned off by visiting a prank site will agree.)
Since IE was windows-only for the most part, Microsoft was free to include as many proprietary things as they wanted, slap copywrites, patents, and all sorts of other protections on them, and basically make it impossible for people on other platforms to add those features to their browsers. It's important to remember that in the early days of the internet (when Mosaic and Netscape first came out, and thus when the actual mindset regarding their feature paths was determined), Windows only barely supported internet access at all, and was in the extreme minority of systems on the internet, which were mostly Unix based. (Yes, Microsoft's browser did technically originate on a Unix system, I've used the original first version of Mosaic when it was first released, on a black-and-white X Terminal attached to an SGI Challenge system.) That meant that while Microsoft was free to make things that worked only on their system and call it good, nobody else could get away with it, as most of their userbase would be left behind.
Besides, adding a new spec like HTML 5 will not fix the browser gap - even now, as new technologies are coming out and new standards and specs are being released, the browser developers are still putting their own unique and incompatible spins on how things work. Ever tried to embed video in a web page and have it be completely XHTML compliant? You can do it in Firefox. You can do it in IE too. You just can't do it in both with the same code, because they interpret the specs differently. That has nothing to do with IE needing to support backwards compatibility at all, since backwards compatibility relies on a different set of tags completely. It also has nothing to do with Firefox's developers being immature and combative, since they took the simpler and saner route of the two, which didn't involve ActiveX, or embedding the Microsoft Media Player. (Yes, ActiveX in web pages is still bad, even if it can't get at your bank software or power off register anymore.)
Parent
Re:Great (Score:4, Insightful)
Anyway, the fact remains that it was us who stole
Parent