Skip navigation
Help

Web Standards

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.
Original author: 
Scott Gilbertson

Look Ma, no floats! Image: Abobe

HTML5 and CSS 3 offer web developers new semantic tags, native animation tools, server-side fonts and much more, but that’s not the end of the story. In fact, for developers slogging away in the web design trenches, one of the most promising parts of CSS 3 is still just over the horizon — true page layout tools.

While it’s possible to create amazingly complex layouts using tools like CSS floats, positioning rules and the odd bit of JavaScript, none of those tools were actually created explicitly for laying out content, which is why it’s amazingly complex to get them working the way you want across browsers.

Soon, however, you’ll be able to throw out your floats and embrace a better way — the CSS Flexible Box Model, better known as simply Flexbox. Flexbox enables you to create complex layouts with only a few lines of code — no more floats and “clearfix” hacks.

Perhaps even more powerful — especially for those building responsive websites — the Flexbox order property allows you to create layouts completely independent of the HTML source order. Want the footer at the top of the page for some reason? No problem, just set your footer CSS to order: 1;. Flexbox also makes it possible to do vertical centering. Finally.

We’ve looked at Flexbox in the past, but, unfortunately the spec has undergone a serious re-write since then, which renders older code obsolete. If you’d like to get up to speed with the new syntax, the Adobe Developer Blog recently published a guide to working with Flexbox by developer Steven Bradley.

Bradley walks through the process of using Flexbox in both mobile and desktop layouts, rearranging source order and elements to get both layouts working with a fraction of the code it would take to do the same using floats and other, older layout tools. The best way to wrap your head around Flexbox is to see it in action, so be sure to follow the links to Bradley’s demo page using either Chrome, Opera or Firefox 20+.

