HTML 5 Circus

March 6, 2011 9:40 AM

Mozilla's HTML 5 Circus rolls into town. The emergence of HTML 5 is marked by, among others, emerging browsers (or browser versions). The soon to be released Firefox 4, often delayed, mirrors the slow march to an HTML 5 Flash reduced web. Like others, Mozilla feels the need to sell HTML 5. We also have Chrome Experiments, Canvas Demos, IE HTML 5 demos and Never Mind the Bullets, and Apple's (warning: sniffer protected) HTML 5 showcase.

A collection of emerging standards also equates to difficult challenges. Should you pull the trigger now and if so, how? How did we get into this situation? Sites using HTML5 exist today.

posted by juiceCake (102 comments total)

Unfortunately, your browser does not support WebGL. To view any of the demos tagged with WebGL, please install an up-to-date web browser (Firefox 4 Beta or Chrome 9) and up to date video card drivers.
You can still watch screencasts of the WebGL demos or fully experience our other non-WebGL demos without updating.

Party like it's 1997
posted by device55 at 10:03 AM on March 6, 2011 [2 favorites]

Party like it's 1997

I feel the same way every time I buy food with side-by-side oven and microwave instructions.
posted by tapesonthefloor at 10:05 AM on March 6, 2011

Ooh. Snark pile on! Ahem... Wow, HTML5 demo's, it's like it's 2005 again!
posted by bjrn at 10:06 AM on March 6, 2011

Snark aside, Dive Into HTML 5 is a great resource available in non-DRM'ed eBook form O'Reilly as HTML5: Up and Running.

It shows how to integrate less bleeding edge HTML features in such a way that it doesn't screw IE8 users.
posted by device55 at 10:07 AM on March 6, 2011 [1 favorite]

I've been doing a lot of work with modern Javascript and SVG lately, largely with Protovis, Polymaps, and the new D3 toolkit. And it's freaking awesome. I finally decided IE can just go screw itself, at least until IE9, and too bad for those users. It's liberating.

Of course, my project is a complex data visualization with scaled vector graphics on maps. If you're just building a basic content site, it's overkill.
posted by Nelson at 10:14 AM on March 6, 2011 [2 favorites]

Okay, Firefox 4, you support a built in vieport for OpenGL 3D graphics, but you do not yet support Text-overflow: elipsis? Let me ask you, which of these do you think I actually need when building a website, as opposed to an overgrown tech demo?
posted by Artw at 10:20 AM on March 6, 2011 [6 favorites]

Nice overview, juiceCake, although I would suggest that the book links don't add much to the post. As for HTML5 itself: I'm holding off using it in production until at least six months after IE9 has been released. There are certainly solutions out there that attempt to bring previous versions of IE up to speed with the spec, but I'd prefer at least some of my IE-using visitors to have native support rather than relying on JavaScript or plug-in shim. (That being said, there's a fairly strong argument that IE9 won't support nearly as much of the current spec as Microsoft is suggesting).

The biggest hurdle facing HTML5 to me is not the spec itself, but standardisation on, and browser support for, AV codecs, an issue which is likely to become the new front in the browser wars for this decade. There's also the potentially confusing fact that HTML5 is to become a "living document", constantly under growth and revision, with no versioning at all: HTML5 is now just HTML. There is the awful possibility - remote, at this point - that HTML5 will become a dead spec walking: never finished, bits falling off, constantly shambling forward.

<audio>, <video> and <canvas> are all well and good, but what gets my geek-heart thumping are the new, small tags like <article>. <time> and <figure>. Used properly, they have the potential to give the web far more semantic richness, better search results, and easier sharing of data across sites.

And then there's CSS3, and embedded fonts, which are going to explode just as soon as font foundries like Hoefler and Frere-Jones sort out their licensing issues.
posted by Bora Horza Gobuchul at 10:21 AM on March 6, 2011 [2 favorites]

We've been aggressively weaning out IE6 for more "standard" web site and using some basic CSS3 techniques (with some legacy 'filter' fallbacks for IE and a tricky homebrew HTC to fake rounded corners) and it's quite nice.

It's lovely to not have to have 47 background images on a page (because designers can't design anything without rounded corners - me included)

But whenever I see "your browser doesn't support foo, download X" it reminds me of "This site best viewed in Netscape Navigator" and I donlikesit.
posted by device55 at 10:22 AM on March 6, 2011

I finally decided IE can just go screw itself, at least until IE9, and too bad for those users. It's liberating.

While this approach was a no-hoper a few years ago, it's becoming increasingly reasonable, or at least reasonable for an increasing subset of domains. If your site is pitched at a particular community (for practically any definition of the term) rather than casual browsers, and isn't ecommerce related or something someone might need to access at an airport kiosk or internet cafe, then why the hell not? Asking someone to install a more capable browser isn't going to work for American Apparel but if you have a more focused or specialized audience you might as well. In some sense you're probably doing them a favor.
posted by George_Spiggott at 10:24 AM on March 6, 2011 [2 favorites]

Don't mean to comment spam, but...

(That being said, there's a fairly strong argument that IE9 won't support nearly as much of the current spec as Microsoft is suggesting).

This is too true. IE9 doesn't support CSS gradients (or didn't at the time I was hacking on it).

IE9 falls back on legacy, proprietary "filter" gradients which are far less full featured (only vertical and horizontal, no radial, only two color stops). They also fail with rounded corners.

So in IE9 if you make a rounded box, with a filter-gradient background, the gradient pokes through the rounded corners. Sucks.

(I did come up with an svg hack solution that works around the problem. but jeez)
posted by device55 at 10:26 AM on March 6, 2011

Sweet! A scripting language running in a document viewer can finally almost do most of things software not running in the document viewer can do!
posted by 0xdeadc0de at 10:28 AM on March 6, 2011 [5 favorites]

Mozilla's HTML 5 Circus rolls into town.

Call me when they release a produciton browser that supports it.

Hint: Anything with the word "beta" in the name is not a production browser.

They also fail with rounded corners.

It seems everything fails, in one way or another, with rounded corners.

SysAdmin: "This breaks on everything. We're not going to do that."

WebDesigner: "This breaks on everything. I'm going to code a set of browser aware hacks to make it work on most things. AAAGHH, IT LOOKS LIKE SHIT ON IE6. HATE HATE HATE. AND WTF, MOZILLA, IT WORKED BEFORE!!!11!!!"

