CSS and Presentation

The challenge of convincing web designers and developers that CSS, rather than presentational markup, is the better approach to developing for the web has long since been won. In this section of the survey, we tried to get an understanding of just how developers are using CSS to this end, and their underlying philosophies about presentation for the web.

Consistency across browsers

One of the ongoing questions in web development is the extent to which sites should “look the same in all browsers”. As with last year, we asked “Which of the following best describes your web design philosophy?” with three possible answers.

This years results are markedly different from last years. While a philosophy of “progressive enhancement”, long advocated by many standards based web designers and developers continues to be the most widely held philosophy, and remained the choice of around 60% of developers (60.5% up from 57.4% last survey), the percentage advocating that “pages should look as near to identical as possible across browsers” dropped noticeably, from around quarter in 2008 to 14% this time round. The more radical concept that “pages might look substantially different in different browsers, but provided they look acceptable in all browsers, consistency is of no great concern” climbed from 9.5% to surpass the concept that pages should look nearly identical, with 15.7% holding this view. The increasing diversity of devices with excellent web browsers may well hold the key to this change, and we’d expect to see the percentage of respondents who hold this last view climb in future surveys.

Which of the following best describes your web design philosophy?

2010
Answer Count %
Pages should look as near to identical as possible across browsers 197 14.05%
Consistency across browsers is important, but I use features supported in newer browsers provided they don’t cause problems for older browsers 848 60.49%
Pages might look substantially different in different browsers, but provided they look acceptable in all browsers, consistency is of no great concern 220 15.69%
2008
Answer Count %
Pages should look as near to identical as possible across browsers 304 24.64%
Consistency across browsers is important, but I use features supported in newer browsers provided they don’t cause problems for older browsers 708 57.37%
Pages might look substantially different in different browsers, but provided they look acceptable in all browsers, consistency is of no great concern 117 9.48%

Development strategies for multiple browsers

Developers need to continue ensuring their sites and applications work acceptably across a broad range of browsers, some, like IE6, many years old now, lacking in features introduced in newer browsers, and shackled with bugs long since fixed in newer versions. We asked respondents how they addressed this issue, with a particular focus on their strategy for ensuring their sites work well in Internet Explorer, the most idiosyncratic of the widely used browsers.

Results for this question were very similar to those for the last survey. Standards based development comes first for almost all developers, with most (77% both surveys) then working around problems with IE. Both years, around 10% claim to not bother working around problems in Internet Explorer, which may reflect a lack of concern for users of that browser, or the opinion that their sites will, if developed using web standards, work “well enough” in Internet Explorer.

Which of the following best describes your approach to developing for multiple browsers?

2010
Answer Count %
I only develop for IE 3 0.21%
I develop for IE first, and then make sure my pages work in other major browsers 39 2.78%
I develop to W3C standards, and then work around IE 1072 76.46%
I develop to W3C standards and expect browsers to support these 150 10.7%
2008
Answer Count %
I only develop for IE 3 0.24%
I develop for IE first, and then make sure my pages work in other major browsers 62 5.02%
I develop to W3C standards, and then work around IE 946 76.66%
I develop to W3C standards and expect browsers to support these 116 9.40%

CSS Specifics

The next set of questions in this section focussed more on the specifics of how respondents use the technology of CSS. We wanted to get a sense of what they were using CSS for, and which aspects of CSS they were using. We also wanted to get a sense of which more experimental aspects of CSS, such as CSS3, and some browser extensions to CSS, developers are using.

When asked what they use CSS for, results from this survey were almost identical to the previous, with around 90% of respondents saying they use CSS for fonts and text style, and even slightly more for page layout. As we commented in our last survey results

Together with responses to a number of the questions in the markup section, it’s clear that the practice of separating content and appearance using HTML and CSS is very well established now, at least among this sample of developers and designers.

Which of the following do you use CSS for?

