Posts in Category "HTML"

Adobe authoring for “HTML5″

Jeffrey Zeldman, today: “Adobe has a brief but golden opportunity to create the tools with which rich HTML5 content is created. Let’s see if they figure that out.”

Best resources:

  • Adobe CEO Shantanu Narayen, June 2009, when asked whether Adobe Creative Suite will support “HTML5″ features, replied that Adobe is “clearly supportive in terms of making sure as HTML 5 is evolving that we will support it in our web authoring tools”.

  • Update: Adobe CTO Kevin Lynch, on Feb 2: “Adobe supports HTML and its evolution and we look forward to adding more capabilities to our software around HTML as it evolves.” (However: “If HTML could reliably do everything Flash does that would certainly save us a lot of effort, but that does not appear to be coming to pass.”)
  • Adobe Creative Suite already produces FXG:

    “FXG 2.0 describes an XML-based graphics interchange format for the Flash Platform. FXG contains high-level graphical and text primitives that can be used to create, group, transform and visually modify basic vector and bitmap shapes. The FXG rendering model follows very closely the Flash Player 10 rendering model and exposes all graphics capabilities of the Flash platform as well as offering expandable support to accommodate future capabilities of the Flash Player. The specification below dives into the technical details governing every element of FXG 2.0….”

    More on potential applications from John NackMark Anders has background on the application goals… AdobeTV has tons of perspective and tutorials. Kevin Suttle described a smoke demo of potential tool integration, but even today you can use FXG for CANVAS and SVG. It’s a mystery why this has been ignored.

  • The best resource is likely… Creative Suite 4! Every tool already produces HTML’s various files. Even has VIDEO support, at least of the H.264 persuasion. You know down deep that Adobe tooling is already a key component in HTML workflows, and there’s no reason by this point for that to change. Your challenge is more to clearly identify what specific changes you need in your own overall work… that’s easier for us to target than just a broad “create the tools with which rich HTML5 content is created”.

Future versions of Adobe Creative Suite? It’s a big software effort, often on a two-year cycle. I know they’re adding “HTML5″ features for the next big release, but we don’t yet even know the runtime engines which will render those new HTML tags — it’s hard to get extensive. As John Nack said the other day, “Adobe makes nearly all its money selling authoring tools that target great runtimes.” Tooling needs to follow implementations… once consumers possess a capability, then content creators can begin to rely upon it. It’d be hard to satisfy all expectations at this point.

Ditching SWF and turning the Flash Professional authoring tool into HTML? Why? What would you do for a movie clip? The application and its interface are already designed against a set of capabilities… you’d have to yank features out and retool the UI after suddenly changing the foundation. A rousing slogan, but think it through.

A short and sad final note, after reading tons of debate the past few days: When you say other things shouldn’t exist — when you seek to kill others, rather than discover what you yourself can be — the rest of us have problems finding ways to tolerate your intolerance. Please, let yourself open up.

Gordon, formats, runtimes

No big news here… just tying together observations on different types of file formats, and how they interact with different types of local runtime engines.

Last week Tobias Schneider released a project named Gordon, a JavaScript library which parses a SWF and renders some all SWF1 tags [demos]. It’s in the spirit of the previous “SVG in SWF” work from Helen Triolo, Claus Wahlers, Brad Neuberg and others — rendering one file format in a runtime designed for a different file format. Geeky, and admirable.

I liked seeing Gordon arrive, because it proves that SWF, SVG and such are just file formats, interconvertible with varying degrees of fidelity — of the same species. Neither is a black box, both have been publicly specified for over a decade, and different types of code can produce, consume, and work with them. Anybody can use either, do whatever they want with ‘em. SWF and SVG are both useful and flexible file formats.

But some of the reaction was a little strange — I’d rather not embarrass people by linking to articles, but (edited) titles like “Gordon Lets You Run Flash On Your iPhone” and “Open Source JavaScript to Replace Flash?” give a flavor. Much of the initial commentary did not seem to distinguish between a file format as a set of instructions, and a runtime as the clientside engine which executes those instructions.

Using instructions in unexpected ways is fun. Different examples include Microsoft Gestalt (writing Ruby or Python in an HTML page), Flash Pro (the announced ability to export ActionScript as iPhone-native), much of the Flash 3D work (taking the Collada modeling file as a datasource). On the flip side, XML is a file format which was expressly designed for universal use.