Hmm. Why, I wonder, are we blaming IE6?
posted by eriko at 10:36 AM on March 6, 2011 [1 favorite]

Hmm. Why, I wonder, are we blaming IE6?

I blame the marketing department.
posted by device55 at 10:39 AM on March 6, 2011 [3 favorites]

Just even talking about the mechanics of HTML and browser versions is not so mainstream interesting anymore. More of a niche for specialists and geeks. Such is the narrative arch of technology. Remember when microchips in the 80s made constant front page news, or OS technology in the 90s led to near civil wars. Who really cares anymore if you use Win7 or Ubuntu or Apple, they all work great and well supported. I think an up and coming popular discussion will be about IP addresses and IPv6 once people realize it's the Peak Oil of the nets.
posted by stbalbach at 10:39 AM on March 6, 2011

<fail>
...but we still have to use javascript kludges to get a decent fluid multicolumn layout...
</fail>

though i read it's a proposed css3 feature
posted by 3mendo at 10:42 AM on March 6, 2011 [3 favorites]

If you are supporting IE<9 and would like to use things like rounded corners and gradients, you are doing yourself a tremendous disservice if you're not using CSS3 PIE. It has a few limitations (only linear gradients with two stops, no text-shadow), but I've found it to be pretty damn solid on a site I'm working on that has to support IE6 and up. I have places where I'm using box-shadow, gradients, and rounded corners all together on the same element, and it works just fine.
posted by !Jim at 10:53 AM on March 6, 2011 [2 favorites]

I only dimly understand the issues involved. But if HTML 5 sucks in the ways suggested, will it not be possible to simply continue using HTML 4?

Or is the plan to break HTML 4 on purpose?
posted by Joe Beese at 10:56 AM on March 6, 2011 [1 favorite]

<fail>
...but we still have to use javascript kludges to get a decent fluid multicolumn layout...
</fail>

First result on google for “fluid multicolumn layout”. No javascript needed.

I have no idea what “decent” means in this context, because I hate fluid layouts.
posted by !Jim at 10:56 AM on March 6, 2011

I only dimly understand the issues involved. But if HTML 5 sucks in the ways suggested, will it not be possible to simply continue using HTML 4?

Or is the plan to break HTML 4 on purpose?

Actually, it is the other way around. HTML5 was designed by first looking at which features were supported in today's browsers and starting from there. So backwards compatibility was a huge priority.

The main difference between the way HTML5 and HTML 4 were developed is that it is the browser manufacturers and web developers who are (largely) calling the shots with HTML5. While this comes with its own set of complications (see the video codec wars), for the most part this is a good thing, but like all transitions it will take time to be fully realized.
posted by jeremias at 11:22 AM on March 6, 2011

The difference between HTML 4 and HTML5 is that HTML5 is basically just a marketing term for a random grab bag of crap.
posted by Artw at 11:33 AM on March 6, 2011 [1 favorite]

Apple's (warning: sniffer protected) HTML 5 showcase

Flagged as a double.
posted by Blazecock Pileon at 11:40 AM on March 6, 2011

the slow march to an HTML 5 Flash reduced web

The march is not inexorable and the outcome is not inevitable. Steve Jobs' ironic "walled garden" rants aside.
posted by january at 12:19 PM on March 6, 2011

TBH I would regard a developer who came up with a site that was only usuable in "HTML5" browsers with their prefered feature set of the moment with every bit of contempt I'd give someone who made their site flash only for no good reason.
posted by Artw at 12:22 PM on March 6, 2011 [2 favorites]

The march is not inexorable and the outcome is not inevitable. Steve Jobs' ironic "walled garden" rants aside.The march is not inexorable and the outcome is not inevitable. Steve Jobs' ironic "walled garden" rants aside.

Agreed. But there is already less Flash on the web then say, 5 years ago I'd say. Not because of Jobs and Apple's iOS policies but because of Google and the rise of inexpensive development models that include Content Management Systems which allow sites to be maintained by non-HTML professionals.

Many of these HTML 5 demos are very Flash like without being as good in terms of performance and features but the complaints about annoying Flash ads and annoying Flash performance may well be replace by complaints of annoy "HTML 5" adds and poor Canvas performance.

As a web developer I love a lot of the coming developments but the mess that were in now doesn't look to be going away anytime soon.

Apple's (warning: sniffer protected) HTML 5 showcase

Flagged as a double.

Double what friend? It's just a friendly warning, nothing more, nothing less.
posted by juiceCake at 12:32 PM on March 6, 2011

Dear browser makers I hate you all. I'm only doing HTML 5 to kill java applets and flash which are more horrible. From security to testing and debugging you have done nothing but lead us into suffering despite your half assed ideas and worthless promises. I think we all know as soon as possible we are ditching you to return to native apps. Maybe some remnant of HTML with CSS and would be helpful for document presentation and linking. The whole embed the ui in the user inputted document along with the program code has been a 20 year disaster, didn't we learn from viruses in visual basic for application in MS office!
posted by humanfont at 12:35 PM on March 6, 2011

But there is already less Flash on the web then say, 5 years ago I'd say. Not because of Jobs and Apple's iOS policies but because of Google

Google pushes use of Flash by integrating it with Chrome and by using Flash to support standard video format playback. They are probably the reason Flash will unfortunately still be around for another 5-10 years.

There's less Flash around because Adobe doesn't seem interested in makng it work reasonably well on anything but Windows, and because iOS's HTML5 audience is a significant and financially desirable market.
posted by Blazecock Pileon at 12:50 PM on March 6, 2011

So you're saying you'd rather install a native app for every interface-heavy website you visit? Crazy.
posted by ryanrs at 12:50 PM on March 6, 2011

Very 2008.
posted by Artw at 12:57 PM on March 6, 2011

Google pushes use of Flash by integrating it with Chrome and by using Flash to support standard video format playback.

Perfectly reasonable as long as there isn't a widely supported web standard for video.

They are probably the reason Flash will unfortunately still be around for another 5-10 years.

Well, that and the fact that Flash can still do a bunch of things not even spec'd out in the standards, and the fact that some of the browser makers will take a few years to get everything that is spec'd out, and that there isn't a highly visible point-and-click tool for authoring standards-based multimedia, and...
posted by weston at 1:24 PM on March 6, 2011 [1 favorite]

The difference between HTML 4 and HTML5 is that HTML5 is basically just a marketing term for a random grab bag of crap.

