Posts in Category "HTML"

… then they call you names….

From the ongoing WhatWG HTML5 IRC chat:

# # [07:31] hsivonen: pasting some URLs for to have a record in the log:
# # [07:32] hsivonen:
# # [07:32] hsivonen:
# # [07:32] hsivonen:
# # [07:32] hsivonen:
# # [07:32] hsivonen: (end of flood)
# # [07:34] * othermaciej: is not sure he gets the theme there
# # [07:34] hsivonen” seems like jd considers the variability of HTML runtimes a problem, so I guess HTML5 should err on the side off well-defined behavior
# # [07:46] othermaciej: oh you’re quoting the Adobe trollblogger?
# # [07:52] hsivonen: othermaciej, I’m quoting the Adobe Flash blogger who seems to blog a lot about HTML these days
# # [07:57] MikeSmith: johnny one-note
# # [07:57] othermaciej: hsivonen, after reading some of his recent posts, I stand by my prior assertion
# # [08:04] othermaciej: yeah, he’s basically Adobe’s Asa Dotzler
# # [08:09] MikeSmith: another possible competitor in this race -
# # [08:09] MikeSmith:
# # [08:10] MikeSmith: but I think he’ll need to try harder than that if he really wants to win it
# # [08:10] othermaciej: it makes Adobe look sad and desparate to try to fight against HTML having more features
# # [08:12] Hixie: i don’t think matt is fighting html having more features in that twitter
# # [08:13] Hixie: since leaving the w3c would make progress on html5 far quicker and easier
# # [08:13] Hixie: if anything, he’s fighting _for_ html having more features
# # [08:14] othermaciej: I wonder why John likes the catchphrase “browser brands” so much
# # [08:14] othermaciej: why does he say that instead of “browsers”? is that an Adobe thing?
# # [08:17] hsivonen: othermaciej, the impression I get is that he wants to portray browsers as different chrome designs
# # [08:17] othermaciej: but wouldn’t that portray the engines as essentially interchangeable?
# # [08:17] othermaciej: which is contrary to his point?
# # [08:17] hsivonen: othermaciej, I suppose
# # [08:18] hsivonen: othermaciej, although I think the point is that you pick your favorite toolbar and run Flash in the space below it
# # [08:18] othermaciej: ah
# # [08:22] othermaciej_: “browser brand” is not a very common phrase outside his blog
# # [08:22] othermaciej_: but yeah I can see how he might want to take the “browsers are just Flash loaders” position

“hsivonen” is Henri Sivonen, who may still be associated with Mozilla… “othermaciej” is Maciej Stachowiak, employed by Apple… “Hixie” is Ian Hickson, once from Netscape, then Opera, now Google.

(Thanks to (the often needlessly foulmouthed ;-) Mr. LastWeekInHTML5 for extracting the above bit from the public-yet-pragmatically-inaccessible IRC chat.)

I’m not “a troll” for asking inconvenient questions. Let me rephrase just a few of the major outstanding ones:

  1. How do you propose that these RIA features in the hypertext spec should actually work out in the world? VIDEO tag seems like it will fail with codec ambiguity. HTML is intrinsically a “Let’s Use Microsoft Runtimes!” kind of scene. How can you specify the syntax for new features, without any realistic plan for making these features possible in the real world?
  2. If you’re actually seeking browser support for patent-unencumbered codecs, expanded local storage, drawing engines and such, then why aren’t you making plugins for other browsers? If it’s because “plugins are not first-class citizens in the browser”, then improve your plugin support and cross-browser homogeneity so that they are. At the very least your VIDEO tag plan must take advantage of existing video support out there in the world. Why has Google Gears been allowed to languish? Why isn’t a CANVAS ActiveX Control seriously discussed? Why do you let an anti-plugin prejudice spoil you to the possibilities for increasing your own success?
  3. How are you really helping content developers reach their audiences? The only benefit VIDEO tag seems to bring is to browser vendors who wish to fragment web video into their own proprietary silos. Ten years ago DHTML powerplays fragmented browser support, and it was content developers who have been paying the cost ever since. It’s good that the current spec will clarify past hypertext ambiguities. But introducing vast new realms of ambiguity does not help. How is this HTML5 proposal actually helping creators reach their audiences, out in the real world?

