All posts tagged ‘HTML’

File Under: HTML, HTML5, Web Standards
Jul
23
2012

Two HTML Standards Diverge in a Wood

By

The two standards bodies that are jointly responsible for developing the HTML specification have cut the final tie that was binding them together.

The World Wide Web Consortium (W3C) and the Web Hypertext Application Technology Working Group (WHATWG) began to move apart last year when the WHATWG announced it would drop the version number and work on a “living standard” sans version numbers. The W3C continued to focus on HTML “snapshots” like HTML5.

However, despite that split the two shared an editor, Ian Hickson, who oversees both specs. Or did. In an e-mail to the WHATWG mailing list, Hickson announced that he is no longer the editor of the W3C HTML WG spec. The change isn’t unexpected; in fact Hickson announced it would happen over a year ago, but it does emphasize the growing distance between the two standards.

“The WHATWG effort is focused on developing the canonical description of HTML,” writes Hickson on the mailing list. “The W3C effort, meanwhile, is now focused on creating a snapshot developed according to the venerable W3C process.”

With different goals for each version of the spec Hickson says that “the chairs of the W3C HTML working group and myself decid[ed] to split the work into two, with a different person responsible for editing the W3C HTML5, canvas, and microdata specifications than is editing the WHATWG specification.”

Now, more than ever before there seems to be two versions of HTML. The question for developers is, what does this mean for the future of HTML? In the short term, very little.

The W3C will continue to develop its fixed-in-time snapshot of HTML5 and the WHATWG will keep going with the “living standard” approach. What some developers fear is that down the road the two specs will diverge in significant ways and HTML will become a messy set of forked standards and varying browser support that lands us back in the bad old days of IE 6.

Anything is possible, but we remain hopeful that that won’t happen, at least in part because the W3C standard is more of a branch than a fork.

If all goes well the process will remain essentially as it has been for the last few years: a browser adds some shiny new feature, the WHATWG documents it and other browsers implement their own versions. There’s an awkward, sometimes frustrating period for web developers while browsers tweak and refine their support, but eventually the dust settles and a new standard is added to the W3C’s version. It may not be a completely ideal process, but it is what’s managed to bring us this far.

Tags: , , ,
File Under: HTML, HTML5, Web Standards
May
17
2012

Ready or Not, Adaptive-Image Solution Is Now Part of HTML

By

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.

Tags: ,
File Under: HTML, Web Standards
May
14
2012

Use Your ‘Head’ For a Better Way to Serve Images

By

A better way to serve responsive images. Photo: Ariel Zambelich/Wired.com

Responsive web design has grown well beyond its humble beginnings — using liquid layouts and media queries to scale websites so they fit any screen — and now means developers must wrestle with much more complex problems, like serving the right image to the right screen.

Mobile screens are small; downloading full-size images is a waste of bandwidth (and quite possibly users’ money as bandwidth caps become more common). But serving tiny pixelated images to increasingly high-resolution screens doesn’t help users either. There are already dozens of creative solutions to the problem of handling images intelligently in responsive design, but ultimately the web needs more than hacks; it needs a built-in responsive image solution.

The Responsive Images community group has been wrestling with this problem for some time and has proposed and refined the <picture> tag, one possible solution. The picture element would work much like the HTML5 <video> tag, with code that looks something like this:

Due to a communication breakdown between the WHAT WG, which actually writes the standards, and the community group, which is a way for outsiders to contribute to standards, the WHAT WG is already considering a different proposed solution that involves adding some elements to the good old <img> tag.

The proposed solution comes from Apple’s Edward O’Connor and mirrors a similar syntax for background images in CSS. Neither are standards yet and we’re hoping neither ever become standards. Here’s an example of the proposed syntax:

<img src="face-600-200@1.jpeg" alt=""
set="face-600-200@1.jpeg 600w 200h 1x,
face-600-200@2.jpeg 600w 200h 2x,
face-icon.png       200w 200h">

That’s a code tangle only a browser maker could love and in the subsequent discussion on the community group post developers are nearly unanimous in preferring the <picture> tag (though many dislike its verboseness). The truth is neither this nor the <picture> tag is a very appealing solutions.

