Archive for the ‘CSS’ Category

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: , ,
File Under: CSS, Web Standards
Feb
9
2012

WebKit Isn’t Breaking the Web. You Are

By

WebKit may seem like the only game in town, but it's not. Photo: Ariel Zambelich/Wired.com

It sounds like something from a galaxy far, far away, but in truth it was not that long ago that the web was littered with sites that proudly proclaimed “works best in Internet Explorer.” Thankfully those days are over. IE6 no longer dominates the web.

But, while IE6 may be a thing of the past, the root problem — websites that work in one and only one web browser — sadly, remains.

This time the culprit is WebKit, the rendering engine that powers the browsers on the iPhone, iPad and Android phones. But what’s different about this round of monoculture is that, unlike IE 6, the WebKit developers haven’t done anything wrong. It’s web developers that have created the WebKit-only web.

Instead of writing code that will work in any browser, which might mean adding an extra three lines of code to their CSS rules, some of even the largest sites on the web are coding exclusively for WebKit.

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.

The 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, says, “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.”

Vendor prefixes like -webkit and -moz were designed to help web developers by allowing browser makers to implement CSS features before the official standard was published. Prefixes were intended to help speed up the process of adding new features to the web and, used properly, they have worked. Unfortunately they’ve also been widely abused.

WebKit is currently the dominant mobile browser in the mind of most web developers (that Opera is actually the single most widely used mobile browser). But even the perceived dominance of WebKit is not the real problem. The problem is — just as it was last time — that web developers are developing exclusively for WebKit.

To be clear, Firefox, IE and Opera also support these features. In most cases, the -webkit properties being used have -moz, -ms and -o prefix equivalents for use in the respective browsers. Popular CSS 3 features like border-radius, transforms, gradients and animations work in all modern browsers. Developers simply need to add those three additional lines of code to make their websites compatible with Firefox, IE and Opera. But they aren’t doing that.

That the problem lies with web developers, not the browsers, led Glazman, to put out a call for action, asking web developers to “stop designing web sites for WebKit only, in particular when adding support for other browsers is only a matter of adding a few extra prefixed CSS properties.”

Neither Glazman, nor anyone else is suggesting that Apple and Google should stop innovating or stop implementing new features as fast as they can. As Tantek Çelik, a Mozilla representative in the CSS WG, says in the minutes of Monday’s meeting, “I think it’s great that Apple wants to innovate as fast as they can…. I don’t want Apple to slow down in innovation and implementing new things. That helps the Web grow and innovate.”

At the same time both Apple and Google have set some bad examples by building a number of WebKit-only demos that might be part of what lead some developers to conclude that only WebKit supports such features. That has also spilled over into the world of tutorials where even sometimes even standards advocates showcase -webkit in their sample code while ignoring -moz-, -ms- and -o-*.

What makes the current -webkit-only epidemic all the more depressing is how easy it is to solve — just use prefixes they way they were intended. Thanks to modern toolkits you don’t even need to write any extra code. Preprocessors like SASS and LESS make it easy to output five lines of prefixed code with a single mixin. Not a fan or SASS or LESS? No problem, just use cssprefixer, which parses your CSS and adds any prefixes you need before you publish it to the web (there’s also a client-side auto-prefixing solution if you prefer).

That’s fine for your website, but what about all the rest of those top 30,000 sites you don’t control? Well, you could email the developers, let them know that their site isn’t working in the most popular mobile web browser; let them know that you can’t use their service. If you’re a programmer or web developer you can help out with Mozilla developer Christian Hellman’s effort to Pre-fix the web. Pre-fix the web 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.

We at Webmonkey hope it’s obvious that building WebKit-only sites is a waste of time. 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 says the CSS WG minutes, “there’s no advantage to the Web to have someone write a platform-specific website.” There’s also no real advantage for the developer, especially when an automated prefixer can do all the work for you. If you want your site to embrace the web, take the time to learn the craft and embrace all of the web. Be good at what you do and do it right.

Tags: , ,
File Under: CSS, Visual Design, Web Standards
Feb
8
2012

Responsive Design Tricks: Fluid Typography With CSS 3

By

Photo: Ariel Zambelich/Wired.com

Building responsive websites means that your design has to adapt to different screen sizes. That there is no such thing as “pixel perfect” has long been a maxim of good web design, but nowhere is this more true than when you start working with percentage widths, em-based type and other flexible techniques of responsive design. While fluid grids, adaptive images and other tools help, sometimes even basic things like the flow of type can look wrong without a little extra help.

