Slashdot Mirror
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?
Blah blah sig blah blah blah irony blah blah
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.
It's all about "Web 2.0". A new source of revenue must be needed, might as well tweak the current HTML spec. No worry that there
isn't a browser that fully supports it, as per spec, just release more bloated crapware.
And here I was happily surfing the web on Lynx.
I'm sure this will add more 'features' to enable revenue generation.
s. And the worst part, and I don't know if this is w3c's fault, but using & for html entities is inexcusably broken. URLs have already had & reserved for years, and now you suddenly can't use a & in a link.
ADVENTURERS! - ANTIHERO FOR HIRE - CARDMASTER CONFLICT
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
Amazingly, my web pages sucked with HTML 4. They sucked with XHTML. They'll probably suck just as bad in HTML 5.
Just my 2 worth.
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.
What are these people, engineers or something?
It needs to have a spiffy name like Extreme HTML or HTML-Pro or Sup-R-HTML or HOT!ml.
Or... I have it. Call it HTML 2.0.
Bother the fact that that version number has already been used, everyone knows that the purpose of version numbers is not to identify sequence but to communicate a marketing message and what could be better than an implication that it's "the HTML for Web 2.0?"
"How to Do Nothing," kids activities, back in print!
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."
Let's have HTML5 exactly like XHTML, but make it case-insensitive. Especially ditch the awful tag. And allow "centre" to be spelt correctly!
/>, <Br />, <bR /> and <br /> would no longer be four different tags; and if they had ever had different meanings, it would have cocked things up. Of course, assigning different meanings to differently-cased versions of the same phrase was itself a Least Surprise Violation in the first place, unless all but one version are considered errors .....
The thing that ruined XHTML was that it introduced case-sensitivity to a system which had previously been case-insensitive. This is a recipe for breakage. Case-sensitive behaviour is fine in its own right -- after all, just because the dollar sign and the figure 4 come from the same key on the keyboard, they aren't interchangeable, so why should the letter "z" and the letter "Z" be thought of so? -- but not when it's introduced suddenly where it never existed before. That is a blatant contradiction of the Principle of Least Surprise.
It could be argued that removing case-sensitivity which had existed previously would create even more breakage; suddenly, <BR
At any rate, capitalised tags make it easier when you're editing HTML on the web server using nano.
Je fume. Tu fumes. Nous fûmes!
Another web standard for microsoft to ignore.
Yes, this was discussed last April on Slashdot
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.
Now what we need is a new version of HTTP that allows "Referrer" to be spelled correctly.
Esli epei etot cumprenan, shris soa Sfaha.
Clearly XHTML is inferior to HTML otherwise the people behind this push for HTML 5.0 would be pushing for XHTML 2.0 instead. But why is XHTML worse than HTML?
After all, XHTML is currently considered harmful.
Sure, HTML includes browser-specific extensions, but if you do not use those, and instead HTML+CSS, you'll end up as more standards compliant than using XHTML with CSS and the wrong MIME type.
Beware: In C++, your friends can see your privates!
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.
that "Centre" is in fact spelled correctly. It's "Color" that's wrong ;-)
Perhaps both Centre and Center, and Color and Colour, could be considered syntactically equivalent for the purposes of rendering, to cater for differing regional variants of English?
F_T
No, I'm saying it doesn't change. Latin is dead too, that doesn't mean it isn't used regularly. It just means that the language no longer changes, and meets the needs of it's users. I'm saying HTML may just not need to change, as it seems to be meeting our needs. The W3C's
Sign up for an account.
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.)
I actually like this feature. I hate when I am reading HTML and all the tags are capitalized. It looks horrible and it usually means I can expect to see some php right smack in the middle of it all.
Long live HTML 2! Depose the usurpers!
need a free COBOL editor for Windows?
Good points and I'm glad to see this get the discussion it merits. Backward-engineering the IE display model is a little bit tedious, but not rocket science; the Opera guys did it very quickly and accurately. There are many things I would like to blame MS for, but I'd like to note that Netscape was far from error-free, and at the time, IE was a breath of fresh air, although that's hard to believe. I'm still not enamored of any browser, although Opera is the best I've found. None are really GREAT pieces of software in the way that, say, Lightspeed C for the Mac was in its day, or ProTERM on the Apple //e, or TextPad on a modern Windows machine.
technical writing / development
IE took over and "ad hoc" implemented what it could and what corporate politics allowed. It was far from perfect but it was better than any other option. Some years later, after IE had gained dominance, a small team brought us Firefox. This new browser tried to rewrite history by claiming it was the guardian of the "one true standard," the Word of the W3C, et al. It seems deliberately designed to ignore the changes in the world of designing web pages brought about by six years of IE dominance.
Uhm, how should I reply to this? How exactly was it a good thing that MS just decided to not only expand on the standard with their own non-standard browser behaviour but also by interpreting the standard in a completely different way from everyone else? Have you even heard of the infamous "Embrace and extend" tactic employed by Microsoft?
The result is a cross-browser coding disaster, and as a web developer of 15 years' experience, I blame Firefox more than IE. Both sides have their own model, and IE can't change, because it must uphold its backward compatibility. Firefox, on the other hand, is a completely incompatible standard that reflects W3C standards written after IE gained market dominance, in some cases. It is needlessly combative and in my view, destructive to those who make pages and the consumer. (Opera, on the other hand, has a saner view: it views IE 5-6 as a de facto standard and adapts, a striking maturity the FireFox developers should find intriguing).
Ok, so the IE developers screwed things up and now they can't fix things because it's too late, how the fsck is that the fault of Firefox? There is nothing "needlessly combative" about implementing the W3C standards instead of the "IE standard", it's simply following the standard. If Microsoft were so desperate for features they should've worked to get those features put into the standard.
HTML 5 is a chance for both sides to fix their sites on something productive. We can for once develop the standard before the browser, and make it work cross-platform, saving web developers years of frustrating and most of all BORING xbrowser code fixes. Also, we can finally admit to each other that while CSS is neat, the original HTML model made more sense for developers and is still more stable than CSS.
There is a pretty good standard: XHTML. There is also CSS 1 and 2 with CSS v3 on the way. This path has a lot of advantages over the "old ways" of HTML 4 and it's predecessors. And the main reason that we need all the ugly cross-browser hacks nowadays is because MS still won't develop their browser to interpret document according to the standard. Hell, it took them years to realize PNGs had an alpha channel..
That's my statement, and I'm sticking by it, after being a Gopher administrator, FTP publisher, early Web site creator/server admin and independently employed Website creator for fifteen years.
So you started writing HTML back in 1992? Somehow I always thought anyway who had more than a few months of experience with HTML wouldn't be so backwards, but maybe it's about time for the WWW to begin developing a few old farts that prefer the old and painful ways over the modern and slightly more sane ways... (nothing personal, I just can't understand all the people in this discussion arguing that XHTML is crap because they can't understand it)
/Mikael
Greylisting is to SMTP as NAT is to IPv4
"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!
...as long as it had been treated as no more than a "kludge" that, by adding a few extra closing tags, double-quotes and other flourishes, let you write XML code that still worked in any well-behaved HTML renderer but could be parsed using XML tools (or, e.g. generated as output by XSL until common browsers get round to implementing FO, assuming it is possible to implement FO...). If you want to do proper semantic markup, just use pure XML with a CSS or XSL stylesheet and forget all the legacy rubish that HTML drags with it.
I don't suppose that W3C will break with tradition and produce a reference implementation of HTML5 so that (a) developers have a reference to compare with or (b) don't need to refer to the reference implementation, because the reference developers fed back the ambiguities and conflicts to the spec writers, who fixed the spec before it is cast in stone...?
Didn't think so.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
So is the same as <ß/>? Yay for capitalization rules. Or are we going for the SQLite style "case insensitive for 7-bit ASCII but case sensitive elsewhere"? :)
Ooops, I got owned by the very thing we're talking about ;)
My XHTML example got embedded in the post!
I know that for some it is tempting to label things that hit loyalty centers as trolls, but look rationally at the situation: this post is not intended as a troll.
Its point is that HTML 5 is a welcome fix to the mess created by cross-browser CSS.
If people have troubling accepting that due to emotional immaturity (see: fanboism, brand loyalty, fanaticism) I can only suggest that this is the reason for Slashdot's continued reliance on meta-moderation.
technical writing / development
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.
I posted a story on this in May and no one cared. The story hasn't changed - but now that it's stale it has become interesting?
(no, not bitter, not me, nope)
Death looks every man in the face. All any man can do is look back and smile. - Marcus Aurelius
Which is a pain, because I have to go to the trouble of writing <span style="font-decoration: underline"> instead.
Deprecating the center tag was absolutely and in every way the proper choice. There are better ways of centering your content via CSS, that don't impose your layout intrusively upon your content.
The new vocabulary of HTML 5 is nice. One can argue it's simpler than XHTML 2's equivalents. But, please, why would one want to retain HTML's loose syntax? I don't see why one would want to offer multiple syntaxes; what's so wrong with XML-like well-formedness? Also, HTML 5 shows no consideration of mobile markup (oi, where did accesskey go?) like the XHTML family does (hey, there are two mobile XHTMLs!) We're going to have Yet Another Markup Standard. This idea that XHTML is the product of stuffy irrelevant committees of wonks and HTML 5 is the evolved, lucid way of the future is misguided; it's just the product of a different committee of wonks...
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."
The reasons for supporting xhtml (more uniformity of expression, simpler parsers etc) are still as valid as ever.
Why not drive people to an xhtml 2 or 3 or whatever by including the advanced content type tags in a
new xhtml standard.
When it comes to syntax standards, less often really is more. Simpler grammar, more expressive vocabulary
is the way to go. Complex grammar + large vocabulary just means hard to parse and to understand.
Where are we going and why are we in a handbasket?
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.)
BWAHAHAHAHAHA! Thanks, I needed a good laugh. Great piece of satire, buddy! Let me see if I can continue in the same vein:
There's no way that all of the protocols and all of the standards that the Internet relies upon were built without Microsoft. And there's no way that the Internet would ever have been used by any business, government, or institution of higher learning before Microsoft made sure that every Wintel desktop would have a browser on it.
That whole canard about how Web browsing was invented by one guy at CERN just isn't true, after all.
Wait. You were serious?
It would have been a dupe ;)
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
What height is H1 supposed to look like by default?
On your Braille reader or your cell phone?
What's the DPI of your display?
Answer: it's not visual markup, it's semantic markup. Style it with CSS if you can't trust your users to chose what they want an H1 to look like.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I will never understand why HTML5 gains momentum while XHTML2 has become shunned. The page describing diffrences between HTML4 and HTML5 is chock full of "WTF?" moments: presentational tags coming back from the grave, new tags that fill niches narrower than a human hair, and new attributes that are simply bizarre. The ping attribute is so ripe for abuse (by marketers) that I can't even begin to describe how bad of a design decision it is. Other structural problems (such as the dl element's lack of internal organization) remain unaddressed.
XHTML may not have been developed that way everyone wants now, but it is a victim of circumstance: IE doesn't handle the application/xhtml+xml mime type at all. Is this the fault of the original XHTML working group? No, the blame for that lies at Microsoft's feet.
XHTML2 has elegant solutions which HTML5 eschews in favor of bloating its tag set. The role attribute could replace half a dozen or more of the new special purpose HTML5 tags. Adding href and src to nearly all the tags is another stroke of genius.
In a world which has embraced XML, why should the most public-facing specification of the W3C make XML compliance optional? Tag soup is for idiots, just like babushka tables. Some claim that XHTML was never embraced by developers. Which developers do they mean: the ones who have read and understand the standards, or the WYSIWYG monkeys who couldn't write a valid "Hello, world!" paragraph by hand if their lives depended on it?
I find it appalling that the W3C has allowed this usurpation to happen. And nothing against Chris Wilson personally, but him as the working group chair will probably have dire consequences eventually.
*HTML or whatever is required.
... not me and others around the world.
.com/.gov/... sites I avoid like the plague (because they are), some shopping site have vanishing select-boxes (I see one) or the download this webapp for the content ... I just quickly go to another (of many options) site for the same products or services.
... for content well fyck'em ... I don't need their content, products, or services.
We in the USA we have a national language of English for communication any other language can be used and may cause business/personal/... problems. The WWW/Internet has the IMO W3C national language for Global WWW/Internet communications and collaboration. You can use what ever you and another person agrees to use for a language, but the impact does fyck you
I can live without the MS/Adobe/... version of WWW/Internet code, but I would like more "Community Commons" that anyone can access.
Any proprietary idiot can break the WWW/Internet, only a standard allows everyone to receive something. Something like all that stuff provided on the WWW/Internet.
Some
If it is a pain, because they used a proprietary format, java-screen-lock,
Unaccountable leaders are masters, and unrepresented people are slaves. How do US and EU fare?
XHTML has only been taken up quite recently in comparison to how long it's been about, and even then it's been implemented incorrectly. Most of us will have become accustomed to creating clean xhtml pages that rely on css for styling, however a vast majority of the web have, it seems, jumped the bandwagon without reading the fine print. I'll be the first to admit I was one of them thanks to numerious net articles, books and even lectures at university.
.dtd.
XHTML is a derivative of XML that uses html-like tags and syntax. When used correctly it will be parsed as XML. This was supposed to be the future - no more varying designs through different browsers or funny rendering quirks because the XML framework and the strict syntax rules prevent this. A page will do just this if the headers are set to 'application/xhtml+xml'. The problem comes in that most people are doing everything right but sending the wrong headers - 'text/html'. When this is done, your lean, tight xml markup becomes html and all the benefits that XHTML was supposed to bring are lost.
But what about the W3C validator I hear you say? Well, yes, it validates just fine because it is correct - but then it doesn't check if you've sent the right content headers as that isn't its job (they can be sent through the server before the page is even sent anyway). Go to an XHTML site, view the source and see how many have a meta content of 'text/html' - a lot I bet.
One major reason why XHTML has ultimately failed is that Internet Explorer hasn't implemented it correctly. I believe it does have the capacity but requires some funky server workaround, as the ' to '>' and putting in the right doctype header and
I recommend you check out the following source which was written in 2002. This has been going on for a while - no wonder HTML5 is being considered.
http://hixie.ch/advocacy/xhtml
Can we get more controls, like combo boxes and numeric up down?
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.
Please explain how is more intrusive than <div style="text-align: center;>.
The latter simply makes your code harder to read (as with most aspects of XHTML vs HTML).
Microsoft can't change how IE handles web pages, because they will break all the sites that were written to depend on IE6's behaviour. They did make some changes in IE7, but they were burnt by the experience and don't want to do it again - see Chris Wilson's comments:
All the other browsers do reverse-engineer IE's behaviour, as well as each other's. HTML 5 is largely an attempt to document and standardise that reverse-engineering: anyone who wants to process the web has to do it in a way that's compatible with the real web, and the real web is written to be compatible with IE, so that has always been the de facto standard and now HTML 5 is making it into a real standard.
There are many cases where IE's exact behaviour is too insane to copy, but Mozilla and Opera and Apple have experience of what behaviour is close enough to work in reality (based on feedback from bug reports about broken sites) - so the result is something that should be sufficiently compatible with IE in all the cases which web authors depend on.
It's not HTML or XHTML I have a problem with, it's CSS.
CSS is simply a horrible way for web developers to have to try and format a page. It's fine if you want to change a color or add border, but for controlling the layout of a site, it's a nightmare. I find that for most things, setting the basic site layout (eg 3 columns) is far more easily achieved with a table than by trying to float divs. Tables simply ALWAYS work in all browsers with minimal code. There are hundreds of websites which try and give you "the best possible way of making a two/three column website" and all of them have dozens of lines of CSS with loads of browser hacks. If you use a table with three columns, the code is a fraction of the size and works in all browsers.
Take slashdot for example. It's a really common site layout (header, navbar, body etc), but it has the most CSS I've ever seen on any website - purely because the author has gone out of their way to avoid using even just ONE table.
I honestly don't see the problem with using one or two tables to define the site layout. Nobody has ever given me a good reason why doing the same thing using only DIVs and CSS is better (and don't even think about using rendering speed as an argument - I've benchmarked it myself and table layouts usually render faster - probably because usually they require less code).
What CSS needs is a way of defining columns, or a way of gluing DIVs together to it's easier to stack them side by side without running into all the problems you get if you float them.
It also REALLY REALLY needs variables. Currently you have to put the same color definition into the CSS file in dozens of different places. If it had variables, you could simply define the colour scheme at the top of the CSS file and change the whole colour scheme in a few seconds without having to do loads of search and replace operations. It would be especially useful if the variable declarations were also accessible form the html. Eg <span style="color: %corporateColorDuJour%;">
It's not. They're both equally stupid.
Something like <div class="foo">Lorem ipsum dolor sit.</div> is much preferable a) because it can be overriden by user stylesheets, and b) because it's possible to change the text alignment at a later time if it becomes useful to do so without editing the document.
Get a better text editor. These days we have this useful feature called 'syntax coloring'.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Fun fun fun, that's all you guys care about.
How about some security for a change?
What we need are tags to help _ensure_ that potentially unsafe content is disabled. This will help prevent stuff like that myspace worm.
For example:
<shieldson lock="randomstring" allowed="keyword,keyword,keyword"
non explicitly allowed material disabled
<shieldsoff lock="randomstring"/>
Possible keywords:
textonly = just text
basic = basic formatting <em> <b> <i> <strong>
tables = tables
urls= plain <a href=""> no javascript etc
images= plain images, no javascript etc.
java=java
javascript=javascript.
There are other ways to do it, but I hope you get the idea.
Naive people say that this is unnecessary and it should be done in html escaping libraries.
BUT, the reason why this is useful is because:
1) browsers behave differently, your library may successfully escape stuff for one browser but nasty stuff might sneak through to another due to some bug. In contrast if a browser is told that "only plain text allowed", it's a lot harder to screw that up and start allowing other stuff.
2) This takes care of new fancy tags/features introduced by the Browser people. Say you start checking your webmail with your new fancy browser and accidentally click on some malware spam. Even if the webmail app does not know how to disable the new "active feature", the spammer's stuff between the tags should be rendered a lot safer.
I've tried to get the browser and W3C people interested, but they seem to prefer making more "Go" buttons (as per the article), and prefer to not even make a single effective "Stop" button.
Maybe someone should replace the brake and other pedals from their cars one day with accelerator pedals. And then tell them the HTML way to stop is to make sure none of the pedals are pressed.
Sheesh.
</rant>
To stop writing new standards and failure modes and focus on their QA efforts while existing browser projects catch up to the existing standards. As a developer and end-user of the results of both the standards and browers, there has been a piss-poor effort of ensuring and evaluating how well each browser satisfies a standard.
Do your apps work in Internet Explorer? If they do, then you haven't used a single feature of XHTML, that's not available in HTML.
In fact most pages on the web that are supposed to be XHTML, aren't even interpreted as XHTML by XHTML-capable browsers (because nothing except MIME type triggers XHTML support, DOCTYPE is absolutely irrelevant).
not only embedded, but stripped!
Gravity Sucks
There's no way that all of the protocols and all of the standards that the Internet relies upon were built without Microsoft. And there's no way that the Internet would ever have been used by any business, government, or institution of higher learning before Microsoft made sure that every Wintel desktop would have a browser on it.
Hah, I saw businesses on the net before MS ever "discovered the web". Back then I even had more bookmarks for Gopher servers than web servers.
FalconShould there be a Law?
p and div aren't being deprecated, nor are they being depreciated. However HTML 5 does have new elements such as nav, header, footer, and article for the exact use case you suggested. If widely used (and yeah, that is a big "if"), this would help both search engines and accessibility tools.
One of the stated design goals of HTML, from way back, has been that it will look different for different people. The web isn't supposed to be the same everywhere. It's supposed to vary from person to person, the way people vary from person to person. I know there are a ton of anal-retentive control freaks who just can't seem to stand that, but it's the truth. Someone already posted examples about things like cell phones and braille. I'll add: What about the spoken word? What about the fact that I might want fonts to be bigger, smaller, rounder, or more cromulent?
If you want everything to look the same as on your screen, invite everyone into your office to see it.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
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.
XHTML is still bettr than HTML in that it's a lot easier to parse. IMHO that is a good thing as it makes it easier for browsers to be smaller and bug free. The point that any device can also render HTML is moot because it still makes the devices work harder and the majority of websites still don't use XHTML because the majority of web designers are trapped in 1997. The majority of websites still just can't easily be tweaked to work on multiple types of devices to any decent level of usability - many don't even work on different browsers or screen sizes properly. Just because people still make really bad code we should take that as a reason to stop trying to make better code? Doh.
We shouldn't be adding a bunch of specialized tags - we need to make it easier to define roles for tags, using CSS and Javascript, that can change as needed. Why not just make tags as optional/flexible as setting the class of a tag. So I can use MyText instead of MyText when I want to. It'd just lead to code being easier to read. Tag attributes such as href, src, rel, etc would be easier if CSS was expanded so that they could be set in that way.
It looks like they still let Javascript ans styles be written inline so it can't be that good a proposal. It just leads to sloppy code and issues like XSS attacks. What we really need is a correct way to specify code that responds to specific browsers and browser versions, to specific disabilities, and to specific window sizes. Also we need a way to specify that scripting and style can't be specified in the body of a page.
Other than that my only real wish list is for better audio/video controls (which it looks like they addressed to some extent) and for some upgrades to Javascript (behaviors being native) and CSS (different layout types, more ways to manipulate text and images, actual workable downloadable fonts). More widgets being available is great but lets fix some of the fundamental issues first.
All of this comes as way less important than actually getting all browsers on the same page. IE7 continues to be a pain as it still has bad CSS and Javascript support.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
I'm aware of the Nicoll quote, of which the quote I posted is almost certainly a paraphrase. But strictly speaking, those are not his words, and I don't know who penned them. I suppose I could have been more complete in my attribution, something like "-- Unknown, likely paraphrase of James D. Nicoll". Given the quotes under discussion, though, I do find this whole meta-discussion quite ironic. :)
Thanks for the link to that well-sourced attribution, though; that's better than anything I have.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
I want to write an interactive application in JavaScript, where an audio clip of shaking leaves plays whenever the player's character walks up to a tree and grabs it. How can this be done by merely linking to an mp3 file?
And an infinitely better user-experience than playing through some horrible flash client, which wont let you re-size or save.Blocking saving is intended to encourage[1] users to pay for a copy.
[1] Pedants: Perfect DRM on audio is impossible, but some publishers find it profitable to keep honest people honest.
Wake me up in 2013 when a practical implementation exists.
No wait, in 2020 when IE implements it.
To be honest, I simply got tired of new amazing, wonderful and promising specs appearing, to only be supported by a minority of browsers - and in an incomplete way. Firefox 3 is still in alpha, and it's only started to pass the ACID2 test. 9 years after CSS2 was published. (And don't get me started on IE)
When the XSLT spec came out, I thought it would mean a whole new web. I started making my webpages on geocities with XML - only to find out that geo's ads defecated on my markup, rendering it unusable.
Call me pesimist - but I just lost almost all hope. What use is publishing the greatest spec in the world, if the industry doesn't give a damn?
A refreshment on the html standard is good - but how will we solve the problem of standards NOT being enforced? A practically optional standard is like no standard at all.
- statutes,
- regulations, and
- court opinions,
but that doesn't mean that a list ends a sentence, let alone a paragraph.b) I buy. But as for a), how would the user know that the class is "foo" in order to make a user stylesheet? And what happens when another web site uses the class "foo" to mean something completely different?
And why didn't you mark up this two-element ordered list using <ol> and <li> elements? ;-)
Yes, I tried. For some CSS features work well only in XHTML mode both in Mozilla and Explorer. :-)
Surprised? I was too!