Not entirely true. HTML5 is three things:
1. Ian Hixson's "standard," now renamed HTML, that dictates what HTML5 is
2. The W3C work-in-progress standard that declares to browser makers what needs to be supported and how
3. A random grab bag of crap that's being thrown around in the same sort of marketing way as Web 2.0 was (made all the more annoying because CSS3 was part of Web 2.0 as well as HTML5 -- but is neither)

HTML5 is a floor wax and a dessert topping. It will not kill Flash, not until CANVAS gets some real performance improvements (people while about Flash eating cycles and spinning fans, but it's nothing like the incredible noises I've heard coming from PCs trying to run an intensive chunk of CANVAS). It's just what it is. And like CSS3, HTML5 The Language will get adopted piecemeal until there's some sort of critical mass to get the spec finished (which, finally, is starting to happen with CSS3). Meanwhile, the accessibility and security issues of HTML5, ones that are STILL not resolved after almost 2 years of fighting across and between WHATWG and W3C, are not getting fixed.

Seriously. This was the ultimate time to come up with ways to move forward from Same Origin Policy and XSS. And yet, 15 years on, we're stuck with the same damn vulnerabilities because Hixie thinks browsers should fix it themselves and everyone else has their panties in a twist because of H.264 and LONGDESC.
posted by dw at 1:24 PM on March 6, 2011 [1 favorite]

So in IE9 if you make a rounded box, with a filter-gradient background, the gradient pokes through the rounded corners. Sucks.

That actually happens with images and Firefox 3.x as well. Supposedly Firefox 4 will sort this out. (Seems there was a misconception in the standard that multiple browser programmers made).

Keep in mind, too, that shadows and gradients are big arguments within the CSS working group right now, e.g. text-shadow was dropped due to some implementation issues (though it will probably come back in to the working document soon). Microsoft has said they're committed to supporting all CSS3 standards that are ready to go, and unfortunately, that means there won't be a full implementation of gradient, text-shadow, or text-stroke.
posted by dw at 1:34 PM on March 6, 2011

Microsoft has said they're committed to supporting all CSS3 standards that are ready to go, and unfortunately, that means there won't be a full implementation of gradient, text-shadow, or text-stroke.

I hate MS with the fire of 100 suns, but this is the exact correct answer. If you can't figure out a spec, it is correct to not try to make a half-assed guess on implementation. That's exactly what makes HTML such a pain in the ass to designers. You ought to be thanking them.

How long have we been mucking around with CSS3's spec? Well, we're coming on 12 years since the first CSS3 module was proposed. Oh, and of course, because of the wonderful "module" idea, anybody can toss a new module in at any time.

Then again, CSS 2.1 is a "Last Call Working Draft." Utterly amusing. You've been working on a spec for nearly 13 years, and the best you can do is "Last Call Working Draft?"

No wonder websites suck so hard. Nobody's willing to say no. Hmm, thinking about it, that's probably why XHTML2 failed -- if you actually sent it as application/xhtml-xml and it wasn't correct, the browser threw an error. IOW, it dared to say no.
posted by eriko at 1:43 PM on March 6, 2011

To be fair, it said "No" to just about every existing HTML document. That's gonna hurt your popularity.
posted by ryanrs at 1:50 PM on March 6, 2011 [1 favorite]

So in IE9 if you make a rounded box, with a filter-gradient background, the gradient pokes through the rounded corners. Sucks.

That actually happens with images and Firefox 3.x as well.

Firefox 3.6.1 works as you'd expect (in what case would the background color of a box protruding beyond the borders make sense? Of course the box model doesn't make much sense either. The width isn't the real width. It's the width without padding or borders. So it's not the width. blarg.)
posted by device55 at 2:11 PM on March 6, 2011

The width isn't the real width. It's the width without padding or borders. So it's not the width. blarg

But it now can be for the low price of just four rule declarations (and keeping your IE6/7 in quirks mode):

* {
box-sizing: border-box;
-ms-box-sizing: border-box;
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
}


Of course the box model doesn't make much sense either.

Nope. Never did.
posted by weston at 2:16 PM on March 6, 2011 [2 favorites]

Is there actually an stable unprefixed version of CSS gradients?
posted by Artw at 2:18 PM on March 6, 2011

Firefox 3.6.1 works as you'd expect (in what case would the background color of a box protruding beyond the borders make sense?

The issue/bug isn't with backgrounds, it's with the contained content. If you have an element with rounded corners, overflow hidden and no padding, and then you stick in image (or any other element) inside it which takes up the full width, then the corners of the image will poke out through the rounded corners. This is fixed in Firefox 4.0.
posted by robertc at 2:19 PM on March 6, 2011

Is there actually an stable unprefixed version of CSS gradients?

Nope, it's all still at working draft status.
posted by robertc at 2:20 PM on March 6, 2011

Is there actually an stable unprefixed version of CSS gradients?

No, but this geegaw sure helps in creating them: http://www.colorzilla.com/gradient-editor/
posted by device55 at 2:20 PM on March 6, 2011

The issue/bug isn't with backgrounds, it's with the contained content. If you have an element with rounded corners, overflow hidden and no padding, and then you stick in image (or any other element) inside it which takes up the full width, then the corners of the image will poke out through the rounded corners. This is fixed in Firefox 4.0.

Ah well, that's a different issue and I can see where there would be confusion in the "spec". I doubt the overflow specs directly addressed rounded corners.

It's reasonable to assume the default overflow of 'visible' would apply to rounded corners as well as regular corners
posted by device55 at 2:23 PM on March 6, 2011

Microsoft has said they're committed to supporting all CSS3 standards that are ready to go, and unfortunately, that means there won't be a full implementation of gradient, text-shadow, or text-stroke.

I hate MS with the fire of 100 suns, but this is the exact correct answer. If you can't figure out a spec, it is correct to not try to make a half-assed guess on implementation. That's exactly what makes HTML such a pain in the ass to designers. You ought to be thanking them.

It would be the exact correct answer if MS were actually doing that and not just using it as an excuse to cherry pick the bits of the standards they want to support. For example they dived in and implemented Canvas, but haven't implemented HTML5 Forms (which was the original component of the HTML5 spec, so it's just about the most stable part).

Then again, CSS 2.1 is a "Last Call Working Draft." Utterly amusing. You've been working on a spec for nearly 13 years, and the best you can do is "Last Call Working Draft?"