(For some of the IRC content: My tweets on make sense if you try to use that UI — each refresh brings back a different set of Ajaxy interactions. A “troll” is someone who uses the anonymity possible on the Internet to harass others — it is not someone who takes named responsibility for asking reasonable questions. “Browser brands” refers to the multiple HTML engines consumers might choose: Microsoft, Mozilla, Apple, Opera, and Google — they differ in their capabilities. Browsers are not “just Flash loaders”… hypertext browsers are vital and unique tools, and we all hope they remain as such.)

Reasonable questions, no matter how difficult, deserve answers. Raising such questions does not deserve namecalling. And namecalling… does not persuade.

Opera CEO quotes on Flash

Yesterday there was a newspaper article titled “Opera: Web standards could eclipse Flash”. This prompted a big debate on Slashdot — about CSS vs TABLEs and such. ;-)

I stayed out of it because I didn’t know what Opera CEO Jon von Tetzchner actually said. Turns out there’s a transcript, and it shows that the headline was picked out from a part at the end of the interview. After a long section on widgets, then on browser competition and HTML5, this came up, before being closed out by app stores and Palm Pre:

(Q) In your presentation earlier, you were talking about what HTML 5 can do as a replacement for Flash.

(A) I think you can do most things with the web standards today. In some ways, you may say you don’t need Flash. On the other hand, I like Adobe — they’re a nice company. I hope they flourish and do well, so this is not about killing Flash. I think Flash will be around for a very, very long time, but I think it’s natural that web standards also evolve to be richer. You can then choose whether you’d like to do it through web standards or whether you’d like to use Flash. What we definitely don’t need is more proprietary technology — that’s the main thing. We have Flash. It’s there — fine. Let’s not get anything more.

(Q) Are you talking about Flash becoming more niche?

(A) It’s more of a choice of what you like doing.

(Q) Where’s the line between what web standards can do and what Flash can do?

(A) You can do everything, I believe, through web standards — you don’t need to use something else. But there might be something where you believe Flash is better; then you choose to use Flash.

He seems mistaken to me — comparing a proposed spec with an existing worldly ability, comparing something minority browsers may make practical in the future with specific features Flash innovated in the past, all while ignoring further capabilities Flash already provides in the world’s browsers, and the rate of innovation it promises to continue fostering in the future — but Flash definitely wasn’t the main point of his interview.

I’m sure the reporter made much better ad revenue with this choice of title, though. ;-)

(Browser vendors have an interesting perspective. They focus on what they themselves can code. They tend not to focus on the real issues of how realworld developers can deliver to realworld audiences. Adobe tries to bridge those silos, removing barriers to creators publishing their work. Different priorities.)

Anyway, no big deal here… much of yesterday’s debate seemed to be more about online drama than about what the Opera CEO actually said. Time will correct many of yesterday’s arguments…. ;-)

Building upon untested assumptions

This morning printed an “Interview with Ian Hickson, editor of the HTML 5 specification”. A particularly disturbing section:

Bruce Lawson: You’ve said that HTML 5 is in “direct competition with other technologies intended for applications deployed over the Web, in particular Flash and Silverlight”. Why is it so important to do so, and isn’t it a lost cause given that those techologies are already out there while HTML 5 is not yet complete?

Ian Hickson: HTML 4 is also in direct competition with proprietary technologies, and it’s winning, hands-down. HTML5 is just continuing the battle, because if we don’t keep up, then the proprietary technologies will gain ground.

Bruce Lawson: What are the main philosophies of HTML 5?

Ian Hickson: Backwards-compatibility, incremental baby steps, defining error handling. Those are the main philosophies.

All day long I’ve been trying to puzzle out how someone could fit those sentences together, what type of ideas must first be assumed in order to make such an utterance conceivable, much less worth saying in an interview.