For some it may still be too early to use Flexbox. Browser support is improving, but obviously older browsers will never support Flexbox, so bear that in mind. Opera 12 supports the new syntax, no prefix necessary. Chrome supports the new syntax, but needs the -webkit prefix. Like Opera, Firefox 20+ Firefox 22 supports the unprefixed version of the new spec. Prior to v22 (currently in the beta channel), Firefox supports the old syntax. IE 10 supports the older Flexbox syntax. Most mobile browsers support the older syntax, though that is starting to change. [Update: Mozilla developer Daniel Holbert, who is working on the Flexbox code in Firefox, wrote to let me know that the Flexbox support has been pushed back to Firefox 22. Actually the new Flexbox syntax is part of Firefox 20 and up, but until v22 arrives it's disabled by default. You can turn it on by heading to about:config and searching for layout.css.flexbox.enabled pref. Set it to true and the modern syntax will work.]

So, as of this writing, only two web browsers really support the new Flexbox syntax, though Firefox will make that three in the next month or so.

But there is a way to work around some of the issues. First off, check out Chris Coyier’s article on mixing the old and new syntaxes to get the widest possible browser support. Coyier’s methods will get your Flexbox layouts working in pretty much everything but IE 9 and below.

If you’re working on a personal site that might be okay — IE 9 and below would just get a simplified, linear layout. Or you could serve an extra stylesheet with some floats to older versions of IE (or use targeted CSS classes if you prefer). That defeats some of the benefits of Flexbox since you’ll be writing floats and the like for IE, but when usage drops off you can just dump that code and help move your site, and the web, forward.

0
Your rating: None

Conversat.io, simple video chat in your browser.
Image: Screenshot/Webmonkey.

WebRTC is changing the web, making possible things which just a few short months ago would have been not just impossible, but nearly unthinkable. Whether it’s a web-based video chat that requires nothing more than visiting a URL, or sharing files with your social networks, WebRTC is quickly expanding the horizons of what web apps can do.

WebRTC is a proposed standard — currently being refined by the W3C — with the goal of providing a web-based set of tools that any device can use to share audio, video and data in real time. It’s still in the early stages, but WebRTC has the potential to supplant Skype, Flash and many device-native apps with web-based alternatives that work on any device.

Cool as WebRTC is, it isn’t always the easiest to work with, which is why the Mozilla Hacks blog has partnered with developers at &yet to create conversat.io, a demo that shows off a number of tools designed to simplify working with WebRTC.

Conversat.io is a working group voice chat app. All you need to do is point your WebRTC-enabled browser to the site, give your chat room a name and you can video chat with up to 6 people — no logins, no joining a new service, just video chat in your browser.

Currently only two web browsers support the WebRTC components necessary to run conversat.io, Chrome and Firefox’s Nightly Channel (and you’ll need to head to about:config in Firefox to enable the media.peerconnection.enabled preference). As such, while conversat.io is a very cool demo, WebRTC is in its infancy and working with it is sometimes frustrating — that’s where the libraries behind the demo come in.

As &yet’s Henrik Joreteg writes on the Hacks blog, “the purpose of conversat.io is two fold. First, it’s a useful communication tool…. Second, it’s a demo of the SimpleWebRTC.js library and the little signaling server that runs it, signalmaster.”

Both tools, which act as wrappers for parts of WebRTC, are designed to simplify the process of writing WebRTC apps — think jQuery for WebRTC. Both libraries are open source (MIT license) and available on GitHub for tinkering and improving.

If you’d like to learn more about SimpleWebRTC and signalmaster and see some example code, head on over to the Mozilla Hacks blog for the full details.

0
Your rating: None

Image: W3C

The W3C, the group that oversees web standards like HTML and CSS, recently held W3Conf, an annual conference for web developers. If, like me, you couldn’t make it this year, fear not, videos of all of the talks are now available online.

Among the highlights are Eric Meyer’s talk on Flexbox, and the future of sane layout tools — what Meyer calls “the Era of Intentional Layout.” Meyer’s talk is also notable for the reminder that, in Mosaic, styling a webpage was something users did, not page creators.

Another highly recommended talk is Lea Verou’s “Another 10 things you didn’t know about CSS.” The “Another” bit in the title refers to a talk Verou gave last year entitled “10 things you might not know about CSS 3.” Also be sure to read our recent interview with Verou for more on the W3C and web standards.

There are quite a few more videos available over on the W3Conf YouTube page, including Jacob Rossi’s talk on Pointer Events, which we linked to in yesterday’s Pointer Events coverage.

0
Your rating: None

CSS Blend Modes demo. Image: Screenshot/Webmonkey.

We use the term “CSS 3″ all the time on Webmonkey, but technically that’s something of a misnomer. There is no spoon, you see.

In fact, the CSS Working Group, which oversees the CSS specification at the W3C, is cranking out draft specs of new features all the time — the monolithic “3.0″ or “4.0″ versioning was tossed out after CSS 2.1. Instead new features are developed as “modules” so that, for example, the Selector Module can be published without waiting for the Layout Module.

That means there are new CSS features coming all the time.

Adobe’s Divya Manian — who is also one of the developers behind HTML5 Boilerplate — recently gave a talk titled “CSS Next“, which highlights some of the exciting new CSS features coming soon to a browser near you.

Among the cool things Manian highlights are some impressive new tricks for web fonts, including better tools for working with ligatures, unicode and icon fonts.

There are also some impressive new layout tools in the works, namely CSS Regions and Exclusions. We looked at both back when Adobe first proposed them, but since then not only have they progressed to actual draft specs, but they’re now supported in Chrome’s Canary builds (rather than requiring a custom build from Adobe).

It’s still going to be a while before either can claim a spot in your CSS layout toolkit, but there are already a few demos you can check out to see the new layout possibilities Regions and Exclusions offer. Grab a copy of Chrome Canary and turn on “Enable Experimental WebKit Features” in chrome:flags and then point your browser to this demo of Regions and this “shape inside” demo of Exclusions.

Other things Manian covers that we’re looking forward to include CSS Filters and Blend modes. CSS Filters already work in WebKit browsers and allow you to apply effects like blur or grayscale to any HTML element. CSS Blend Modes work just like layer-blending modes in Photoshop and other graphics apps — allowing you to blend layers using modes like “difference,” “overlay,” “multiply” and so on. As of right now you still need a special build of Chromium to see Blend Modes in action.

Manian also covers two intriguing WebKit-only features that aren’t yet a part of any CSS spec, but could be one day. Be sure to read through Manian’s post for more info and a few other new things, including two Webmonkey has covered recently — CSS @supports and CSS Variables.

0
Your rating: None

So many screens, so few images (testing responsive sites with Adobe Shadow). Photo: Adobe.

The web needs a more intelligent way to serve images.

No one wants to waste bandwidth sending large images over limited mobile pipes, but everyone wants images to look good on the myriad screens connecting to today’s web. Currently web authors use a variety of hacks to (incompletely) work around this problem, but to really solve it the web likely needs new tools.

Unfortunately, thanks to miscommunication between standards bodies, web developers and browser makers, instead of a solution to the image problem what developers got this week feels more like a slap in the face. Eventually an adaptive image solution will likely emerge, but the real lesson for many developers will be about how the standards process works and how they fit into it, if at all.

Webmonkey has previously looked at some proposed solutions to the adaptive image problem. Some very smart web developers came up with the idea of a <picture> element that works much like the current HTML <video> element. These developers thought they had the attention of the Web Hypertext Application Technology Working Group, better known as the WHATWG. Then, earlier this week, Edward O’Connor, Apple’s WHATWG representative, proposed another method of solving the problem, using a new srcset attribute on the <img> element. See our earlier coverage of the srcset attribute for a more detailed look at how it works and compares to the <picture> proposal.

What has web developers up in arms is that Ian Hickson, editor of the WHATWG spec (and better known as Hixie) has already added the srcset attribute to the WHATWG’s HTML draft spec, seemingly ignoring the months of effort that went into <picture>. Worse, members of the WHATWG apparently weren’t even aware that developers were putting forth the effort to come up with a solution via the Responsive Images community group. Nor were concerns about the srcset syntax given much consideration. Hickson does address some objections to srcset in his message to the WHATWG, but ends up dismissing most of them.

That doesn’t match up with how most people envision the web standards process. But as web developer and standards advocate Jeremy Keith writes, “this is exactly how the WHATWG is supposed to work. Use-cases are evaluated and whatever Hixie thinks is the best solution gets put in the spec, regardless of how popular or unpopular it is.”

In fact, think of the WHATWG as the source for initial, rapid development of new features. The group was started by browser makers because the W3C’s HTML Working Group (HTMLWG) moved too slowly. But if the WHATWG is the source of rapid development, the W3C is an effective check on that speed, ensuring that even those of us who don’t make web browsers still have a voice in the future of HTML. (see our earlier overview for more on the history and differences between the HTML WG and the WHATWG.)

While the HTML WG is also chaired by Hickson (a position he will soon step down from), it offers a much more democratic (and consequently slower) process and has overridden the WHATWG’s rash decisions in the past. For example the W3C added the time element back after Hickson removed it from the WHATWG spec.

Confused yet? It gets worse. The WHATWG is working on an ever-evolving standard, what it calls a “living standard,” which is different from — and may well diverge from — the snapshot-based standards issued by the W3C, like HTML5. In a comment on longtime web standards champion Jeffery Zeldman’s post on the matter, Jeremy Keith writes, “I don’t mind if the srcset attribute is in the WHATWG HTML spec but not in the W3C HTML5 spec. If it works, it’ll end up in a future W3C version number.”

Implicit in Keith’s statement is that if the srcset attribute doesn’t end up working out it won’t be in HTML5.x and would likely just fade away like the blink tag, the applet tag and other HTML ideas tried and later discarded.

Which is another way of saying developers need not panic. Perhaps web developers don’t have a voice in the WHATWG simply because we’ve been using the wrong channels (W3C community groups don’t seem to be an effective means of communicating with standards bodies, in fact they seem more like this.). If you’ve got ideas and would like a voice in the future of the web join the WHATWG mailing list and login to the IRC channel. Introduce yourself, learn the rules and contribute.

0
Your rating: None

The high-resolution web is coming. Photo: Ariel Zambelich/Wired

Given enough time, all simple, already solved problems of the web eventually rear their ugly heads again.

Remember when limited bandwidth was a huge problem? Then bandwidth was infinite. Now it’s a problem again. And that means serving up images is once again a complex problem with no elegant solution. Its seems simple. Websites should serve the right image to the right screen, high-resolution images to high-resolution devices and low res to the rest. But of course it’s not that simple. Factors like bandwidth as well as screen size and orientation complicate the matter considerably.

Arguably the best solution right now is to send low-res images to every device. Sure, your images might look terrible on high-res screens, but at least you aren’t wasting people’s time or worse, costing them money.

While that’s the safest solution for now, the web doesn’t get better if no one takes any risks. Fortunately, until some standard or best practice emerges, we’ll likely continue to see developers pushing the boundaries and discovering new ways to handle the seemingly simple task of serving the appropriate image to the appropriate device.

The latest image cleverness we’ve seen is Adam Bradley’s Foresight.js. Foresight.js is designed to make it easy to serve up high-resolution images to devices like the new iPad, but what sets foresight.js apart from half a dozen other solutions that do the same thing is that it not only checks for a hi-res screen, but also checks to see if the device currently has a fast enough network connection for larger images. If, and only if, your visitor has both a device capable of displaying high-res images and a network connection fast enough to handle the larger file size, are larger images served.

Part of what makes Foresight.js appealing is its use of the proposed CSS image-set() function, one possible solution to the problem of serving up the right image at the right time. The image-set() function, which works in WebKit nightly builds and is under consideration by the W3C, looks like this:

myselector {
    background: image-set(url(foo-lowres.png) 1x, url(foo-highres.png) 2x) center;
}

Foresight.js takes the image-set() proposal and uses an ingenious hack to make it work in other browsers: the font-family property. Yes, it sounds crazy. But it works and remains technically valid CSS because font-family allows for arbitrary strings (to handle font names). That means browsers have no problem with a rule like this:

myselector {
    font-family: ' image-set( url(/images/foo.png), url(/images/foo_2x.png) 2x high-bandwidth ) ';
}

It’s a hack to be sure, but it’s our favorite kind of hack: clever and functional. Because browsers successfully parse the font-family rule (even if they can’t apply it) the value is added to the DOM and JavaScript has no problem accessing it, which is exactly what foresight.js does.

For more on foresight.js, head over to the GitHub page which as links to plenty of examples uses and copious documentation on the script’s many tricks. Also be sure to read through Bradley’s Challenges for High Resolution Images, which offers some background on foresight.js and the design decisions he made.

0
Your rating: None

The high-resolution retina display iPad has one downside — normal resolution images look worse than on lower resolution displays. On the web that means that text looks just fine, as does any CSS-based art, but photographs look worse, sometimes even when they’re actually high-resolution images.

Pro photographer Duncan Davidson was experimenting with serving high-resolution images to the iPad 3 when he ran up against what seemed to be a limit to the resolution of JPG images in WebKit. Serving small high-resolution images — in the sub-2000px range — works great, but replacing 1000px wide photographs with 2000px wide photos actually looks worse due to downsampling.

The solution (turns out) is to go back to something you probably haven’t used in quite a while — progressive JPGs. It’s a clever solution to a little quirk in Mobile Safari’s resource limitations. Read Davidson’s follow-up post for more details, and be sure to look at the example image if you’ve got a new iPad because more than just a clever solution, this is what the future of images on web will look like.

As Davidson says:

For the first time, I’m looking at a photograph I’ve made on a screen that has the same sort of visceral appeal as a print. Or maybe a transparency laying on a lightbox. Ok, maybe not quite that good, but it’s pretty incredible. In fact, I really shouldn’t be comparing it to a print or a transparency at all. Really, it’s its own very unique experience.

To show off the sample on his site Davidson uses a bit of JavaScript to toggle the high- and low-res images, highlighting the difference.

But how could you go about serving the higher res image to just those screens with high enough resolution and fast enough connections to warrant it?

You can’t.

So what’s a web developer with high-res images to show off supposed to do? Well, right now you’re going to have to decide between all or nothing. Or you can use a hack like one of the less-than-ideal responsive image solutions we’ve covered before.

Right now visitors with the new iPad are probably a minority for most websites, so not that many people will be affected by low-res or poorly rendered high-res images. But Microsoft is already prepping Windows 8 for high-res retina-style screens and Apple is getting ready to bring the same concept to laptops.

The high-res future is coming fast and the web needs to evolve just as fast.

In the long run that means the web is going to need a real responsive image solution; something that’s part of HTML itself. An new HTML element like the proposed <picture> tag is one possible solution. The picture element would work much like the video tag, with code that looks something like this:


 
 
 

The browser uses this code to choose which image to load based on the current screen width.

The picture element would solve one part of the larger problem, namely serving the appropriate image to the appropriate screen resolution. But screen size isn’t the only consideration; we also need a way to measure the bandwidth available.

At home on my Wi-Fi connection I’d love to get Davidson’s high-res images on my iPad. When I’m out and about using a 3G connection it would be better to skip that extra overhead in favor of faster page load times.

Ideally browsers would send more information about the user’s environment along with each HTTP request. Think screen size, pixel density and network connection speed. Developers could then use that information to make a better-informed guess about which images it to serve. Unfortunately, it seems unlikely we’ll get such tools standardized and widely supported before the high-res world overtakes the web. With any server-side solution to the bandwidth problem still far off on the horizon, navigator.connection will become even more valuable in the mean time.

Further complicating the problem are two additional factors, data caps on mobile connections and technologies like Apple’s AirPlay. The former means that even if I have a fast LTE connection and a high-resolution screen I still might not want to use my limited data allotment to download high-res images.

AirPlay means I can browse to a site with my phone — which would likely trigger smaller images and videos since it’s a smaller screen — but then project the result on a huge HD TV screen. This is not even a hypothetical problem, you can experience it today with PBS’s iPhone app and AirPlay.

Want to help figure out how the web needs to evolve and what new tools we’re going to need? Keep an eye on the W3C’s Responsive Images community group, join the mailing list and don’t be shy about contributing. Post your experiments on the web and document your findings like Davidson and countless others are already doing.

It’s not going to happen overnight, but eventually the standards bodies and the browser makers are going to start implementing solutions and the more test cases that are out there, the more experimenting web developers have done, the better those solutions will be. It’s your web after all, so make it better.

Photo: Ariel Zambelich/Wired

0
Your rating: None

Photo: Ariel Zambelich/Wired.com

Building responsive websites means that your design has to adapt to different screen sizes. That there is no such thing as “pixel perfect” has long been a maxim of good web design, but nowhere is this more true than when you start working with percentage widths, em-based type and other flexible techniques of responsive design. While fluid grids, adaptive images and other tools help, sometimes even basic things like the flow of type can look wrong without a little extra help.

One common problem when designing for multiple devices is handling the changes that happen when the user rotates the screen. It’s frustrating to see your elegant portrait-oriented designs fall apart as the device moves to landscape mode (or vice versa). Frequently the problem is that images, videos and other embedded content in your page is sized in relation to the pixel width of the viewport, but the type is not. That means that the type fails to adapt to layout changes, leaving ugly gaps, whitespace or hard-to-read, overly long lines.

There are a number of ways to solve this problem, but one of the simplest and easiest is to use fluid typography in addition to your fluid grid. BBC developer Mark Hurrell wrote up an excellent tutorial some time ago that shows how, by specifying font sizes in rems, you can “adjust every font-size on the page by using media-queries to change the font-size set on the BODY or HTML element according to viewport width.”

To find the right size type for various screen widths, Hurrell calculates a resolution-independent font scale based on target widths. That is then applied using a series of media queries and the new CSS 3 unit rem. The rem unit means ems relative to the root (the HTML) element. That means your type gets proportionally larger overall, rather than in relation to its parent element as would happen with a simple em. As Hurrell notes, support is pretty much universal on tablets and phones (browsers that don’t support it will fall back to px sizing, so all is not lost).

In the end what you get using rems and media queries is fluid typography that scales just like a fluid grid. That means that when the device rotates the type resizes to fit the new screen dimensions. For more details on how to make it work on your site be sure to check out the Responsive News blog post, which also has a few links to websites already using this trick.

0
Your rating: None

The hype surrounding HTML5 video has thankfully receded from the high water mark of 2011. But the absence of hype doesn’t mean HTML5 video is a thing of the past. In fact, while it’s true that HTML5 video still can’t completely match all of the features available in Flash, the state of HTML5 video on the web continues to improve with every new browser release.

For a very thorough rundown of exactly where and how well HTML5 video works on the web right now, check out the excellent report on the state of HTML5 video from Long Tail Video. Put together by the makers of JW Player, an HTML5 video player toolkit, the state of HTML5 video report is mercifully free of any evangelism for any particular technology. Instead it offers a level-headed look at reality, answering the basic questions — where can you use HTML5 video? How well will it work for users? And when will you need Flash fallbacks?.

HTML5 video enthusiasts will be happy to know that the state of native video on the web is looking better these days. Two-thirds of all the browsers on the web now support the HTML5 video tag. Support for the various video tag attributes has improved as well, with both Safari and Chrome offering full support.

Still, for all the bright points in the report, there is clearly still a need for Flash fallbacks if you want your video to reach the widest possible audience. With older versions of Internet Explorer still lingering (IE 9 and up support the HTML5 video tag) and the lack of support for closed captions and audio descriptions in any browser, Flash will likely remain the only option for at least some portion of the web for some time.

The good news is that, in some cases, the state of HTML5 video will be improving very soon, for example Firefox 10, which will be released in final form very soon, will support native fullscreen playback.

For more details on which parts of HTML5 video work and which don’t in today’s browsers, be sure to read through the full report.

0
Your rating: None

The World Wide Web Consortium (W3C) has released the first draft of a new web standard aimed at improving online privacy. The W3C’s new Standard for Online Privacy is a set of tools that will ultimately enable your browser to stop sites from tracking your every move on the web.

The first draft of the new privacy standard revolves around the “Do Not Track” (DNT) HTTP header originally introduced by Mozilla as a part of Firefox 4. The DNT header — a bit of code sent every time your browser talks to a web server — can be used to tell websites you don’t want to be tracked. The goal is to give you an easy way to opt out of often invasive tracking practices like behavioral advertising.

Behavior advertising refers to the increasingly common practice of tracking your online behavior and using it to tailor ads to your habits. Advertisers use cookies to follow you around the web, tracking which sites you visit, what you buy and even, in the case of mobile browsers, where you go.

Some web browsers, including Internet Explorer and Chrome, offer an opt-out mechanism in the form of a cookie — add the cookie to your browser and participating sites won’t track your browsing. While the cookie-based approach is widely supported by advertisers, if you ever clear your browser’s cookies for any reason, your privacy settings are lost.

Mozilla’s original “Do Not Track” tool offered the same end result — broadcasting your privacy settings to advertiser’s servers — but instead of using a cookie, Mozilla’s DNT effort created a new HTTP header. The header offers a more robust and permanent solution than cookies and it’s easier for users to control via a simple browser preference.

Mozilla's basic overview of how the DNT header might work

Earlier this year Mozilla turned its DNT efforts over to the W3C where the Tracking Protection Working Group was formed. The working group thus far includes everyone from the major browser vendors to large websites like Google and Facebook. Consumer advocacy groups like Consumer Watchdog, the Electronic Frontier Foundation and even the U.S. Federal Trade Commission are also participating. This first draft of the new privacy standard is the groups’ first public release.

The new spec goes quite a bit further than Mozilla’s original definition of DNT, including sections to define how the header is transmitted, what URI servers should use to respond and how websites are to comply with the preference. Obviously, because this is just the first draft there are still many gaps in the spec.

The new privacy spec is only a first draft, but that’s not the main problem currently stopping DNT from becoming a real-world way to protect your privacy. The real problem is the advertisers. While many are already on board with the new DNT standard, so far few actually obey it. Skeptics often argue that the DNT header won’t truly protect your privacy because there’s no way to force advertising sites to obey it. That is true, and there will no doubt always be some bad apples on the web, but the advertising industry has a surprisingly good track record of self-regulation. Much of that record no doubt stems from fear that, without some degree of self-regulation, governments will step in to impose their own regulation on behalf of consumers.

The W3C’s new privacy standard effort is a long way from finished, and, because it relies on the voluntary participation of advertisers, it will likely never completely protect your privacy. Still, it’s a stronger means of opting out than cookies. Moreover, the existence of an official DNT standard blessed by the W3C just might convince more advertisers to support the initiative.

[Footprints photo by Vinoth Chandar/Flickr/CC]

See Also:

0
Your rating: None