Adobe is intent on giving the web more than just the oft-vilified Flash plugin. In fact the company has been busy proposing web standards for some time, and its CSS Shaders proposal is now officially part of the CSS 3 specification.

That means CSS Shaders will become a web standard, though not on their own; instead the W3C is going to roll CSS Shaders into the CSS Filter Effects specification. The feature formerly known as Shaders will now be referred to as Custom Filters

The original name “Shader” has its roots in the 3-D graphics world and roughly describes what “Custom Filters” will do, namely create 3-D effects, like the rippling motion in a waving flag, by “shading” regions.

In the end the name isn’t that important; just know that Custom Filters will allow web developers to easily apply cinema-style filter effects to any HTML content. Think grayscale-to-color transitions, animated shadows, photo-realistic warping and other mainstays of the 3-D animation world.

You’ll still need a special build of WebKit that Adobe put together to see Custom Filters in action. You can grab the experimental browser from the GitHub page, where you’ll also find plenty of examples and sample code that show how shaders, er, Custom Filters work. Also be sure to check out Adobe’s earlier write-up on how Filters work and how you can use them.

Now that Shaders are an official part of CSS, hopefully web browsers will begin adding support.

[Update:The original title of this post was Adobe’s CSS Shaders Now an Official Web Standard, wherein I intended “Official Web Standard” to mean “a part of the web standards process”, not actually a published W3C recommendation. Judging by the comments that’s how most of you took it, but of course it was definitely possible to read it as something more than it actually is, so the headline has been updated to clarify that point.]

]]>http://www.webmonkey.com/2012/09/adobes-css-shaders-now-an-official-web-standard/feed/0‘Vendor Tokens’ Offer Another Way Out of the CSS Prefix Messhttp://www.webmonkey.com/2012/05/vendor-tokens-offer-another-way-out-of-the-css-prefix-mess/
http://www.webmonkey.com/2012/05/vendor-tokens-offer-another-way-out-of-the-css-prefix-mess/#commentsFri, 11 May 2012 17:38:02 +0000Scott Gilbertsonhttp://www.webmonkey.com/?p=56481

A new proposal to fix CSS vendor prefixes uses a little bit of the past to make the future look better. It's just a proposal, but CSS expert Eric Meyer thinks "Vendor Tokens" just might offer a solution to the fractured world of CSS.

CSS expert Eric Meyer thinks that a new proposal, CSS Vendor Tokens, might offer a way out of the CSS vendor prefixes mess.

CSS vendor prefixes were designed to help web developers by providing a way to target CSS rules to specific browsers and use proposed standards before they were finalized. Alas, while they have helped, they’ve also hurt the web.

The W3C’s CSS Working Group is currently in the process of trying to fix some of the problems. We’ve covered one proposed solution from Florian Rivoal, which would make vendor prefixes into aliases and ensure that when a browser implements a new CSS feature, it will work both prefixed and unprefixed.

Another proposal that Meyer wrote to tell us about comes from François Remy, who proposes what he calls Vendor Tokens. “I propose we use unprefixed properties from start,” writes Remy in a message to the www-style mailing list, “but with a token explaining which version of the property we built our CSS for.”

Essentially what Remy proposes is to use a flag much like !important, but to signal which version of the CSS property the rule is aimed at. The advantage is that instead of targeting browsers directly, you’re targeting a draft version of the spec.

Here’s Remy’s example of the syntax:

selector {
border-radius: 1em !webkit-draft;
}

It’s a bit less typing than the current method, which would require four lines to convey the same information and, as Meyer suggests, dropping the -draft would simplify things even more. But more important than a simpler syntax is that, as Remy explains it: “any browser which is not webkit but implemented border-radius in a way that is compatible with the ‘webkit draft’ can support the declaration.” That’s a little different than vendor prefixes. With Remy’s proposal other browsers wouldn’t need to impersonate webkit, “they just acknowledge they support one specific property the way the webkit draft defines it.”

So a more full-featured declaration might look like this:

selector {
border-radius: 1em !webkit-draft !moz-draft !o-draft;
}

Remy also includes a way to handle scenarios where Apple’s version of WebKit might differ from Google’s or even account for differences in versions of the spec.

As Remy admits, there are some drawbacks to this approach, and the syntax isn’t the cleanest we’ve seen, but as Meyer writes, “it feels cleaner than trying to do the same thing with prefixes.”