Tweezing apart some of the apparent assumptions of anyone able to make such a statement:

  • “HTML 4″, as a cross-company hypertext specification, is said to be somehow directly comparable to a common clientside capability such as Flash. How can the HTML 4 spec compete with its own extension mechanism? What must you assume before being able to craft such a sentence?
  • Aside from issues of logical levels and comparing apples to oranges, there is the apparent assumption that “anything Flash can do, my favored runtimes must do, better”. Why? If Flash has added many capabilities to today’s World Wide Web, why must people billing themselves as “The Open Web” fight it? He seems to think there’s obvious reason, but there’s a step missing in the description.
  • Perhaps most importantly of all, he’s assuming that a hypertext specification should become a multimedia/RIA specification. This is dangerous to the entire HTML ecology. Even the current specs are confusing, after they’ve spun out styling, object model, even image formats into separate specs. Stuffing an additional drawing spec and a storage spec and animation and 3D and what-all into the hypertext spec weighs it down even further. I think he is espousing a recipe for ruin, and I don’t know why, because he doesn’t publicly examine his assumptions.
  • The mention of Silverlight is intriguing. This cross-browser plugin has had no realworld effect. Silverlight does not realistically threaten Chrome. HTML5 and Silverlight perhaps compete in blogosphere mindshare. Or perhaps he’s just raising it as an “M$ boogeyman” to better bash Flash. There’s something that prompts him to include Silverlight in his assertion, but it is not clear what assumptions underlay its mention.
  • Why even bother to say “and it’s winning, hands-down”? Is there a “winning”? If so, how do you measure it? What type of boosterism could produce such an utterance?
  • Bruce directly asked whether this was “a lost cause” because Flash was already in use while HTML5 was still in committee. Ian ignored this vital question of how to bring a concept out into the world, making a capability genuinely useful to people. It seems he assumes it’s not important enough to think about.
  • He assumes that “HTML5″ is “continuing a battle”. Perhaps he knows what the battle is. The rest of us have to guess at his assumptions.
  • He assumes that there is something called “proprietary technologies”. I assume he does not assume this includes Apple’s Webkit governance, or Google’s ubiquitous web beacons.
  • The “main philosophies of HTML 5″ include a helpful point: defining what browsers “should” do when they encounter improper content. But “incremental baby steps”!? It’s more like a wild jump to Rich Internet Applications. Maybe the assumption here is “No one will challenge me on this jive”.

I’ve been trying to see the world through Ian’s eyes, but I cannot — he has built a rhetorical structure atop untested assumptions, instead of establishing upon common ground.

What would I like to see?

I’d like to see some clear discussion on the appropriate scope of a spec that any hypertext implementation should be able to easily reach. If CSS is a separate specification, then why isn’t RIA?

I want to see more “standards” discussions about the needs of people who actually publish to the web. We should not have had the last ten years of people working around browser differences. No more!

I wouldn’t mind seeing standalone RIA specs in the SMIL, HTML+TIME, SVG mode. These live or die on their own, and do not threaten the extraordinarily-useful HTML spec itself.

I want to see “open web” evangelists find ways to bring their functionality into other browser brands. Instead of worrying about microshare, figure a way to make cheap codecs available to any person in any browser today. Browsers were opened up to third-party rendering long ago — don’t fight to turn back the clock. Stop railing against cross-browser functionality; stop thinking you must own it all yourself; if you say you’re for “open video” then act it. A campaign for a Theora plugin would hold more relevance.

(The proposed fragmentation of Today’s Web doesn’t worry me as much… Flash makes too much sense for people to abandon it, and Adobe thrives by uniting fragmented silos. Those content developers who don’t see through the hype will be the ones to pay the price. But increasing fragmentation and siloing would not be a good thing for HTML in general, which is why I’m writing this essay.)

What do I think is really going on?

I think it’s a corporate powerplay to “bless as standard” runtimes from the corporations pushing the multimedia syntax. There’s no angle for realworld developers in VIDEO tag and the rest — their proponents shy away from any discussion of how these might someday be supported and useful in the world. This campaign is not for content developers or their audiences. It’s a marketing play, like how Microsoft lobbied for OOXML.

That’s why it doesn’t matter that VIDEO leaves codecs unaddressed… why it doesn’t really matter that most consumers use Internet Explorer. This is not really about content developers. It’s about browser vendors. They can make any content requirements they wish upon publishers, once their engine is “blessed” for VIDEO tag.

Some vendors sell proprietary hardware. Some sell proprietary data about what you watch to advertisers. I suspect either would be happy to fragment Flash capabilities if they could. Instead they’ve found other ways to construct a walled garden around audiences. And it’s easy enough to find fanboys as footsoldiers.

Flash scares them because it opens things up too much, levels the playing field. That’s what I think is really going on.

Summary: The HTML5 editor says he’s fighting a battle against Flash. But he doesn’t explain why, so it’s hard for us to help him get better.