2010
Answer Count %
Fonts and text style 1246 88.87%
Page layout 1252 89.3%
Print appearance 966 68.9%
2008
Answer Count %
Controlling fonts and text style 1112 90.11%
Controlling page layout 1115 90.36%
Controlling print appearance 851 68.96%

Next we looked more deeply into which CSS features respondents were using.

Selectors

As with the previous survey, 80% or more use HTML element, class and id selectors, with nearly 80% (78%) using descendent selectors. While class and id are still extensively used, the widespread use of descendent selectors probably reflects a decrease in the over-reliance on these selectors.

37% of respondents use child selectors, up significantly from 27%, but very similar numbers also use CSS3 structural selectors (like last-child), and attribute selectors.

Question 24: Which of these types of selector do you regularly use?

2010
Answer Count %
HTML element selectors such as p {} 1192 85.02%
Class selectors such as p.classname {} 1194 85.16%
ID selectors such as p#idname {} 1140 81.31%
Descendent selectors such as p a {} 1125 80.24%
Child selectors such as p > a {} 516 36.8%
attribute selectors such as a[href] 526 37.52%
structural selectors such as p:last-child 525 37.45%
2008
Answer Count %
HTML element selectors such as p {} 1027 83.23%
Class selectors such as p.classname {} 1057 85.66%
ID selectors such as p#idname {} 999 80.96%
Descendent selectors such as p a {} 961 77.88%
Child selectors such as p > a {} 337 27.31%
CSS3 and Experimental CSS

A little over a year before the current survey, we asked respondents about their use of CSS3 and experimental CSS properties. Back then, an overwhelming majority (68%) didn’t. A scant 13 months later, in early 2010, and nearly half of the respondents (45%) said they did. The increasing support for these features in Chrome, Firefox and Opera, in addition to Safari which has somewhat lead the way in this regard, coupled with a philosophy of “progressive enhancement” would seem to be driving this rather dramatic takeup of something still not supported by Internet Explorer.

Do you use any CSS3 or experimental CSS properties, such as CSS transitions, transforms, animations, shadows?

2010
Answer Count %
Yes 636 45.36%
No 616 43.94%
2008
Answer Count %
Yes 274 22.20%
No 843 68.31%

We followed up by asking “Which such properties do you use?”. Of those who answered that they use CSS3 and experimental CSS

  • 48% (up from 40%) use border-radius
  • Around 25% use text-shadows and box shadows, a similar number to those who replied “shadows” in last year’s survey.
  • Transitions (12%) and transforms (8%), come in with similar numbers to last year (both around 10%)
  • Use of opacity appears to have dropped off, from around 10%, to around 6%
  • About 12% (up markedly from 5% )use RGBa colors
  • Gradients (4%), animations (2%) and somewhat surprisingly multi-column text (.6%) are all still in their earliest stages of adoption, though support for animation is currently Webkit only, and gradients and multi-column text still only Webkit and Firefox.
2010
property Count %
text-shadow 166 26%
box-shadow 158 25%
border-radius 305 48%
gradient 24 4%
multi-column 4 .6%
rgba 74 12%
opacity 37 6%
transitions 86 14%
transforms 50 8%
animation 13 2%
Fonts

Web designers and developers have long been keen to expand the range of fonts available, and have typically resorted to image replacement, or flash based replacement techniques like SiFR, all of which are less than ideal solutions. The last 18 months or so have seen the widespread adoption of CSS font embedding technologies in Firefox, Webkit browsers and Opera. Internet Explorer has for many years supported font embedding, but its use has always been legally challenging, and frankly painful.

In late 2008, a very small percentage of respondents (around 4%) responded that they use the @font-face statement. This number has increased dramatically in the short period of time since, to nearly 23%. One reason is the increased support for @font-face (now well supported in all current browsers, other than Mobile Safari). Also, since the last survey a number of “fonts as a service” companies, like Kernest and Typekit (disclosure, John Allsopp is an advisor to Typekit), coupled with increasingly liberal licensing of fonts by some foundries allowing linking to fonts have helped drive this adoption. We suspect that this trend will continue, and font linking will be very widely adopted by respondents in the next 12 to 18 months.