It will likely be some time before the CSS Working Group makes a decision on what, if anything, to do about vendor prefixes. If you’re interested in keeping up with the discussion on this and other proposals keep an eye on the www-style mailing list.

]]>http://www.webmonkey.com/2012/05/vendor-tokens-offer-another-way-out-of-the-css-prefix-mess/feed/0Opera Forges Ahead With Plan to Support WebKit Prefixeshttp://www.webmonkey.com/2012/04/opera-forges-ahead-with-plan-to-support-webkit-prefixes/
http://www.webmonkey.com/2012/04/opera-forges-ahead-with-plan-to-support-webkit-prefixes/#commentsFri, 27 Apr 2012 19:01:40 +0000Scott Gilbertsonhttp://www.webmonkey.com/?p=55975Opera software says that in order to remain competitive it will have to pick up the slack from web developers and implement a CSS prefix meant only for WebKit browsers. Mozilla's Firefox may not be far behind.

CSS vendor prefixes were designed to help web developers by giving them a way to target CSS to specific browsers and use proposed standards before they were finalized. The idea was to move the web forward without rushing the CSS standards process. Unfortunately, it hasn’t always worked out that way. In fact, web developers fell in love with the -webkit- prefix and often forget that there are other prefixes as well: -o- for Opera, -moz- for Firefox and -ms- for Internet Explorer.

Now Opera says that to remain competitive it plans to support -webkit- in addition to its normal -o- prefix.

The problem, in Opera’s view, is that instead of writing code that will work in any web browser, some of even the largest sites on the web are coding exclusively for WebKit (the rendering engine that powers web browsers on the iPhone, iPad and Android phones). Web developers have, the argument goes, created the same sort of monoculture that used to exist around Internet Explorer, with websites proudly proclaiming they “work best in WebKit.”

In most cases Opera, Firefox and Internet Explorer support the same CSS features found in WebKit. The problem is that developers are only using the -webkit prefix, so only WebKit browsers render the effects. As a result, Opera, Firefox and IE look like less capable browsers even when they aren’t.

Opera web evangelist Bruce Lawson writes on the Opera development blog, “this leads to a reduced user experience on Opera and Firefox, which don’t receive the same shiny effects such as transitions, gradients and the like, even if the browser supported those effects” (emphasis in original).

Non-WebKit browser vendors first started talking about implementing the -webkit prefix earlier this year during a CSS Working Group meeting. Microsoft, Mozilla and Opera all said they felt the need to support -webkit, lest their users be relegated to an inferior browsing experience (because so many sites are using only the -webkit prefix).

While it’s not hard to understand Opera’s position, we’re disappointed to see Opera moving forward with this plan.

The very real danger is that if other browsers implement -webkit prefixes then the entire CSS standards effort will be broken.

Instead of coding against a single CSS specification developers will need to code against changing vendor prefixes. As CSS Working Group co-chair, Daniel Glazman, wrote when Opera first floated the idea, “I don’t think this is the right way. And this is the first time in this WG that we are proposing to do things that are not the right way.”

We at Webmonkey hope it’s obvious that building WebKit-only sites is a mistake. If you’re only interested in iOS users then take a tip from Instagram and build a native app. As Peter Linss, Hewlett-Packard’s CSS WG representative and co-chair of the working group, said at the earlier CSS WG meeting, “there’s no advantage to the web to have someone write a platform-specific website.” There’s no real advantage for the developer either, especially when an automated CSS prefixer can do all the work for you. So, if you’re using prefixes, we encourage you to take the time to add them all, test your site in as many browsers as possible and make sure your site works for everyone.

]]>http://www.webmonkey.com/2012/04/opera-forges-ahead-with-plan-to-support-webkit-prefixes/feed/2W3C Publishes an HTML5 Spec for Web Developershttp://www.webmonkey.com/2011/08/w3c-publishes-an-html5-spec-for-web-developers/
http://www.webmonkey.com/2011/08/w3c-publishes-an-html5-spec-for-web-developers/#commentsWed, 10 Aug 2011 16:19:33 +0000Scott Gilbertsonhttp://www.webmonkey.com/?p=51326Chances are, despite embracing the tools therein, you’ve probably never read the HTML5 spec. We don’t blame you. Frankly the worst part of this job is when we have to translate gibberish from the actual HTML5 spec into words normal humans can understand. The problem is that the HTML5 spec is written for browser makers, […]

Chances are, despite embracing the tools therein, you’ve probably never read the HTML5 spec. We don’t blame you. Frankly the worst part of this job is when we have to translate gibberish from the actual HTML5 spec into words normal humans can understand.

