Is It Time for a 'Kinder, Gentler HTML'? 382
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.'"
Not Impressed (Score:5, Insightful)
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.
"Kinder Gentler," What the Hell Is That? (Score:4, Insightful)
From the part of the proposal entitled "That's It" I learn:
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 [google.com] and for some reason the first result was the White House page for George Herbert Walker Bush. What the hell?
I love it (Score:2, Insightful)
Re:"Kinder Gentler," What the Hell Is That? (Score:3, Insightful)
Re:The erosion of society (Score:3, Insightful)
It's the browser's fault not the HTML standards fault. And it will never go away unless all of them do away with it at once? Why, because then little Johnny, who messes up a website and only tests it in IE (for example) will see that it works for IE, not FF, not understand why, and reintroduce those crappy "looks best in IE" stickers.
Re:"Kinder Gentler," What the Hell Is That? (Score:3, Insightful)
Easy to use. Forgiving.
Compare YAML (and JSON) to XML, S-Expressions, or (shudder) HTML. YAML's syntax can be stated clearly in about 20 lines of text. JSON's syntax is a subset of that. And yet, YAML is very forgiving. XML requires dozens (or is it hundreds) of pages. HTML requires waaaay more. S-Exps have a nice syntax, but are not forgiving. It uses many parentheses and can grow to become difficult to read. I know which I would rather work with.
Speed (Score:2, Insightful)
Re:"Kinder Gentler," What the Hell Is That? (Score:3, Insightful)
You know, it's fun to finish a javascript method in Firefox with Firebug there to help you debug and step through it. You think it's fun to watch IE bitch about only God knows what and not work. Or simply not show anything at all if you're trying to evoke a method on a javascript object that isn't valid. No feedback, just
Keep your mouth shut about karma whoring unless you have had to suffer through this stuff. I'll post this anonymously to prove I don't give a damn about karma when I know what it's like to have to deal with that shit day after day. I have a job to do, I put in overtime I'm not paid for and a lot of the time it's so I make the schedule work. Almost every single time I have had to devote time specifically for IE and it's bullshit "do whatever we want" mentality. There are standards out there that make sense. Please, for the love of God, use them. I'd rather be using my time doing something productive than thinking about a round about hack to fix a problem--that I already have a solution for--and it often just looks ugly and is barely maintainable.
I must be new here (Score:1, Insightful)
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
Market forces screwed up HTML (Score:4, Insightful)
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.
Ain't broken (Score:3, Insightful)
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?
Re:Not Impressed (Score:3, Insightful)
What's wrong with that? They shouldn't be trying to shoehorn features into HTML that aren't in line with its purpose, marking up hyper text. If you want a rich, network capable, multimedia enabled application framework, write one! Don't ruin my HTML.
Re:Not Impressed (Score:3, Insightful)
Very simple.
"Let's get rid of HTML features that I believe cause problems."
Is not the same as:
"These HTML features have been empirically shown to cause more problems than they solve. Deprecating them will therefore improve the quality of the standard."
Re:Not Impressed (Score:4, Insightful)
Yet, if I was involved in the HTML5 drafts I'd be insulted. He does dismiss an actual complete design (HTML5), in favor of few vague niceties and abstract wishes that don't change the big picture even a bit.
Does it really matter so much if we'll use DOCTYPE or version="5" attribute to specify the document type?
HTML5 is trying to prepare the web to handle robust web applications, and he's there dissing it and saying "let's instead just drop some legacy features, put some syntactic sugar on it and call it a day".
Re:Not Impressed (Score:3, Insightful)
security; xml (Score:3, Insightful)
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.
Hell No (Score:3, Insightful)
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?
UTF8 (Score:1, Insightful)
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.
HTML is DEAD (Score:3, Insightful)
...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 [slashdot.org], 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 [wikipedia.org] 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.
Re:Not Impressed (Score:2, Insightful)
Re:Not Impressed (Score:2, Insightful)
Honestly, everything in the web is getting bloated. ECMA Script 4 is bloated, HTML 5 is bloated, browsers are bloated (call me crazy, but even Opera is bloated for my tastes). I agree with Doug. Let's make the web a safer and easier place to work. Whether or not his suggestions are the best solution is up for debate, but the idea to get rid of bloat and make web programmer's (aka. my) job easier can only be good.
Now for some real fun. JSON vs XML... go!
Re:AHAHAHA (This guy is a joke) (Score:2, Insightful)
And JSON was a really stupid idea (Score:3, Insightful)
"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.
Or just start over (Score:3, Insightful)
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.
Re:Not Impressed (Score:4, Insightful)
"[R]eads this and gets upset". Again, who is he talking about? This hardly sounds "upset":
?
Here's an amazing answer for you: Each has its advantages and disadvantages. Evaluate your project needs before choosing a solution.
Seriously, you mods need to lay off the crack. Or at least share with the rest of us.
Re:Kinder? Gentler? (Score:2, Insightful)
Sure, more people are aware of other browsers like FireFox and OS's like Ubuntu that have it installed by default, but until it stops being an MS/IE world, all the standards documents in the world won't make a difference. Unless of course, Microsoft tries to get it's "html standard" defined as a standard. Which I'm surprised they haven't done this already.
Re:Not Impressed (Score:4, Insightful)
The "controversy" about Han unification is inane nationalistic posturing on the part of those Asian nations; it has no basis in either linguistics or practice. It's as if every European nation wanted their own codes for the Roman alphabet.
Start mandating UTF-8 and you're going to have people breaking the standard in favor of national charsets faster than you can say "cultural imperialist."
"Han unification" is not "cultural imperialism", it's simply applying the same design principles to Chinese characters that were applied to other languages. People object to Han unification for a variety of reasons, most of them related to nationalism, arrogance, or simply ignorance. For example, there are lingering animosities between Japan and China. And many traditionalists in Asia think of the West as inferior and would have found grounds for objecting to any character set not designed domestically.
The technically correct thing to do is to keep Han unification, just like all other scripts are unified, and address problems with specific glyphs as they come up.
Re:Not Impressed (Score:4, Insightful)
No, it is not. Unicode was developed by an international group of experts, including plenty of participants from Asia. It represents a reasonable and practical compromise between lots of different design goals. Everybody had to make some sacrifices there. People like you are just trying to rattle people's cages by turning a technical issue into a nationalistic one. "GB 18030" is a China-centric standard, Unicode is a global and neutral standard.
Furthermore, to the degree that there are problems with Unicode and Asian languages, the way to address them is to fix Unicode, not for each Asian nation to fall back to some national character set.
Of course, there are plenty of political and economic incentives for nations like China and Japan to try to have their own national character sets; hopefully, organizations like the UN and WTO will recognize this for what it is: attempts at content control and attempts at erecting illegal trade barriers, and deal with it accordingly.