However, toward the bottom of that discussion thread Denis Leblanc proposes another possible solution, namely, header tags. Matt Wilcox, who created the Adaptive Images solution we’ve covered before, takes Leblanc’s idea and runs with it in another post. What Leblanc proposes is creating a new head tag that would allow web developers to create breakpoints with a media-query-like syntax:

<head>
<meta name='case' data='breakpoint1' media='min-width:350px' />
<meta name='case' data='breakpoint2' media='min-width:1000px' />
</head>

Here’s Wilcox’s explanation of how it would work:

What the code above does is set “case” to equal a particular value, when a media query expression is matched. And if that’s done in the HTML <head> we know that absolutely everything else can rely on it — the <head> is the very first thing parsed by a browser, even before anything inside <body>. Anyone familiar with working on the ‘responsive images’ problem should at this point be getting very excited. It means that the browser can be aware of the need to adapt before any pre-fetch behaviours have been triggered by finding an <img /> element in the mark-up. That is a major advantage and is how this solution solves the problem of image pre-fetch.

In other words, this solution neatly avoids downloading anything other than only the image needed, saving bandwidth and processing power. Then in your body you would simply write:

<img src='/content/images/{case}/photo.jpg' alt='' />

It’s certainly less verbose than either of the other proposals, needing only a single image element with no custom properties or other code. It’s also backward-compatible provided you either create a directory called “{case}” on your server or alias the path to an existing file. Browsers that don’t understand the syntax simply serve the image referenced and those that do choose the appropriate image from the meta tag breakpoints you’ve set.

In short, this looks like a very ideal solution from a web author’s point of view. Whether or not browser makers and the standards bodies agree remains to be seen. One possible strike against it is that it would add variables to HTML in the form of the {case} syntax, but variables are already part of CSS and JavaScript, so why not HTML?

None of these proposals is anything more than an idea at this stage — though there is already a JavaScript polyfill for the new head tag idea — but if you’d like to keep up with what’s happening, be sure to keep an eye on the W3C’s Responsive Images community group. It’s not going to happen overnight, but eventually standards bodies and browser makers are going to start implementing solutions and the more experimenting web developers have done, the better those solutions will be. It’s your web after all, so make it better.

Tags: , ,
File Under: HTML, HTML5, Multimedia, Software & Tools, Visual Design, Web Standards
Aug
2
2011

Review: Adobe’s Edge Offers Web Animation Sans Flash

By

Adobe has released a preview version of a new HTML animation tool dubbed Edge. Together with Wallaby, Adobe’s Flash-to-HTML conversion app, Edge is part of Adobe’s push to remind the web that the company is more than just its much-maligned Flash plugin.

Edge has been released as a free, beta public preview and is available for download through the Adobe Labs website.

Edge is not intended to replace Adobe Flash. At least not in the short term. Instead Edge is aimed at Flash animators looking for a visual way into the world of HTML, CSS and JavaScript-based animations, particularly the relatively simple animations often currently found in Flash-based advertisements.

HTML, especially some of the new elements in HTML5, combined with CSS 3′s animation syntax offers web designers a way to create sophisticated animations without requiring users to have the Flash plugin installed. That’s a good thing since no iOS user is going to have the Flash plugin.

Unfortunately, HTML, CSS and JavaScript don’t offer any easy way to create animations. Developers comfortable writing raw code in text editors have, thus far, been the driving force behind web standards-based animation. Designers and animators accustomed to development tools like Flash, which offers visual layouts and drag-and-drop animation, have been left out of the web standards animation trend.

Edge is Adobe’s attempt to bring the good parts of the Flash development app — visual animation tools, keyframe-based timelines and a stage where you can drag-and-drop objects — to the world of web standards-based animation. But of course, instead of publishing your animations as Flash files, Edge publishes them as web standard HTML, CSS and JavaScript.

Like Hype (see our review) and other HTML animation apps out there, Edge looks and behaves much like Adobe’s Flash development environment with a timeline, keyframes and editing tools that will look familiar to Flash developers. If you know how to use Flash, you’ll be up to speed with Edge in no time.

The Edge interface should look familiar to anyone who has used Flash.

Despite Adobe’s marketing efforts, there’s almost nothing about Edge that is HTML5. Adobe is hardly alone in its misleading use of the HTML5 moniker. Both Hype and Sencha Animator claim to be “HTML5″ animation apps and, like Adobe, neither generates much of anything that isn’t in the HTML4 spec.

