All posts tagged ‘CSS’

File Under: CSS, Web Standards

New Proposal Could End the CSS Prefix Madness

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.

File Under: CSS, Web Standards

Opera Forges Ahead With Plan to Support WebKit Prefixes

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.

File Under: CSS

HTML5 Offers ‘Scoped’ CSS for Precision Styling

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.

CSS Regions: Coming Soon to a Webpage Near You

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.

File Under: CSS, Mobile

The iPhone Monoculture Is in Your Mind

Photo: Ariel Zambelich/Wired.com

In the recent kerfuffle over the prevalence of the -webkit CSS prefix and the lack of corresponding prefixes for other browsers, we told you that the problem was with developers, not WebKit browsers. Instead of writing code that will work in any browser many developers are coding exclusively for WebKit and that’s a problem.

But mobile expert Peter-Paul Koch, better known in the web developer community as just PPK, argues that the real problem is not WebKit, nor is it even web developers’ fascination with WebKit. The real problem is the developer-created monoculture of the iPhone.

According to Koch, “web developers don’t care about WebKit…. They care about the iPhone.”

The interesting thing about Koch’s argument is that he doesn’t claim there is actually a monoculture of the iPhone on the web. In fact, he cites some of Mozilla’s web crawler stats which seem to say just the opposite. Instead Koch believes the problem is in our heads, so to speak.

“What we have here is an iPhone monoculture; not in the stats, but in web developers’ minds,” writes Koch. “This is the fundamental problem we must address.”

The cure, says Koch, is to diversify tutorials and examples. “Start talking about testing in mobile non-WebKit browsers (i.e., Opera),” he writes. “Start talking about other platforms besides iPhone (and Android). Start talking about mobile diversity, instead of showing the iPhone over and over and over again.” What do you do if the only phone you have to test on is the iPhone? Well, there are emulators available for most phones, including Opera’s very powerful mobile emulator which can simulate all kinds of phones and connections. And don’t forget that Opera Mini is available for the iPhone if you’d like to at least test your site in something other than Mobile Safari.