[Comments: I'm not really keen on diluting this conversation with guesses about what he may have meant, thanks in advance.]

The Browsers of Tomorrow

The browsers of tomorrow will likely include some type of editorial guidance, as this example of a child-oriented browser at TechCrunch today shows.

During The First Browser Wars, Netscape and Microsoft competed on adding similar new features in incompatible implementations, and in the rush did not think through the security implications. This pattern is recurring in The Second Browser Wars today, with the current “HTML5″ committee focusing on RIA specs, and it’s likely that many of the brandname browsers of tomorrow will be much larger codebases, with more functionality which will inevitably interact in unexpected ways.

But a different approach is to tailor the browser to the needs of the audience, rather than to the needs of the browser vendors. Here a group optimizes a user-experience for children using AIR. As TechCrunch describes:

KIDO’Z is a pretty nifty Adobe AIR-powered desktop browser app that gives kids a safe and fun environment to play games, watch videos and/or visit pre-approved websites. When you first install the AIR app as a parent, you can configure the age and gender of your offspring as well as your location and preferred language… All content only shows up when a KIDO’Z team member approved the content beforehand, and to add more layers of security all scripts, file downloads, pop-ups and any other attempts that could lead to content which has not been approved, are thoroughly blocked. To use the app, kids won’t need to know how to read or write since obviously the whole UI is quite visual of nature, and very colorful to boot.”

The application is tailored to the needs of the audience. HTML should serve children well… children should not be forced to have adult sensibilities before using a browser. One editorial approach will not suffice for all, obviously, and there are many possible “trusted voices” which can help guide the web-browsing experience.

I think the hypertext specification should be clear and easy to implement. But that now conflicts with corporate desires to control each layer of the consumer experience, and to lock-in use of their own runtime engines. AIR provides a way to fight back, by using HTML or SWF to customize a particular user experience atop a standard Webkit implementation.

AIR includes a browser, but is not itself a browser… you can think of it as a web browser toolkit. Anyone can now make tools for surfing the web more efficiently, more appropriately. No need to all wear the same uniform… browsers can now be customized for the audiences they serve.

Anticipating standardization, and deprecating standardization

Two different stories here, of the difficulties of banking on either presumptive or actual standards.

Dave Shea had an essay this week on how he is no longer using XHTML conventions in his paying work: “Six years ago, many of us thought XHTML would be the future of the web and we’d be living in an XML world by now. But in the intervening time it’s become fairly apparent to myself and others that XHTML2 really isn’t going anywhere, at least not in the realm that we care about. For me, a guy who builds web sites and applications for clients that have to work in today’s browsers, XHTML2 is a non-issue. No browser support, no use to today’s web authors. End of story.”

Advocates for a proposal often speak of it as an accomplished reality, before it actually achieves agreement from others, much less is available from browser vendors, then adopted by significant audiences, then proven cost-effective by content developers. There was enough talk about XHTML that it was easy to assume it was real. Dave bet on XHTML, and is now walking away from that bet.

Jason Grant mentions that the same dynamic is occuring today: “I find this very strange. Somehow you feel like HTML5 ‘is here’ while I would argue that XHTML2.0 nor HTML5 are here either. The ‘improvements’ offered by HTML5 are few and browser vendors have jumped into implementing it without really considering the future properly… Most people I speak to are not happy with HTML5 to great extent and that specification does not seem to be heading forward that rapidly either — in other words one could argue both XHTML2.0 and HTML5 are pretty dead.”

Dave demurs that he’s merely expecting HTML5 to be ratified and then implemented in its current form, and later adds: “I don’t feel like it’s remotely close to the right time to start delivering client sites in HTML5. Experimental and personal sites, maybe.”

Late in the thread Duane Storey had this interesting tidbit on a different subject, the academic rationale for XHTML and what happened when it met the real world: “The only real benefit to having a XHTML/XML document is that it can be properly parsed by a XML parser. In theory, that should make manipulating the document easier and rendering the document less error-prone. The reality is though, as a third party developer, since most sites don’t actually properly validate as XML, you can’t make the assumption that they are parsable, which basically means you have to treat most things as HTML anyways and allow for some slop.”

Most of the rest of the lengthy comments section is about arguing over rules, and what the rules mean, and what the rules should mean… not much about results.

What I got from Dave’s piece: Anticipating that a proposal will become a de jure standard, and then a meaningful de facto standard, is a gambling game.

Jonathan Snook brought up different-yet-similar problem… when should content developers consider fighting against what audiences actually use? IE6 has dropped from universal consumer support down to Firefox range, but it costs more for content developers to do new tricks in it. He doesn’t come down on either side of “the IE6 question”, but provides some new ways of looking at the problem.

Here’s how he opens: “If you haven’t done so, I highly recommend cracking out a copy of Firefox 1. Start bouncing around to a few sites and check out what’s broken. Sure, most stuff is fine but you’d probably be surprised at what’s broken. What about Firefox 2…?”

And here’s how he closes: “You may say that Opera is too small to really care about. It’s only 2%. You don’t care about Firefox 2 users. It’s only 2%. You may not care about accessibility issues. It’s only 2%. Soon enough, you’ve whittled down your potential market to 90% of what it could have been… I’ll keep thinking about all those people I could be getting. Did they walk away with the best experience? Sometimes it hurts my head just to think about it. So now it’s your turn: Should we care about old browsers or fringe browsers? Or are we safe in our little bubble?”

Internet Explorer 6 was the exclusive browser choice of over 80% of all surfers as recently as December 2005 — no other browser version has ever been used by so much of the audience! It’s the closest thing to a standard release (in terms of realworld audience support) that the browser world has ever seen. Even today it still has marketshare about equal to all versions of Firefox combined.

IE6 was the standard, and now we’re thinking of changing the definition of “HTML” out from under it to include things it won’t understand.

Another way to look at it: Should content developers effectively outlaw ex-standard user agents from their new-standard designs? Tricky question.

Comments at Jonathan’s were mostly “here’s what I test against”. Scott Jehl brought up the key point of mobile HTML, and I followed up on that, although I didn’t bring up the other key issue of archival formats versus the ephemeral web. Comments didn’t surface a solid answer to Jonathan’s question.

Dave was dealing with anticipating that something may become a realworld standard. Jonathan wrote about deprecating something that was already an overwhelming realworld standard.

Don’t know what it all means, and I don’t have answers to their questions, but thes are striking questions to think about.

Flash is in here, too, but the versioning issues are much less severe, and there’s already progress being made on addressing cross-device issues.

I don’t know what percentage of IE6 users are using the current Flash Player, but imagine it’s pretty high — people are hesitant to make big visible software updates because it risks changing things, and “if it ain’t broke don’t fix it”. But browser plugins don’t change UI or habits, don’t risk losing data. If you want to do new stuff faster, then it makes sense to have the runtime work across browser brands, across browser versions, and not to make a big splash of itself when it arrives.

There’s more resistance to updating a browser, much less changing a browser brand, and any browser choice tends to be an exclusive one.

Flash works with almost any browser, and doesn’t make you choose among them.

Different dynamics. The technologies complement each other.

Thoughts on Ruby’s “HTML Reunification”

I was off-the-grid when Sam Ruby of IBM, co-chair of W3C HTML Working Group wrote an essay on HTML 5 which sparked many comments, followups. Some of it went off into details, but here are some of the higher-level ideas I pulled out of it.

Sam starts by describing how the current HTML5 proposals fall into two camps: new features for browsers, and then how existing features should actually behave. The difficulties lie in that latter half — even small details like whether quoteblocks should assume quotemarks aren’t yet standardized in the spec, or in the world.

But it was a rephrasing a little later which really resonated with me:

TV Raman made a comment a number of times that we need to partition the idea of extensibility into two parts: extending the platform vs. extending the language. Those two words didn’t make much sense to me, but his examples did. Video and 2D graphics are things that need to be implemented by the browser vendors. And care needs to be taken that such features are defined in a way that they interact consistently with how other parts of the platform interact with other components such as CSS. Raman refers to these as platform features.

The second type of feature is one that does not need any support by browser vendors other than to simply to parse the unknown elements and attributes into a DOM, and to provide access to the DOM via JavaScript. RDFa comes to mind as such a feature, as does ubiquity-xforms. TV Raman refers to these as language features.

I like and endorse TV Raman’s split. Different burdens of proof and policies need to be applied to each type of feature.

He goes on to say that for new types of features to actually be usable by developers, “consensus by browser vendors is essential” — minority browser-vendors risk forking the Web; realworld adoption and practical deployment must be addressed. For language improvements, I think he wants to see better error-reporting to the user if some markup isn’t recognized.

But the part that struck me was how much of the current HTML5 discussion falls into two distinct sets: new “platform” features, and better handling of existing language features. For too long, runtime makers have added non-standard features, pushing the testing costs back onto content developers — the DHTML Feature Wars gave us a decade of web developers sweating out the differences. There’s a similar dynamic emerging today. But what serves the needs of vendors does not necessarily serve the needs of developers.

In reading some of the spin-off essays, I was particularly struck by this passage, from Rob Sayre of Mozilla:

“I don’t see a problem with HTML5 and XHTML2 continuing their separate ways. I do see a problem with some features being made part of HTML. Examples include a laughably underspecified SQL syntax, a video element that isn’t interoperable, and an RDF syntax that uses namespaces in text/html and QNames in content. Maybe we can all agree that those examples don’t belong in the HTML specification at this point. But then the problem shifts to one of endorsement. People want the HTML specification to tell them what they’re doing is OK. I don’t think the HTML document should do that either.”

That last point is key — if the VIDEO tag doesn’t actually serve content developers, then who does it serve, to warrant such attention? The most reasonable hypothesis is that the standards process is being used to “bless” the multimedia runtimes browser vendors want to create and control. We’ve seen it happen with the OOXML controversy, where standards bodies were used to bless a technology in the marketplace.

Endorsement of a browser vendor’s needs. That could explain why much of this is being pushed through, despite the apparent costs to content developers and their audiences.

I went through all the comments — painful reading, but I’m glad I did, because it revealed this little section of different perspectives from those seeking HTML runtime adoption, and those with a more pragmatic perspective:

Brad Neuberg of Dojo expresses the “HTML5 must have shiny features” position:

“If we follow Rob’s disassembly of HTML 5, there won’t be anything there to actually drive adoption. Sam, you suggest that his version has well-defined error semantics…. that didn’t work too well for XHTML though to drive adoption. We need a real-world standard with compelling features to keep up with Silverlight, AIR, etc., not an academic document that simply cleans things up. Unfortunately that’s not enough.”

Karl Dubost of W3C, in reply:

“This is a noble goal, but it really looks like a Geek Wet Dream. There are awesome things done with Canvas, but the thing that the hardcore geeks of html5 tend to forget that it is still far beyond what the Flash or Adobe Air platform propose. I’m not advocating for them. I really wish it was different. You can definitely say that canvas is a baby step for making an application platform to compete with adobe air in 15 years indeed. (Though don’t forget the competition will advance.) But selling canvas and some of the features of html 5 as a competitive technology with regards to the others make us (people in the HTML 5 WG) ridiculous.”

Brad seems to like Flash and AIR, but it’s not clear why he wants to force all browsers to try to duplicate such functionality. If vendors are still arguing over how simpler text features “should” work, then that seems a more pressing problem to solve.

Pervin’ the Standards

This is not a tightly-honed, logical, and factually persuasive essay. I cannot predict the future well enough to induce others to change from a dangerous course. Consider this as just an honest rant. I’m quite apprehensive of the future of HTML, if enough of us do not rant longly and loudly enough. Just an unedited draft of a rant; happy Friday to ya. ;-)