The standard itself hasn't changed much in years (just typos and clarifications), what we're waiting on is two compatible and interoperable implementations. To determine if you have two of them, you have to have a test suite.
posted by robertc at 2:27 PM on March 6, 2011

I give them credit. A lot of the new features are reflections of how people are actually using the web, which is the way standards should be developed; they should give structure and long-term thinking to the things people actually do, instead of trying to prescribe behavior for them. If only the debate over singular "they" could be done this way.

Three things I think are conspicuously missing (unless they're in the standard and I just haven't heard about them). However, all three would probably have to be implemented concurrently in order to avoid security issues:

1. A <remote> element or attribute, indicating that the content in question should be loaded from another URI. The initial content of that element could be a "placeholder" to allow preprocessing of layout while the remote document is retrieved. A nifty perk might be to allow the "target" attribute on <a> tags to specify a specific remote element by ID and only load that region (goodbye, 80% of AJAX overuse). Security restrictions may be similar to those of XHR, depending on whether the next feature is implemented...
2. The ability to "sandbox" a section of the page, using a mechanism such as namespacing. This would include the ability to exclude that part of the page from expensive DOM processing unless explicitly requested, and to limit the behavior of that component to its own display area and data model. This would allow designers and content developers to easily focus on the structure of their own part of the page without worrying about side-effects and visual spillover... essentially a more robust version of what people currently do with iframes or the "overflow" CSS property. One major benefit would be making it safer to use third-party advertising services without as many cross-site scripting vulnerabilities, as well as limiting the performance and data issues that will be caused by intensive animation markup being incorporated into the overall DOM.
3. A built-in authentication standard at the element level. This would be pretty meaningless without the <remote> element, as you wouldn't submit authenticated content to an unauthenticated user even if their browser prevented its rendering. What it would do would be to reduce the amount of server-side code that goes into things like checking credentials in a million non-standard ways, or handling dozens of different permutations of the same page in a bunch of JSP "if" tags or whatever.

I'd also like to see a better security context for form data. I'm not sure what the exact implementation would be, but what it boils down to is that I'd really like to see a warning if there's ever an <input type="password"> that could conceivably be submitted via HTTP instead of HTTPS. It's 2011 and that shouldn't be happening, people.
posted by Riki tiki at 2:28 PM on March 6, 2011 [1 favorite]

TBH I would regard a developer who came up with a site that was only usuable in "HTML5" browsers with their prefered feature set of the moment with every bit of contempt I'd give someone who made their site flash only for no good reason.

So many times this. I work as a UI developer - I don't design, I realize designs that come to me as .png comps from the designers in HTML and CSS, then hand that off to the developers to advance it from a static goal mockup to dynamic php. Clearly, our designer has recently stumbled across jQuery's UI library, because he's introduced a resizeable jQuery modal that with rounded corners in the latest revision, which now demands that we include the UI library in our .js rollup. Problem is, the UI library is crammed full of browser hacks and therefore doesn't validate through the w3c (one of the requirements of my position, along with cross-browser compatibility from a single stylesheet) as well as adding another 30-odd k to our initial pageload. When I offered a solution that was more appropriate for the use case (a modal of a fixed size with no rounded corners), it was shot down. Has to be the jQuery one. For no other reason than it has to be the jQuery one.

I have nightmares about him hitting some HTML5 demo.
posted by davelog at 2:29 PM on March 6, 2011

I doubt the overflow specs directly addressed rounded corners.

For your reference: Mozilla bug and an examples of the issue.
posted by robertc at 2:34 PM on March 6, 2011 [1 favorite]

Behold, for this is the future. Regard the little particles that respond to your mouse clicks. The smooth gradients. The fluid animation.

And the fact that your computer's fans had to spin up to render that thing. I look forward to seeing more of this functional technology on the web.
posted by mccarty.tim at 2:40 PM on March 6, 2011

Three things I think are conspicuously missing (unless they're in the standard and I just haven't heard about them)

You might get some traction for parts 1&2 of that proposal, but you'd to explain how they offer significant advantages over iframes and the sandbox attribute.

What it would do would be to reduce the amount of server-side code that goes into things like checking credentials in a million non-standard ways, or handling dozens of different permutations of the same page in a bunch of JSP "if" tags or whatever.

I don't see how it could - on the server side you can never assume anything of the client. For example, the client could be a hacker with a specially built web browser which doesn't do any of your proposed client side checking (or someone with IE6).

I'd also like to see a better security context for form data. I'm not sure what the exact implementation would be, but what it boils down to is that I'd really like to see a warning if there's ever an <input type="password"> that could conceivably be submitted via HTTP instead of HTTPS. It's 2011 and that shouldn't be happening, people.

I don't think you'll ever see that in the spec for two reasons:

1. It's really a browser implementation issue rather than a spec issue. The spec could recommend the browser notifies the user in some way, but it's never going to mandate the exact mechanics (the same way the validation notifications for forms are not mandated in the spec).
2. The majority of sites on the web are never going to implement it. For instance I'm not going to buy an SSH certificate just so I can have encrypted log in to my personal blog.

Possibly making OpenID be more easy to use/implement/integrate with the browser would be the way to go here.
posted by robertc at 2:47 PM on March 6, 2011

Has to be the jQuery one. For no other reason than it has to be the jQuery one.

I'm so sorry, man. jQuery is the devil.
posted by Civil_Disobedient at 2:48 PM on March 6, 2011

but you'd to explain

D'Oh! "But you'd have to explain." Like any pre-HTML5 browser, if my sentences don't make sense, please just keep inserting words in them until they do...

I look forward to seeing more of this functional technology on the web.

This is the functional technology we should be more interested in, but it doesn't make for such an interesting visual demo.
posted by robertc at 2:53 PM on March 6, 2011

It's reasonable to assume the default overflow of 'visible' would apply to rounded corners as well as regular corners

The issue was when you had overflow set to hidden, it still acted as if overflow was visible with images. And yes, the bugs are related in that both the IE team and the Mozilla team forgot that boxes can contain more than text, and so they botched overflow on gradients/images.

The ability to "sandbox" a section of the page, using a mechanism such as namespacing.

Actually, you can do this with XHTML5 and CSS3's namespace support, though not in IE 6-8, of course.
posted by dw at 2:57 PM on March 6, 2011

I've been working at a SaaS firm for the last month doing a little UX and a lot of CSS. They're still in quirks mode.