But each of these file formats is then processed by an engine of some type, often a clientside runtime. It’s the interaction of format and runtime that determines the actual feature set, the actual performance, the actual deployment cost.

Here’s an example of the confusion: “While the open source Gordon is available to all, it still doesn’t solve one of Flash’s biggest problems. These SWF files still hog the CPU. One demo, a simple vector graphic of a tiger, throws my desktop browser up to around 100% CPU usage.”

Do you see the problem? The author assumes that his performance is controlled by the content — the instructions — rather than the way those instructions are processed in his environment.

Another example: “This frees Flash from requiring a plug in. But it’s also a proof of concept that shows that you can do all the cool, propritary-plug-in stuff using just plain HTML.” Even if this JavaScript library could acceptably handle all the SWF10 tags (instead of some all SWF1 tags), it would still be a JavaScript library, downloaded afresh each time. Sending your runtime code as file format is not as efficient as using a native local runtime engine.

Perhaps the most concerning type of theme: “Any developer wishing to get their Flash files to work on iPhone just needs to ensure they include a HTML wrapper and through the power of Gordon it should ‘just work’.” Here there seems to be an assumption that all runtimes are interchangeable, and that certain file formats are more magic than others.

When a Gordon project “runs on an iPhone”, it’s actually a SWF being parsed by JavaScript instructions which are executed by Apple’s Safari runtime engine. Although this SWF file format is being used, it’s more properly a Safari app than a Flash app by that point.

It’s fun to use file formats in unexpected ways. But different runtime engines are tuned for different jobs, optimized for different types of instructions. Flash’s textfields can display HTML, but you wouldn’t use that to replace your local dedicated HTML-eating runtime engine. Different runtimes are engineered to take best advantage of different file formats.

I like the Gordon project, because it shows there’s nothing mysterious about SWF. Just like HTML, the file format definitions have been public for over a decade. They’re of similar nature, similar usability.

There are differences — SWF is binary, rather than text — that’s a meaningful difference. Another difference is that HTML is about hypertext, while SWF has been designed from the start for rich-media interactivity. Or you could argue that Adobe has provided saner governance over SWF than the WhatWG Consortium has over “HTML5″. The biggest difference between SWF and HTML is likely in the predictability of the runtime engine.

There are differences between HTML and SWF, but even a JavaScript engine can understand simple SWF files… nothing mysterious or alien about it.

[Update: Changed "some SWF1 tags" to "all SWF1 tags"... my apologies to Tobias, I had forgotten that the FutureSplash Animator version had only a dozen logic elements!]

Private Browsing

Good news… Adobe Flash Player 10.1 can tie into the “Private Browsing Mode” of some browsers, meaning that any local storage is flushed at the end of each session.

I haven’t worked with it across browsers myself yet, but it already tests successfully within Microsoft Internet Explorer 8.0, Mozilla FireFox 3.5, and Google Chrome 1.0. Apple Safari is also reported to be supporting it in the future. (I’m not sure about Opera’s Private Mode, especially in light of their quotes about plugins, but I hope it will also work in Opera.)

This won’t matter for most of us, but is good protection on shared screens (libraries, hotels, etc)… if we enter a password on a public computer, this could clean out all traces in both the browser’s cache and Flash’s Local Storage.

The Flash Player’s local storage options have existed since Player 6 in 2002, possibly earlier. They’re necessary for storing application state across sessions, and also for synching with servers. Back then browsers rarely offered interfaces for managing their own local storage, so Player offered a mini-UI on a context-click, and a larger Settings interface on an adobe.com webpage to expose your local data store. Now that browsers are offering more mature privacy controls — and ones with which plugins can connect! — it’s great to see many control aspects united in a common interface.

This may cause complications for content developers, however. While “Private Mode” makes most sense for public screens, their alternate name of “Porn Mode” implies use on family machines too. If someone returns to a game after entering Private Mode, then the game may not recognize their previous levels of accomplishment. Even within the same Private Mode session, browsers vary in how they handle inter-page communication, so it may be difficult to retain app-state across HTML refreshes. The last half of the Developer Connection article has more info on potential new support costs.

If you’re working in this area of local storage, then you might also want to check into “3rd-Party Cookies, DOM Storage and Privacy”, a recent survey of how different browsers deal with different third-party storage requests in different user-modes.