Do you use linked fonts with the @font-face statement?

2010
Answer Count %
Yes 320 22.82%
No 932 66.48%
2008
Answer Count %
Yes 51 4.13%
No 1060 85.90%

When we last surveyed, there were essentially two font formats supported by browsers for font linking. Webkit supported linking to TrueType fonts only. Internet Explorer supported linking to EOT fonts (as it had for a decade or so but not TrueType). Developers wishing to use the same font in these two different browsers needed to link to two different font formats. When asked in late 2008 which formats they linked to, only .6% (or about 10% of those who used font linking) linked to EOT fonts, while 4% (almost 100%) linked to TrueType fonts. With the addition of @font-face support in Firefox and Opera, not only has the overall number of developers using font linking increased dramatically, but EOT (14% of all respondents) is approaching parity with TrueType (17%), while OpenType is the most widely supported format (17.7%). Even WOFF, a new, compressed format currently supported only in Firefox, and only since Firefox 3.6 even has support by over 7% of all respondents, nearly twice the percentage who used font linking at all in the previous survey.

More than CSS3, or HTML5, it would seem the buggest change in the state of web design and development in the last 12 months or so has been the significant takeoff in professional (as opposed to experimental) use of font linking. In late 2008, essentially not one of our respondents was using font linking except experimentally. 13 months later, perhaps as many as one fifth are.

Which type of fonts do you link to?

2010
Type Count %
Truetype 237 16.9%
EOT 193 13.77%
WOFF 99 7.06%
OpenType 248 17.69%
2008
Type Count %
Truetype 50 4.05%
EOT 7 0.57%
Other browser based graphics

In this section, we also asked respondents whether, and how they used SVG, and Canvas, two other widely supported (in browsers other than IE) standards or proposed standards for web graphics.

SVG

Three quarters of respondents replied in the negative to the question “Do you use SVG”, up a little from 2008. 13% replied “a little” (down from 14%), while a little under 1% replied “extensively” (last year it was 1.2%). So, it would seem SVG use is holding roughly steady. However, the increasing maturity of two libraries, SVGWeb from Google, which makes SVG work in Internet Explorer (which as of version 8 still doesn’t support SVG) and Raphaël, a library which provides a JavaScript interface for graphics that are then translated into VML on Internet Explorer, and SVG on other browsers, coupled with the news that IE9 will (and already does in early release) support SVG may see this change in the coming 12 months. If after IE natively supports SVG it continues to show this level of support, one wonders whether we’ll continue to see it remain a very valuable, but ultimately niche solution.

Do you use SVG?

2010
Answer Count %
No 1057 75.39%
A little 180 12.84%
Extensively 13 0.93%
2008
Answer Count %
No 923 74.80%
A little 172 13.94%
Extensively 15 1.22%

SVG Libraries

This survey we also asked respondents who use SVG which if any libraries they use. A significant proportion of the respondents who use SVG use one or more libraries, with Raphaël currently the most popular, and Google’s SVGWeb showing about half this level of popularity. The difference may be instructive. SVGWeb enables SVG markup to be used across all modern browsers. Raphael lets JavaScript developers create SVG based graphics programmatically using its own graphics API, without the need to directly manipulate the SVG DOM. With SVGWeb, developers write SVG. With Raphael, they use JavaScript to create the graphics. It may be that for many purposes, developers prefer the JavaScript approach of Raphael.

Which, if any libraries do you use for cross browser SVG support?

2010
Answer Count %
Raphael 74 5.28%
SVG Web 37 2.64%
Other 50 3.57%
Canvas

The canvas element, a much talked about part of the proposed HTML5 standard, currently supported in shipping versions of all major browsers other than Internet Explorer, is as yet still less widely adopted as SVG, but unlike SVG did see an increase in adoption between the two surveys. While 75% of respondents still don’t use the canvas element at all (down from 80%), around 14% (up from 9%) do a little, and less than 1% extensively.