Total number of times I've said "we could do that if we didn't support IE" since I've started has now reached 20.
posted by dw at 2:59 PM on March 6, 2011

So, anyone who follows this industry more closer than me want to say if plug-in-free video is still an issue across browsers? I remember hearing that Firefox currently only supports Ogg Theora, as it's completely open source, and that Chrome and IE support MP4/h.264 because the license is free to use and it's a widely used format. And then apparently Google came out with their own open video format for web video that they were hoping everyone would adopt?

Anyway, what are the chances by the time HTML 5 is more cemented that we'll have consistent video support using just one file format and set of tags for all browsers?
posted by mccarty.tim at 3:49 PM on March 6, 2011

I'm so sorry, man. jQuery is the devil.

I think jQuery rocks - as long as you don't go overboard. I design everything now as XHTML 1.0 Strict with a mishmash of CSS2.1 and 3. Forms are handled with some PHP.

Everything works all the way back to IE6 and degrades nicely.

Could things be better? Absolutely ( I can't wait for easy flowable columns, for example). But things are a lot better than they used to be. Almost bearable, even.

You know a lot of these new standards are gonna be as heavily misused as Flash ever was, don't you?
posted by Benny Andajetz at 3:52 PM on March 6, 2011

Problem is, the UI library is crammed full of browser hacks and therefore doesn't validate through the w3c (one of the requirements of my position, along with cross-browser compatibility from a single stylesheet)

So wait, in your job, validating to a standard is more important than usability and working across browsers? I don't understand.

I shoot for a compliant document, and actually don't use browser hacks at all in my own code, but excluding a very useful and (mostly?) well-regarded UI library because it includes hacks seems kind of insane.
posted by !Jim at 4:14 PM on March 6, 2011

So, anyone who follows this industry more closer than me want to say if plug-in-free video is still an issue across browsers?

It is more of an issue than ever, actually, since there is now Google's "WebM" format in addition to Ogg and H.264.


Anyway, what are the chances by the time HTML 5 is more cemented that we'll have consistent video support using just one file format and set of tags for all browsers?

1%
posted by jeremias at 4:17 PM on March 6, 2011 [1 favorite]

Anyway, what are the chances by the time HTML 5 is more cemented that we'll have consistent video support using just one file format and set of tags for all browsers?

The Google codec is WebM, it will be supported natively by Chrome, Firefox and Opera, and probably any other future open source HTML5 capable browser. I can't remember the exact status for IE but I believe it was along the lines of "if the codec is installed for Windows Media Player, IE9 will play it" and the same thing has been said for Safari on the Mac. The hope/plan is that YouTube will drive codec uptake for those that don't have native browser support.

The situation on mobile is more complex, not least because the current crop of devices, many of which have built in MP4 decoding hardware, will be in use for many years to come. What is needed for mobile device uptake, and the main reason stated for not supporting Ogg/Theora, is hardware supported decoding (to preserve battery life). Google is funding development of hardware, but it's not available yet, and even when it is available it likely won't be retrofit into current devices. The only silver lining is that people tend to replace their mobile devices more often than they replace their desktop computers.
posted by robertc at 4:20 PM on March 6, 2011

An interesting new twist in the whole codecs affair...

US Justice Department reportedly investigating MPEG LA over VP8 threats
posted by Artw at 5:51 PM on March 6, 2011

You know a lot of these new standards are gonna be as heavily misused as Flash ever was, don't you?

Complaining about someone potentially "overusing" standards doesn't make any sense at all.
posted by odinsdream at 6:39 PM on March 6, 2011

The hope/plan is that YouTube will drive codec uptake for those that don't have native browser support.

Maybe the US DOJ should investigate Google using YouTube to push its format on others, if and when it comes to that. I wouldn't be surprised if there are similar antitrust issues surrounding Google's attempt to control web formats.
posted by Blazecock Pileon at 7:01 PM on March 6, 2011

odinsdream: "Complaining about someone potentially "overusing" standards doesn't make any sense at all."

Two words for you: metric time.
posted by Riki tiki at 7:35 PM on March 6, 2011

Complaining about someone potentially "overusing" standards doesn't make any sense at all.

I didn't say overused - I said misused. Just because you can do something doesn't mean you should. Pretty at the expense of useful and useable is almost always a bad idea.
posted by Benny Andajetz at 8:35 PM on March 6, 2011

Google pushes use of Flash by integrating it with Chrome and by using Flash to support standard video format playback. They are probably the reason Flash will unfortunately still be around for another 5-10 years.

And Google, the web site, search service, discourages Flash for entire sites because of poor indexing. Google doesn't "push" Flash so much as support it's use because, well, it's in use here and there for some very specific things that it does much better than the emerging group of standards referred to as HTML5. Delivering it that way helps keep the browser stable and disabling is easy.

Perhaps you disagree my friend, and that's fine. I respect that. But speaking of our own development model, Google is the single largest reason we have been discouraging the use of Flash, and specifically Flash only sites, for years, with great CMS's as the second primary reason, and a love for standards, a third. iOS has been a nice "oh by the way, that too" and looks to be more of the case into the future, but for our own development cycle and the concerns of all but a few clients, it's barely a factor. Your mileage may vary, run with it and enjoy.
posted by juiceCake at 9:04 PM on March 6, 2011

I remember hearing that Firefox currently only supports Ogg Theora, as it's completely open source, and that Chrome and IE support MP4/h.264 because the license is free to use and it's a widely used format. And then apparently Google came out with their own open video format for web video that they were hoping everyone would adopt?


Firefox 4 supports webm and if you look at the source code for their demo there is a .ovg and a .webm video. Chrome supports both as well, but newer versions of Chrome (if not already) will not support .h264 because they, like Mozilla and Opera, don't want to pay for the licensing. Apple and Microsoft offer native support for .h264 because they are fine with paying the license. So the model is now Flash as a fallback for older browers and if a browser doesn't support a codec you've used, and/or providing videos encoded in probably webm and h264 and the browser will play whichever one it can.

YouTube and therefore Google behind it, uses this model on most of their videos so videos can viewed on multiple browsers and devices.

I'm so sorry, man. jQuery is the devil.

Fascinating how different things can be to different people. One of the reasons (but not the primary reason) we selected Yii for our PHP framework is it's support for jQuery from the ground up.
posted by juiceCake at 9:15 PM on March 6, 2011

Maybe the US DOJ should investigate Google using YouTube to push its format on others, if and when it comes to that.

So, assuming they ever require that, what's the standard for investigation here? Releasing a large library of content in a chosen format? YouTube is pretty big, but it's got plenty of competition and no lock in -- nobody has to go through YouTube to release video on the web.

I wouldn't be surprised if there are similar antitrust issues surrounding Google's attempt to control web formats.

Sure, just like like the sinister attempts by the PNG folks to control web graphics. I mean, if putting out code freely released under BSD-style provisions combined with royalty-free license grants is controlling.
posted by weston at 9:28 PM on March 6, 2011

So, assuming they ever require that, what's the standard for investigation here?... YouTube is pretty big, but it's got plenty of competition and no lock in -- nobody has to go through YouTube to release video on the web.

I'm not sure there are firm standards, given how the criteria are being applied now, but maybe using an unrelated product to control what happens in another market is a good start. HTML5 is working because people have learned that one company controlling how they use the web leads to a poor experience and impedes progress. If WebM is truly superior and unencumbered, why not let it stand on its own two feet in the marketplace, or defend it in court? These are fair questions, I think.
posted by Blazecock Pileon at 10:25 PM on March 6, 2011

Google seriously doesn't give a shit about video codecs. If they're pushing some new format, it's only because the other industry players haven't got it together yet. It's not like Google makes its money off patent royalties or selling codecs. The video codec, and indeed YouTube itself, is just a means to an end (which is selling advertisements).
posted by ryanrs at 11:21 PM on March 6, 2011

The video codec, and indeed YouTube itself, is just a means to an end (which is selling advertisements).

Not too long ago, Microsoft did the same thing with Internet Explorer (as a means to sell licenses of Windows and Office) and look how poorly that worked out for everyone. We're only now starting to get over the damage that caused.
posted by Blazecock Pileon at 11:32 PM on March 6, 2011

As I recall, Microsoft didn't release the IE source code under the BSD license and irrevocably release all its related patents. So not quite the same.

Look, even the FSF have endorsed the WebM format and licensing terms. If it's free enough for Stallman, it's probably free enough for you, too.
posted by ryanrs at 12:04 AM on March 7, 2011 [1 favorite]

but maybe using an unrelated product to control what happens in another market is a good start.

Unrelated? Video formats and web video?

And control how? The highest level of compulsion Google can apply via YouTube is using that property to encourage adoption of whatever technology they use for display. They can't lock out a competing format.

HTML5 is working because people have learned that one company controlling how they use the web

Like I said earlier, BSD-ish provisioned code and royalty free licenses don't make for control by any single entity.

If WebM is truly superior and unencumbered, why not let it stand on its own two feet in the marketplace

So far, that seems to be the course of action.

or defend it in court?

Probably because thus far, no plaintiff seems to have decided to file a suit.
posted by weston at 12:07 AM on March 7, 2011

As I recall, Microsoft didn't release the IE source code under the BSD license and irrevocably release all its related patents. So not quite the same.

No, not quite the same, but the patents are not the point. The point is that control over how media are encoded is better off in the hands of a few competing parties, than in one party. And the fact remains that, for better or worse, if YouTube were to change to WebM, that would more than likely put cost and design pressures on device makers to drop hardware and software for an existing standard, adding support for a different format in its place. This would leave older device owners out of luck, as well. Doesn't seem too friendly.
posted by Blazecock Pileon at 12:40 AM on March 7, 2011

So your fear is that Google is going to lock out all existing mobile devices, thereby severely cutting its ad revenue in the fastest growing internet market segment? That's a pretty far-fetched scenario, if you ask me. How does Google retain any control over the codec? And assuming the do, how is such control even profitable? Are they just doing it to be dicks?
posted by ryanrs at 12:59 AM on March 7, 2011

No, not quite the same

More than not quite the same. Really entirely different realms. Microsoft's control of the far-and-away dominant software platform and the eventually dominant web browser meant that they could lock out any feature or format they chose at the OEM and then browser level -- they could literally dictate the featureset of the browser until they foolishly stopped caring for half a decade.

There's really no comparison to what Google is able to do. They can use the carrot of some popular web destinations to encourage adoption, but they can't forbid anything on the rest of the internet or on anybody's devices.

The closer analogy really is PNG.

but the patents are not the point. The point is that control over how media are encoded is better off in the hands of a few competing parties, than in one party.

The "one party control" idea you keep incorrectly positing is nullified in no small part by the patents you say are not the point.

cost and design pressures on device makers to drop hardware and software for an existing standard, adding support for a different format in its place. This would leave older device owners out of luck, as well. Doesn't seem too friendly.

If these cost and design pressures are strong enough there can be only a single format simultaneously supported in hardware, then it'll be interesting to see how WebM fares working uphill against them -- terribly unfriendly how H.264 has the edge there right now, don't you think?
posted by weston at 1:11 AM on March 7, 2011 [1 favorite]

Are they just doing it to be dicks?

They are doing it to sell ads. Which explains, for example, the irony of propping up a somewhat closed platform like Flash, in spite of HTML5 gaining ground everywhere else.

They can use the carrot of some popular web destinations to encourage adoption, but they can't forbid anything on the rest of the internet or on anybody's devices.

Nothing stopped anyone from using Netscape, iCab or other non-IE browsers, but by using MS compatibility as a carrot, Microsoft was able to talk businesses into buying MS products. Microsoft didn't forbid Netscape or iCab, but that didn't stop them from getting away with strong-arming the web for a decade.

If someone forks WebM and it no longer works with a Google-WebM-locked-down YouTube, do you think manufacturers will use Google's version of WebM, or the forked version of WebM? More than likely, customers (both manufacturers and real end users) will probably pick the WebM that works with locked-down YouTube and other Google properties.

terribly unfriendly how H.264 has the edge there right now, don't you think?

It is royalty-free for YouTube, unless Google plans to start charging users for viewing videos. Other than political opposition to the idea of licensing, it doesn't seem any more unfriendly than any other piece of decent software.

Anyway, the whole patent thing is a bit of a non sequitor. A lesson from IE and HTML5 is that, historically, standards are good when there a lot of people at the table, and that things have gone very bad when one party gets to decide what the "standard" is for everyone. It's hard to argue that it is an impossibility when there is clear historical precedence for it.
posted by Blazecock Pileon at 3:47 AM on March 7, 2011

I supposed it's too late now to reconsider the whole angle brackets thing.
posted by flabdablet at 4:04 AM on March 7, 2011

They are doing it to sell ads.

Yes, correct. So how does forking webm, dropping flash support, or generally starting format wars further the cause of selling ads? The idea that Google would intentionally break video support for many YouTube mobile users is quite ridiculous. Internally, those kinds of decisions are extremely revenue-driven. Obviously I can't give you any proof of this. I can only tell you that those numbers are tracked by many people, and in great detail.

That's the problem with all these strawman situations you've concocted, Blazecock. They're all revenue negative, and especially revenue-growth negative. Are you worried that Google is going to try to kill the iOS platform to help Android, or something like that? (Though obviously Google can't strong-arm Apple into dropping H.264 support, since Apple designs their own chips.)
posted by ryanrs at 4:20 AM on March 7, 2011