The tipping point for the rant? “An analogue clock using only CSS“. Paul Hayes made an (admittedly studly) example where JavaScript queries the local system’s time, and Cascading Style Sheets move the hour, minute and second hands around.

Stylesheets. For animation.

Not SVG. Not an internal browser-specific drawing language. Not bitmap rotations through JavaScript.



Styling guides themselves have been around since SGML days. It’s handy to separate presentation and content.

The “Cascading” in CSS refers to how styling choices of the designer, the reader, and the browser vendor are reconciled together. It’s a tricky task, and Wikipedia has an intro to the innovations in this area in the 1990s.

What’s “a style”? The original intent was font, sizing, color, and other reading attributes. This makes sense. Later it was used for layout and positioning, instead of table-based layout. That’s questionable scope-creep, but is a done deal.

Now Apple is promoting styles as animation engines, transition engines, even 3D engines.

That’s kinky. Otaku, chikan. Ham sup. A Kraft-Ebbing candidate, just a wee bit too twisted.

Questions on CSS already dominate the web-design mailing lists, and have done so for many years. It isn’t clear how to use and practically deploy this cascade of styling instructions between creator, consumer, and browser vendor. Adding 3D and other animation into it may serve the needs of browser vendors, but does not promise to help content creators or their audiences, and runs difficult-to-predict scope creep risks.

