Skip navigation
Help

HTML 5

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

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

Responsible responsive design demands responsive images—images whose dimensions and file size suit the viewport and bandwidth of the receiving device. As HTML provides no standard element to achieve this purpose, serving responsive images has meant using JavaScript trickery, and accepting that your solution will fail for some users.

Then a few months ago, in response to an article here, a W3C Responsive Images Community Group formed—and proposed a simple-to-understand HTML picture element capable of serving responsive images. The group even delivered picture functionality to older browsers via two polyfills: namely, Scott Jehl’s Picturefill and Abban Dunne’s jQuery Picture. The WHATWG has responded by ignoring the community’s work on the picture element, and proposing a more complicated img set element.

Which proposed standard is better, and for whom? Which will win? And what can you do to help avert an “us versus them” crisis that could hurt end-users and turn developers off to the standards process? ALA’s own Mat Marquis explains the ins and outs of responsive images and web standards at the turning point.

0
Your rating: None


HTML5Rocks Live, Episode 1

In this episode of HTML5Rocks Live, Boris, Eric and Paul join us to show some great new libraries and performance tips. Please leave your comments on our plus page at goo.gl In the first chapter, Paul shows how to use some of Chrome's new developer tools to understand how things are rendering and get improved performance. In the second chapter (21:25), Boris shows off his new device.js library to help make development of mobile web applications and sites easier. Eric closes the hangout (40:00) and talks about his new file system API polyfill that uses indexed db as it's back end. 02:15 Scroll Effects Demo goo.gl 23:04 - Media Queries Site goo.gl 24:15 - WURFL goo.gl 26:40 - Boris' Device Library goo.gl 29:28 - Device.js Demo goo.gl 33:25 - Bug to add touch-enabled media query to Chrome, please star goo.gl 35:00 - Chrome's DevTools for Mobile Development 38:56 - Paul Irish's Touch Demos goo.gl 40:43 - File System API Book goo.gl 43:10 - Eric's idb.filesystem.js goo.gl 44:27 - idb.filesystem HTML5 File System Demo goo.gl 47:33 - HTML5 Filesystem Playground goo.gl
From:
GoogleDevelopers
Views:
11028

209
ratings
Time:
52:29
More in
Science & Technology

0
Your rating: None

HTML5 Logo

Adoption of the HTML5 video specification continues to climb rapidly according to research from media platform company LongTail Video. The firm presents a wide gamut of data, gathered as part of the development process for its JW Player, on a page appropriately called "The State of HTML5 Video." Naturally it hits on the essentials like browser integration, supported file formats, and fullscreen playback capability, but LongTail's tests also dive into the nitty gritty aspects of tag attributes, JavaScript, and accessibility support. There's a clear upward trend for nearly all browsers other than past releases of Internet Explorer: versions 6, 7, and 8 forgo HTML5 video entirely, though IE9 has thankfully implemented the specification....

Continue reading…

0
Your rating: None



Mozilla has teamed up with Web design studio Little Workshop to develop a Web-based multiplayer adventure game called BrowserQuest. The game is built with standards-based Web technologies and is designed to be played within a Web browser.

With the technical capabilities offered by the latest standards, Web developers no longer have to rely on plugins to create interactive multimedia experiences and application-like user interfaces. As we reported earlier this month, modern standards are making the Web an increasingly viable platform for game development.

BrowserQuest, which is built with JavaScript and HTML5, is a compelling demonstration of how existing standards can be used to create browser games. It uses the HTML5 Canvas element to render a tile-based 2D world, HTML5 audio APIs to support sound effects, WebSockets to facilitate communication with the backend server, and localStorage to save the player's progress.

The game's remote backend, which enables the real-time multiplayer gameplay, was coded in JavaScript and runs on top of Node.js. The load is balanced across multiple Node.js instances on three separate severs. At the time this story was written, the backend was successfully handling over 1,900 simultaneous players. The status of the BrowserQuest backend can be monitored through the game's real-time dashboard interface.

The developers focused on using widely-supported standards so that the game would work well across a wide range of desktop and mobile browsers. It works just as well on a tablet device, for example, as it does on a desktop computer.

The future looks even brighter, as there are a number of pending Web standards that will greatly enhance support for building games on the Web in the future. Features like 3D graphics and support for game controller peripherals, for example, could eventually take the browser beyond the realm of casual gaming. You can refer to Mozilla's wiki to see an overview of the work that the organization is doing to improve browser-based gaming. For more details about BrowserQuest, see the Mozilla Hacks blog or check out the backend server code on GitHub.

Read the comments on this post

0
Your rating: None