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
"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."
In other words, implement everything new as polyfills. But how would one have implemented new HTML5 features, such as the 2D Canvas, WebGL, and the video tag as polyfills? Even if one doesn't standardize new extensions to HTML markup, one still needs to standardize new extensions to the DOM. In addition, no new elements means that user agents that do not process script or WAI-ARIA, such as robots used by search engines, won't be able to make sense of pages. Do any current web search engines process WAI-ARIA?
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"?
Just eliminating Flash and Javascript for example would eliminate a vast majority of the world's browsing headaches.
HTML needs an active companion language, an actual programming language
The big problems inherent to Flash and Javascript are not that they don't work. It's that both involve letting arbitrary code run on your computer and their security isn't perfect.
Replacing them with a new programming language that will run arbitrary programs on your computer is not going to solve that because a new language isn't going to have perfect security either.
With a new, active language, you'd still get annoying ads, drive-by malware downloads, pages that load a several megabytes of crappy code to display three lines of text and all of the other problems that make people hate Flash and Javascript.
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.
His point was about web content being more dynamic than he thinks is required. A fair point, nowadays a straightforward web form with very limited scope is frowned upon if it neglects to do some sort of javascript trickery or another. He isn't after *more* capability, he seeks a more constrained experience and to have more developers exhibit a shred of restraint rather than mandate moderately more open ended access to the client facilities for superfluous bells and whistles. If a browser hangs up nowadays, it's almost certainly due to badly written javascript or javascript implementation gone insane in the face of valid javascript. Simplistic content doesn't choke up browsers and in a lot of cases, that simplicistic content model *could* suffice for the purpose. There are cases where javascript can enrich the experience beyond what is reasonable without it, but web developers immediately jump to the deep end without a second thought today.
Now, in terms of 'powerful and flexible', I'd argue that inherently it cannot hold that crown precisely because javascript is restricted from doing things like opening arbitrary filehandles and such. This isn't a bad thing, but it means the claim of 'most powerful' is flawed. Javascript is a popular language not due to having 'the' best set of capabilities or the best syntax (everyone bundles some sort of 'library' precisely to bandaid over javascripts failing at the low level), it's popular by virtue of being ubiquitous.
XML is like violence. If it doesn't solve the problem, use more.
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.
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
HTML5 is riddled with faulty logic, flawed reasoning, and bad semantics. Even reading the spec gives the impression that the writing is of lesser quality than pervious versions. Why this is the case after 9 years completely baffles me.
Selected points:
Last but not least: enough with the XML hatred. XHTML5, with proper XML syntax, should be the focus instead of an afterthought. XML syntax compliance isn't that hard or time consuming. Markup languages are for machine consumption, not human readability. Not requiring tags to be closed, bare unary attributes (ie, checked instead of checked="checked") and all the other shortcuts are asinine and only foster laziness and sloppiness... which would not be tolerated in any compiled or interpreted language.