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.

File Under: Frameworks, Multimedia

Meet Treesaver, a New HTML Magazine App

A startup called Treesaver has developed a slick presentation framework for digital magazines that runs in the browser. It has many of the features you’d expect from a clean, reader-friendly content wrapper (like Instapaper or Readability) but it couples that functionality with a way-cool user interface.

Pages can be navigated by swiping from side-to-side, and you get helpful ghost images on either side of the page you’re reading, which aid in signposting. Also, the pages within the web app dynamically resize for different screens — and it even resizes on the fly as you make the browser smaller and larger. It’s all HTML, JavaScript and CSS.

Here’s the demo video for Nomad Editions, the first of Treesaver’s launch partners using the company’s framework to make a public announcement (Treesaver is still pre-launch right now):

Nomad also got some love from The New York Times Wednesday.

With digital magazines all the rage, everyone’s racing to get their traditional paper-and-ink publications onto the iPad. There are two routes — the native app, which requires the use of Apple’s tools and adherence to its rules, or the web app, which lets you do just about whatever you want as long as it works in a browser.

If you build a native app, you get some impressive performance with the swipey-swipey stuff, and you control both the ad revenue and your kerning pairs. But you’re also locked into a specific device’s platform, distribution is a pain, and you’re disconnected from the internet unless you bother to build it in.

The webby route has its own advantages, of course. Filipe Fortes, one of the founders of Treesaver, has posted an excellent list of all the ways the web wins — a wider audience, a wider range of compatible devices, easy access to social networking tools, real hyperlinks, search indexing, content embedding.

Treesaver will be entering beta testing in a few weeks, and the code will be released under an open-source license soon after that.

See Also:

File Under: CSS, HTML, Web Standards

The Solar System, Rendered in CSS and HTML

A web developer named Alex Giron has created a working model of the solar system using only web standards.

It’s fully animated — though Alex takes advantage of some new CSS 3 features (border-radius, transforms and animations) and utilizes the -webkit prefix, so you’ll need to view it in Safari or Chrome to see the planets move around the sun.

Firefox and Opera users won’t see the animations, just a static CSS layout. But the hover events work, so you can mouse over each planet and learn the story of each celestial body. And yes, he included Pluto.

Here’s Alex’s blog post that includes a walk-through of the code.

Bonus: Alex’s screenshot of the same page in IE.

[Via kottke]

See Also:

File Under: Software, Visual Design

Photoshop Contemplates Adding Live HTML Layers

Adobe’s Principal Product Manager of Photoshop, John Nack has posted an idea for a new Photoshop feature on his blog. Nack’s idea is to create a way of rendering HTML and CSS within Photoshop. This means visual designers could work with “live” HTML objects as they’re building websites within a team of programmers, easing the workflow between the designing and coding stages.

Before you get to excited (or disappointed) keep in mind that isn’t a feature, isn’t even part of a plan, it’s simply and idea that Nack would like feedback on.

Nack describes the idea (and workflow) like this: a designer creates a mockup, which he hands off to a programmer. The programmer then renders the mockup in HTML/CSS, at which point he could hand it back to the designer who can open it in Photoshop as a kind of live layer. Resizing and other layer actions would cause the code to respond according to how the programmer has written the code.

What Nack is envisioning is a smart layer that uses WebKit (already part of the Creative Suite) to render what he calls “programmable layers.”

Among the benefits Nack sees are “[live] pixel-accurate web rendering (text and shapes); the ability to style objects via CSS parameters (enabling effects like dotted lines); data-driven 2D and 3D graphics; and high fidelity web output (HTML as HTML).”

The real world example Nack uses is a calendar widget, but that particular example raises an interesting question — what about scripting languages? We don’t know of anyone who writes out calendar code in HTML, that would be insane to update. So if you’re generating the calendar with, say, PHP, where does the script rendering happen?

So far, the comments appear pretty evenly divided between those who think such a feature would be great and those think that either it’s just more bloat in Photoshop, or that Fireworks would be a better home for the idea.

If you’ve got strong opinions one way or the other, head over to Nack’s blog and let him know what you think, either in the comments or by completing this survey.

Just remember that this is not part of a roadmap and may well never happen. In the words of Douglas Adams, “Don’t panic.”

See Also:

File Under: HTML, UI/UX

Using ‘Mad Libs’ to Make Web Forms More Fun

In an ideal world, the web would have a built-in identity solutions — websites would automatically know who you are when you arrive. In the real world, however, almost every website has its own sign up and authentication process, endless forms enticing you to enter your name, your e-mail, pick a password… yawn, what now?

It’s repetitive, boring and makes many of your users click away in disgust. But what if you turned the sign up form into a narrative, something a bit like a Mad Lib?

That’s exactly what web developer Jeremy Keith has done for his podcasting site, Huffduffer. Instead of a list of blank boxes, Huffduffer’s sign up form looks like this:

All the usual behaviors of a web form are still there. You can tab between fields, your password is still masked and errors are highlighted if there are any. The difference is the in the presentation. It doesn’t look like some kind of online test.

In short, Huffduffer’s sign up for is refreshing, but does it work? Well, Luke Wroblewski, Chief Design Architect at Yahoo and author of the book Web Form Design, had the same question and, with some help from the team at Vast.com, ran some tests.

The designers at Vast redesigned their response forms along the lines of Huffduffer’s form and found that, as Wroblewski reports, “Mad Libs style forms increased conversion across the board by 25-40 percent.”

The forms are live on both Vast and the Kelley Blue Book website if you’d like to experience them yourself. Wroblewski has a few minor caveats about the increased number of users — be sure to check out his post for the complete details — but at least in some cases it would seem that a narrative flow trumps the boring old form.

See Also:

File Under: HTML, Web Standards

Make an HTML Document

HTML is the lingua franca of the web. It’s a simple, universal mark-up language that allows web publishers to create complex pages of text and images that can be viewed by anyone else on the web, regardless of what kind of computer or browser is being used.

Despite what you might have heard, you don’t need any special software to create an HTML page; all you need is a word processor (such as SimpleText, BBEdit, or Microsoft Word) and a working knowledge of HTML. And lucky for all of us, basic HTML is dead easy.

It’s All About the Tags

HTML is just a series of tags that are integrated into a text document. They’re a lot like stage directions — silently telling the browser what to do, and what props to use. Continue Reading “Make an HTML Document” »