All posts tagged ‘CSS’

File Under: CSS
May
11
2012

‘Vendor Tokens’ Offer Another Way Out of the CSS Prefix Mess

By

Sisyphus

Sisyphus, by Max Klinger. The four ladies up top are named Gecko, WebKit, Trident and Presto. Image: Max Klinger via Wikimedia

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.

Tags: , ,
File Under: CSS, Web Standards
May
8
2012

New Proposal Could End the CSS Prefix Madness

By

Photo: Ariel Zambelich/Wired.com

The W3C continues to wrestle with the problems CSS vendor prefixes are causing the web. While they’re useful for web developers, prefixed CSS rules as they are currently known may be causing more problems than they solve. Now W3C member Florian Rivoal has proposed a new solution to the prefixing problem.

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.

Rivoal blames the prefix policy itself, writing, “I believe the current prefixing policy is hurting more than it helps, and that the problems are fundamental to the policy itself, rather than something that can be blamed on various parties for not following it correctly.”

The result is that the web is now in a situation where browsers are planning to start supporting other browser’s prefixes, which just might defeat the entire point of having web standards.

Rivoal’s proposal would change the way prefixes currently work and would solve some, though probably not all of the problems. Here’s Rivoal’s full proposal:

When a browser vendor implements a new CSS feature, it should support it, from day 1, both prefixed and unprefixed, the two being aliased. If a style sheet contains both prefixed and unprefixed, the last one wins, according to the cascade.

Authors should write their style sheets using the unprefixed property, and only add a prefixed version of the property (below the unprefixed one) if they discover a bug or inconsistency that they need to work around in a particular browser.

If a large amount of content accumulates using a particular vendor prefix to work around an issue with the early implementation in that browser, the vendor could decide to freeze the behavior of the prefixed property while continuing to improve the unprefixed one.

The biggest win for web developers — should Rivoal’s proposal be implemented — is that it greatly simplifies the process of trying new features. It would give developers the tools they need to work around individual browser quirks with new features, but is less likely to lead to a situation like today, where WebKit-only CSS rules litter the web.

Another nice benefit of Rivoal’s approach is that it solves the Opera dilemma — that no one is using prefixes for less well-known browsers. “No browser, however new or obscure, would have the problem of being excluded,” writes Rivoal, “authors might not test in it, but if the browser does a good enough job of implementing the property, sites will render as intended.”

Obviously this proposal is just that, but there’s already an extensive dialog on The W3C’s www-style mailing list and it appears that most members are supportive, though some have expressed reservations and possible problems. Mozilla’s Henri Sivonen does a nice job of addressing many potential issues and shortcomings in a very long, thorough post to the mailing list.

It will likely be some time before any changes are made to the way vendor prefixes are handled, and of course none of this solves the problem that’s already on the web today. But, hopefully, with a few changes to the way prefixes work, the web can avoid the WebKit-only problem in the future.

Tags: ,
File Under: CSS, Web Standards
Apr
27
2012

Opera Forges Ahead With Plan to Support WebKit Prefixes

By

Even the mobile web is more than just WebKit. Photo: Ariel Zambelich/Wired.com

Opera software will make good on its plan to implement the -webkit- prefix in the Opera web browser. To give developers a taste of what that will entail the company has released an update for its mobile emulator with support for the -webkit- prefix.

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.

Tags: , ,
File Under: CSS
Apr
24
2012

HTML5 Offers ‘Scoped’ CSS for Precision Styling

By

HTML5′s controversial “scoped” style attribute is now supported in the latest Canary builds of Google’s Chrome web browser and Mozilla may eventually add support to Firefox as well.

HTML5 adds an attribute, scoped, to the style element which limits the scope of the styles contained within the tag. Google’s Alex Danilo has a good introduction to scoped over at HTML5Rocks. Essentially scoped allows you to nest styles within HTML and those styles will only apply to any child elements. The easiest way to understand scoped is to see it in action:

<html lang="en">
    <head>
        <style>
            p { color: white; }
        </style>
    </head>
    <body>
        <p>The text in this will be white</p>
        <div>
            <style scoped>
                p { color: red; }
            </style>
            <p>The text in this paragraph will be red</p>
        </div>
        <p>And we're back to white text</p>
    </body>
