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."
Absolutely right (Score:5, Insightful)
Or are the W3C just trying to justify their existence?
Regress is the New Standard for Progress (Score:5, Insightful)
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.
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.
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
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...
Re:Cry for relevency (Score:1, Insightful)
Re:Regress is the New Standard for Progress (Score:1, Insightful)
XHTML needed a 'killer tag', but it was just a lame extension to HTML 4. If they had provided these features then it would have been accepted (I think its clear now the industry does not accept XHTML).
No, XForms do not count, the key is backwards compatibility.
Re:A clean slate again (Score:3, Insightful)
Re:Absolutely right (Score:1, Insightful)
Otherwise, in my experience, XHTML is definitely the more correct, optimum, eventual solution. I can't imagine how (in programming at least) ambiguity can be more desirable than clean-cut standards.
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.)
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.
Re:Regress is the New Standard for Progress (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 from the developer working with me, I can feel it.
Give me clean code and forced usage of CSS any day.
Re:Cry for relevency (Score:3, Insightful)
This can be solved with moderately smarter CSS munging (whitelist the font-* stuff) or simply not allowing your users to use HTML in form posts in the first place - use bbcode instead.
That can be munged by the server however it wants.
Rest of what you were saying was kinda silly so I just focused on the one legitimate one.
Oh, and target="_blank" - that's fair. The only alternative is javascript, which often is no alternative at all. On the other hand, I do find that target bloody annoying. Let me decide if I want to open a link in a new window, dammit. I'm not exactly sorry it is gone.
Re:Great (Score:4, Insightful)
Anyway, the fact remains that it was us who stole
Re:I hate ACs (Score:3, Insightful)
"Indeed they do, but in 10 years if every web board declares XHTML strict convention, there's plenty of handy stuff that no longer works, and has no replacement."
Got any examples of what you can't do in XHTML that you can do in HTML? At the end of the day you can always embed CSS directly into your code when using something like a form on a forum using the style attribute, for example:
Blah blah
It ain't good practice, but backwards compatibility isn't necessarily about good practice because sometimes the things you're being backwards compatible with weren't good practice to start with.
Furthermore, you talk about additional functionality being missing from XHTML that's available in HTML but again, this misses one of the core points as to what XHTML is about, the X in XHTML means extensible, XHTML is designed to be a solid core of HTML markup that's embedded in the XML rules, so that any application can define a new doctype with new tags to do new things as needed. HTML doesn't have this option without simply breaking the standard.
Many of your comments also suggest you don't understand the concept and importance of separation of code, content and presentation and what this means. The W3Cs recommendations aren't about creating new standards to stay relevant, they're about pushing standards that improve:
- Accessibility
- Extensibility
- Compatibility
I can't see how this is in any way a bad thing for anyone other than those who simply can't be arsed to spend 10 minutes finding out what's different!
Re:The Author is Not Completely Wrong (Score:3, Insightful)
Because XHTML adoption has been slowed by a lack of backwards compatibility: you can't currently deliver XHTML in a standards-compliant way and expect it to work on anything other than a small minority of browsers. Sending the data with content type 'application/xhtml+xml' or whatever confuses the current installed base of internet explorer, making it an extremely bad idea, and probably unusable for general consumption sites for at least the next 5 years. See this excellent article for more reasons [hixie.ch] why this is a good idea.
Re:Absolutely right (Score:3, Insightful)
Perhaps you'd like to write it? I'd like to see such a thing. It would be quite amazing if it was done well.
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].
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.
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.)
Re:date tag? (Score:2, Insightful)
Re:As a standard, HTML4 has failed (Score:3, Insightful)
I fail to see the difficulty. Headings aren't supposed to have a particular default height. What makes this difficult? Browser vendors can simply pick one themselves.
It's trivial. It's a bit more complicated if you are talking about the subset of HTML and CSS that Internet Explorer supports, but there have been established techniques for years.
Part of Apple's philosophy is that applications should be based around the concept of documents, and they've been quite successful with it. A document model is not antithetical to applications.
This is not true. The idea is to use the most appropriate element type. <div> and <span> elements should only be used when there isn't something more suitable.
Please refer to the Rule of Least Power [w3.org]. It has all kinds of implications that make what you are suggesting a much worse idea than a document-based design.
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).
Re:Absolutely right (Score:3, Insightful)
Nice strawman. CSS 1.0 was 11 years ago. Do you know how hard it is to make a 4-column table using HTML 2.0, which was the HTML standard 11 years ago?
(Hint: HTML 2.0 didn't have tables.)
4 columns in CSS is trivial [glish.com], if you don't limit yourself to what CSS was like 11 years ago.
Re:Absolutely right (Score:4, Insightful)
Oh, wait. They don't.
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!
Re:Absolutely right (Score:3, Insightful)
It means you get to use a validation component on the included content before sending it to a browser.
You can bet your butt that there will be such components available before HTML 5 reaches any notable market penetration. Open source coders will Likely get them out there before the standard is even finalized.
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.
Re:Absolutely right (Score:3, Insightful)
Well, it would be a shame to use any software that'd break like that! How come that the web is the sole programming environment where it's impossible to get an error, where programmers are thus encouraged to make errors, where coders can ignore string validation (and supposing a strict HTML parser, they'd blame the parser just like a clueless newbie would blame a compiler)? Please, we're not talking about complicated markup nor about string validation done in assembly or C -- web languages have easy built-in routines that do just that.
HTML monkeys rely on that great "error-recovery" misfeature and that alone explains why browsers are so big and slow. Every tag-soup-recovery method used by MSIE must be reproduced, so the standard shifts to how-does-MSIE-handle-that. Had Netscape won the browsers war, the same situation would prevail.
And there is no reasonable explanation nor incentive to base the web on human error recovery! Come on now. The web would still exist if it required strict conformance to standards. Javascript syntax errors are fatal, how come people who can't code HTML properly are able to code syntax-error-free javascript?
Re:Regress is the New Standard for Progress (Score:3, Insightful)
Incorrect. Web developers don't adopt it because they're not required to. XHTML offers one big benefit that many bad web developers, like yourself, fail to see. That is strict parsing and failures associated with parse errors. When you write a program, the compiler/interpreter expects you to write code that adheres to the syntax defined by the language. Failure to do so results in an error. There is exists no such thing for HTML4 markup, therefore you can gloss over several parser errors and never notice them. XHTML was out to fix that, but because the W3C has such a shitty track record with the other half of defining standards (which is testing, quality assurance, and certifcations), nobody bothers.
The parser should be anal. We've already developed and studied parser technology to the point where it is pretty standard or even automated [wikipedia.org] to write a parser as long as you have a grammar. Having an anal parser is almost "free" testing--something many web developers need more training on.
It's only painful because you've been doing it wrong the entire time and you were allowed to get away with it.
No, you don't need those things. You think you do, but you don't. The internet was intended to spread information. Text and hyperlinks are a great way to get that across. But somewhere, someone(s) started playing with other types of content like images, animated images, built-in programmability (Javascript/ECMA script), and embedded programs and other types of media (flash, video, audio). Now we have bloated pages, pages that mess with your computer, and a complete mess called the world wide web.
I don't disagree that there are some benefits to having these things, but there's been an awful lot of hurt and pain caused by having them. Therefore, I believe it is much better to take a conservative approach to adopting standards that go beyond basic text. Once we've finally gotten that first step right, then maybe we'll get the others implemented better. But everyone's always quick to define the solution but never the problem that the solution is to solve. Because of that we end up with standards and solutions that have issues and are fairly limited in their lifespan or application.
Re:I think you'll find (Score:2, Insightful)
Re:Absolutely right (Score:3, Insightful)
Sure, I know we can't suddenly flip a switch and declare that all HTML must be valid and well-formed from now on, I'm just saying that if we'd treated HTML the way we treat programming languages, we'd be in much better shape today. Too bad HTML tags weren't defined as a bunch of PostScript macros....
Re:Regress is the New Standard for Progress (Score:3, Insightful)
``Ill tell you why web developers do not adopt XHTML, its not because of reluctance to change, its because XHTML OFFERS NO BENEFITS TO HTML 4.''
On the contrary. XHTML, contrary to HTML, is easy to parse. There is a whole slew of tools available for parsing and processing XML documents, which can be used with XHTML straightforwardly (by virtue of XHTML being XML). Now, these benefits might be external to web developers, but, eventually, they should (and have) come back to them. Some XML tools can be put to good use by webmasters. If the webmaster outputs valid XML, that is.
``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.''
If your HTML was good, there is very little pain. If the HTML was crap, then, perhaps, you shouldn't bother with updating indeed.
``HTML 5 FINALLY introduces features that web developers NEED.''
One of the key benefits of XHTML is that other XML formats can be used together with it. This allows an infinite number of useful formats to be developed orthogonally, and then put together as the need arises.
``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 trick is, of course, that with HTML, you do indeed need to put the features in the spec. With XML, you can keep things modular. MathML doesn't have to be in the XHTML spec to make it valid to embed MathML in an XHTML document. Of course, as long as user agents don't implement the necessary support, you're stuck no matter if the spec includes your favorite feature or leaves it up to a separate spec. And that's where the real issue is as far as features are concerned. The browser vendors don't have to wait for W3C to cook up something before they implement it, and, conversely, just because the W3C has cooked up something doesn't mean the browser vendors will implement it.
``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.''
In what reality?
Re:Absolutely right (Score:3, Insightful)
No, the idea was to build up the standards gradually. Start with the simple stuff and then move on to the more complicated problems. You know, good software engineering. Plus HTML was never intended to be a page description language. Computers at the time didn't have the kind of huge high-resolution screen that would make multiple columns a good idea.
(In fact, plenty of us still don't think they're a good idea on screens [456bereastreet.com].)