Slashdot Mirror
Stop Standardizing HTML
pfignaux writes with an interesting view on the place of centralized standardization in modern browsers. From the article: "When HTML first appeared, it offered a coherent if limited vocabulary for sharing content on the newly created World Wide Web. Today, after HTML has handed off most of its actual work to other specifications, it's time to stop worrying about this central core and let developers choose their own markup vocabularies and processing."
Instead, the author proposes that CSS, Javascript+DOM, the W3C's accessibility framework, and Web Components are sufficient to implement the rendering of smaller, domain-specific markups.
How about "no"?
There is also a benefit to having people share a common vocabulary, such as communication in broader languages like English, Spanish, etc. I have a hard enough time communicating with people in the same language!
Some people die at 25 and aren't buried until 75. -Benjamin Franklin
Stop making our job skills transferable!
Your courageous and selfless spelling corrections have made me a better person.
If you break the html standard... each browser will interpret things even more differently than they already do. This means you now have to give a crap about what browser the visitor of your site is using, because the developers went off and did their own thing. I'm glad the author found some toys he likes... but this hardly makes an html standard useless. For example, what does this do for tomcat? What does this do for ASP.NET? The answer is nothing.
<_MSIE_XZ92 MS_FONT_TP = "comic sans" Q_BINARY_BLOB = "89FF372198A" BRWSR_FOO_P = "unidiv/flimblargle">Great idea!</_MSIE_XZ92>
This post optimized for viewing with with MSIE 9.3.
The web worked when it had a simple standard that worked in every situation.
We've put layers on top of that, and now it's chaos. A bloated, irregular, often incomprehensible chaos designed to allow people to make custom interfaces out of the web.
The whole point of the web, versus having an application for every specific task (like we did on desktops before the 1990s, and like we now do on smartphones), was to have a standard and simplified interface.
The web grew and thrived under that goal. It's become more corporate, nuanced, isolated, sealed-off, etc. under our "new" way.
HTML needs an active companion language, an actual programming language, one that will replace the disparate third-party technologies in use today. Just eliminating Flash and Javascript for example would eliminate a vast majority of the world's browsing headaches.
I agree!
I shall call this new language "Jscript"!
-Bill
You ask for a companion programming language and at the same time propose eliminating Javascript. I see a contradiction in there.
CSS, HTML and JavaScript need to be standardized and built to work together. If you want to add your own libraries on then that is fine but I run into so many issues with different browsers handling my scripts differently, this is 100% due to nothing being standardized. I shouldn't have to use special operators or libraries to create the effects I want / need.
Just eliminating Flash and Javascript for example would eliminate a vast majority of the world's browsing headaches.
If you know of a language that will do what Flash and Javascript will do with no headaches, please share it with us.
The cow says "Moo." The dog says "Woof." The Timothy says "Thanks, valued customer. We appreciate your input."
Ok, I'll take the bait. How in the hell is JavaScript *not* a programming language?
1. It is a language
2. I write programs with it
We are so close to a Web-based operating system I can taste it.
One of the things I like to say is, "In the long run, all file formats become programming languages". When somebody says they need a simple format for a config file or something, inevitably scope creep causes them to ask for something like a conditional (can you have a config setup so that if we're running offline it does this; but if the network is available it does that?). For the developer of the file format, *any* file format, it's a good idea to have a language developer's perspective.
Now, once you look at programming languages you start to get drawn into operating systems. C was developed in conjunction with Unix. Forth tends to become an operating system. Lisp, although it runs in userspace is used as a shell via Emacs and some have compared that to an OS. They talked about building Java chips at one point, and a Java OS certainly would have been written to go with it--it's only natural.
Thus I feel compelled to revise my little one-liner. "In the long run, all file formats become operating systems".
The next time the boss says he needs a flat-text config file, think about what kind of scheduling algorithm you want to use.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
The author's proposal sounds suspiciously like he has fallen for the seductive path of elegant generalizations(that are too theoretical for the ugly details to yet be visible) instead of confronting the ugly details that our current attempt at standardization has made visible...
To be sure, the sausage-by-comittee that tends to result when you try to standardize something is quite ugly and takes ages to settle down; but if the proposal is "Just let people use whatever shims they want for everything" you haven't really solved the problem, just comitted yourself to standardizing a suitably powerful interface for the shims to sit on, along with giant piles of shim-dependent code that crawlers and any other applications that break the shims' assumptions won't be able to make the slightest sense of.
Heck, for maximum elegance in the core standards, we could just replace virtually everything with the "Object" tag, and let people embed whatever they want, or abandon this 'HTML' nonsense entirely and just make Native Client the standard, freeing developers to implement pretty much any conceivable structure, from a legacy browser engine, to a Flash client, to a TECO interpreter built entirely out of Minecraft redstone logic, as the shim for their 'site'. A glorious age of unfettered freedom!
HTML5 is the response by a bunch of whiners that normal xhtml is "too hard." Yes it's too hard to remember to close your tags. It's too hard to remember to put quotes around attributes. Why are humans checking your syntax? Have the danged computer check your syntax.
"Pave the cowpaths" is an excuse to appease a bunch of zealots that are hellbent on pushing their personal preferences and egos into a standard rather than designing something that is quick/easy to parse and universally render across platforms. It's only going to get worse as the standard is never completed over the next decade.
XML serialization of HTML sucks. It's verbose, and it's ugly. But it's effective because it's well defined and it leaves very little room for interpretation.
Honestly, I'd like to see two standards. One, is XHTML5 Strict that follows the XML serialization. This will be left to the big boys who have real work to do. The other standard would be an extension to MarkDown to allow CSS customization with classes and ids. This would allow the path the cowpaths crowd to get things down as fast as possible and keep the verbosity of XML out of their way.
A computer program is defined as "a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result," and a programming language defines the syntax and semantics of computer programs. So what makes a scripting language not a programming language? What makes a script not a computer program? For all I can see, JavaScript is like Lua and Python: a dynamically typed programming language that is transmitted over the wire in source code form.
But how would one have implemented new HTML5 features, such as the 2D Canvas,
Simple. Each pixel is a separate div.
WebGL,
Lots and lots of divs. Lots of divs.
"First they came for the slanderers and i said nothing."
OK, honest question about JavaScript, since I don't know it. Does JavaScript enclose blocks of code in curly-braces?
As we all know, curly braces are the One True Distinction between real profession programming languages and toy scripting languages. For example, everyone knows C# is a real profession programming language, but Visual Basic is a toy scripting language, despite offering nearly-identical functionality on top of the CLR. However, C# clearly encloses blocks of test in curly braces, and Visual Basic laughably doesn't, toy that it is!
So, let's settle this JavaScript debate once and for all: on which side of the curly braces line does it lie?
Socialism: a lie told by totalitarians and believed by fools.
That's never gonna win against the implementation of COBOL* that I am about to release shortly.
*CuteObjectBasedOnlineLolcode