Slashdot Mirror
Is It Time for a 'Kinder, Gentler HTML'?
jg21 writes "Via the Web 2.0 Journal, a worthy link to Yahoo! Architect and JSON inventor Douglas Crockford's latest ideas to fix HTML. He's categorically not a fan of HTML 5, which is still just an Editor's Draft and not endorsed by W3C yet. Crock puts forward ten ideas that in his view would provide extensibility without complexity, adding that the simplification of HTML he is proposing would reduce the cost of training of web developers and incorporates the best practices of AJAX development. From the article: 'The problems with HTML will not be solved by making it bigger and more complicated. I think instead we should generalize what it does well, while excising features that are problematic. HTML can be made into a general application delivery format without disrupting its original role as a document format.'"
You can read his proposal in full over here: http://www.crockford.com/html/
:-)
Make sure you have about 2 minutes to spare. You're going to need about that long to read it from beginning to end. What you'll probably find is that he hasn't really solved any of the major issues plaguing HTML or even thought through many of the problems and use-cases that HTML 5 is trying to solve. In fact, his entire "design" can be summed up with the following sentence: "Let's get rid of HTML features that I believe cause problems."
Meanwhile, he still leaves the problems of consistent parsing, semantic meaning, multimedia presentation, and a whole host of other issues unaddressed. Which means that his "design" fails to compete with the intended purpose of HTML 5 at even the most basic level.
I have the highest respect for Mr. Crockford, but my opinion is that he should study the reasons behind HTML 5 a bit more carefully, as well as solicit a bit more feedback from the community before attempting to push a non-solution to their problems. Best of luck to him.
Javascript + Nintendo DSi = DSiCade
I especially like the "module" concept, which could help to standardize, secure, and simplify a lot of AJAX and similar concepts.
I concur, just make it as simple as possible, as non-error-prone as possible. Any of the stuff that "kinda works" should be in a separate spec, i.e. the HTML-KW (kinda works) specification.
stuff |
It is time for what I call binary pages.
Binary pages would be similar to Java applications. They would be created in Pagemaker. Dynamic content would be provided via Binary Page Scripting (BPS).
I think this is a great idea.
Very kindest regards,
Joe Lieberman
Yeah: we should make it more like C++, because HTML is just too hard.
From the part of the proposal entitled "That's It" I learn: These changes significantly improve the reliability, security, and performance of HTML applications. The simplification of the language reduces the cost of training of web developers. It incorporates the best practices of Ajax development. It provides extensibility without complexity. The deltas from HTML 4 are generalizations and reductions, which should make browser implementation more straightforward. This is particularly important for mobile devices that cannot tolerate the power demands of complex platforms. The only new feature here is the module, which is critical for security. Modules makes safe mashups possible. So what I'm reading here is you think these changes make it more "straightforward mobile-friendly?"
I am by no means an expert on this but I do code web applications for a living. I will tell you that these changes do not necessarily "improve reliability, security and performance" of HTML. You are suggesting changes with mobile devices in mind and the developers in mind. Adding another getElementsByTagName method to Javascript will make it easier for developers but over use of that will only make searching the DOM more intensive and lead to worse performance. And remember the original intent of HTML! If you are complaining that mobile devices can't render what a desktop can, perhaps it's time to look at a mobile-HTML standard and either you put a cross translator on the mobile browsers or you entice developers to make two sites. I'm not opposed to these ideas, I just don't see how they're going to really help anything but the specific users this guy has in mind. They certainly wouldn't help me at all or provide a better user experience for my end users.
This is ridiculous. You are attacking the wrong target here, you should be attacking the browsers that don't behave according to standards like the cowboy Internet Explorer browser that sometimes does whatever it wants. Many nights I have spent hacking code that checks what browser is being run and behaves differently because it's Internet Explorer and not "everybody else."
Also, a bit offtopic but I Googled "kinder gentler" in an attempt to understand its meaning and for some reason the first result was the White House page for George Herbert Walker Bush. What the hell?
My work here is dung.
This sounds great, but I feel that by turning HTML into a more well-formed document (i.e., XML instead of SGML), the W3C did browser writers and developers a service. Please, let's not go back to the "guess if there's a closing tag" game. I don't mind the script, frame, module, CSS, encoding, and entity changes, but the custom tags/attributes and looser format limits (quoting, ending tags) seem bad.
ttuttle is a rankmaniac
The problem is that he wants to build applications on top of the HyperText markup language. This means that all "active" things need to be grafted on through scripting and other non-document presentation related cruft.
If what he wants is a better application platform, then that's what he should design. Relying on HTML to fulfill this goal is probably a necessary step, but just as we don't use veronica or gopher anymore, at some point we will ditch HTML for APTL (or some other inscrutable TLA).
The ideas he has are interesting, but his desire to cling to HTML makes him seem more like an old dog trying to learn new tricks rather than a young pup.
The tag form is allowed, but not required for
or
He had me going until this little gem. Sometimes it takes me a little while to spot a joke, sorry.
Sigh. Preview. Preview. PREVIEW! Sorry :(
HTML 5 is strict in the formulation of HTML entities. In the past, some browsers have been too forgiving of malformed entities, exposing users to security exploits. Browsers should not perform heroics to try to make bad content displayable. Such heroics result in security vulnerabilities.
This will clearly have a negative effect on society. When the script kiddies can't "haxxor" anymore, the only alternative is DRUGS! AND DRUGS ARE EVIL!! CRIME WILL SKYROCKET!
I got a catholic block.
Too many people have put too much crap into HTML. Too many people have a stake in each useless tag.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
*waits for 5: Awesome at putting words in bold*
So basically, -1 troll/offtopic is really slashdots way of saying "I hate that you thought of something before me."
I like the getElementsByCSSSelector() idea. Better yet would be a way to change css styles dynamically and have the browser respond. Say if I wanted to change the default color of all "a" tags on a page -- in other words, I want javascript access to the css parse tree just like with the DOM. Correct me if I'm wrong, but I don't think there's an easy way to implement this currently.
Elimination of DOCTYPES in favor of a version attribute to the html tag is just semantics, and kind of silly.
"There is only one scripting language allowed on a page."
That's just arbitrary and short-sighted. His reasoning that it would make things simpler is correct, in the same way that not being allowed to drive makes planning your commute to work simpler, since you can only walk or bike.
If moderation could change anything, it would be illegal.
That sounds like a great idea! I loved everything he said and support it fully. Now all we need to do is formalize it by committee, get Firefox and IE to both support it, get 95% of users to upgrade to the new versions of browsers, and rewrite all of our existing HTML in this new format. Let's get going. :)
Seriously, I'm not sure I even care about HTML 5 in anycase. Currently browser makers still do not fully and equally support what we already have what is the point of adding even more complexity by adding new stuff.
When I can code once ((x)html/javascript-ecma if you like/CSS2) and get exactly the same result in IE 7, FF 2/3, Opera, and Safari then if might be time to talk about adding and changing things.
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
One that eats babies for breakfast, at minimum.
It strikes me that would be the route to go to get rid of all these crappy, poorly done pages.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
That's the best solution I can come up with. The web right now is stagnating under a ton of HTML and JavaScript that has been around since the web began, with very, very little improvement apart from some patchwork Ajax stuff.
Everybody wants to go beyond HTML and create something new and flexible that everyone can feasibly implement, like the early days of the web. Naturally, Microsoft doesn't want to go down this route with IE. Also, people will continue to use what they know will work everywhere - sort of. The legacy counts for a lot, and the Internet Explorer versus everyone else stand-off is keeping things the way they are.
I agree with your point that what matters most to the user community is how major products implement the standards. However, I think that some major problems with the HTML standard involve ambiguities and other such inconsistencies. If there is "room for interpretation" in the standards, and/or they are complex it will have the effect of inconsistent and complex implementations in the major products.
What needs to happen here is that HTML 5 needs to clarify and simplify the standard to remove those places where we define something in relatives instead of concretes. (This also plagues CSS... for a good example, look at table borders/padding/spacing.) I can't tell for sure since the link is down, but based on the summary I'm inferring that Crockford is interested in stregthening the standards through simplication.
WTF!
Kinder and gentler? Jesus, you kids today! We need an HTML that stinks like mace, has sharp barbs all over it, smokes, drinks, hires hookers, opens bottle caps with its teeth and beats the hell out of innocent policemen and then fries them with their own tasers.
-mcgrew
mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
What would the world be without Captain Hook!
It's called Gopher.
Without breaking Slashdot tradition and reading TFA, why not:
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
I'd rather have XAML and a good WYSIWYG editor. I so fcking sick of slinging HTML.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
Don't forget, a compact markup could improve transfer rates too.
This is my sig. There are thousands more, but this one is mine.
Allow a way automatically print out the href as the link text.
If people would just write for standards-conforming browsers (e.g. Opera) instead of ones who blatantly break conformity with standards (e.g. Internet Explorer, Firefox), then coding would be a hell of a lot easier to read.
I RTFA. I was not impressed.
HTML needs fixing.
At the risk of sounding like the geezer that I actually am, they used to say "if it ain't broke, don't fix it." HTML is simple as dirt! If you can't code HTML you need a job at the McBurger Factory.
Since then, the web has grown from a document retrieval system into an application delivery system.
Someone's pants are on too tight. Application delivery, my ass.
If its value is 5, then the following HTML 5 rules apply. If it is 4 or if the attribute is missing, then the HTML 4 rules apply.
I use 1.1. Damned kids, make the <html> tag mandatory. If there's no tag, then everything is rendered as plain text.
There is only one scripting language allowed on a page
Yeah, dumb it down and take away my choices. Just because I don't see any reason for more than one scripting language per page doesn't mean nobody else has a valid reason.
No more framesets, frames, or iframes. The security properties of these were problematic. Instead we'll call them "modules". That will fix the security problems!
The default CSS content needs to be standardized
Yeah, good luck convincing Microsoft to follow standards. In case you haven't heard, there's this organization called the W3C that spells out CSS standards.
The only character encoding permitted in HTML 5 is UTF-8.
See "only one scripting language allowed".
Browsers should not perform heroics to try to make bad content displayable.
That has nothing to do with the server side, but the client side. You're not only going to have to convince Microsoft but everyone else making a browser. Good luck with that, kid.
<empty>? I'm gonna have to look that one up. Sounds like a joke!
Custom HTML tags have always been allowed in HTML. In HTML 5 they become first class.
This has to be the absolutely most retarded slashdot article I've read all month. Now I remember why we're not supposed to RTFA!
-mcgrew
mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
More blithering idiots is just what we need. After all, why should you study basics, then move on to intermediate topics a few years later and finally learn to do things properly from experience? Reading To the Moon in 21 hours is so much simpler!
HTML was never perfect. Then the standards people took too long to update it.
Netscape and then Microsoft added custom HTML.
At this point, the browser became written to execute bad code well...
Now we've got cross-browser headaches and standards confusion.
I say bring on HTML 5, and bring on the strict. Make it look good in both browsers. End the sheer boredom of trying to make code display well on FireFox and IE, both of which are bloated pieces of crap, when it works just fine in Opera.
Simplify, and abstract, but don't expect HTML coders to be coders... it's a language for layout for the rest of us, and its genius has always been its simplicity and adaptability.
technical writing / development
With all the Amazon 'Kindle' hype, did anyone else read this as a 'Kin-der', Gentler HTML?
Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.
it started going downhill when they added POST and GET (yes, that long ago).
"Something else" should have been done for dynamic content.
Now we have all these huge workarounds to make a website like an application.
I love how the first sentence is:
O RLY? HTML is probably the most widely deployed document format in the entire history of computing (after ASCII plaintext, which I'm not sure counts as a "format"). An unknowably huge number of documents are authored in it every day. All but a tiny fraction are successfully retrieved and rendered by millions of clients ranging from dual-core desktop PCs to mobile phones.
It's one thing to say "HTML is ugly" (to which I'd agree) or "HTML needs extending" (I'd agree with that too) but "HTML needs fixing"? Really? Is there anybody in the planet who wants to publish something online today but can't because of problems with HTML?
Read my blog.
I agree that the list reads more like an idiosyncratic gripes list than anything else; I expect more of someone more financially secure than I, and probably a better coder/architect as well. I think the differences between it and HTML4 are so great that a lot of older code will stay out there, mooting his security improvements---more honestly, I'm irritated by the disingenuousness of his 'well, HTML5 is very different from HTML4 ['so far', I'd add] and HTML very different from XHTML"---he's talking about dropping a few tags that have been all over the place for a century in web-years.
As a JavaScript user and (more frequently than I'd wish) developer, I'd intensely miss "javascript:" URIs---I have a bunch of them on my personal toolbar, and find them very useful for simple debugging. Similarly, I'd miss "document.write()", which can be very good for debugging and which never forced anyone to use it...
I don't like the "run all script tags when done with the <head> or <body/> tag enclosing" idea. I like finer control.
Missing?: A decent, simple, "<include/>" mechanism. Sure, the "<module/>" tag would do this, but it does so much more and will probably be shot down...I also don't like the way "<module/>" privileges JSON.
Mobile? The problem is mostly browser incompatability...I _wish_ I could run into trouble running normal desktop browser JS under pIE.
Yet the Yahoo developers keep on trying to tell the rest of the world how to create web sites, or how HTML should look, etc.
The Yahoo developers should first build credibility by getting their own house in order before they try to instruct others how to do their job.
Very, very few people will code by hand. It'll all be done by Blogger and similar stuff with templates. So making it as complicated as possible will create job security for a few and be invisible to others. Just make sure it works. Why can't someone sneak in a tag or javascript that causes IE to dump, thus generating migration away from the standard non-compliance beast?
Precisely the point of XHTML was to SEPARATE SYNTAX FROM MARKUP, so that you don't need to know in advance which tags are closed and which ones aren't.
Someone mod the article lame, please.
I'm not a programmer, and I don't have all day to debug the HTML that I write. I DO have valuable information I'd like to share with you. Keeping HTML error-tolerant and non-programmatic is a benefit to the majority of people, but not to the majority of programmers.
Honestly, HTML is already too fiddly- many people I know who would benefit from putting up their own websites feel too intimidated to learn it. It's unavoidable, I guess, although I wish there was a better free WISIWIG editor out there than the usual choices.
Ideally, it should be all things to all people, of course, but most things generally aren't. XHTML and similar are nightmares for the amateur, and defeat the big-tent notion of the web- a printing press crossed with an encyclopedia crossed with a zine that anyone can edit. An HTML thaThe notion of the web as an application platform is nice, but not nearly as useful or revolutionary.
So I went to read this "proposal", but basically stopped after the first point:
Everyone would love to do this. Unfortunately, not including a doctype throws current day browsers into quirks mode. That is not a workable solution. No one is going to ignore current day browsers, and current day browsers are likely to linger with a significant market share for at least a decade. This is why the WHATWG found the shortest doctype which still triggers standards mode - <!DOCTYPE HTML> (incidentally the only doctype I've ever been able to remember). All of this has been explained endlessly, so why does Crockford blithely ignore it? The people in the WHATWG and W3C know what they're doing - but they have to deal with the real web; no matter how much easier their task would be if they could ignore it like all their criticasters do.
No more doctypes.
.
Doctypes are there to provide extensibility. You can develop a parser that has no understanding of what markup language you're using by as long as it can interpret the doctype it will at least understand what bits of your markup are "code" and which bits are "content". This means a parser built today would work 20 years from now assuming you don't muck things up by doing stupid things like, say, removing the doctype. Now that 20 year old parser won't work because it has no clue what "version X" is because it was built with version 1.
tags do not specify a type or language.
This man needs to read up on his HTML spec. The type attribute exists specifically for this purpose.
Furthermore, limiting web pages to a single scripting language won't actually work. You'll, at the very least, have different versions of ECMAScript. What happens when an old function is discovered to be insecure and removed from a future version? What about backwards compatibility. You don't solve the problem, you're just change the look of the problem.
Also this completely ignores things like Flash, JAVA, and whatever other, future embedded objects people put into their web pages that will also be capable of executing scripts.
No more framesets, frames, or iframes.
Absolutely correct. Good luck pushing the idea. The web is awash in high-profile sites making heavy (ab)use of frames.
Modules
I will hold off on this for now. But the short of it is it may be a bit better than frames, but you're not solving all the security issues frames present. Especially if you want things like current AJAX applications to keep working.
The default CSS content needs to be standardized.
Dead. Fucking. Wrong. The browser should not be driving style. Style is subjective. Everyone has their own opinion. Let everyone make their own opinion a reality rather than forcing yours on everyone else.
Instead the current approach should remain. This is where web developers create their own baseline stylesheet that sets padding and margins and such on block elements and leading/kerning/etc on text elements. The real fix here is to add a pseudoselector to CSS that lets you address all block elements. Something like *:block { margin: 1em 0; } would be perfect. It'd cut down on the size of these "baseline" stylesheets from dozens of lines to only a few. It would also allow stylesheets to grow with HTML as new elements are introduced into the markup. Then a 10 year old stylesheet will still apply those margins to block elements even if the original author had no knowledge that we'd someday have a element.
The only character encoding permitted in HTML 5 is UTF-8.
Nice idea. Problematic with backwards compatibility. But if you do this CSS and any other external text files (Javascript) also has to have UTF-8 encoding. Mixing encoding types will actually break some browsers. The impact this decision would have on other technologies probably hasn't been thought through all the way.
Browsers should not perform heroics to try to make bad content displayable
This is less an issue with HTML and more an issue of browser implementation. Talk to Microsoft, Oracle, Firefox, Apple, etc. about this. Again, this is a backwards compatibility.
The tag form is allowed, but not required for
or
This is not entirely true. First, the empty tag form we know now is a result of the move to XHTML and the need to conform to XML specs. The XHTML 1.0 Transitional doctype allows non-closed tags like and
, but 1.0 Strict and 1.1 do require it, making those unclosed tags invalid.
Custom HTML tags have always been allowed in HTML.
Dead. Fucking. Wrong.
Because when the clever web developer uses to wrap and style data derived from a chart in his webpage he's not thinking 10 years down the road when we do get a real tag, at
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.crockford.com%2Fhtml%2F&charset=(detect+automatically)&doctype=Inline&group=0
He doesn't even terminate his own entities correctly.
While a simple HTML version 5 might seem like a good idea, HTML and AJAX (JavaScript, etc...) are what is wrong with the Internet. Document formats do not make a programming language. They are just a continuation of mainframe (server) control over applications. Even web enabled desktop applications like Google Earth which break out of the stale browsers metaphor tie the end user with a ball and chain to the Internet as they require always on connections to work.
How about fully downloadable and distributed application environment that enables concurrent and collaborative document and information sharing as defined by the web site AND as defined by it's users. Sure many site will want to still be basically documents but many want to break out from the ball and chains of, ick, web browsers.
And don't think that the pathetic Java language is an answer for it isn't for many reasons that are apparent to anyone doing distributed information systems work.
The Web Technologies deployed and in the pipe are Archaic Technologies belonging to an extinction primed era.
What's next? Power to the user. That's what the "Personal Computer" revolution was supposed to be about. Not more power to the mainframe under central control of corporations or others. Personal Computing in an internet age means ditching the notion of servers and moving to a mesh network independent of the control imposed by servers. Sure there will be people wanting to deploy with the current control matrix that web servers give them, if that's what they want to do, but they are missing the revolution - Meshed Personal Computers - that's coming.
Power to the People.
For example. I'd like to visit a site like WikiPedia and download the whole darn site to my Personal Computer and keep it updated (on a schedule that is acceptable to me). That allows me to have a "disconnected internet" experience. Sure I can download it now if I'm a tech guru but it's not really designed for wide spread distributed usage from millions of independent nodes. WikiPedia is designed for control by a few so that they can line their pockets with a nice cash flow and control of ideas. (WikiPedia is notorious for deleting valid content). In any event, distributed technologies are way too democratic for the power hungry since without control you don't have power (unless you enter the world of using weapons where you have power as long as you have ammo and the will or the threat to use it).
HTML sucks big time. All versions of it. Past. Present. Future.
AJAX. ditto.
Web Browsers: FireFox, Explorer, etc.... Take them out back and shoot them please. Send them to bit heaven.
Honestly are HTML authors really that damn stupid and lazy that they can't manage to write compliant XHTML 1.0? Really, people, it ISN'T THAT BAD. Yes, there is a lot of complex stuff and does namespaces and its all modular and things, but you don't need to use all of that! Putting a forward slash in an empty tag and quotes on your attributes and case sensitivity really aren't HUGE burdens on developers. Perhaps we've all gotten too used to IDEs that auto-complete and auto-adjust case and everything else that we've all turned off our brains. It doesn't help that Microsoft (and even Netscape played along in the bad old days) have encouraged the development of crock-o-crap HTML by adding their own bling to standards and resorting to loosey-goosey tag-soup parsing fro so many years.
HTML5 seems to be doing a lot to make sure mediocre developers can stay in their comfort zone and to perpetuate many of the more serious problems we still face today. The HTML5 FAQ makes me cringe in many places!
* "no DOCTYPE. You may include one if you wish, though this is not recommended as they are only relevant when using a validating parser which web browsers do not have." - This is the wrong recommendation and a really stupid rationale. One cannot assume that web browsers will be the only clients to read your document, nor that all clients will lack validating parsers. This saves a small bit of work for lazy HTML authors at the expense of making
* "HTML 5 is being developed with IE compatibility in mind." - This is a backwards way to move forward with proper standards. You design applications towards standards, not standards towards applications. IE is already mostly compatible with existing standards--the solution is to make sure IE8 tows the line, not to bend over for IE developers. In the automation industry, there is a massive, complicated 8-headed beast of a standard called IEC 61158 that is a good example of what happens when applications drive standards. The IEC was somewhat stuck here however because they got into the game late, when all these battling vendor-developed systems were already established. With the Internet, though the situation is not perfect, existing standards hold a fair and increasing amount of influence. I believe the philosophies behind HTML5 don't do enough to prevent the perpetuation of tag soup and loose vendor-driven application of standards.
* "The details are still being worked out, but the plan is to indicate the maturity level on a per-section basis." - This puzzles me: They seem to be abandoning the "modules" approach being sought by XHTML in the interests of simplicity, however it is intended that user-agent developers will be implementing the standard "on a per-section basis" as they figure everything out along the way? And they expect this process to take TWICE AS LONG as XHTML did to establish itself as a ratified standard? I sense a lack of vision here--something along the lines of "lets look at what we've got, put Bondo on the dents and holes then spray it with Tremclad to make it look pretty". Not only that, they've decided that they'll work on the right fender and the left door this year, then the rear bumper next year and so on. There's nothing wrong with incrementally ratifying standards, but how about some VISION and PLANNING? Define some modules and their scopes then set teams upon them to tackle them individually and have them ratified as they reach maturity, and do so in a logical fashion (some sort of "core", then forms, then scripting, etc)
* "Void elements in HTML (the new name for empty elements) do not require a trailing slash...However, due to the widespread attempts to use XHTML 1.0, there are a significant number of pages using the trailing slash"--yet ANOTHER wrong recommendation and faulty reasoning. Lazy HTML authors are annoyed by the slash, but it's been part of XHTML for years so there are a lot of web documents that use it, so HTML5 parsers will have to continue to parse tag soup and do the "guess if there's a closing t
The web has desperately needed a foundation asynchronous protocol to build on; I'm thinking of something like BXXP. Request/Response is so archaic and it's forced developers to find all sorts of hacks to get around that problem.
I swear to God...I swear to God! That is NOT how you treat your human!
Get rid of all those sharp, pointy brackets around tags! Ouch!
"Flyin' in just a sweet place,
Never been known to fail..."
if we should have stuck with image maps :P
Modules: <module> creates a sub-tree which can contain a document with a communication channel These tags are deprecated anyway right? But I think we need to just plain throw them out. A single concept should be able to replace them all. Custom Tags: Custom HTML tags have always been allowed in HTML... They have? What's the point? Somebody help me out here. Is something wrong with <div> and <span> for this purpose?
In some ways, his proposal sounds a bit like XHTML 2. Not so much the details, but the idea of breaking from the existing spec, and trying to simplify things. And to put it bluntly, XHMTL 2 has not exactly been taking the world by storm. It seems that nobody really likes it, so it has not gotten much support. It's unlikely that it will ever make it out of draft status.
Software sucks. Open Source sucks less.
>The only character encoding permitted in HTML 5 is UTF-8.
:)
This one made me Laught Out Loud! C'mon! UTF-8 isn't even near of holding all necessary characters most languages needs! Even for a latin one like Brazilian Portuguese it have some issues, I can't even imagine Chinese
I like the idea of modules being something like PHP's include on client side. But all the rest really is very poor ideas with exception of making html simpler that only seems to happen in his version attribute for html tag.
He seems to forget that html 5 is meatn to be retro-compatible with html 4.
If newer and better tags arise, the old ones (someone still uses blink?) will vanish with the time, thinking into changing html all of a sudden and break compatibility is just a drem, even if a good one.
It's one thing to say "Windows is ugly" (to which I'd agree) or "Windows needs extending" (I'd agree with that too) but "Windows needs fixing"? Really? Is there anybody in the planet who wants to do something online today but can't because of problems with Windows?
pb Reply or e-mail; don't vaguely moderate.
I'm baffled by the concept of advocating a new version of html to get rid of security problems. Web browsers aren't going to break compatibility with old versions of html. What good does it do you if your browser supports secure html, but also supports insecure html? The vast majority of the security problems on the web are problems that are specific to IE+Win, because Windows's security model has problems, and security has never been a priority for the IE maintainers. None of that is going to change if you just invent a new version of html. Also, many of the security problems in IE+Win have historically been because of proprietary extensions that MS introduced. If MS shoots itself in the foot by not following standards, then I don't see how a new standard is going to help.
Another problem with the proposal is that it's a dead end when it comes to new functionality like SVG and MathML. These are xml-based standards, and there is no standards-based way to implement them in html; they have to be implemented in xhtml, or else they have to be implemented in a nonstandard way. Today, if you want to write a web page with mathml in it, and you want it to degrade in a sensible way in versions of IE that don't have the relevant plugin (i.e., 85% of all browsers out there), the choices aren't pretty; basically you either have to serve up multiple versions of your page, or you have to do incredibly kludgy tricks with xslt, or you have to do incredibly complicated stuff with javascript. The fundamental problem is that html has forked into html and xhtml, IE doesn't support application/xhtml+xml and probably never will, and xhtml is the only sensible way to incorporate new technology like SVG and MathML.
Find free books.
I whined about cross-browser compatibility chaos before, but it got ignored because I both slam Firefox and fail to really praise IE. Since I've been using Opera, I'm happier, although it could still use some work. Reminds me of the Dilbert cartoon where a rat's random typing becomes browser code.
The end result is that we waste a lot of time and generate thicker, uglier code. HTML became the standard because it was easily created, could link up with just about anything, and was a great lingua franca intermediate format. (It makes me feel weird to say this, but I think of the English language in much the same way.)
What's intriguing about HTML 5 is that it goes back to the original model of HTML, which was what made it successful in the first place, before much meddling occurred. I also agree with the other guy who replied that some things like flash and vector graphics need their own, embeddable standards.
technical writing / development
HTML can be made into a general application delivery format without disrupting its original role as a document format.'"
Trying to turn HTML into an application delivery format is a brain-dead idea from the get go. Here's a thought: let's use HTML as a document and hypermedia format, and turn to application specific protocols for delivering applications?
// TODO: Insert Cool Sig
Make every charset of everything on the planet use UTF-32 and stop whinning. This charset issue has been there forever and sucks.
We shall only replace UTF-32 when aliens come up with a new alphabet if we cannot make it fit. goddamnit!
well lets be realistic. The only encodings that should be useable ANYWHERE (html, apps, etc..) should be:
UTF-8 (note: IT IS 100% ASCII COMPATIBLE)
UTF-16
UTF-32
since UTF-16/32 are just wasting space for most languages.
...or at least will play a much less significant role in the future.
As a document format, HTML is great... for example, I throw in a few tags in this forum to create bold, italics, links, etc. Throw in tables and images an you can create a very nice looking article for the web.
However, there is a huge difference between "documents" which can be read in various different monitor/browser sizes, fonts, and languages and what a majority of paid developers do with HTML within corporations. That being creating pixel perfect applications that work in one particular browser (IE or Firefox).
To that end, what we need isn't yet another HTML specification which will make the browsers even that much more bloated and incompatible with each other... it is an application framework for the web. In fact, this is what Adobe and Microsoft are creating with Flex/AIR and Silverlight, respectively. Ultimately, the "markup language" of the future will be dynamically created and compiled on the server and sent to the browser in a binary format which is run by a plug-in.
Therefore, I believe HTML should evolve into what is started out as... a DOCUMENT format. It should really move towards a light-weight Open Document specification, NOT towards something that attempts to embody "Web 2.0" features which are already evolving well beyond dated HTML specifications that are nearly a decade old.
programming myself into obsolescence
I guess you may as well, it's not very long, but know that it's a waste of a few moments. The author seems tired of training new developers, and so wants to change HTML to achieve two primary goals:
1 use fewer characters by eliminating robustness (one attribute instead of a whole doctype, one meta tag instead of specifying each script language)
2 eliminate features that tend to lead to vulnerabilities
The author forgets, doesn't know, or doesn't realize, or doesn't care that each of these things translates into real power when one uses them correctly. He also doesn't understand that if you allow for dummer developers, there will be more exploits not fewer.
He outright eliminates document.write and frames saying that they are insecure. And he outright says that frames are to be rebuilt into modules. Sir, I'm glad that you have devised solutions to your struggles, but please do not push them onto the rest of us who enjoy certain levels of power through the use of multiple script languages and weird frame power.
Incidentally, for your education Sir, I think you've forgotten a very import part of programming and computers in general. You can't simply say that all web pages should be in UTF-8. First, good job thinking that UTF-8 is the last ultimate character set. Second, good job completely destroying every existing page out there. Third, good job making every single english-only page twice the size it needs to be. You've eliminated optimization completely. I'd have rather gone the other way and allowed the developer to define a character set -- I don't know, maybe through the doctype that you've blown away.
Meanwhile, you haven't added the one thing that I've been wanting ever since IE kind of lost it -- embedded fonts. A quick and easy way to eliminate 95% of graphics used to present navigation text and teeny tiny little wingding icons.
I've got no problem making things easy by granting additional power, or abstracting power to developers. But to eliminate complexity with the goal of eliminating features is just, well, it smacks of someone who's never managed to find a use for that power.
Having built HTA applications that flex three script languages, javascript domains, and at least a dozen iframes on each "page", I can say for certain that your changes (i.e. restrictions) would have rendered my applications impossible to build.
All of that said, I can't argue with making custom tags and attributes first class, except to say that it would be nice if FireFox supported custom (read expando) attributes in the first place, and that custom tags and custom attributes would be a much greater source of vulnerabilities due to parsing errors than incomplete attributes ever were.
W3C has already deprecated quite a bit of the mess from HTML 4 that mixed up the presentation with the structure, and HTML 5 aims to make that distinction more clear than ever, and make more sense with more "natural" tags for the page structure. I don't see HTML being very complex now at all, with so much of the presentation having been moved to CSS.
What most editors still generate and lots you see on the web is actually deprecated stuff. Things like FONT tags and color attributes for whatever.
A page that don't use scripts or such things like deprecated page design methodologies look very clean to me already, and a HTML 5 page will thanks to the more natural tags introduced for structure will probably be even more human readable and understandable.
Beware: In C++, your friends can see your privates!
That's a little presumptuous, to put it mildly. I've been using JavaScript Object Notation to store data for JavaScript programs for quite a few years now, and I just heard of this guy today. What am I missing? The inventor of JavaScript Object Notation is the guy who created the JavaScript syntax.
Do you have ESP?
Sounds like you want Jquery. I've only been using it for a few weeks (I've been working on the Drigg javascript), but it's pretty damned cool.
.someclass').removeClass('someclass');
For instance, to remove a particular class from all <p> elements:
$('p
To send each element through a javascript function:
$('.someotherclass').each( functionName );
You use CSS-like selectors to target actions.
If you add a class to an element, the browser correctly[1] displays the element with the new class applied. Remove a class, and the style associated with that class is removed from the element. It all behaves exactly as you asked. It's easy. It's intuitive, especially for folks familiar with both the DOM and CSS.
I have no association with Jquery. I just started using their library a couple of weeks ago. I've just been very impressed with their library, so thought I'd spread the Gospel to one who seeks.
[1] Except for IE 6, at least. There's a huge-ass bug in IE 6 multiple-class handling, such that multiple-class CSS selectors ('.class1.class2') don't work. Check out this writeup for more information.
Microsoft is to software what Budweiser is to beer.
Another catch is that the evolving of HTML into XHTML may be with good intentions but the end result is that it's no longer an easy world to work in. That means that HTML still should evolve in it's own right. However there are a few features that I really would like to see in future HTML versions:
- Consistent tag handling where all tags shall have start and stop tagging as XHTML has. It will make things more consistent.
- HTML may keep it's case insensitive tags - that's no big issue.
- Look into a few new input tag types, the ones that exists aren't bad but sometimes there would be benefit from a <select> tag that also allows the user to manually input a value, which is impossible today unless you insert a special component to handle that feature.
- A certification test program for web browsers wouldn't really hurt. There is the Acid2 test and a few others, but a more comprehensive test wouldn't hurt.
Aside from the fact that HTML may need a few new features it's actually relatively good, healthy and kicking.Another web feature that needs an overhaul is the scripting. JavaScript is in some ways good, but it's also very bad since it isn't type-safe. It is however a lot better than VBscript which is something that we got for our sins and binds the functionality to the Microsoft world only. So what we have are two solutions; One half-baked, namely JavaScript and one completely sticky and messy, VBScript.
So much for rants and flames...
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
All I'm asking is that an anchor display the href to the user without having to type it in.
The only way to make a language simpler is to remove flexibility. HTML can be a bear to manipulate and get what you want out of it, and it requires a little knowledge, but if you remove that flexibility by making it simpler, you also remove the ability to make it do what you want.
No one ever said HTML was for everyone or supposed to be easy to do correctly. If you don't want to learn HTML, use a WYSIWYG editor, don't dumb down the spec...
-AC
really, if you want to make a good XML based application language that's easier to Do Stuff In , i don't see why you'd beat the tired old html horse. move on.
CS majors know the time/space tradeoff, but they never get taught the 3rd, crucial, tradeoff of the set: comprehension!
Please send the IE devs a picture book with the full specs in very clear English.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
He introduces the idea of relaxing br and hr to accept the ambiguous empty form (which doesn't distinguish an empty tag from an unclosed tag error). Then he wraps up his discussion with the statement: These changes significantly improve the reliability, security, and performance of HTML applications. I can see the merit of reducing the punctuation mark clutter on a couple of extremely common and "well known" (in the IANA sense) empty tags. But this constitutes an exception that introduces a new ambiguity to document parsing for the sake of removing a single punctuation mark whose insertion either by humans or in the application context is purely automatic. Where precisely is the simplicity in that trade-off?
I would not be opposed to introducing the concept of relaxed validation in which well-known empty tags are presumed to be self-closing. Any instance of a presumed self-closing tag used as an end-tag would fail relaxed validation (make up your mind, and stick to it). Relaxed validation could be allowed on the basis that translation to strong validation is purely mechanical.
My opinion is that anyone who makes the bare statement X simplifies Y is up to no good. The properly motivated form is: X simplifies Y for the sake of A at the expense of B. But then simplicity doesn't seem simple any more, and that defeats the purpose of vending the snake oil in the first place, to position oneself as the bearer of light and goodness, whose stock price is very high lately.
After writing this sans RSI entities, I discovered that ecode appears to function as a kind of nowiki with autoquote plus font change: Slash doesn't even provide a hyperlink to a description of the allowed HTML. Shamed by Wikipedia. How low can you go?
"JSON" refers to strings of JavaScript source, which are essentially S-expressions, used for marshalling data for transmission. It's promoted as an alternative to XML, because parsing XML in Javascript requires shipping an XML parser in Javascript along with the web page.
The trouble with this idea is that Javascript has the wrong primitives for this operation. In LISP, there's the "reader", which turns a character string into an S-expression, and "eval", which executes an S-expression. JavaScript combines those two functions into "eval", which takes in a string and runs it as a program. Uh oh. Big security hole there.
So the JSON crowd has to provide "firewalls", written in Javascript, which look at the string to be executed before running it. Some of these "firewalls" almost work. Some don't. Ones that work more reliably are complicated, like XML parsers. So, overall, JSON didn't turn out to be a win over XML.
If JavaScript had a built-in "reader" like LISP, a parser that just produced a linked structure as output but didn't do anything more, the JSON idea would work better.
Maybe the whole thing needs to be rethought from the ground up. What do we use web browsers for nowadays anyhow? I see the following...
.NET-type language (maybe even compiled to bytecode) is a better way to go. The key is to integrate this together at all levels, not the current patchwork of embedded client-side or server-side scripts. Make the development process simulate the same steps one goes through to create a native application instead.
1. Displaying mixed text/image documents. HTML sucks for laying these out.
2. Filling in forms and database interaction.
3. "Online" applications.
It seems to me that using a "markup" language doesn't meet any of these goals well. The onscreen (and printable) views would be much better in something similar to Postsrcipt, forms would be better as something akin to an MS Access, and online apps require a way to either remotely display the app on the client and interact, or download an applet of some sort that synchronizes with the server.
I'd say creating a standardized VM that displays Postscript and uses a Java or
Right now, when making a web app, I have to create PHP scripts that generate SQL queries, crunch the data, and then output HTML and possibly client-side Javascript. What a pain in the ass - there's at least 3 languages involved and really the whole thing is a mother to debug.
There seem to be some common misconceptions in the posts here (yeah i know it's slashdot)
.. THANK YOU!!! If I see one more bloody document in the DOCTYPE telling me it's an ISO8859 and then having the MS-Word back/forward tickets embedded in the middle then I might pull out a gun and start shooting people. I'm not a violent person.
.. those marketing depts. love to fear monger.
.. a two pass filter (similar to the quirks mode employed today in most browsers).
DOCTYPES:
Doctypes aren't implemented correctly on probably 98% of the documents on the web because none of noob web designers fucking understand them - so anything 20 years from now won't be able to trust them, we might as well eliminate them and replace them a simple version #.
UTF8: YES YES YES!!! OMFG
LEGACY SUPPORT + FRAMES/IFRAMES:
I agree browsers aren't going to drop fields like iFrames, etc. BUT as an administrator I could turn it off for my clueless users who might be mislead, hurrah! I have no problem if they can't access their mutual funds/bank account from company computers. I might turn it off for my parents so they don't get h4xx0r3d, eventually norton and mcafee can warn people who are visiting sites using pre version 5 that it is "less safe"
LEGACY SUPPORT = "Not more secure"
Not true -- first off HTML 5 only can be an option if users need to access a subset of intranet sites. I think marketing HTML 5 as "simple, more secure" might get CIO types to mandate more use of it in their organizations.
Furthermore older browsers could (when possible) use a translation engine to convert HTML 4 to HTML 5
Keeping the ecma-script + dom engine further from the "quirky" content makes a ton of sense to me. Anybody who doesn't believe that separating phases adds security need only look at apps like Qmail, etc.
RE: HTML IS NOT BROKEN
HTML 1.0, 2.0 were easy to learn - and THEY are the reason HTML is successful. Anybody could pick up a book and in a few hours be building HTML pages.
HTML 4.0 / XHTML was clearly defined by a committee of people who don't actually work in the "real" world try to support users.
The more complicated you make it, the less people can/will use it. I realize slashdot does not necessarily cater to that audience, but most people think they are dumb and don't like learning/a challenge -- and I personally hate troubleshooting their X-HTML documents.
NEED PROOF HTML IS BROKEN = LEARN WIKI:
The reason we see so many systems switching to WIKI content management versus HTML is because of all the issues and learning curve associated with HTML, and how easy it is to break HTML.
In fact the majority of the new original **content** being added to the web these days is probably in WIKI simply because HTML is broken.
You have to admit that nobody would have invented WIKI if we were still using HTML v1 or v2.
Just the fact that HTML5 makes XML compliance optional is enough to keep me away from it. Never mind the bloated tag set and the inconsistent return of presentational tags.
I hope the author speaks of HTML in a generic sense. HTML4 has long since been deprecated, but is still in use because some developers can't be bothered to upgrade their skills, or they don't really have any skill at all because they're incapable of writing markup by hand (I call them Dreamweaver monkeys). XHTML is the now, and XHTML2 should be the future.
Most web developers are self taught... if they have any formal training, it's on tools^H^H^H^H^Hcrutches such as Dreamweaver or graphics software (Photoshop, Fireworks, or god forbid, Flash). It depends on the developer's level of interest in their skills as to how capable they are. There's no training available for the less concrete, but more important topics such as usability, accessibility, or semantics.
The guy doesn't even follow his own rules in his examples; he says which characters are allowed to be in parameter value strings that are not quoted, and the slash (/) isn't one of them; yet, in his example code, he includes some unquoted strings that include slashes. Thus, he seems to be proposing a new version of the same ill-defined tag soup that is already in wide use.
--Dan
Web Tips
is that, most of the time, they're an awful workaround for an awful defficiency: Lack of Client side includes.
/>
Part of my proposal is having a friggin' INCLUDE tag which would save tons of problems and bandwidth.
<include href="heregoesthemenu.html"
For simplicity, the include tag cannot include unbalanced html, but it will generate a DOM subtree.
There ya go. Ta-da!
The Open Group and Posix/Single Unix Specification could be an inspiration on how to approach this (although OpenGroup didn't implement properly with Unix either).
The W3C should do the following:
- Trademark "Web Browser", "HTML-5", "CSS-3", and get Sun to donate the "JavaScript" trademark
- Provide a free-gratis MIT, BSD, or public domain licensed reference implementation of html/css rendering and javascript engines
- Provide a free-gratis browser test suite focusing on standards and consistancy of rendering. Any proprietary extensions automatically will be cause for failure
- Browsers that pass the test suite can be licensed to be labled a "Web Browser" and "HTML5/CSS3/Javascript Ready"
- Launch public campaign of scorn and shame to get non-complient "unlicensed" browsers shunned.
Properly implemented and administered, that would end fragmentation. Focus should be on consistancy of rendering, not golly-gee-whiz features. What is actually in the standard is less important than that everybody renders it the same.His first suggestion is eliminate doctype in favor of an element attribute. His second suggestion is eliminating the element language attribute in favor of a meta element. It seems to me this is moving in two different directions. If your goal is to simplify things, be consistent!
No more document.write. No more in-page event handlers. No more javascript: urls. First off, why don't you have the browser sandbox things if it wants to? Creating a new language doesn't seems like a good approach to me. Second, no more in-page event handlers? Seriously, they're the quickest and easiest way to handle some things, why would you get rid of them?(Let the browser sandbox if you want, you can always modify your js settings if you want to as well)
The only character encoding permitted in HTML 5 is UTF-8. Yet again, i see no reason as to why to not let the browser do what it wants and keep UTF-8 as default, and the others deprecated.
That's just my opinion, of course I'm also a fan of an interpreted binary file for web pages. I also think that most of the security should be done at a browser level, sand boxing the developer isn't the way to go for security. All in all i really don't see too much interesting in his proposition, modules are maybe the only thing of value in his proposal, but that kind of behavior can already be emulated by javascript with DIV blocks or parent/child windows.
If i had one dollar for every brain you dont have, i would have $1.
Try this instead of getElementsBySelector(): http://jquery.com/. .some_class').get() [/code] would do the trick.
[code] var element = $('#some_id
Not to mention the other really usefully things that you can do other than ".get()"
Babies are responsible for all those pages?!? *stares at baby* I'm watching you...
"Get in my belly"!
What mods modded this a troll? Surely not mods that have any experience building public facing websites.
For years I've seen WC3 this WC3 that. And what does it do? Except create "standards" that are ignored or partially implemented by the browsers. And the browsers are what matters. WC3 might as well not exist. They keep moving forward, and the people that matter are not listening.
Yes.
Well, neither would I, but then again, people that want total control in the hands of a graphic designer usually seem to want something like that. OTOH, XSL:FO was designed to handle use cases where you have multiple pages (as would be the case for paged media, either print or slideshow) or where a document is laid out on a single page whose size is known only to the renderer (as would be typical in a web browser). Quoting from part of the XSL 1.1 spec discussing pages in FOs:
Its just that its apparently a lot more work to implement than CSS, and so its mostly only been implemented in print (or at least print-like, e.g., PDF generation) applications, rather than browsers, where (the complaints registered here, aside), CSS does well-enough for most uses. Early on, there were some proof-of-concept limited-functionality XSL:FO browsers, but FO support hasn't (yet, at least) made it into mainstream browsers, and AFAICT those early efforts were all abandoned.
>>> "something that is actually useful to graphic designers."
:0p>
Don't worry, drop-shadows and rounded corners are coming in CSS3.
You can already have lots of shades of grey with text that's minimally contrasting and too small to read alongside completely unrelated images of flowers or girls smiling or something.
tags can:
have begin and end tag.
stuff
be a single self-ended tag.
but, what I would like is a auto ending tags,
that are auto-ended with the same tag at the same level, or ended with an eneded parent tag.
item 1
item 1
item 1
yes, I realize that some tags in html1 were auto-ended, but It would be nice to have a legal way to do that in xml.
the simplification of HTML he is proposing would reduce the cost of training of web developers
How much, exactly, does it cost to train a chimpanzee these days? Must be approaching what it costs to train a QA tester.
The problem with all these "lets improve on HTML" concepts is that they dont improve much on anything. They take whats already widely adopted and works well, and make things more convaluted.
Its loosely analagous to people constantly thinking they must create a new Coca Cola to replace the original because the original just isnt good enough. Or how about Fords constant belief they had to improve on the Mustang until they realized they fucked it up so bad they needed to return to the original.
Programmers and analysts constantly thinking they must improve on something until they fuck it up so bad its not worth the pain and effort to use anymore.
CSS is powerful, but its a lot easier and faster doing a layout etc from one html page in the old tables and tag days. I know this sounds crazy but its true. The whole seperating display code from logic is good, but CSS and html both define display. And the constant flipping back and forth between external CSS and html, testing display gets annoying. It reminds me of the difference between creating fancy layouts for invoices or labels for print jobs on UNIX using PCL code never able to see the display as its created versus say formatting the fancy label layout in a nice GUI application.
We are being forced to use display code as defined by command line type of people. Stick with the logical language, stop messing with trying to change the way we define "display" with display code like html.
Oh boy Zen Garden.
Lets see 1999, apply background images to tables.
2007 wow look at fancy css layouts: Apply blocky fancy background images to divs.
Whoope doo.
SGML (the ancestor of HTML) is a *MARKUP LANGUAGE* (the "ML" in "SGML"). HTML is an acronym for Hyper Text Markup Language. It was originally written for text terminals of different widths. The original HTML pages never assumed that everybody had an identical screen. Early HTML only tried to control *GROUPING* of text (breaks, lists, etc). It assumed that *YOUR* browser would wrap the text to fit *YOUR* screen. It was *NOT* intended for "This page is best viewed with IE 3.1415926 on an 800x600 display with at least 32 colour display".
Then along came the "layout" freaks. This one is dedicated to all those "modern electronic media" who can't seem to throw off the shackles of Gutenburg. You know who you are...
Attention all
anal-retentive
control-freak,
layout editor
refugees from
19th century
newspapers. The
web is *NOT*,
repeat, *NOT* a
newspaper. A
PC monitor is
wider than it's
tall. Standard
newspaper-type
column format
totally sucks
when viewed on
PC monitors.
I use 1920X1280
display and get
1/6th of screen
for left panel,
1/6th for the
actual printed
column, 1/6th
for the right
panel. *THE
ENTIRE RIGHT
HALF OF THE
SCREEN IS 100%
BLANK*.
And of course
I then have to
scroll, scroll,
scroll to read
an item that
should easily
fit onto one
screen.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
While some of this guy's recommendations I can agree with, other comments he says makes me wonder if he knows anything about what he's talking about, even with his credentials. For instance, I've been working day-in and day-out over the last several months with character set encodings for HTML, et al., and his comments about only using UTF-8 is...well, naive. Sure, I adore UTF-8, but it is definitely NOT the be-all, end-all of encodings, and it is not very hard to deal with them. And then he says all the problems can be solved with gzip...RIIIIIGHT. (It's not JUST about content-length.) Encoding in HTML is just fine the way it is now. (Although, defaulting to UTF-8 rather than Latin-1 would be nice, but that's an HTTP standard, not HTML.) That's not the only recommendation he makes that's got problems. Frankly, I like where WhatWG's recommendations for HTML 5 are going. THOSE recommendations are made by a group of people who have been working on REAL problems. That's not to say that some of these suggestions aren't worth considering for HTML 5, and many are definitely needed, but...they are by no means all of the same calibur. Especially not the encoding one :P
HTML can be made into a general application delivery format without disrupting its original role as a document format.
Fuck no.
We need more, simplified thinking like this. The feature and tag bloat that is HTML now needs to be slimmed down, and bad. It seems a lof people who read the (yes, short, thank god) proposal neglected to read the part about custom tags and attributes: this is how we solve the problem of semantics. We can use microformats with real, custom tags. Regarding security, the iFrame/Frameset model can be maintained for backwards compatibility when serving version=4 documents, and the "module" tag (needs a better name IMHO) can use the message queue methodology he proposes. Most of the structural complexity can now simply be expressed with simple heirarchy. The only major change I'd add to his proposed spec is removal of all the crazy bloat-tags made redundant by CSS (HTML 5 proposes only removing about 8 tags!)
Thinkingman.com New Media
Accidentally left out:encodings should probably be limited to UTF-8. No matter what people say, having to deal with a bazillion different encodings over the last twenty years has made me itch to throw the rest out the freakin' window. I don't want to have to guess every five seconds which encoding we're using now as opposed to then - did the user's agent really just try to paste in BIG-5 encoding into our Latin1 charset? Was the UTF-8 incorrectly served as a MacRoman document? Etc etc etc...
Thinkingman.com New Media