W3C Considering An HTML 5
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."
Because what the world really needs right now is another version of a web standard which has had hardly any full, correct implementations in any version that's ever existed.
Or are the W3C just trying to justify their existence?
TFA makes several great points about how this seeming sentiment of "we'll stick with the HTML we know and love" is more an unwillingness to change than it is to update a standard. The whole idea of XHTML was to provide a segueway into an altogether new way of distributing content. This really seems a regression more than anything. What does XHTML fail to deliver that would cause WC3 to shy away from the previously hardline (and appropriate, IMHO) stance of "this is the new HTML, get used to it"?
Appended to the end of comments you post. 120 chars.
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 last time.
Appended to the end of comments you post. 120 chars.
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.
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.
FanFictionRecs.net
Isn't the & character forbidden in XHTML links? You have to use the & entity, if I remember correctly. Sure, it's allowed in HTML 4.01, but not in XHTML (again, if I remember correctly)
It's too hard to implement, because there is no default way it should look like. There is no default, standard stylesheet. What height is H1 supposed to look like by default?
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.
Quickly, and in the order you mentioned them...
First, the italic and bold tags don't have semantic replacements either. You have the em tag, which is supposed to represent emphasised text, and the strong tag, which is supposed to represent strongly emphasised text. Following standard typographic conventions, emphasised text is rendered in italics, and strongly emphasised text is rendered in bold. These are not the same thing as the i and b tags. A screen reader would completely ignore those, but might use the em or strong tags to apply emphasis to the spoken version of a page. A non-graphical user agent might represent them in a different way.
That's why the i, u, and b elements still exist in XHTML 1.1. They're just for italic, bold, and underlined text that has no semantic meaning. When writing something in a foreign language, for example, it's conventional to use italics. That's not the same as emphasised text - a screen reader should not emphasise the italic portion just because it's in italic. So you'd use an i element, or some other element with italic font styling applied to it.
Of course lists aren't allowed in paragraphs. How could they be? If you're writing a paragraph, and you then start writing a list, have you not in fact finished the paragraph first?
The HTML entities thing is from SGML.
Or as the CV writers would say: "extensive experience with HTML 4, XHTML, where he was responsible for delivering high quality web pages. Has studied the HTML5 standard and is confident that he will be able to maintain the same quality of delivery with this new technology."
you, sir, are apparently the last person i should be listening to about HTML.
it's a joke. laugh.
Another web standard for microsoft to ignore.
Can I have a client side include this time around?
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.
I wank in the shower.
If the standard is "do whatever IE does" then how would Firefox ever actually be able to implement that standard. There is no published documents on how IE functions, so how is Firefox supposed to keep up with that. If Firefox emulated IE 6 perfectly, and then MS released IE7 and completely changed the markup (like they do all the time with their doc format), then Firefox would have to go through a lot of work, trying to figure out what MS was doing. the W3C standards exist because people want to use operating systems other than windows to access the web. They exist because they want to be able to rely on other vendors to provide a web browser that works. If anything I would blame MS for holding everyone back, when we could be creating beautiful webpages very easily, but instead it ends up taking twice as long because we have to deal with all the quirks in IE. Even if no other browsers existed, it would still take this long, because there is no documentation or definition of what IE will do with any give HTML or CSS code.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
I have suggested this before and always got shouted down for it... but as a web developer, I really wish they had simply implemented tags like 'date', which the browser would automatically know about as a date field and have its own built-in popup calendar for browsing dates, rather than having to either rely on plain text, lame dropdown menus, or else implementing yet another date popup javascript library (or including yet another javascript library which slows down the user experience even more).
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.
After Mosaic faded out, Netscape was the dominant browser, . . . Microsoft IE took over as the dominant browser.
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.)
Anyway, the fact remains that it was us who stole
Je fume. Tu fumes. Nous fûmes!
"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!
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.
HTML 5 won't matter until Microsoft almost handles it in Internet Explorer. I'd guess that might happen 5 years after the standard is adopted.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
I see this a step back.
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.)
W3C was formed to create a "consortium" not only of browser makers, but also tool vendors and other major HTML users. The W3C explicitly differed from IETF in having members pay dues (and hefty ones for big companies), and in having more structure, though still less than real standards bodies such as ISO.
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.
You mean like display:table-cell that's part of CSS since 1996, and works reliably in every browser except IE?
For constants use server-side processing (color:%foo% is trivial to implement). For really variable-variables you have DHTML and W3C DOM2 Style.
That's "bastardised", dear boy :-)
Obligatory: "English doesn't borrow from other languages. English follows other languages down dark alleys, knocks them over, and goes through their pockets for loose grammar." -- Author unknown
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.