Tag Archives: HTML

HTML5 as a “programming language”

A JavaWorld article rhetorically asks, “Will HTML5 kill the mobile app?” Windows 8 will purportedly have a new type of application, written in HTML5 and JavaScript. I have to wonder whether the people who are proposing HTML5, CSS3, and JavaScript as a programming environment have the least idea of what programming is about.

The idea is so bizarre that it’s hard to know where to start a refutation. How would you refute a claim that silly putty is going to be the new way to build skyscrapers? HTML, in any version, just isn’t a programming language. JavaScript can be used for some programming tasks — in principle, it can implement any computation that you could write in another language — but doing anything but the simplest programming tasks in it is agonizing.

There are innocent people who’ve copied a script to produce a Web page effect, and there are less innocent people who find it convenient to delude them with the notion that that’s what programming is. The web page for HTML5 for Dummies declares: “HTML is the predominant programming language used to create Web pages.” If you can believe that, you’re part of the target audience of the title.

HTML5, just three years away

According to the latest version of the HTML Working Group Charter, HTML5 will become a W3C recommendation in 2014.

Smart money is on the AES audio metadata schema being made public first, but I wouldn’t be too sure.

HTML5 security

Yesterday, February 24, Ming Chow gave a talk to the ABCD security group at Harvard on HTML5 security. As far as I can tell he hasn’t made any of the content publicly available online, but here are some high points:

  • HTML5 has a lot of new features, giving it a bigger “attack surface.”
  • There’s no effective security to local and session storage, so writing sensitive information there is a bad idea.
  • The database feature raises all the standard concerns about injection of malicious SQL code into fields.
  • Application caches can be written by any website. It may be possible to spoof pages this way.
  • There is now a function, XDomainRequest, in JavaScript, which allows communication between different sites. The receiver of the request must specify Access-Control-Allow-Origin to indicate whose requests are allowed. Wild-carding this allows anyone at all to send data to a page, which may be dangerous. Implementers of a receiver should always verify the sender’s identity.
  • With the audio, video, and canvas tags, the codecs can be vulnerable. Opera has been hit with a heap buffer overflow exploit in HTML5.
  • The noscript tag is no longer supported. Users who try to make themselves safer by disabling Javascript are more screwed than ever.
  • The problems are new, but the approach to safety is the same: common sense, input validation, being careful with unsecured connections, etc.

The HTML5 logo again

In an earlier post, I questioned how W3C’s new HTML5 logo could help provide a “consistent, standardized visual vocabulary” when it stood for nothing in particular. Others have taken even stronger positions than mine, and W3C has backtracked. The HTML5 logo now stands for HTML5, not for HTML5, CSS3, H.264, and every other “cool” technology showing up on the web these days.

It’s still, as I noted, not a mark of conformance or certification, so its use on a website proves nothing, but at least now what it’s claiming to say is clearer.

HTML5 logo

HTML5 logoW3C has a new logo for HTML5. The blog post says:

As you’re aware, the term HTML5 has taken on a life of its own; there has been significant confusion and debate both within the developer community and in the public at large as to what exactly HTML5 is when the term is used outside of simply referring to the spec itself. This variability in perception is what inspired the project – a group of developers and HTML5 evangelists came to us and posed the question, ‘How can we better communicate all of the technologies and potential that HTML5 represents?’ …and the resounding answer was, the standard needs a standard. That is, HTML5 needs a consistent, standardized visual vocabulary to serve as a framework for conversations, presentations, and explanations moving forward.

How it will do this when the logo stands for nothing in particular — it isn’t a mark of conformance, certification, or anything else, and anyone can use it under a CC license — isn’t clear.

CSS3: Threat or menace?

Lately I’ve been looking at CSS3 animations as a possible solution to a problem I’ve been dealing with. But after thinking about it, I’m getting more concerned: CSS animations? CSS is supposed to be about the layout of a page, not the creation of special effects. I’ve seen pages describing supposedly wonderful effects that can be created with CSS3. Fine, but what if you don’t want them?

JavaScript and Flash product many annoying effects, introduced by designers who effectively are yelling “Hey, look how clever we are!” at you while you’re trying to concentrate on reading. You can turn off JavaScript and Flash and still get readable content, at least with many sites. But turn off CSS and most modern web pages will turn into a messy jumble. CSS3 looks like a narcissistic web designer’s dream: a way to bombard you with special effects that you just can’t escape from.

If you aren’t worried yet, consider this post on how to do Flash-like ads using only CSS3.

Addendum: The CSS3 working draft was recently updated.

HTML5 and video

There’s an entry on the W3C blog about the state of HTML5 video. The most significant point is that “we still don’t have a baseline video codec for HTML5.” Without that, it’s silly to talk about HTML5 as an alternative to Flash or any other kind of video presentation. Microsoft is pushing H.264, and IE9 will support only H.264 under HTML5. Mozilla is going with Ogg Theora. Both codecs have patent issues, limiting the opportunities for third parties to fill in the gap. Both have enthusiastic advocates.

The Browser Wars are back.

So what is HTML 5 exactly?