If Google leveraged their position to strong-arm the destruction of a codec then sure, investigate away. They are not doing this. They are not supporting .h264 in Chrome because they don't want to pay the licensing fee.

But for YouTube, they do support .h264 and there is no evidence that they will not continue to do so until which time companies like Apple and Microsoft stop using their position to force the use of a codec that costs money on others or they support alternate codecs themselves.
posted by juiceCake at 8:47 AM on March 7, 2011

Nothing stopped anyone from using Netscape

There was an anti-trust lawsuit you may have heard about in which the courts came to a rather different conclusion.

If someone forks WebM and it no longer works with a Google-WebM-locked-down YouTube

I'm assuming anybody who had anything significant to contribute to future development of WebM as a format would also be smart enough to go with a superset/backwards compatibility approach.

It is royalty-free for YouTube, unless Google plans to start charging users for viewing videos.

This is pretty much a non-sequitur response in an exchange about hardware economics.

that things have gone very bad when one party gets to decide what the "standard" is for everyone.

Then it's a good thing that Google doesn't have the ability to do that.
posted by weston at 9:33 AM on March 7, 2011 [1 favorite]

Nothing stopped anyone from using Netscape

There was an anti-trust lawsuit you may have heard about in which the courts came to a rather different conclusion.

Indeed. It is true that nothing stopped consumers and business not selling OEM Windows boxes from downloading and installing Netscape, Microsoft did unlawfully abuse their monopoly by strong arming vendors from customizing their Windows installs with a browser other than IE, hence the anti-trust kerfuffle. Microsoft didn't force end users to use IE in most cases, just like they didn't force businesses to write applications that relied on IE 6 at the time. That was just bad planning at the time though to be fair, the industry and technology was young so it's easy to be critical in hindsight (and doing things server side was far more expensive then than it is now). Of course, by the time IE 5 rolled out, and particularly IE 6, Netscape 4 was close to garbage anyway. I worked directly with Netscape and their server applications. They were horribly managed and untrustworthy. I was not at all surprised to see them tank.