If you want to make an animating clock in a browser, then go for it. But please don’t drag poor CSS in for that task! They’re style sheets people… not the kitchen sink!

Think of how such a proposal could possibly evolve. Some browsers will do animation through CSS. Some won’t. We already see it with the over-ambition of Ajax: tricksy sites will request visitors to change their browser brand, or will just outright fail on the smaller mobile browsers.

If animation becomes a mandated feature of CSS, competing proprietary browsers will run the risk of being labeled as non-compliant. It raises the barriers to new browser entrants. It serves to lock-in browsers which have already developed all this extra effluvia.

Sure you can code it. But how will people see it? (And by people I don’t mean “just you and your enlightened friends”… I mean universal access.) Take a tip from Hari Seldon, and think of how the technology would grow.

(Caveat: I’ve “known” Dave Hyatt, Dean Jackson, and Chris Marrin for years online, and I trust them as people. What I’m objecting to is the corporate drive to use a standards body to “bless” Apple’s internal needs for a media-savvy runtime engine via pollution of CSS’s core mission.)

(Related: Sam Ruby on HTML5 Evolution; Doug Crockford on HTML5 reset.)

Here are some of the common objections I expect to the above:

“Oh, we don’t want a full 3D engine like VRML, we just want little 3D effects.”

The clock example shows that people will use technologies in unexpected ways. The creators of Usenet did not intend mass advertising. The creators of email did not intend to create spam. The inventors of IFRAME and mashups did not anticipate third-party exploits. Stuffing the genie back inside the bottle is harder than looking carefully at the bottle before opening it.

