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
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
There is probably some irony in the fact that inter-document communications feature in HTML 5 would allow him to implement his "module" concept in an HTML 5 compliant browser. In fact, the HTML 5 proposal is actually superior to his "module" proposal in the method it uses to receive messages. Rather than polling for a JSON packet (which could be costly in both processor time and responsiveness), the HTML 5 solution adapts the existing DOM 2 event model to make the messaging smooth, seamless, and fast.
Javascript + Nintendo DSi = DSiCade
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.
*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."
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. :)
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).
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
This is very possible. Has been for quite a while. http://www.quirksmode.org/dom/classchange.html
What would the world be without Captain Hook!
I think it's kind of self-defeating. On one hand he advocates custom-tag creation, then he advocates elements by tag selector. Encouraging one or the other is fine. But offering both will only confuse developers and undermine both options. Going with custom tags is probably the better solution as it encapsulates the semantic information a programmer would be looking for while still being unique enough to style with CSS.
That being said, if you really want that feature try this script:
http://simonwillison.net/2003/Mar/25/getElementsBySelector/
I think you want to read the DOM Level 2 Style Specification. The short answer is: Yes, the CSS is accessible through DOM APIs. The long answer involves lots of shouting and complaining about Microsoft and their stranglehold on the market.
Javascript + Nintendo DSi = DSiCade
Without breaking Slashdot tradition and reading TFA, why not:
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
It's called NeWS, and it's quite old. As you can see, What's Old is NeWS Again.
Javascript + Nintendo DSi = DSiCade
Don't forget, a compact markup could improve transfer rates too.
This is my sig. There are thousands more, but this one is mine.
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
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.
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.
Erm, you do realize DOCTYPE was in original HTML draft published in 1993, before the W3C existed and almost five years before XML existed, right?
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
Get rid of all those sharp, pointy brackets around tags! Ouch!
"Flyin' in just a sweet place,
Never been known to fail..."
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.
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.
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
...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
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?
You, and the AC below, don't appear to know what UTF-8 means. UTF-8 != 255 codepoints. Please read this page and this page.
"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.