Category: Specs

Tech specs

Categories
HTML5 Specs W3C

The “WhatWG’s Mine is Mine” Design Principle kerfuffle

I’m not part of the HTML WG, but still follow along. Enough to see that one of the big ongoing debates lately is about the HTML WG’s Design Principles draft document. There are too many threads to link, but I would suggest the following as good places to start:

I think some people, i.e. Laura and Larry, expect the Design Principles to be used as rules, rather than as means of explaining

My own opinion of the document, and the discussion surrounding the document, is that the HTML WG Design Principles document is imprecise, vague, and vulnerable to use by self-justifying entities—OK, if you just want a fuzzy feel-good document that looks good in the press, but not something you want to see from a formal W3C Note, which is what the Design Principles wants to be…when it grows up. Definitely not something you want to see used to enforce, or justify, design decisions.

There have been numerous objections to the Design Principles document, in the past and in the current debate, not all of which have been addressed. In my opinion, though, what’s more important is that provisions in the HTML WG Design document have been used to shoot down discussion and debate about namespace support in HTML, support for RDFa, and the introduction of the microdata section:

But I don’t want RDFa to hog all of the focus. Other groups and interests have also been gently schooled in the HTML Design Principles:

So, what do we know about the Design Principles? Ian Hickson in the HTML WG mailing list:

I think the text in the Introduction of the editor’s draft of the HTML Design Principles as of rev 1.26 is quite accurate, and that the rest of the text in that document meets the goals set out in the introduction admirably. I think that it is ridiculous to think that language design can ever be based on strict objective rules, and I do not think that the design guidelines claim that this is what is attempted (indeed quite the opposite). In fact, that’s what the term “design principles” means.

Thank you for that clarification, Ian. Oh, Henri, about that DOM Consistency principle you frequently mention…

Categories
HTML5 RDF Specs W3C

My HTML WG status

I posted about quitting the HTML WG on Twitter, but there’s only so much one can shove into 140 characters. Of course, I realize that most people will probably be uninterested in a longer writing on my reasons, but that’s the advantage of syndication feeds—you can see at a glance whether you want to read beyond the first few sentences of a writing. Or not.

First of all a clarification: I joined the HTML WG once. I quit the HTML WG once. I joined the HTML WG reluctantly, because as I wrote at the time, I’m really not a joiner. I feel I’m best writing in my own space, not participating in a back and forth in email lists; definitely not through quick non-thinking blurbs in an IRC channel, or teleconferences where key players never participate.

I did join, though, and became actively involved. However, I never could figure out the “rules” of the effort, and I found it both discouraging and exhausting. So much so that it drained the energy I needed for the writing I need to do for a living. More importantly, I felt I really wasn’t making a difference, and I’m not sure I was willing to play the game in order to make a difference.

A further point of clarification: My decision to quit did not come about because of any exchange I had yesterday with any person. It was a number of factors that led to my quitting, a primary one being the one I just mentioned, needing to focus on work. I’d already decided to quit before yesterday, but was waiting for a specific thread on RDFa to play out. I will mention, though, that some of the reasons why I’m leaving were echoed in that thread, including the hostility of the WhatWG backchannel IRC, and the lack of respect some members of this group have for members of the HTML WG and other W3C groups.

Some of the the WhatWG members seem to think that I’ve quit the HTML WG more than once, but they are mistaken. I unsubscribed from the WhatWG email lists, because I found the environment hostile. I stopped working on my assessment of metadata use cases, because the HTML5 author, Ian Hickson, suddenly released a new microdata section, changing everything I wanted to write.

I have unsubscribed from the WhatWG mailing list, and that won’t change. I have quit the HTML WG, and I may, but it’s unlikely, rejoin at some later time. But I have not stopped writing about the HTML5 specification. Whether I make a difference or not, my way of “participating”, in the HTML5 effort, and any other, is by writing in this space. And I will continue to do so, in my own time, and in my own way.

Categories
Specs

Best of luck finding a suitable employer

Roger Johansson

I believe having more content creators and ”authors”, i.e. web designers and web developers, in the HTML Working Group would be good. Unfortunately I think it’s hard to find web professionals who can spare the time unless they get paid to participate. I know I can’t.

When I mentioned something virtually identical to Ian Hickson, he told me

I am sorry you feel that you need to be compensated for your participation in the standards community, and wish you the best of luck in finding a suitable employer.

Can’t wait to read Ian Hickson telling Roger Johansson, “…best of luck in finding a suitable employer.”

Categories
Specs

IE’s compatibility view

There’s been a lot of confusion about IE8’s compatibility view. To address the confusion, the IE Blog posted a note to clarify how compatibility view works. I think the site did a good job laying all the variations, though I’m not necessarily overjoyed about Microsoft’s decision to create a list of sites that are IE7 compatibility view, by default.

To see which sites will be displayed in IE mode, rather than standards mode, type the following into the IE address bar:

res://iecompat.dll/iecompatdata.xml