Paul Cotton, co-chair from Microsoft on the W3C HTML Working Group, has some interesting comments on exactly what people mean by “HTML 5.” This may help explain some odd statements about “HTML video” which I’ve commented on in recent posts. The interview includes other remarks on the status of HTML 5.

First, I believe that most people use the term “HTML 5” to refer to the HTML 5 specification currently being worked on by the HTML WG. The HTML 5 specification defines the syntax and the semantics of the elements and attributes in the HTML markup language and several of the APIs that are used to process HTML documents. Recently the HTML WG has started to break the HTML 5 specification into more modular and separate Working Drafts e.g. HTML+RDFa, HTML Microdata, and HTML Canvas 2D Context. The HTML WG is also publishing two additional documents to aid users of HTML 5: the HTML 5 differences from HTML4 specification and HTML: The Markup Language which is aimed at developers that produce HTML 5 output.

Each of these additional Working Drafts are still part of “HTML 5” and are all on track to become separate but related W3C Recommendations or Working Group Notes. I believe that the content of these WDs taken together will define the part of “HTML 5” being worked on by the HTML WG.

But I believe that some use the term “HTML 5” to refer also to the important related API specifications being worked on by the WebApps WG. The WebApps WG is chartered to create client-side APIs that can be used with the HTML markup language – in fact some of its specifications started as part of the HTML 5 specification but were migrated over to be separate modular specifications managed by the WebApps WG. In addition there are some very interesting APIs under development by the Device APIs and Policy Working Group which are related to HTML 5 since they can be used with the HTML language and in user agents.

Others use the term “HTML 5” to also include the ECMAScript-262 Language which defines the programming language that we use today to build dynamic web applications.

Flash “vs.” HTML: the shadowboxing continues

The shadowboxing between Flash and HTML 5 is getting pretty serious. A lot of people are using “HTML 5 video” as a shorthand for “non-Flash video technologies which HTML 5 facilitates,” and Adobe is clearly worried.

An article by Justin Nichols regards HTML 5 and Flash as competitors, and that article is showing a solid five-star rating on feeds.adobe.com, though it isn’t written by an Adobe employee, so it probably expresses a view that’s popular at Adobe. It refers to Flash as a “platform,” and that may be the key point; there’s an unstated suggestion that it can’t just live inside standardized HTML elements. But if it can’t, we’re in for still more rounds of browser incompatibility. Just as “the end of history” when the Soviet empire collapsed was a delusion, the “end of the browser wars” is most likely another.

A New York Times article on the lack of Flash on the iPad is entertaining for its disclaimer at the bottom. The body of the article says:

But concerns over the lack of Flash in the iPad and iPhone may be short-lived. Many online video sites have been experimenting with a new Web language that can support video, called HTML5. Unlike Flash, which is a downloaded piece of software that can interact with a computer’s operating system, HTML5 works directly in a Web browser. And although this new video format does not work in all browsers, it will allow iPhone and iPad users to enjoy more Web-based video content.

Then in a correction it notes that that was wrong:

An article on Monday about the absence of the multimedia software Flash in Apple’s new iPad tablet computer referred incorrectly to the Web language HTML5. While HTML5 can support video, it is not itself a video format. The article also misstated the ownership of HTML5 patents. HTML5, like other versions of Hypertext Markup Language, is open source; it is not owned by a group of companies, including Apple.

Can I hope they learned their error by reading this blog? Probably not. Even the disclaimer isn’t completely right; HTML 5 is a specification, not a program, so it’s meaningless to call it “open source.” Some implementations of it are open source, and others aren’t.

Standardization of the means of embedding video is a good thing. If that has Adobe worried it will face competition, that’s a good thing too.

Flash “vs.” HTML? Not so.

CNET has a rather confused article titled “HTML vs. Flash: Can a turf war be avoided?” This is like asking whether a turf war can be avoided between mixing bowls and batter.

The article says: “Bruce Lawson, Web standards evangelist for browser maker Opera Software, believes HTML and the other technologies inevitably will replace Flash and already collectively are ‘very close’ to reproducing today’s Flash abilities.” Further on: “Perhaps the most visible HTML5 aspect is built-in support for audio and video.”

This is complete nonsense. HTML 5 does not include “built-in support” for video. All that it does is provide a standardized means for browsers to support it. The video and audio tags provide a standardized means of expressing video and audio content, but don’t define any means of interpreting the content. That’s left up to the browser, just as it is with HTML 4 with its lack of standardized media tags. The browser can support MPEG 4, Flash, Ogg, all of them, none of them, or something else entirely.

Perhaps author Stephen Shankland is thinking of a different issue. There are some Web pages whose content is made up entirely of Flash. If you bring them up on a browser where Flash support is lacking or disabled, you generally get a blank page, not even a clue about what’s wrong. This could be considered Flash vs. HTML competition, but it’s an area where Flash has no excuse for being there and deserves to be beaten. The appropriate use of Flash, to present animation and video, is actually better supported by HTML 5 than by earlier versions, and the idea that the technologies compete is meaningless.