Cooperation on “Private Mode” settings is a positive step, but there’s still more work to do… as Adobe’s Brad Arkin recently explained: “For a long time we have been trying to work with the web browser vendors for them to open up the API, so that when the user clicks ‘clear browser cookies,’ this will also clear the Flash Player Local Shared Objects. But the browsers don’t expose those APIs today. That’s something that we’ve been working with the browser vendors, because if they can open up that API ability then we can hook into that as Flash Player, so that when the user clicks ‘clear’ it will clear LSOs as well as the browser cookies. Our goal is to make it as easy and as intuitive as possible for the users to manage Local Shared Objects. There’s a lot of study going on right now around the user interface and the integration at the browser level of how we can best support that.”

(btw, I do not agree with pundits’ speech that “privacy is really, really dead”… most of these arguments are of the form “privacy is not absolute; therefore it does not exist”. Just as with protection from crime or disease, the goal is to minimize your exposure to risk. In this case it’s prudent to minimize the effect of web trackers to create proprietary databases which are then potentially vulnerable to internal or external breaches. Just because we likely cannot resist a highly determined privacy attack does not imply that we should fail to protect against all other privacy risks.)

Helping video understanding

Apple-oriented pundit John Gruber writes of his understanding of showing video in browsers. Here are some tidbits which may help:

  • HTML 4.0 did deprecate the realworld EMBED tag, but the Apple/Google/WhatWG “HTML5″ proposals bless it again.

  • VIDEO tag is not a Standard, nor a W3C Recommendation… this shouldn’t stop your experimentation, but neither should the label “standard” stop you.
  • Congratulations on moving past the very proprietary “QuickTime”… the stewardship of that proposal has been disappointing.
  • If thinking of VIDEO tag, you must think of codecs too… Ogg Theora decoders and VIDEO tag parsing do not completely overlap.
  • It’s fortunate that this experimentation was performed on a site where two-thirds of the visitors use Apple-branded browsers. Most sites don’t enjoy the luxury of such near-monoculture.
  • Yes, buffering and startup behavior, like codecs, are issues which were not adequately addressed in the spec. Specifying a VIDEO tag was an easy first step, but does not suffice… captioning, for instance, has been a particularly divisive omission. The WHATWG proposals make more sense as a “blessing” of what Apple was going to do anyway.
  • “I think the HTML5 spec should be changed such that the value of the autobuffer attribute may not be ignored.” May be difficult, due to last call.
  • “Why would I publish content using a technology that I personally block by default?” Because it works.

Two incidental followups: I’m still seeking the factual basis of that surprising claim “We know for a fact that Adobe has no interest in the Mac implementation’s quality,” and if you could correct that prior “arrogance” claim to reflect what I actually said then that would be great, thanks.