The anti-trust motions were not directly about consumers. We always had a choice. We could have used Macs, Amigas, NeXT, BeOS, Irix, etc. We could use any browser we liked. Lots of PC vendors did not have that choice (or rather they did, which is was to pay more for selling machines with Windows or potentially have the ability to have selling machines with Windows revoked. MPEG-LA's little dance could largely be about trying to stop the adoption of a free to use codec and make it not free, or not attractive, so that .h264 is taken up and they generate revenue from it. Their attempt, thus far, has been weak. If webm is violating/using patents that belong to others than so be it, bring that forward. Google did research that aspect for a number of months before releasing it for free use. We've heard nothing to the contrary except speculation that there could be some patent lurk so watch out! It's a cock move.
posted by juiceCake at 12:38 PM on March 7, 2011

There was an anti-trust lawsuit you may have heard about in which the courts came to a rather different conclusion.

That's not what I meant — and you know it.
posted by Blazecock Pileon at 3:24 PM on March 7, 2011

My apologies for any roll I've had in providing an opening for this boring-ass fighty derail.
posted by Artw at 4:30 PM on March 7, 2011

Role or roll?

HTML 5 is a derail unto itself in many ways. It will be interesting when it all settles, or mostly settles. The video/Flash derail that has been going on for the last couple of years is one of the more annoying elements, with commercial interests looking to spoil the party when we have advanced quite a lot in other areas.
posted by juiceCake at 5:24 PM on March 7, 2011

One thing I hate is people running around ranting and raving about WebM while completely eliding MPEG-LA's patent on H.264.

The only people who seem to be screaming about WebM are Apple groupies and a small subset of HTML5 junkies. Everyone else seems to just shrug their shoulders, even the Microsoft groupies whose company paid MPEG-LA to use H.264.

There were always going to be multiple video formats. Not all of them would be natively supported in browser. Plugins were going to happen no matter what.

And as for HTML5, it'll be a standard one day, but right now it's just a bunch of confusing crap with a few good things mixed in. And that's already leading some really odd arguments. This is what happens when you let a guy who's never designed a production website write an HTML spec.
posted by dw at 6:32 PM on March 7, 2011

Man, those arguments about which of the dozens of semi-arbitary replacement containers for DIV to use in a given circumstance give me a headache. And I can say with certainty that designers aren't going to helpfully give me comps where every element falls neatly into the HTML5 semantic scheme either.
posted by Artw at 6:53 PM on March 7, 2011

And that's why I've been very reticent about HTML5 -- having DIVs with IDs or classes like "header" and "footer" makes much more sense to me than codifying web design into headers and footers. Keep the framework open.

The aside tag has been a cluster from the beginning for precisely the reason I stated -- Hixie has never designed a production website, so he was flying blind on a number of the tags. And given that most of WHATWG is a bunch of yes-men and they tend to shout down external opposition, no one really got thought about what it meant.

I don't worry about whether designers get everything neatened up with semantics. Helps that I'm usually the designer, so I don't have to break my brain on someone else's mess....
posted by dw at 7:21 PM on March 7, 2011

The only people who seem to be screaming about WebM are Apple groupies and a small subset of HTML5 junkies.

No one has screamed about it, but knowing about the subject at hand I think there are arguably more citable similarities than differences that are worth considering. But I can see how this subject demands that kind of passive-aggressiveness.
posted by Blazecock Pileon at 7:22 PM on March 7, 2011

Just imagine the fun people who like to complain about italics and bold being used instead of EM and STRONG are going to have...
posted by Artw at 7:42 PM on March 7, 2011

Still, it could be worse, the orignal meaning of FOOTER made bog all sense.
posted by Artw at 7:53 PM on March 7, 2011

So wait, in your job, validating to a standard is more important than usability and working across browsers? I don't understand.

Validating to a standard is something that can be measured.

"Usability" and "working across browsers" are completely abstract concepts. What's usable to one person might be impossible for the next. You have no way of knowing beforehand what knowledge a user brings to the table. And what's working today could be broken tomorrow, or the other way around, and what does working even mean, really? Working enough to get my task accomplished? Working withing the parameters of the initial designer's intent? Etc.

But validating? Validating is a check mark on a report filed after each and every enhancement request or bug fix that is shipped to production. That report tells the CEO of the company that the manager is doing their job. The check mark on the report tells them that you are doing your job.

Welcome to the real world.
posted by Civil_Disobedient at 5:17 AM on March 8, 2011

I've never found validation to have all that much to do with the real world, TBH, though I can see why it might be a useful checkmark to show off to dissinterested bosses.

I wonder how this business of HTML becoming a "living standard" affects validators? TBH the whole scheme seems like a recipe for random crazypants browser features getting thrown onto the web whenever a browser maker feels like it's not getting enough attention.
posted by Artw at 8:08 AM on March 8, 2011

Adobe Releases Flash to HTML 5 Converter "Wallaby"
posted by Artw at 10:19 AM on March 8, 2011

Civil_Disobedient: "But validating? Validating is a check mark on a report filed after each and every enhancement request or bug fix that is shipped to production. That report tells the CEO of the company that the manager is doing their job. The check mark on the report tells them that you are doing your job.

Welcome to the real world."

No offense, but I think you need a better job, Civil. If "validating" was my job then every single enhancement I made would consist of "<div/>".

In the real world I've seen, validating is just something that simplifies unit tests. Which is admirable, but much (I'd guess most) web markup these days is dynamically generated (making it all but impossible to check a box saying your code "validates" as HTML), and there's plenty of broken UI out there that validates perfectly.

