All posts tagged ‘CSS’

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: ,
File Under: CSS, Mobile
Feb
21
2012

The iPhone Monoculture Is in Your Mind

By

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.

Tags: , ,
File Under: CSS, Web Standards
Feb
10
2012

Web Developers Sound Off on WebKit Prefixes

By

Photo: Ariel Zambelich/Wired.com

Yesterday we told you about a disturbance in the web standards force, a supposed rash of websites that work in one and only one web browser. Instead of writing code that will work in any browser many developers are coding exclusively for WebKit, the engine that powers Safari, Chrome, iOS and Android web browsers.

The problem is bad enough that on Monday at the CSS Working Group meeting, Microsoft, Mozilla and Opera announced that each are planning to add support for some -webkit prefixed CSS properties. In other words, because web developers are using only the -webkit prefix, other browsers must either add support for -webkit or risk being seen as less capable browsers even when they aren’t.

We aren’t the only ones who think that spells disaster not just for web standards but for the long-term viability of the open web. In fact the response from the web community has all but drowned out everything else in our RSS and Twitter feeds.

Here’s our round-up of what’s being proposed, what it might mean for the web and how we might go about solving the problem:

First and foremost read the minutes from the CSS Work Group meeting, which is where all of this started. The legend for the names is at the top of the page, though you’ll need to scroll about half way down to get to the actual meat of the discussion.

The second must-read post on vendor prefixes comes from CSS Working Group Co-Chair Daniel Glazman who calls on other browser makers to not implement the -webkit prefix and asks developers to make the extra effort to build cross-browser apps. Glazman has since followed up that piece with two more, one clarifying the original post and one defending the CSS Working Group against those who argue that the reason prefixes exist is because the standards process is too slow. If you believe that the CSS spec moves to slowly, this post is well worth a read (spoiler alert: it’s typically browser makers arguing, not the standards process, that creates the hold up on new features).

Remy Sharp of HTML5Doctor fame, weighs in with a series of rough ideas, neatly summarizing the issue and looking at it from both sides. In the end Sharp seems to conclude that just about everyone is to blame, from the browsers to the working group to developers.

Rachel Andrew of the web standards project generally agrees with Glazman writing, “once again we run the risk of having sites built only for one platform, and [will] find it very hard to get that platform to go away if things move on.”

The ever-humorous Bruce Lawson, who works as a web standards evangelist at Opera Software, writes: “Personally — PERSONALLY — I’m pretty depressed about all this. I’ve spent 10 years — pretty much since IE6 came out — evangelizing cross-browser, accessible, standards-based sites. As a development community we chased the Shiny and we caused IE6 to linger around like a vindaloo fart in a windowless loo. And now we’re doing the same again.”

Over at Quirksblog mobile expert Peter-Paul Koch argues that vendor prefixes are just plain wrong: “Vendor prefixes are the most developer-hostile solution imaginable. The vendor prefix idea was flawed from the start by putting the full brunt of namespace management on web developers.” He goes on to propose an interesting idea of vendor-neutral prefixes like -alpha and -beta for experimental features.

Aaron Gustafson, a member of the Web Standards Project, has started a petition to ask Mozilla, Microsoft and Opera to not implement -webkit. Gustafson also has a one-line bash script you can use to search your code for any instances of the -webkit prefix so you can double check to make sure you’re supporting other browsers as well.

Mozilla developer Christian Heilman believes that “this mess has partly been created by developers, the least we can do is help fix it.” To that end Heilmann’s Pre-fix the web project is looking for developers willing to seek out projects on Github that only work in Webkit and then fork the project, adding the missing prefixes to the CSS, extending JS code to do proper feature detection and then sending a pull request. In other words, literally fixing the web.

JavaScript developer Peter van der Zee has some other possible solutions: “Either we strongly limit the life span or availability of the prefix by making them only available in beta versions of a browser. Or we force other vendors to pick up on the slack by giving them a certain time to come up with their own implementation of a certain feature, or forfeit that possibility after a certain amount of time.”

Finally, if you read through the CSS WG notes you’ll notice that Tantek Çelik cites developer Lea Verou as an example of web developers who use just the -webkit prefix. In fact that’s completely untrue and Çelik has since corrected his statement. Verou has long advocated using all prefixes and even created prefixfree to help automate the process.

Tags: , ,
« OLDER POSTS