One common problem when designing for multiple devices is handling the changes that happen when the user rotates the screen. It’s frustrating to see your elegant portrait-oriented designs fall apart as the device moves to landscape mode (or vice versa). Frequently the problem is that images, videos and other embedded content in your page is sized in relation to the pixel width of the viewport, but the type is not. That means that the type fails to adapt to layout changes, leaving ugly gaps, whitespace or hard-to-read, overly long lines.

There are a number of ways to solve this problem, but one of the simplest and easiest is to use fluid typography in addition to your fluid grid. BBC developer Mark Hurrell wrote up an excellent tutorial some time ago that shows how, by specifying font sizes in rems, you can “adjust every font-size on the page by using media-queries to change the font-size set on the BODY or HTML element according to viewport width.”

To find the right size type for various screen widths, Hurrell calculates a resolution-independent font scale based on target widths. That is then applied using a series of media queries and the new CSS 3 unit rem. The rem unit means ems relative to the root (the HTML) element. That means your type gets proportionally larger overall, rather than in relation to its parent element as would happen with a simple em. As Hurrell notes, support is pretty much universal on tablets and phones (browsers that don’t support it will fall back to px sizing, so all is not lost).

In the end what you get using rems and media queries is fluid typography that scales just like a fluid grid. That means that when the device rotates the type resizes to fit the new screen dimensions. For more details on how to make it work on your site be sure to check out the Responsive News blog post, which also has a few links to websites already using this trick.

Tags: ,
File Under: CSS, Frameworks, Mobile, Visual Design
Jan
26
2012

Twitter Adds Responsive Design Tools to Bootstrap 2.0

By

Twitter is gearing up for the release of Bootstrap 2.0, the second major version of its popular open source front-end toolkit for web developers.

Bootstrap 2.0 will arrive Jan. 31, but if you’d like to take it for a spin today you can help test the pre-release build. Just head on over to GitHub and checkout the branch, 2.0-wip.

Bootstrap is designed to help you get your website up and running as fast as possible. Somewhere between a CSS framework and a “theme,” Bootstrap offers an HTML, CSS and JavaScript base for your designs, including built-in forms, buttons, tables, grids and navigation elements. Among Bootstrap’s more impressive tricks is the grid layout tool, which is based on the 960 grid system, with support for advanced features like nested and offset columns.

Bootstrap 2.0 will solve one of the bigger complaints about Bootstrap 1.0 — it was not responsive. To embrace a more responsive approach for mobile devices, Bootstrap is moving to a flexible 12-column grid system. The 2.0 release also includes some updated progress bars and customizable gallery thumbnails, but perhaps the best news is that, at just 10kb (gzipped), Bootstrap 2.0 remains an impressively lightweight framework.

While Bootstrap offers good browser support, with all the modern options covered you should be aware that it won’t work with Internet Explorer 6. To see some real world examples of what you can do with Bootstrap, head on over to the unofficial showcase, Built with Bootstrap on Tumblr.

Photo by Mike Love/flickr/CC.

Tags: ,
File Under: CSS, HTML, HTML5
Jan
25
2012

‘HTML5 Please’ Helps You Decide Which Parts of HTML5 and CSS 3 to Use

By

Keeping track of the ever-evolving HTML5 and CSS 3 support in today’s web browsers can be an overwhelming task. Sure you can use CSS animations to create some whiz-bang effects, but should you? Which browsers support it? What should you do about older browsers?

The first question can be answered by When Can I Use, which tracks browser support for HTML5 and CSS 3. You can then add tools like Modernizer to detect whether or not a feature is supported, so that you can gracefully degrade or provide an alternate solution for browsers that don’t support the features you’re using. But just what are those alternate solutions and polyfills? That’s what the new (somewhat poorly named) HTML5 Please site is designed to help with.

HTML5 Please offers a list of HTML5 elements and CSS 3 rules with an overview of browser support and any polyfills for each element listed (CSS 3 is the much more heavily documented of the two, which is why the HTML5 emphasis in the name is perhaps not the best choice). The creators of the site then go a step further and offer recommendations, “so you can decide if and how to put each of these features to use.”

The goal is to help you “use the new and shiny responsibly.”

HTML5 Please was created by Paul Irish, head of Google Chrome developer relations, Divya Manian, Web Opener for Opera Software, (along with many others) who point out that the recommendations offered on the site “represent the collective knowledge of developers who have been deep in the HTML5 trenches.”

The recommendations for HTML5 and CSS 3 features are divided into three groups — “use”, “use with caution” and “avoid”. The result is a site that makes it easy to figure out which new elements are safe to use (with polyfills) and which are still probably too new for mainstream work. If the misleading name bothers you, there’s also Browser Support, which offers similar data.

If you’d like to contribute to the project, head over to the GitHub repo.

Tags: ,
File Under: CSS
Jan
19
2012

CSS1K Showcases How Developers Can Do More With Less