Netflix, Forbes, CNN, several Google sites in various countries, SF Gate, Facebook, microsoft.com…there are a significant number of sites in “compatibility view”. I appreciate that Microsoft is holding on to a tiger that is currently biting its butt, but protecting sites that need to update just keeps crappy stuff around that much longer.

For those sites not on the list, you can click a button on the toolbar to view it in compatibility view. However, the button will not display if the site uses a meta element to specifically say the site is IE8 standards compatible. If you access most of my sites with IE8, you won’t see the button. If you do, it’s only because I’ve forgotten to add the meta tag— my sites all work with both IE7 and IE8. IE6, too, but rather plainly.

I wish we didn’t have these browser version games, as they limit the advances we can make on the web. The IE compatibility view reminds me of the recently approved US DTV switch delay: they penalize the prepared and reward the procrastinator.

Categories
Specs

The nobility of specification work

Hank Williams responded to the recent ECMAScript Harmony announcement with a post titled, Ru Roh! Adobe Screwed By EcmaScript Standards Agreement. In it, he writes:

Adobe provided support to the standards body in helping to define the standard, and most importantly, in creating an open source virtual machine called Tamarin that would run EcmaScript 4.0. But they did all of this before the standard was officially sanctioned. EcmaScipt 4.0 was nothing more than a draft proposal. But Adobe needed to make this bet because they needed a better language than the early ActionScript was, and the existing template, JavaScript, hadn’t moved substantively forward in years.

And so Adobe released Tamarin, the EcmaScript 4.0/ActionScript 3.0 running virtual machine, and a raft of products based it…Unfortunately, while the technology of EcmaScript 4.0/ActionScript 3.0/Tamarin is compelling, the politics sucked.

Adobe and Microsoft are bitter rivals, and the last thing Microsoft would be willing to accept is wide-spread adoption of a language that is strategically critical to a competitor…And so this meant EcmaScript 4.0 was stillborn.

At the end of his writing, Hank summarizes Adobe’s plight, now that it has been betrayed:

the interesting question is what will Adobe do now. The technology they have is no less impressive today than it was a few days ago. But they are now totally on their own, which wasn’t exactly the plan.

Poor, poor Adobe. Lost in the wilds of the web, all alone.

Balderdash.

Hank is correct with his assessment of the politics and rivalry, (though not all decisions were political in nature). But he’s incorrect about his assumption that ECMAScript 4 is dead. Certain pieces of pre-existing ECMAScript 4 effort are not being pursued, true, but there will be an ECMAScript 4, they same as there will be a 5, 6, and on and on, as browsers and other applications that support ECMAScript evolve over time.

That’s really been the issue all along: there’s a group within the ECMAScript community that has been pushing a much more aggressive course in the development of the next specification release than other players have been comfortable with. By other players, I don’t mean only Microsoft— Google, Yahoo, Opera, Apple…all of the companies impacted by ECMAScript have agreed, with relief, that an interim specification release with full browser company support is the wisest course, with more cautious development in the future.

In addition, Hank also overplayed the nobleness of Adobe’s contribution of Tamarin, as well as the company being “screwed” in this decision. For one, Adobe agrees with the Harmony effort, while managing to get its digs in about the superiority of its offering, as implemented in Flex et al.

Make no mistake: Adobe knew it was throwing the cat among the pigeons when it contributed Tamarin. In 2006, I expressed my concerns about Tamarin:

So what do I think of all of this? I think it’s exciting, I love the canvas element and I’m interested in many of these other innovations, it’s good to revisit HTML, but I wouldn’t be me if I also didn’t note concerns: HTML element bloat; confusion as to direction of standards and where people should be heading; vastly incompatible web pages as browsers desperately try to keep up with all the changes; frustrated web page developers and designers also trying to keep up with changes; and a growing dominance of Mozilla/Adobe in regards to JavaScript and whether this could lead to a non-neutral ECMAScript 4.x, which does no one any good.

In a way, Hank’s biggest misunderstanding is his assuming that any of the other organizations involved with ECMAScript are somehow more “noble” than Microsoft in their involvement. Frankly, that’s a naive assumption. The best we can interpret all of the organizations’ involvement in the development of the ECMAScript specification—any specification, really— as being based on enlightened self interest. I wouldn’t trust any organization that says otherwise.

No, Adobe took a gamble, and the gamble didn’t pay off. It will now shrug its shoulders, reflect on the ubiquity of Flash, and continue its merry course. Forgive me if I don’t greet its noble stoicism at being stood up at the prom, with tears in my eyes and murmurs of “poor baby”.

Interesting comment in the Adobe post in answer to another comment:

Unfortunately, standards aren’t also the smartest things. Dumbing down is often a fact of standardization. We haven’t let that stop us from innovation in the past; we won’t in the future.

Yes, trying to establish a standard that is implemented in all the major browsers is really a dumb thing to do. What we should be doing is picking a winner in this little contest, and then celebrate by increasing the number of torturous cross-browser hacks for the next two decades. That’s the ticket: let’s show everyone how really smart we all are by continuing our worst practices. As long as we call it “innovation” why, it’s all right.

Yes, it’s all right.