[Comments: Ideas are good, but trolls won't be fed.]

Levels of Runtime Predictability

Yesterday Peter-Paul Koch followed up on his testing of browser technologies with a piece examining implementations of one particular browser library, and concludes There is no WebKit on Mobile — there’s iPhone WebKit, Android WebKit, S60 WebKit (at least two versions each), Bolt, Iris, Ozone, and Palm Pre, and I don’t doubt that I’ve overlooked a few minor WebKits along the way.”

I’d urge you to read Peter-Paul’s original paper, as well as followup essays by Savio Rodrigues, Stefan Constantinescu, others.

WebKit is an interesting situation. In HTML itself the file format is openly published, and implementers are encouraged to build their own versions. The WebKit project, under Apple governance, openly publishes HTML runtime source code, which is then modified and distributed by device manufacturers.

In HTML, a file format is “open”, and implementations vary. In WebKit, a reference implementation is “open”, and device-specific implementations still vary.

Flash complements these two. The SWF file format is openly published, same as the HTML file format (although governance of file format improvements is within the Adobe ecology, rather than the W3C/WhatWG ecology). With Open Screen Project we’re more in the WebKit range, where Adobe establishes the reference implementation, and partners customize this to their device. Flash Player 10.1 will differ across device based upon device capabilities (screensize, input methods, accelerometer, etc), but I don’t expect it to vary in basic runtime capability the way WebKit does.

Is one better than the other? Is WebKit better than HTML, or Flash better than WebKit? I don’t think so… each serves different purposes. Apple’s donation of WebKit sourcecode helps resolve some of the implementation differences of the HTML/JS/CSS/DOM/etc specifications. Adobe donates a standard Flash implementation to the world’s screens. These options are better when they work together, when one doesn’t try to be the other. They’re different… both good.

Advanced Support, from Diverse Audiences

Google did an interesting thing yesterday… they extended the Microsoft Internet Explorer browser to dramatic degree, offering Google’s own Chrome browser as an alternative renderer within Internet Explorer’s windows. Here’s where to download the “early-stage open source plug-in”, and many opinions are collected at Techmeme.

I haven’t investigated the hack’s details, and know nowhere near enough to speculate how the project might evolve. But it’s significant, to me, for being the first comprehensive attempt to address bringing the “HTML5″ ideas to realworld audiences.

A person’s browser becomes their habit — they’re loathe to give up surfing efficiency, not quite willing to risk the expense of exploring a new interface. The global surfing public has diverse choice in browsers, and Microsoft Internet Explorer has proven to be a very strong habit for many.

Google Chrome Frame is (from what I understand) respectful of the current user experience… people don’t need to risk their existing browser habits and efficiencies, yet can still explore something new.

I like that. It’s like the Adobe Flash Player… a capability which can be invoked across a wide range of HTML engines… an invisible addition, uniting browser choices.

There’s a wry aspect to the news too, of course… in 140 characters: “So Google’s using a browser plugin, to advance WhatWG’s ‘HTML5′, which tries to do what plugins already do, coz plugins are bad. Is that it?” Seemed to have struck a chord.

There’s no need to seek direct conflict. People have been improving browsers for fifteen years, and while growth is slow, it is steady. No need to bash plugins when announcing new feature sets.

Plugins enfranchise minority browsers… the De Facto Web is a more accessible scene than If Plugins Never Were. Objecting “because it is a Plug-in” is as empty a phrase as objecting “because it ‘IS’ proprietary.” No need to be a hater or a killer. It’s too weird to hear closedness coming from those evangelizing openness.

So, welcome Google, to the challenge of cross-browser plugins — improving the capability of diverse consumer installations, by cooperating with their choice of browser configurations. Glad you’re here, it’s a little less lonely now. ;-)

(Hmm, matter of fact, why isn’t there much talk yet about making an Ogg Theora set of plugins? Seems to make sense, so that sites which prefer opensource codecs can accommodate diverse audiences without making content developers sweat the multi-encoding. Here’s a request from May 2009: “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 [please] improve your plugin support and cross-browser homogeneity so that they are.” Why shouldn’t “open codec” people make cross-browser plugins too?)

Comments are turned off on this entry, due to past history on the topic. If you’d like to do your own blogpost, then including the phrase “Advanced Support, from Diverse Audiences” in the text will let me find it find it fastest in the search engines, thanks!

World Wide Web… legacy content?

We’re familiar with workstation display screens, and are coming to grips with pocket-sized display screens, and next year we’ll start seeing “digital home” screens.

What types of interactions will we have through The Internet, sitting back a few feet away from a large entertainment screen, remote control in hand?

Take a look the photo in Jessica Hodgson’s WSJ article on upcoming Internet TV models. It shows a future TV with a slide-out tool bar, little application widgets available. The looks don’t matter at this point — think of the function.

You’d want to customize the types of info you can call up. Probably a notification system of some type, IM presence, caller ID, a webcam to the front door, various personal services. You probably wouldn’t want to dig into a big document on that big screen — more like quickly monitoring changing world conditions, connecting to others.

Would you want to use a web browser? to surf the Web? to pull up pages which were designed to fit a certain laptop sized screen? to have the ads and the sidebars and the third-party widgets that today’s WWW pages possess? Take a look again at that photo… would you want browser panes and all up on that screen?

I don’t think so. It would be good to have access to a WWW browsing tool, but the numberless millions of today’s WWW pages were explicitly designed for laptop display screens. The very network effects which led to the fast growth of WWW content over the past decade make the viewing not quite satisfactory with other types of digital display screens.

Your mobile phone has a WWW browser. It’s indeed handy. But if you have the choice of a fullsize screen, this is much handier. Or if the site has a parallel version designed for a small screen, then that’s handier too. It’s useful to be able to Surf the Web on a small screen, but the bulk of the content on today’s WWW is not very friendly to unexpected display devices.