In its current form Edge will export your animations using div tags, some CSS animations, a fair bit of JSON and a combination of jQuery and some custom JavaScript to hold everything together.

Why go with div and CSS-based animations when there’s Canvas and SVG? Well, for one thing, this is a very early preview and Adobe claims that eventually Edge will support canvas and SVG (in fact Edge already has some support for importing SVG file). A Mozilla developer raised this question in the Adobe forums and Adobe’s Mark Anders chimed in to say that, “we seriously considered canvas, but current performance on mobile browsers (especially iOS) is very bad.”

Anders goes on to note that iOS 5 will remedy much of iOS’s canvas performance woes, and Adobe is clearly looking for developer feedback on where to go with Edge. If you’ve got strong feelings about where Edge should focus its efforts, head over to the forums and let Adobe know.

While Edge is a long way from a finished product, this early release shows considerable promise. If you’re a Flash developer looking to expand your repertoire to include HTML, CSS and JavaScript animations, Edge just might help. For a nice overview of how to use Edge be sure to check out Mark Anders’ Edge overview movie on Adobe TV.

See Also:

Tags: , , ,
File Under: HTML, HTML5, Web Standards
Jan
21
2011

Meet HTML, The Spec Formerly Known as HTML5

By

It won’t be an unpronounceable symbol, but HTML5 is getting a Prince-style name change. From here on out HTML5 will simply be HTML — according to the WHATWG anyway.

Just a day after the W3C unveiled its new HTML5 logo, the Web Hypertext Application Technology Working Group (WHATWG) has announced that it will drop the term “HTML5,” stop the versioning of HTML altogether and instead treat the evolving specification as a “living standard.”

While eliminating the version number from HTML has been part of the WHATWG’s plan from the beginning, the timing of the change is clearly related to the W3C’s attempt to embrace the term “HTML5.” The W3C recently showed off a new HTML5 logo, but the accompanying FAQ used the term HTML5 to cover everything from the actual spec to only tangentially related tools like CSS 3, WOFF and SVG. Many developers saw the W3C’s nebulous use of the term HTML5 as a sign that the term had become, like “AJAX,” just another marketing buzzword.

The W3C has since rewritten its FAQ to clarify and more sharply define just what HTML5 is and is not, but before that happened Ian Hickson, the WHATWG’s editor, announced that the WHATWG was renaming its spec to just HTML. Hickson says the WHATWG was “going to change the name last year but ended up deciding to wait a bit since people still used the term ‘HTML5′ a lot.”

Hickson then makes a not-so-subtle jab at the W3C, saying HTML5 “is now basically being used to mean anything Web-standards-related, so it’s time to move on!”

The W3C has long had a tenuous relationship with the WHATWG. Technically the W3C is the standards body charged with publishing the HTML spec. The WHATWG — a consortium of browser makers — grew out of the W3C’s neglect of HTML and its misguided decision to pursue XHTML 2. Now that both groups are working on the same spec, in theory, their goals are the same. In practice, however, the two groups often butt heads. In other words, just because the WHATWG has decided to abandon the term HTML5, don’t expect it to disappear overnight.

The W3C will continue to work toward “snapshots” that reflect stable milestones of the ever-changing WHATWG version of the spec. For now at least, that means the term HTML5 will be alive and well at the W3C, as the group works through its standard practice of issuing working drafts, holding last calls on changes and finally publishing the spec as a “recommendation.”

Since browser makers have long been well ahead of the W3C when it comes to implementing the latest and greatest parts of the HTML5 spec, they will likely focus on the WHATWG’s HTML spec, which will, like Google’s Chrome browser, follow a “rolling release” schedule.

No doubt the media and marketers will continue to use HTML5 as a buzzword that means far more than just the spec, but even that’s not always a bad thing. There’s no doubt that Apple, Google, the New York Times and everyone else who’s used HTML5 as an analog for the New Shiny has helped HTML5 — and all the other tools it’s come to stand for — gain momentum. As web developer Jeff Croft puts it, “sometimes we just need a word to rally behind.”

While not everyone understands the nuances of what’s HTML5, what’s CSS 3 and what’s just JavaScript, that doesn’t change the fact that everyone is excited about building a better web and that is exactly what HTML(5) is designed to do.

See Also:

Tags: ,
« OLDER POSTS