Archive for the ‘Web Standards’ Category

File Under: HTML5, Web Standards

Mozilla Busts HTML5 Myths

Image: Christian Heilmann/Flickr

Mozilla has jumped into the shark-infested debate about whether or not HTML5 can compete with platform native apps. Chris Heilmann, Mozilla’s Principal Evangelist for HTML5, has a new post on the Mozilla Hacks blog that challenges many “false assumptions” about HTML5.

Heilmann’s post is not so much about which you ought to use for your next app — right now that depends on what you’re building — rather it attempts to clear the air about just what HTML5 actually can and cannot do.

Among the things Heilmann covers are the myths that HTML5 has performance problems, that it can’t work offline and that developers can’t make money building HTML5 apps.

Along the way Heilmann also acknowledges where platform-native apps have the lead, namely, access to device APIs. It’s not a shortcoming of HTML5 that iOS and Android both prevent web apps from accessing many APIs native apps can use, but it is a practical reality that keeps many developers building native apps for the time being. As Heilmann writes, “in essence HTML5 is a Formula 1 car that has to drive on a dirt road whilst dragging a lot of extra payload given to it by the operating system without a chance to work around that — for now.”

The qualifier, “for now,” is the key part of that analogy. Not only are platforms slowly adding more HTML5 support to their native browsers, we’ve also seen increased support for accessing device capabilities — like GPS or the camera — through web apps. And of course Mozilla is building its own mobile OS which will consist exclusively of HTML5 apps.

It may be some time before app developers start favoring the web over platform-specific apps, but as Heilmann points out this is hardly the first time the web has taken over from a closed system: “historically, closed platforms came and went and the web is still going strong.”

File Under: CSS, UI/UX, Web Standards

Create More Accessible Color Schemes With ‘Contrast Ratio’

Quick, easy contrast ratios. Image: Screenshot/Webmonkey.

Making websites accessible to users with disabilities — things like poor vision, blindness, limited dexterity — has been central to the mission of the web’s overseers since the dawn of the browser.

Following accessibility guidelines actually helps just about everyone, especially when it comes to making your site readable. And one of the cornerstones of accessibility is making sure your background and text colors have proper contrast ratio. But how do you know what’s a proper contrast ratio? For that turn to WCAG 2.0, a set of accessibility guidelines that most government and many private sector websites adhere to.

Unfortunately, while the W3C has plenty of guidelines for building the web, it’s not in the business of creating tools to go with them, which means bringing the guidelines into the real world can sometimes be a hassle. That’s why developer Lea Verou built this awesome contrast ratio tool. Verou works for the W3C (though the tool is not an official W3C project) and needed a way to ensure that her color choices passed WCAG muster. That’s exactly what the contrast ratio tool does: give it any form of CSS color — hex, rgb(), rgba(), hsla(), etc — and it will automatically calculate the contrast ratio and let you know which level of the WCAG guidelines your contrast meets.

Verou’s contrast calculator even accepts semi-transparent colors for sites using overlays. To make the semi-transparent colors work Verou had to write her own algorithm. For semi-transparent backgrounds, the WCAG contrast ratio is presented with an error margin, since the actual contrast can vary depending on what’s under your semi-transparent overlay.

The contrast ratio tool supports all modern browsers and has “basic support for IE9.” The code is available on GitHub.

Also worth noting is Verou’s blog post on accessibility and contrast ratios. Like many of us, Verou “used to think that WCAG-mandated contrast ratios were too restrictive and basically tried to force you to use black and white.” The truth is, as Verou writes, “in practice, I found that in most cases they are very reasonable: When a color combination doesn’t pass WCAG, it usually is hard to read.”

File Under: HTML5, Mobile, Web Standards

New HTML Tricks for Web Developers in Apple’s iOS 6

Image: Screenshot/Webmonkey

Apple’s recent iOS 6 update added some nice new web standards support to Mobile Safari, the default iOS web browser for the iPhone, iPad and iPod touch.

Apple’s documentation remains sparse and occasionally outdated, but luckily Max Firtman, author of O’Reilly’s Programming the Mobile Web, has a very thorough rundown of everything that’s new in iOS for web developers.

By far the biggest news is support for file uploads and camera access using a combination of the File API and the HTML Media Capture API. To let users take a picture from your web app, you’d use a file input tag something like this:

<input type="file" accept="image/*" capture="camera">

Mobile Safari’s Media Capture support is incomplete so it will ignore the capture attribute, as well as any value for accept other than image or video, but at least web apps can now capture and upload images from the iPhone’s camera.

I put together a quick demo page of Mobile Safari’s Media Capture support so you can see the new interface in action. The first two examples on that page work, the third audio example does not. You can see in the demo that Mobile Safari helpfully shows a thumbnail of the image prior to upload. It’s also worth noting that Mobile Safari supports the multiple boolean flag for uploading more than one image at a time, though in that case you lose the ability to access the camera.

For more on what to do with those images once the user has selected them, check out the Mozilla developer network, which has an excellent tutorial on using the File API.