You imply that "usability" and "working across browsers" are unmeasurable, but that's not true. For a given interface, you can do a usability test and determine that a (nonvalidating) change made 90% of IE users perform a specified task in less time and 86% of overall users reported that they thought it was "more intuitive". That's a measurement as valid as in any other science that relies on statistical extrapolation, even though what it's measuring may seem more abstract.

Or do you really think there's no measurable difference between the usability of "<span>Important news update: pie is delicious.</span>", and that of "<!-- Important news update: pie is delicious. -->"?
posted by Riki tiki at 11:54 AM on March 8, 2011

I wonder how this business of HTML becoming a "living standard" affects validators? TBH the whole scheme seems like a recipe for random crazypants browser features getting thrown onto the web whenever a browser maker feels like it's not getting enough attention.

It changes the game, validation is not what it used to be. HTML 4 conformance depends on the syntax details of the markup, HTML 5 conformance depends on the DOM tree produced, syntax details of the markup are less relevant. You should have a read of this:

The reason there’s such a big difference is simple: HTML validation is now separated from “linting”. A validator should not throw errors for code styling inconsistencies, but should only throw errors for, well, code errors.

There's an HTML Linter here.
posted by robertc at 3:39 PM on March 8, 2011

So... any old random crap validates as long as it has angle brackets?

/scratches head.
posted by Artw at 3:52 PM on March 8, 2011

We strive for validation when we can just to be clean and therefore, usually, simple code with inheritance in mind, SEO, structure for JavaScript, etc., but compromises are often made. I don't think this is going to change but the idea of writing clean, valid code, we find, helps to create very good markup.
posted by juiceCake at 4:22 PM on March 8, 2011

Never was a big fan of making sure I didn't have *any* validation problems (particularly CSS hacks, some of which I still find far more convenient than conditional comments and separate stylesheets), but I have to say I've definitely found it useful to run a validator on my work, make sure I understand the messages, and then make decisions about what to change.
posted by weston at 6:10 PM on March 8, 2011

No offense, but I think you need a better job, Civil.

I wasn't speaking for myself. I was replying to !Jim, answering for davelog.

Keep up, man!
posted by Civil_Disobedient at 12:03 AM on March 9, 2011

Welcome to the real world.

I've been in the real world for about 6 years now, but thanks!
posted by !Jim at 10:18 PM on March 9, 2011

Adobe is now getting into the proposing random features game: Adobe proposes standard for magazine-like Web

Good luck with doing that whne you don't have a browser to force it upon people with.
posted by Artw at 7:30 PM on March 11, 2011

If you look at things from a slightly different perspective they do have a browser, plus they could just implement it in Flash and give everyone yet another reason to continue to use it.

In any case it's likely neither this, nor Microsoft's recent proposal, or Microsoft's older proposal, or the original CSS3 Layout, will end up enshrined as a standard: work has already begun to unify the various proposals of recent years.
posted by robertc at 3:29 PM on March 12, 2011

Possibly this is me being cynical, but given what's happened in the past it seems like whatever is the most useless proposal possible in terms of laying out text on pages will win the day, most likely on some hazy theoretical merit that only someone who has never built a website could have interest in.

Or Mozilla or Apple will impliment some random thing and everyone will just decide it's the standard.
posted by Artw at 3:39 PM on March 12, 2011

Good luck with doing that whne you don't have a browser to force it upon people with.

Except Adobe's been at the W3C table for years and has been a good actor all the way along. This is just another piece of the CSS3 puzzle. The good news is that it's looking more and more like there will a critical mass around CSS3 Layout, maybe enough that it'll make it into IE10.

I'm increasingly hopeful we'll see CSS variables and mixins this year. Chrome is supposed to implement both, and rumor is Firefox will have something similar. The biggest question now is how to deal with backwards compatibility with variables... or if it's even possible without using a framework.
posted by dw at 4:09 PM on March 12, 2011

State of HTML5 Audio

Nitro JS engine appears enabled only for in-mobile-safari use (ie, not available in UIWebView or saved-to-home-screen apps)
posted by weston at 10:23 AM on March 13, 2011

Interesting article. The "argument" that Google is promoting Flash would now, by the logic of that argument above, have to be extended to Apple and Microsoft in terms of audio but as usual, it's not that simple. We are in transition. HTML 5 cannot support a lot of what Flash currently does and it will be some time before it does.
posted by juiceCake at 11:17 AM on March 14, 2011