</html>

In this example the first style declaration applies to all the p tags on the page while the scoped style declaration applies only to the p tags within that scope (in this case all the p tags within our div tag). The scope rule has a higher specificity so it overrides the other rule and makes the middle text red.

It seems handy at first glance, but scoped can be a step backward if you overuse it. It’s akin to using inline styles, a long-frowned-upon practice that means mingling content and presentation. Indeed, scoped should be used sparingly; it will cause you pain if you just start throwing it around.

That said, there are some cases where scoped makes sense and makes developers’ lives easier. If you’re pulling in content from some outside source and displaying it on your page, styles and all, scoped can help you avoid style conflicts. Similarly if you’re building a widget designed to be embedded elsewhere scoped ensures your styles won’t affect the rest of the page.

Another use case that’s worth mentioning is within content management systems. Developer Arley McBlain recently covered the advantages of the scoped attribute for handling CMS content in some depth over at CSS Tricks. McBlain even has a demo WordPress site that uses scoped to style content on a per-post basis.

The big catch to using scoped right now is that it doesn’t work anywhere but Chrome 19+. Worse, because other browsers do understand the style element, they’ll apply your styles, but they’ll apply them globally. In other words, don’t use scoped without a polyfill like the JQuery Scoped CSS Plugin.

Also note that to test out Chrome’s scoped support you’ll need to be using Chrome 19 and then head to chrome://flags. Look for the “Enable <style scoped>” towards the end of the list and click “Enable.” Restart the browser and scoped should work.

Tags: , ,
File Under: CSS, Visual Design, Web Standards
Mar
21
2012

CSS Regions: Coming Soon to a Webpage Near You

By

CSS Regions on a Galaxy Tab (image from Adobe)

It’s been just over a year since Adobe first announced its CSS Regions proposal for flowing text around and into irregular shapes. Since then, as the CSS Regions proposal has worked its way through the W3C standardization process it’s been simplified somewhat and brought into line with other, similar proposals.

Adobe’s web platform blog recently posted an overview of what’s changed in the last year and where the CSS Regions proposal stands today.

The short — and disappointing — answer is that CSS Regions is still not ready for prime time. Browser support is limited and even where it exists the spec is still a moving target and will likely change before it’s finalized. In other words, it’s still too soon to use CSS Regions in production.

That said, if you’d like to experiment with CSS Regions, Chrome 17+, the latest Safari nightly builds and Internet Explorer 10 all support the current draft version.

The best way to understand what CSS Regions are and how they will (hopefully) one day change the way we lay out content on the web is to see them in action. Google Chrome developer Paul Irish demonstrated CSS Regions during a SXSW lightning talk earlier this month (note that if you’re using the YouTube HTML5 video player you’ll need to manually skip to the 1:50:00 mark or follow the link to YouTube):

As part of the standardization process the CSS Regions proposal now specifically refers to a set of rules to control how text flows across defined regions. The canonical example being the sort of multi-column text layout — complete with column-spanning images — such as you might find in a print magazine.

In addition to Regions there are two other related proposals to handle different layout situations. The CSS Exclusions proposal describes how to flow content around shapes (as in the example at the top of this post) or into shapes, such as text inside a pie chart. The third piece in the Regions layout puzzle is the CSS Fragmentation proposal which defines how content breaks across columns and other regions.

It’s worth noting that Regions are just one of several proper layout tools coming soon. There’s also the CSS Multi-column Layout Module (which is surprisingly well supported in browsers), the Flexible Box Layout Module, the Grid Layout proposal and the Paged Media proposal, which we’ve covered in depth before.

With the exception of the Multi-column Layout Module which works in Firefox 2+, Opera 11.1+, Safari 3.1+, Chrome 4+ and IE 10+, none of the proposals are ready for production use. And even Multi-column isn’t going to work in current versions of IE, so it’s best limited to personal sites and experiments. But as with all things new and shiny, it’s in this experimental stage that we’ll start to see what sort of exciting new possibilities these layout tools will inspire. Webmonkey is starting to catalog these early efforts, so if you’ve built something that uses CSS Regions be sure to let me know in the comments below.

Tags: ,
« OLDER POSTS