The problem is that the HTML5 spec is written for browser makers, not web developers, and contains highly technical and very esoteric language.

The W3C’s web developer version of the spec is still more technical than the WHATWG’s version, and nowhere near as nice to look at, but at least you can read the HTML5 spec without all the notes about conformance criteria and other browser maker-specific lingo. Flipping between the two web developer versions it’s actually not hard to wrap your head around when to use <section> and when to use <article>.

If you’ve ever tried to wrestled your way through the complexities of the HTML5 specification, we’ve got good news — there’s now a “web developer edition.” The main HTML5 spec can be overwhelming for web developers trying to understand how to use HTML5 in their sites and web apps. Much of the spec is written […]

If you’ve ever tried to wrestled your way through the complexities of the HTML5 specification, we’ve got good news — there’s now a “web developer edition.”

The main HTML5 spec can be overwhelming for web developers trying to understand how to use HTML5 in their sites and web apps. Much of the spec is written for browser makers and other implementers, not web developers, and contains highly technical and very esoteric language.

The web developer version of HTML5 strips out all the elements that are only of interest to browser makers, and focuses on developers, making for a more readable, understandable document. In other words, it makes sense to mere mortals.

As an added bonus, the new website hosting the web developer version has a much cleaner, simpler design that doesn’t look like it crawled, zombie-style, out of 1994.

Apple posted a showcase of “HTML5 and web standards” on its website Thursday that highlights the level of support for the emerging standard in the company’s Safari and Mobile Safari browsers. It’s nice to see Apple (or anyone for that matter) talking about HTML5 and mentioning more than just video. The site showcases HTML5 audio […]

Apple posted a showcase of “HTML5 and web standards” on its website Thursday that highlights the level of support for the emerging standard in the company’s Safari and Mobile Safari browsers.

It’s nice to see Apple (or anyone for that matter) talking about HTML5 and mentioning more than just video. The site showcases HTML5 audio and canvas elements, as well as CSS 3 transitions and typography tools. It also has a nice photo gallery that looks and behaves just like former Apple designer Mike Matas’ amazing photo-gallery site.

Unfortunately, the way Apple presents the showcase, you would think Safari is the only web browser that supports these new web standards.

In fact, visit the site with any other browser and you’ll get a message telling you to download Safari. Surely your browser must be inadequate? Actually, your browser is probably capable of handling the showcase just fine, but ultimately the showcase isn’t about web standards: It’s about Apple’s version of web standards.

Apple is detecting the user-agent string (the bit of identifying data your browser passes to a web server when it requests a page) and only allowing Safari users to see the galleries. Other browsers are effectively cut off, regardless of the fact that many can render them just fine.

So much for web standards. Not only is user-agent sniffing absolutely the wrong way to determine the HTML5 capabilities of the current user, the implicit suggestion is that HTML5 is something only Apple supports.

Microsoft recently published its own HTML5 showcase to hype the coming release of Internet Explorer 9, and its demo pages are viewable (and work) in any non-IE browser with the proper support. Mozilla’s HTML5 demo pages are geared to work with experimental builds of Firefox, but at least other browsers aren’t blocked, and most of the demos actually work in Chrome.

To test Apple’s demos in other browsers, we spoofed the user agent in Firefox and Chromium and found that, while several examples do indeed fail in Firefox, most worked just fine. Naturally, everything works without issue in Chromium, because it uses the same WebKit rendering engine as Safari. Apple is being disingenuous by making its browser seem more compelling than others. That’s not surprising, but we’d be disappointed to see independent developers follow suit. [Update: As several commenters, and John Gruber point out, the version WebKit that Chromium uses doesn’t yet support all of CSS 3′s 3D transforms, which renders this demo incomplete, though still functional, in Chrome/Chromium.]

So how should you detect whether the current browser can display whatever bit of HTML5 or CSS 3 you’re using? The long-established best practice is to detect for features, not browsers. To find out which features are available in the current browser isn’t hard — there are even several free, open source libraries out there that do just that.

Modernizr is one of our favorites. This handy little JavaScript library can detect which HTML5 features are available. Then, armed with that information, you can then create conditional JavaScript statements to offer HTML5 to those browsers that support it, but still fall back on other content for those that don’t.

There are however, some cases where Modernizr might be overkill. For example, if you just want to embed some HTML5 video, you only need to detect one element. If Modernizr isn’t right for your project, check out Mark Pilgrim’s list of ways to detect HTML5 elements. The list of elements and how to detect them is an appendix to Pilgrim’s book in progress, Dive Into HTML5.