Now, the web tech itself can make the crossover across devices, I think… shouldn’t be any reason why hypertext markup and JavaScript couldn’t drive a good TV display too. But the World Wide Web of content, all those pages, all those sites… it’s hard for me to picture that as being as much fun eight feet away from the screen with a keypad.

Web tech… that’s a different subject than WWW content. That content was tuned for one screen. In a multiscreen world, we have to figure out how to migrate the useful parts of this legacy content.

If you’ve got a work screen, a pocket screen, and a home screen, it would be strange if they all showed the same thing. The World Wide Web’s current content is largely designed to be displayed upon a workstation screen. It’s legacy content.

Followup on last post

Yesterday I pulled out a section from the Adobe analyst call, where Adobe CEO Shantanu Narayen was asked “What do you think of ‘HTML5′?” The key points were (a) “to the extent that an improved HTML standard accelerates innovation and consistent reach for web content, we’re very supportive”; (b) “the challenge for HTML 5 will continue to be consistent display across browsers”; and (c) “the fragmentation of browsers makes Flash even more important”.

That’s what Adobe says, and I agree with it.

But I also added some points of my own which may have confused others, judging from the comments at the original post, at Digg, articles, elsewhere. Let me re-run some passages:

“It’s hard for Adobe to have an official opinion on whatever this consortium of minority browser vendors chooses to do… seeing what the final agreement turns out to be, and how it is eventually manifested in the world, both are prerequisites for practical tool-making.”

Another way of speaking this idea: The WhatWG “HTML5″ proposals are underwritten by browser vendors, and will apply to browser vendors. As a toolmaker, Adobe would naturally be slower to speak on it than the browser vendors themselves. Tool vendors follow later, looking at what customers need to do, are able to do. It’s no surprise that most of the early “HTML5″ conversation has been dominated by browser vendors rather than tool vendors.

(That “minority” phrase confused some. Microsoft Internet Explorer is the majority browser… IE6 declining, IE8 advancing, IE7 used by the greatest portion of web surfers… all the other browsers added together support less than half the audience of what IE supports. I haven’t seen any realistic plan to make “HTML5″ practical for content developers or site owners, who cannot afford to turn the majority of people away. This “minority browser” problem needs to be addressed for “HTML5″ to succeed.)

Another section some found confusing:

“I’m increasingly uncomfortable with calling the WhatWG proposals ‘HTML 5′ though, and particularly when it’s used in opposition to successful realworld capabilities of today. When ECMAScript 4 was in discussion there weren’t magazine headlines about how untyped variables were now evil. What counts is not a press release, but a realworld deliverable. De jure is nice, and potential de jure is also interesting, but de facto capability determines what you can actually do for real audiences.”

Much of the early evangelism about “The HTML5 Standard” attempts to persuade by implying that it is already “a standard”, a foregone conclusion, a done deal. If you’ve been following things closely, though, you know there are multiple friction points. The future is far from clear.

I use quotes around the term because it is a name-of-convenience we are applying to a particular process which has not yet run its course. It is not “HTML 5.0, a W3C Recommendation” … it is something we are calling “HTML5″ as a verbal shortcut. As the W3C Blog itself says, “HTML5 isn’t a W3C standard. We certainly look forward to the day when it is, but it isn’t yet.”

Comparing a future potential to a current reality may not make much logical sense, but it does make journalistic sense and evangelical sense. Particularly in light of consortia work such as XHTML and ECMAScript 4, it’s more sensible to observe what the world actually is, rather than assume the world will match our plans.

That’s why I’m putting “HTML5″ in quotes. It’s more realistic.

A sidenote: Most of the critical questions focused on minutiae off the main topic. I thought the “minority consortium” section didn’t warrant the commentary it received… there was a whole segment about iPhone helping Flash Lite… one person was sure I hadn’t been tracking this subject for years… some asked “Why are you so defensive when people talk of Killing Flash?” These glossed past what Shantanu emphasized about “consistent reach for web content”. Instead of focusing on how “HTML5″ will actually work for the world, commenters’ attention was fragmented into extraneous issues. Noteworthy.

One other oddity about the previous post and spinoffs: the number of anonymous critics. If you don’t think your words are valuable enough to own, then they’re probably not valuable enough for us to spend our time reading. Bet your rep — show us the totality of the person behind the words, and the other words you’ve written elsewhere — or your comment will not be published here on this entry. Open up.