“We want patent-unencumbered codecs, so toolmakers can make video tools without licensing modern codecs.”

I’m with you on the goal. But putting VIDEO into the Hypertext spec is not the way to do it. You cannot require new browser vendors to follow your lead. Make an Ogg Theora plugin, so that anyone can use it, with minimal impact on the overall spec itself. Don’t enact dependencies on a particular browser brand.

“But we don’t want a plugin — we want Open Video to be a First Class Citizen on The Open Web!”

So improve your plugin support! WMODE layering is still flakey across the various browsers. JavaScript/plugin intercommunication is still messier and more variable than it should be by this point. Make plugins a first-class citizen in the browser brands you control, and your video will have a wider, more inclusive audience.

“You’re just saying that ’cause Flash pays your salary.”

Adobe actually benefits from increased browser fragmentation, because we sell the tools that reconcile the various browser brands. And the more over-ambitious HTML becomes, the better Flash will do in comparison. But I’d rather not have that income if it comes at increased cost to people actually trying to use HTML.

Apple makes more money when it locks people into Uncle Steve’s Walled Garden. Google makes more money when it knows you better than you know yourself and can sell your attention to advertisers. Web pundits earn more self-esteem when they’re seen as being ahead of new trends. Web journalists earn more when they increase the power of advertising networks. Web devs earn peer respect when they code something new.

All of us have self-interest. None of us are pure. Question the arguments, don’t shoot the messenger.

Fortunately, there’s hope. Check out the apprehension in some of the comments at the Ajaxian write-up:

“While this interesting and maybe a little bit cool, I think it is inappropriate for Webkit to take CSS (even if only for itself) in this direction. CSS was created to define style. This seems more like a behavior to me and that belongs to the Javascript problem space.”

“CSS should be a style guide, not a programming language.”

“To me, it seems like Webkit is trying create CSS behaviors similar to what MS did with IE’s CSS Expressions close to a decade ago (which they have since abandoned in the most recent release of IE). I’m really hoping the W3C doesn’t add these behaviors to the CSS spec – behavior is much better suited to JS.”

“I thought the whole reason for CSS in the first place was separation of purpose, removing styling from content. Now we’re adding behavior into style?”

“Why is it bad when MS goes off in wild proprietary directions with CSS, but if Safari/Apple does it it’s newsworthy?”

“I for one want CSS to do CSS, Javascript to do Javascript, HTML to do HTML and ASP/PHP to do ASP/PHP. Once we start getting into overlap of these technologies it can only cause feature bloat, confusion and problems. I want each tech to be lean and mean to do be the best at what it does and leave other tasks outside their areas for the tech designed to handle those tasks.”

We may not be able to persuasively articulate why this will eventually be considered a bad architectural decision. It’s like when vendors of email clients started talking about how wonderful it would be to add hidden graphics and scripting to the emails strangers send to you. Vague warnings of an unsound future are at a disadvantage to self-interested “But I wanna do it!!” evangelists.

It’s hard to persuasively document future risks. But encumbering HTML and CSS like this is not the way to bless your own multimedia engine.

This is not a sound path. Think it through. Trust your gut.

A clock… in stylesheets!? There is something deeply wrong with this picture.

Standards for thee, but not for me

Strange news today… Mozilla announces an initiative for “3D on the Web”.

Now, both VRML97 and Extensible 3D are already full ISO/IEC standards.

But Mozilla’s proposal relies upon further proprietary extensions to the experimental CANVAS tag, as opposed to Apple’s 3D extensions to Cascading Style Sheets, both of which are part of the contentious HTML5 discussions, some of which may eventually wind up as a W3C Recommendation, which might then possibly become an actual ISO/IEC Standard. (Yes, it’s convoluted. ;-)