The list isn’t just elements, though it does cover those as well. But it also shows you how to detect API support for things like offline storage or geolocation, as well as SVG, SVG-in-HTML and even which video codec the current browser supports.

One thing Pilgrim doesn’t cover is CSS 3 features (CSS 3 != HTML5). To detect which CSS 3 features are available in the current browser you can use Modernizer or you can roll your own code using a library like jQuery, which includes a support() method to check a wide range of browser features before executing code.

]]>http://www.webmonkey.com/2010/06/apples-html5-showcase-less-about-web-standards-more-about-apple/feed/147CSShttp://www.webmonkey.com/2010/02/css/
http://www.webmonkey.com/2010/02/css/#commentsMon, 15 Feb 2010 20:45:47 +0000Webmonkey Staffhttp://stag.wired.com/primate/?p=93CSS, or cascading stylesheets, allow you to define how web page elements are displayed. Specific margins or colors can be associated with elements on the web page; Headers and links, for example. When style sheets are applied to a new page, the elements are changed according to the specifications of the style.

Specific margins or colors can be associated with elements on the web page; Headers and links, for example. When style sheets are applied to a new page, the elements are changed according to the specifications of the style.

]]>http://www.webmonkey.com/2010/02/css/feed/1Document Object Modelhttp://www.webmonkey.com/2010/02/document_object_model/
http://www.webmonkey.com/2010/02/document_object_model/#commentsMon, 15 Feb 2010 20:45:47 +0000Webmonkey Staffhttp://stag.wired.com/primate/?p=110The document object model (DOM) is the specification for how objects on a web page are represented. A DOM defines each object on a web page (images, text, scripts, links, etc.) and also defines what attributes are associated with these objects and how they can be manipulated.

]]>http://www.webmonkey.com/2010/02/document_object_model/feed/1ISO Entitieshttp://www.webmonkey.com/2010/02/iso_entities/
http://www.webmonkey.com/2010/02/iso_entities/#commentsMon, 15 Feb 2010 20:45:47 +0000Webmonkey Staffhttp://stag.wired.com/primate/?p=183ISO (International Standards Organization) entities, sometimes referred to as character entities, are a group of ASCII characters that can be used in HTML to display special characters. For example, you can’t simply type the registered trademark symbol ® from your keyboard since it’s not a standard ASCII character; it’ll show up as garbage on your […]

ISO (International Standards Organization) entities, sometimes referred to as character entities, are a group of ASCII characters that can be used in HTML to display special characters. For example, you can’t simply type the registered trademark symbol ® from your keyboard since it’s not a standard ASCII character; it’ll show up as garbage on your web page. But if you use the ISO entity equivalent, the web browser will be able to interpret the character correctly.

]]>http://www.webmonkey.com/2010/02/iso_entities/feed/1What Comes After HTML5? Just HTMLhttp://www.webmonkey.com/2010/01/what_comes_after_html5__htmldot/
http://www.webmonkey.com/2010/01/what_comes_after_html5__htmldot/#commentsThu, 14 Jan 2010 09:44:50 +0000Scott Gilbertsonhttp://www.webmonkey.com/blog/whatcomesafterhtml5justhtmlThe future of the web is fast approaching. HTML5, the successor to today’s HTML 4, the lingua franca of the web, has reached the Last Call stage and is beginning to look like a finished spec. While it will be some time before HTML5 can be called complete, forward-thinking browsers already support much of the […]

What will this HTML look like you ask? Well, Mark Pilgrim, who works on the WHAT Working Group, has started a new series of posts on the group’s blog entitled What’s Next in HTML?

The answer, at least for now, is a possible new tag: <device>.

As you would expect <device> will offer web developers a way to access devices, for example your PC’s webcam or perhaps your mobile device’s accelerometer.

The obvious application for the device tag is video chat — something currently only possible using proprietary tools like Adobe Flash. As Pilgrim points out in his post, if you combine the existing video tag and web socket tools of HTML5 with the new device tag, all the elements necessary for an online video chat application are in place.

Before web developers get too excited it’s important to realize that <device> is a long, long way from being a real HTML element. As Pilgrim notes: “the entire device API is still in its infancy… nobody has even started implementing a prototype of that piece yet, and the whole idea might be scrapped.”

That shouldn’t be too surprising for those of you following the bleeding edge of the web, after all we’ve already been teased with the promise of a single video codec only to see that vanish.

But with any luck, the device tag won’t suffer a similar fate and one day web developers will be able to take advantage of yet another set of tools that were once the sole province of desktop software.