Update Tue June 23: I’m closing off comments on this entry, for two reasons: (a) latter comments are repetitious and off-topic, with people seeking any reason to reject the neutral info presented above; and (b) one Mac-oriented blogger who attracts an abusive crowd has pointed this link out, and I’m not keen on hosting drive-by ranters.

Adobe on “HTML5″

The current WhatWG proposals called “HTML 5″ have been stirring up a lot of polarizing speech lately… articles with Flash-killer headlines lead to street-level fracases.

It’s hard for Adobe to have an official opinion on whatever this consortium of minority browser vendors chooses to do… seeing what the final agreement turns out to be, and how it is eventually manifested in the world, both are prerequisites for practical tool-making.

Still, I’m glad that an analyst asked a question about it at the quarterly financial call. Here’s what Adobe CEO Shantanu Narayen had to say, from the transcript at Seeking Alpha:


David Hilal – Friedman, Billings, Ramsey

Okay, and then Shantanu, maybe a bigger picture question but as we read and learn more and more about HTML 5, I wanted to understand in your view both the opportunity and threat that that may present to Adobe.

Shantanu Narayen

Sure. So I mean, to the extent that an improved HTML standard accelerates innovation and consistent reach for web content, we’re very supportive and clearly from the perspective of our tools, we will support the creation and management of HTML content to the level that they want.

I think it speaks increasingly to the realization that rich Internet applications and delivering engaging experiences is increasingly important to all of our customers. I think the challenge for HTLM 5 will continue to be how do you get a consistent display of HTML 5 across browsers. And when you think about when the rollout plans that are currently being talked about, they feel like it might be a decade before HTML 5 sees standardization across the number of browsers that are going to be out there.

So clearly supportive in terms of making sure as HTML 5 is evolving that we will support it in our web authoring tools but from the perspective of continuing to drive Flash and innovation around Flash and rich Internet applications, we still think that actually the fragmentation of browsers makes Flash even more important rather than less important.

David Hilal – Friedman, Billings, Ramsey

Great. Thank you.

Adobe’s about communicating your ideas — publishing to various channels — not just about Flash. Dreamweaver, ColdFusion and the imaging tools all benefit from an increase in HTML. Flash is a strong bet for emerging platforms — we really do need the ability to predictably deploy advanced capability across a range of device brands and browser brands — but Adobe profits from easing communication in general.

I’m increasingly uncomfortable with calling the WhatWG proposals “HTML 5″ though, and particularly when it’s used in opposition to successful realworld capabilities of today. When ECMAScript 4 was in discussion there weren’t magazine headlines about how untyped variables were now evil. What counts is not a press release, but a realworld deliverable. De jure is nice, and potential de jure is also interesting, but de facto capability determines what you can actually do for real audiences.

But Shantanu’s last point in there really resonates with me… this whole “HTML5″ campaign will likely benefit Flash, because few remain who oppose the idea that “experience matters”. Things are quite a bit different than five years ago. Silverlight’s launch helped boost the popularity of Flash… iPhone helped to radically increase the number of phones with Flash support… the “HTML5″ publicity helps marginalize those few who still argue that images, animation, audio/video and rich interactivity have no place on the web. Flash will be able to deliver on those heightened expectations, regardless of what each separate browser engine does.

Update Tue June 23: I’m closing off comments on this entry, for two reasons: (a) latter comments are repetitious and off-topic, with people seeking any reason to reject the neutral info presented above; and (b) one Mac-oriented blogger who attracts an abusive crowd has pointed this link out, and I’m not keen on hosting drive-by ranters.

Amazing AIR 4.0 demos!

If you’ve been reading the techblogs this week, you may be wondering “Is this the death of Flash?” There’s lots of commentary out there, and no matter how ill-founded, we’ll all likely end up in conversations with less-clued-in coworkers or friends asking, “Hey, I heard that *this* will finally be the death of Flash!” Fun, huh?

If so, then relax. It’s all going to get worse. ;-)

There are more corporate conferences coming up in the next few weeks, and a browser release or two. These are easy stories for a PR staff to get placed in newsblogs. We’re only at the beginning of a hype cycle. There’s more to come.

