All posts tagged ‘HTML’

Review: Adobe’s Edge Offers Web Animation Sans Flash

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:

File Under: HTML, HTML5, Web Standards

Meet HTML, The Spec Formerly Known as HTML5

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:

File Under: CSS, HTML5, Visual Design

Celebrate the Holidays With the Advent Calendar for Web Nerds

How do we know it’s holiday season? Sure, it’s getting colder, and possibly even snowing where you live. But the real sign for web nerds is that 24Ways, the annual advent calendar for web geeks, is shining in all its standards-promoting glory.

This year 24Ways is, along with the rest of us, embracing HTML5 and CSS3. Among the useful hints, tips and tutorials so far this year are Christian Heilmann’s take HTML5′s Local Storage API for offline content and Scott Schiller’s The State of HTML5 audio.

On the CSS side, Inayaili de León has a great CSS wishlist, which includes comments from Tab Atkins, a CSSWG member who addresses many of the possibilities raised in the piece. One particularly noteworthy item in de León’s piece is something we didn’t know existed: the :-moz-any() selector group. Although not yet a formal part of the CSS spec, it looks like the any() selector has a good chance of making it in one day.

The any() selector would be useful for shortening code, for example, because HTML5 encourages multiple h1 tags, which might be at all sorts of depths within the page, you could simple write (to borrow Mozilla’s example):

-moz-any(section, article, aside, nav) h1 {
  font-size: 25px;
}

Again, the any() selector is a just a proposal at this point, but it does work in the latest beta of Firefox if you’d like to test it.

Other good articles so far in this year’s 24ways include a look at design workflows and how you can improve your own, and everyone’s perennial favorite — how to avoid the flash of unstyled content when embedding fonts in your page.

This year’s 24Ways also has a new twist: when the series is finished, there will be a limited edition print annual. You can order a copy today, and all proceeds will go to UNICEF.

Altoids Advent Calendar photo by Kim Taylor/Flickr/CC. For instructions, visit her blog.

See Also:

File Under: HTML5

HTML5 Simplequiz: The Complexities of the Cite Tag

The latest installment in HTML5Doctor’s Simplequiz — part of a series of “tests” designed to help you understand HTML5 and how to use it — delves into what might be the most controversial change in HTML5: the cite tag.

The question in the quiz seems simple: given a passage by an author, how do you mark up the author’s name? The possible answers are, using the <b> tag, the <i> tag, a span tag, the <cite> or nothing at all.

There’s something of a trick lurking in those answers, because if you’re familiar with HTML as it’s been applied for the last decade, you’d probably pick <cite>. In HTML 4.01, the cite tag is “intended to give information about the source from which the quotation was borrowed.” Source is somewhat ambiguous, but most of us would assume that a person could be the source of a quote, thus, wrapping their name in a cite tag makes perfect sense.

In HTML5, however, the spec is not ambiguous and clearly says: “the cite element represents the title of a work… a person’s name is not the title of a work — even if people call that person a piece of work — and the element must therefore not be used to mark up people’s names.”

So, while the cite tag might have been a possible answer to the question of how you should mark up an author’s name in HTML 4.01. it clearly is not in HTML5.

I know what you’re thinking, HTML5 is supposed to be backwards-compatible with previous versions of HTML. So what’s up with redefining the cite tag? Well, there’s a good chance that the authors of HTML 4 meant what the authors of HTML5 actually wrote, but that doesn’t change that fact that there are probably millions of cases on pages around the web where <cite> will suddenly be wrong. So much for backward compatibility.

As web developer Jeremy Keith has pointed out, it’s actually much worse than it looks at first glance. Not only is cite no longer an option for peoples names, the HTML5 spec suggests that <b> might be appropriate to mark up author’s name. As Keith says, “we are seriously being told to use semantically meaningless elements to mark up content that is semantically meaningful.”

Keith calls for users to reject HTML5′s definition of <cite> and there’s a page on the WHATWG wiki that tracks the usage of <cite> in the wild to attempt to prove that HTML5′s change is ill-advised. Given that the default WordPress theme uses <cite> to mark up the names of blog commenters, there’s no shortage of examples.

However, given that Keith’s article dates from 2009 and there have been no major changes to the <cite> tag since, his may be a losing battle.

As for the HTML5 Simplequiz question, well, I’d use the <cite> tag. But I’d do so knowing I was trading valid code for more semantically meaningful content and, while that may not be “correct,” I can live with it. I’d just pair it with a little CSS to get rid of the browser’s default use of italics for <cite>.

See Also:

File Under: CSS, JavaScript

Google Shows Off Its Bouncy Balls

If you’ve visited Google’s home page Tuesday, you’ve seen the bouncy ball demo. The Google logo is made of little colored balls that run away from your mouse and jump around furiously when you click on them. The balls will also jiggle from side-to-side if you move your browser window around.

The company did it using CSS positioning and some JavaScript math.random functions, so it works best in non-IE browsers with fancy JavaScript engines. In the useless-but-freaky-cool department, it ranks up there with the playable Pac-Man doodle from earlier this year.

Not content to let Google have all the fun, Rob Hawkes created an alternate version using HTML5 canvas that reproduces most of the functionality. His code is on github, too.