By

CSS1K: light on the file size, heavy on variety

When the web standards movement first began to take off years ago one of its primary advocates, Dave Shea, launched CSS Zen Garden to showcase what designers could do using only web standards. CSS Zen Garden proved a huge hit, drawing hundreds of contributions from web developers around the world.

The web has changed considerably since the heyday of CSS Zen Garden. Today we can do just about anything using web standards like HTML and CSS, but now there’s a new problem — websites are getting fatter, as much as 25 percent fatter in the last year alone. Much of that added weight comes from JavaScript, but CSS shares some of the blame. According to HTTP Archive, the top 1,000 sites on the web load an average 30KB worth of CSS.

Inspired by CSS Zen Garden and driven by a desire to showcase what can be done with a mere 1KB of CSS, Jacob Rask, a web developer at Opera Software, created CSS1K about six months ago. Since then the site has showcased 68 different designs, all with stylesheets under 1KB.

The site is modeled on CSS Zen Garden, with a fixed set of HTML tags and content. Using that HTML base designers can then bend the basic frame to whatever look they’ve come up with — provided the total minified size of the CSS file is only 1KB.

Call it an effort in minimalism if you like, or simply think of it as a design constraint; either way designs submitted to CSS1K demonstrate just how much is possible with very little CSS. While no one is suggesting every website needs to be so constrained, playing with CSS1K is a nice reminder that you don’t always need huge stylesheets to create a nice-looking website.

If you’d like to participate in the CSS1K fun just fork CSS1K at GitHub and send your submission as a pull request. There is essentially only one rule — you can’t use data URIs, @font-face or @import statements to skirt the 1K CSS filesize limit. Note, however, that your 1K CSS file can be minified and any browser prefixes you need don’t count toward the total (in fact, you submit your code unprefixed and CSS1K adds the prefixes for you). For the full details and file requirements, head over to CSS1K.

Tags:
File Under: CSS
Jan
17
2012

Visually Stunning Redesign Showcases the 3-D Power of CSS

By

Steven Wittens' Acko.net features an impressive and unique 3-D header.

It’s one thing to hear about the powerful new 3-D tools coming to CSS, but it’s a very different thing to actually see them used creatively in the wild. Developer Steven Wittens recently did just that when he redesigned his Acko.net website. Wittens turned to the 3-D features in CSS 3 — with a little JavaScript help — to create a visually stunning 3-D page header.

To see the 3-D in action you’ll need to be using a WebKit browser (Safari or Chrome), though the site nicely degrades to a still very readable state for Firefox and other browsers that don’t yet support the 3-D rules coming to CSS. To get the full 3-D effect be sure to scroll down the page.

Wittens has a blog post detailing exactly how he pulled off the effects and he’s even built a 3-D editor you can play around with. Of the initial inspiration Wittens writes:

This idea started with an accidental discovery: if you put a CSS perspective on a scrollable <DIV>, then 3-D elements inside that <DIV> will retain their perspective while you scroll. This results in smooth, native parallax effects, and makes objects jump out of the page, particularly when using an analog input device with inertial scrolling.

…

This raises the obvious question: how far can you take it? Of course, this only works on WebKit browsers, who currently have the only CSS 3-D implementation out of beta, so it’s not a viable strategy by itself yet. IE10 and Firefox will be the next browsers to offer it.

To work around some of CSS limitations in the browsers, Wittens turned to Three.js, a JavaScript 3-D engine written by Ricardo Cabello, better known as Mr. Doob. For those interested in the code behind some of the transformation happening on Acko.net, Wittens has promised to release it via GitHub in the near future.

Tags:
File Under: CSS, HTML5, JavaScript, Mobile, UI/UX, Visual Design, Web Basics
Jan
12
2012

Building a Responsive, Future-Friendly Web for Everyone

By

A handful of the many screens your site needs to handle. Photo: Ariel Zambelich/Wired.com

This week’s Consumer Electronics Show in Las Vegas has seen the arrival of dozens of new devices from tablets to televisions. Some of these newfangled gadgets will soon be in the hands of consumers who will use them to access your website. Will your site work? Or will it end up mangled by a subpar web browser, odd screen size or slow network connection?

No one wants to rewrite their website every time a new device or browser hits the web. That’s why approaches like responsive design, and the even broader efforts of the future-friendly group, are trying to develop tools and techniques for building adaptable websites. That way, when a dozen new tablets suddenly appear on the scene, you can relax knowing your site will look and perform as intended, no matter which devices your audience is using.

Even if you aren’t a gadget lover, CES should help drive home the fundamental truth of today’s web — devices, they are a comin’. Webmonkey has compiled helpful resources for creating responsive design in the past, but the field is new and evolving rapidly so here’s an updated list of links to help you get started responsive, future-friendly sites that serve your audience’s needs whether they’re browsing with a tiny phone, a huge television or the web-enabled toaster of tomorrow.