In a way, it’s similar to the blogosphere buzz cycle around Silverlight a few years ago. Back then it was tough to swallow comments like “makes Flex look like a toy”, “the execution of Adobe”, “the Web was rebooted today” and the like.

But it’s easier to deal with such high-level assertions once you examine the low-level basics. The WhatWG is a set of browser vendors who are drafting a new version of Hypertext Markup Language, and much of the controversy is around whether various vendor RIA specifications fit. One tipoff is that core questions — handling the IE-using majority, “plugins are good when they’re Google’s”, what VIDEO tag will actually do, “what innovation’s in imitation?”, many more — are actively being ignored. The only response is namecalling.

This is different than the Silverlight dynamic. Microsoft staff and fans actually addressed reasonable questions. Their weblogs were open to other viewpoints. Dissent was not ridiculed.

Further, these questions today are coming from the grassroots. Top-level bloggers may be touched for a good story, but their commenters raise a whole series of reasonable questions. And they get — no answers. That pressure for truth and openness will not decrease.

Here, let me pull some of the comments which struck me from a recent oreilly.com transcript of a Google presentation. (I’m leaving out names because I’m interested in the ideas, but if you commented there and want your words removed from here, then please let me know, thanks.) It’s just one blogpost’s comments among the many, but shows the disconnect between the suits and the street:

“Most companies want to reach the widest audience possible and will likely continue to ask for IE6 support for another 2 to 3 years. So we are looking at another 5 to 7 years before IE7 can be ignored and working with whatever basic HTML5 support is available in IE8.”

“The Google mantra about the web vs desktop is b******t. Do an objective comparison between (canvas or svg) vs ((flash or silverlight) or desktop) and you’ll quickly note the differences. We don’t need an academic paper or more buzz.”

“There’s no standard for video codecs, meaning each browser vendor will decide on what codecs to support if any. Which means in order for the video tag to work, the web developer will have to supply multiple versions of the video in a variety of codecs. This has the potential to get even messier… Meanwhile, from a user’s perspective, you unfortunately will have to switch browsers to view video in a different codex, which certain users may want to, as there’s a big difference in quality and performance in video codecs.”

“It’s just INSANE that people try to evolve on things like HTML, CSS and Javascript. CSS and HTML are not consistent and not all that robust.”

“Hi Tim, You wrote: ‘Microsoft has announced that it will support HTML 5.’ I’ve also read they have suggested breaking out different working groups to work on different parts of HTML 5. Do you have a link or reference to something where they’ve actually said they will support all the major features, in one form or another, of the current HTML 5 draft? I went looking for some sort of statement but couldn’t find it. Microsoft is always the elephant in the room when it comes to cross-browser support for HTML 5.”

“There are no plugins perhaps, but because several major vendors have refused to support Ogg Theora, there is currently no standard codec that does not have patent problems.”

“A couple of others have already made the ‘what do you mean, no plugins, no mismatched codecs?’ comments that I was going to add… Sadly, I see the demo html5 page at youtube seems to present only proprietary .mp4 video, requiring a proprietary plugin for those of us not using Safari.”

“In the graph the vertical axis is nerdgasmicity. The horizontal axis is goldfish-time. I got this from reddit.”

“Google going big for HTML5 is probably helped by the fact that the sole author for HTML5, Ian Hickson, works for Google.”

“OK, HTML 5 is probably awesome. But IE is gonna screw it all up by being 5 years late to adopt or going their own direction. Standards are great for development, but only if they are enforced!!”

“On the plugin vs. HTML 5 comments I don’t understand why anyone assumes it is a winner-take-all contest or that we will escape from “plugin hell” any time soon. The work Google and Mozilla are doing is wonderful but I also think many people take a more realistic attitude toward the value of plugins.”

There are some personal judgments in there, but also some reasonable questions too.

This week, those reasonable questions may be overwhelmed by effusive hype, but these questions will persist.

These are questions that the presenters must persuasively answer before the future they declare can arrive.

So… if you talk about Flash with your partners or friends, the next few weeks may be difficult. I don’t think the hype will reach Oprah-like levels, but it will be close. Hang in there. Look at the claims yourself, seek out skeptical questions, determine if these are openly answered.

But the trend’s your friend. Hype cycles last only so long before the journalistic pressure to debunk them becomes overwhelming. Truth does out. ;-)