With Adobe having announced Flash (and Illustrator) to canvas export in CS5, opening up the canvas element to those other than proficient JavaScript developers, the canvas element may see a considerable uptake in support. While popular applications like Illustrator having SVG export options for some time don’t seem to have particularly increased the adoption of SVG, this may be because for most web based uses, a widely supported, standards based bitmap format may be at least an acceptable graphics solution. For web based animations, at present only Flash and Silverlight offer a widely supported solution, and many developers may prefer the native canvas format to a plug-in based solution. While IE9 has yet to announce canvas support, 3rd party leaks suggest that this support will be forthcoming, and such support may well be a key driver to developer adoption. Canvas has certainly seen a lot of hype in the last 12 months or so. The next 12 months may be crucial to its widespread adoption.

Question 31: Do you use the Canvas element?

2010
Answer Count %
No 1045 74.54%
A little 193 13.77%
Extensively 20 1.43%
2008
Answer Count %
No 989 80.15%
A little 111 9.00%
Extensively 9 0.73%
The non desktop web

For a decade or more, the promise of the web on devices other than desktop and laptop computers remained illusory. The release of the iPhone, and in its wake, a new generation of mobile devices sporting first class web experiences, has made this promise a reality.

But despite the iPhone being available for around 18 months when our first survey was conducted, only 25% of respondents said they “optimize[d] [their] sites for devices other than laptops/PCs”. In this survey, that is up to around a third (32.67%), but this is still much less than one might expect from this cohort of respondents.

Do you optimize your sites for devices other than laptops/PCs?

2010
Answer Count %
No 803 57.28%
Yes 458 32.67%
2008
Answer Count %
Yes 310 25.12%
No 813 65.88%

So, which devices do they optimize for? We asked developers to name the devices they specifically targeted. Not surprisingly, the iPhone dominates here, and in numerical terms, nearly twice as many respondents this survey than last report optimizing for it. But as a percentage of those who optimize for devices other than laptops/desktops, the increase is not nearly so marked – up from 44% of all those who optimize for non pc devices, to 51%. Android, available on a single handset in late 2008, saw a dramatic rise, to 10% of respondents who optimize for non desktop devices. Blackberry saw its mindshare remain at similar, or slightly higher levels, while Opera Mobile and the Wii both saw something of a decline when it comes to developers focussing on these devices. Palm’s Pre, launched between the two surveys, saw a handful of developers pay it attention, but certainly has made far less of an inroad than some may have expected, or hoped, given the enthusiasm with which many greeted the device and its new webOS .

What other devices do you optimize your websites for?

2010
Device Count %
iphone/mobile safari 234 51%
blackberry 23 5%
android 47 10%
opera mobile 6 1.3%
Palm Pre 4 1.3%
wii 3 .7%
2008
Device Count %
iphone/mobile safari 136 44%
blackberry 13 4%
android 3 1%
opera mobile 5 1.6%
wii 5 1.6%

For the first time this survey we asked respondents what techniques they used to target specific devices. Each of the three main approaches were used in similar numbers by respondents (they could choose more than one technique as a response). Long recommended against, “client side sniffing” continues to be popular, while media queries, a relatively recent innovation, and well supported in contemporary browsers, particularly those on non pc devices, were surprisingly popular.

Question 34: If you optimize sites for different devices, what technique or techniques do you use?

2010
Client Side browser sniffing 204 14.55%
Server Side browser sniffing 213 15.19%
Media Queries 191 13.62%

There have been considerable changes in the area of web site and application presentation between the two surveys. Most notably, CSS3 is being increasingly widely used, while font linking has taken off like few other web development technologies before it, particularly strongly given it had essentially lain dormant for a decade or more since its introduction in “version 4 browsers”. SVG and the HTML5 canvas element at present don’t show the sort of strong growth we’ve seen in some other presentation technologies, but this may well change for one or both of these technologies in the coming 12 months.

Next

Next we’ll look at how respondents are using JavaScript, Ajax and the DOM.