Basics:

  • Use @media to scale your layout for any screen, but remember that this alone isn’t really responsive design.
  • Use liquid layouts that can accommodate any screen size. Don’t simply design one look for 4-inch screens, one for 7-inch, one for 10-inch and one for desktop. Keep it liquid, otherwise what happens when the 11.4-inch screen suddenly becomes popular?
  • Roll your own grids based on the specifics of your site’s content. Canned grid systems will rarely fit the bill. The problem with canned grids is that they don’t fit your unique content. Create layouts from the content out, rather than the canvas (or grid) in.
  • Start small. Start with the smallest size screen and work your way up, adding @media rules to float elements into the larger windows of tablet and desktop browsers. Start with a narrow, single-column layout to handle mobile browsers and then scale up from there rather than the other way around. Starting with the smallest screen and working your way up means it’s the desktop browsers that need to handle @media, make sure older browsers work by using polyfills like Respond.
  • Forget Photoshop, build your comps in the browser. It’s virtually impossible to mock up liquid layouts in Photoshop, start in the browser instead.
  • Scale images using img { max-width: 100%; }. For very large images, consider using something like Responsive Images to offer the very smallest screens smaller image downloads and then use JavaScript to swap in larger images for larger screens. Similar techniques can be used to scale video.
  • Forget about perfect. If you haven’t already, abandon the notion of pixel perfect designs across devices. An iPad isn’t a laptop isn’t a television. Build the perfect site for each.

Further Reading:

  • Future Friendly — An overview of how some of the smartest people in web design are thinking about the ever-broadening reach of the web: “We can’t be all things on all devices. To manage in a world of ever-increasing device complexity, we need to focus on what matters most to our customers and businesses. Not by building lowest common-denominator solutions but by creating meaningful content and services. People are also increasingly tired of excessive noise and finding ways to simplify things for themselves. Focus your service before your customers and increasing diversity do it for you.”
  • Building a Future-Friendly Web — Brad Frost’s excellent advice: “Think of your core content as a fluid thing that gets poured into a huge number of containers.”
  • There is no mobile web — “There is no mobile web, nor desktop web. It is just the web. Start with the content and meet people halfway.”
  • Responsive by default — Andy Hume on why the web has always been responsive, but was temporarily sidetracked by the fad of fixed-width sites.
  • COPE: Create Once, Publish Everywhere — NPR’s Director of Application Development, Daniel Jacobson, walks through how NPR separates content from display and uses a single data source for all its apps, sites, APIs and feeds. A great example of what Frost talks about regarding content as a fluid thing.
  • Support Versus Optimization — It can seem daunting to support dozens of mobile browsers, but if you aren’t up to the challenge of a few mobile browsers now what are you going to do when you need to support car dashboards, refrigerators, televisions and toasters, all with dozens of varying browsers?
  • The Coming Zombie Apocalypse — Not satisfied thinking a few years ahead? Scott Jenson explores further into the future and tries to imagine what the web might look like when devices all but invisible.

Techniques:

Tags: , ,
File Under: CSS
Dec
16
2011

Dabblet: An Interactive CSS ‘Playground’ in Your Browser

By

Dabblet: Live CSS editing (even better with monkeys)

CSS guru Lea Verou has unveiled a new project, Dabblet, which she describes as “an interactive CSS playground.”

Inspired by online editors like JSFiddle, Dabblet is an interactive testing app for CSS — write some code and instantly see the results in the same window. The site works in most modern web browsers, including Chrome, Firefox and Safari (Opera support is in the works).

Unlike JSFiddle where the emphasis is clearly on JavaScript, Verou’s app is designed from the ground up to focus on CSS. Among Dabblet’s nice features are automatic vendor prefixing for CSS 3 properties (via Verou’s -prefix-free library). The prefix-free script means you can just write, for example, border-radius instead of -moz-border-radius, -webkit-border-radius, -o-border-radius and so on.

Perhaps the most useful feature though is that Dabblet can save all of your work as GitHub gists. Not only those that making sharing your work with others easier it also ensure that even if Dabblet doesn’t last forever you’ll still have your data on GitHub.

The Dabblet source code is available on GitHub if you’d like to contribute or fork it for you own project (it’s licensed under the NPOSL 3.0 which carries a non-profit restriction).

Dabblet is simple to use, just dive in and start writing some code. However, not all of the advanced features are immediately obvious so if you’d like to see a kind of guide to Dabblet, head over to Verou’s blog where she has a basic screencast that shows Dabblet in action.

Tags:
« OLDER POSTS