But such de-jure standards for Web 3D as ISO/IEC 14772 and ISO/IEC 19775 already do exist.

And projects like Papervision3D are already very successful, and work quite well in Firefox, or any browser brand, right now. You’re welcome to contribute to this or any of the other existing opensource 3D projects that play in peoples’ browsers today.

De-facto standards for Web 3D already exist too.

Thinking just a little past the press release and the coding strategies… how will the runtime code be distributed? If it’s only embedded within one or two browser brands, that’s a clear non-starter, at least for non-hobbyist audiences. If the renderer is available as a new cross-browser plugin, then that enfranchises the range of browser brands, but imposes adoption costs upon consumers. A rock and a hard place.

Mozilla folk? I share your overall goals about advancing web technology. But think things through, objectively. It may be fun to re-invent stuff yourself, but it’s more productive to work well with others.

And you’d lose the moral fulsomeness of the “Web Standards for The Open Web!” pitch when focusing on your own proprietary alternatives to existing standards.

“Standards for thee, but not for me”… that’s not the most convincing approach!

Plugins enfranchise minority browsers

Neat story at a Mozilla contributor’s weblog… online banking in Taiwan used bank-distributed encryption coding modules, which were previously only available as an ActiveX Control. They recently repackaged these modules in the classic cross-browser extension mechanism, Netscape Plugins.

Result? Now more people have choice in browsers, because third-party functionality could be included in each minority brand.

Opening up to standard cross-browser extensibility results in a much better situation than if plugins never were.

CANVAS, accessibility, appropriateness

It’s good to have Web content available to the widest range of people — to not turn people away because of their operating system or browser brand, or because of physical differences such as visual acuity or motor-skill difficulties.

In the Flash world we’ve been dealing with this inclusiveness issue for a long time — figuring out how to improve the economics of providing a multi-modal experience — and recently there have been exciting improvements in tasks such as captioning video. Still, the objection “but Flash isn’t accessible” is often used when someone wants to nix your project.

Here’s a different perspective on that “must be accessible” priority… David Baron of Mozilla, in “Web Accessibility as a Political Movement” responds to those who wonder why so many of the projects labeled as “HTML5″ do not seem to be attending to the needs of diverse audiences. This is part of a lengthier conversation on the CANVAS tag and its use.

Here’s one argument, which you may have seen in different form before: “Existing disability law, for example, might require installation of wheelchair ramps in places of ‘public accommodation,’ but doesn’t require them to be installed in everybody’s houses. Likewise, I would expect an online form on a government Web site that is required to visit the United States to be usable by blind people, and likewise expect good alternative text for an image on a government Web site describing how a bill becomes law. Yet I would not expect a bunch of photos that John Smith shares with a few friends on a Web site to be required to have reasonable alternative text. In other words, content on the Web varies widely in importance and amount of use. Yet some accessibility advocates insist that even John Smith posting a few photos online must be forced to provide equivalent alternative text to replace the photos.”

There’s also acknowledgment that purely idealistic positions may be difficult when brought into reality in the world: “Web accessibility involves tradeoffs, such as between burdens on those who send information and burdens on those who receive it. Sensible choices along this spectrum can vary depending on how the Web is being used; there’s a big difference between publishing to an audience of five (that might be larger later, if you happen to succeed) and publishing to an audience already known to be in the millions.”

Both of these emphasize the need to look at the total situation, and that a particular stance may not apply to every case… far from the usual absolutism of “but it’s ‘proprietary’“.

I’m not sure I agree with his entire position though… sections like these seem to go too far: “I think the attitude that evil Web authors need to be forced to care about accessibility leads to technically worse solutions that require more work for authors and leave the Web less accessible to disabled users as a result… I think this community is in significant danger of being taken over by, or at least best known by, those within it who espouse such extreme positions that they risk causing the entire community to be ignored.”

Read it yourself, figure out how you feel about it… accessibility is definitely an area in which we need to encourage better practices, but bringing that about is the hard part. I just found it refreshing that someone at Mozilla emphasized how pragmatism and idealism must necessarily balance each other.

There’s one more wrinkle about “accessibility”: the concept applies not just to differences in physical capability, but also intellectual capability, language, and cultural differences. Text itself imposes cognitive and language-skill restrictions (my own text here is discriminatory!). But imagery, animation and video all reach a wider range of people in the world than text alone can. It’s hard to craft a message which reaches every potential audience member, but “rich media” should definitely be one tool in our toolbox when attempting to do so.