Other highlights for web developers in the new Mobile Safari include support for the Web Audio API (great news for anyone building mobile, web-based games), increased application cache sizes (now 25MB), a faster JavaScript engine and some new CSS tricks as well — CSS Filters, CSS Cross Fades and the not-yet-a-standard CSS Image Set we told you about earlier. Be sure to read through Firtman’s whole post for all the details.

While there’s plenty to like about the new Mobile Safari there are some things missing, like support for WebRTC and getUserMedia, WebGL and sadly our least favorite bug — the Viewport Scaling Bug, which causes Mobile Safari to incorrectly reflow content when rotating from portrait to landscape — seems to still be hanging around. As always there’s a JavaScript workaround available.

File Under: HTML5, Web Standards

W3C Unveils Plan to Finish HTML5 in 2014

Image: Screenshot/Webmonkey.

Like the Cylons, HTML5 was created by man. It rebelled. It evolved. It looks and feels like HTML. And now, it has a plan.

Namely, to be done in 2014.

The W3C has formalized its plan to move the HTML5 spec to the official “Candidate Recommendation” status by the end of 2014. That might seem like a long time from now, especially if, like most of us, you’ve been using the bulk of HTML5 for some time, but 2014 is quite a bit better than the 2022 date that used to be tossed around.

But there’s a catch. In order to get HTML5 to the Candidate Recommendation stage on time the W3C is going to move some less stable parts of the spec to the newly designated HTML 5.1.

HTML5 has already been “modularized” over the years, spinning off sections like Web Workers, WebSockets, Microdata and half a dozen others, which are all now separate specifications at the W3C.

Now the W3C plans to split the remaining chunk of HTML 5.0 into HTML 5.0 and HTML 5.1. Each spec will then move through the process of becoming an official web standard. Here’s the W3C HTML Working Group’s plan for HTML5:

  • we determine which features are likely to meet the “Public Permissive” CR exit criteria,
  • we create a “stable HTML5.0″ draft which includes just those “stable” features, and which omits the remaining “unstable” features
  • we create an HTML 5.1 editor’s draft which is a superset of the stable HTML5.0 but with the “unstable” features included instead of omitted, and also with any new proposed features included

The HTML WG would then rinse and repeat with HTML5.1 in 2016. And then HTML5.2 and so on. The result will hopefully be a faster evolving series of specs, which in turn means more features reach the Recommendation stage in less time.

For web developers in the trenches finalizing HTML5 might seem irrelevant — after all, browsers already support most of it so who really cares? There are two reasons reaching the Candidate Recommendation stage matters: It usually means improved cross-browser support and it always means that the spec is covered by the all important W3C patent policy, which ensures that HTML5 remains a royalty-free standard.

For a complete list of everything that’s “unstable” in the current draft of HTML5, as well as the plan for how to handle it, be sure to read through the W3C’s plan.

File Under: Web Standards

Like CSS? Then You Might One Day Enjoy ‘Cascading Attribute Sheets’

But maybe Cascading Attribute Sheets can. Image: Noah Sussman/Flickr

Cascading Stylesheets are awesome, why not take the same idea and apply it to HTML attributes?

That’s the question the W3C’s WebApps Working Group has been pondering ever since Tab Atkins Jr., a Google representative at the W3C, proposed an entirely new web language — Cascading Attribute Sheets, or CAS for short.

Atkins proposes that CAS use more or less the same syntax as CSS, but apply the concept to HTML attributes. The key difference, which limits CAS slightly, but which would keep it speedy, is that CAS would run once, when the element is added to the page, with no dynamic changes after the fact.

Here’s how CAS would work in practice: first, you would include a link to your CAS file using a <script> tag. Then, assuming you have a video tag on your page, you might do something like this in your CAS:

 

video {
    preload: metadata;
}

These lines would add the preload attribute to all your video tags and set the value to metadata. What if you want to target just the video tags inside your main content container? No problem, just use the same selector nesting you’d use in CSS:

#content video {
    preload: auto;
}

This would target only video tags inside the #content container, this time setting the preload attribute to auto.

To make CAS as simple as possible for both browser makers and developers it would very closely mirror CSS. “In the place where CSS normally has a property name, CAS allows any attribute name,” writes Atkins on the W3C mailing list. For an attribute value CAS allows “any single token, such as a number, identifier or string.” In theory this would allow CAS to reuse the browser’s CSS parser, limiting the amount of work necessary to get browsers to support CAS.

Atkins hopes that “by reusing the CSS parser and restricting all the expensive parts of CSS (dynamicness, remembering where a value came from, etc.), I can pull the bar down low enough for this to make it… It is just sugar, but it’s useful sugar, as evidenced by the fact that people keep trying to push content attributes into CSS.”

However, Maciej Stachowiak, an Apple representative at the W3C, questions whether or not CAS would work with WebKit’s CSS parser writing, “I doubt we would be able to actually reuse the CSS parser, at least at the code level, at least for WebKit.”

Whether or not Atkins’ proposal is ever accepted, or if browsers would ever support it, remains to be seen, but now that the tantalizing idea has been planted in our heads we’re really hoping it catches on. For more on the fate of CAS and some discussion of its potential inner workings, have a look at the full thread on the W3C mailing list.