CSS3

An interesting implementation has recently made its way into the latest Webkit nightlies – a detailed method of styling scrollbars using a combination of new pseudo-elements and pseudo-classes.

Example

Although the new syntax can seem complicated at first, Webkits implementation gives authors the ability to completely alter the look and feel of scrollbars of overflow sections, listboxes, dropdown menus & textareas, and when used in conjunction with border-image and multiple backgrounds, the results can look beautiful.

Whitepaper gives more details on the implementation.

Believe it or not there still a lot of discussion around CSS 3. The concerns among designers/developers vary widely and we’ve found that our visitors use CSS3.info in many different ways.

1. General questions about your CSS 3,
2. Research for future-proofing your projects,
3. Browser support issues and updates,
4. Tutorials and how to’s on CSS 3 features,
5. Goings on in the CSS world

So there’s quite a range of information that we can get into and provide, but we would like some feedback from our readers so that we can continue to make the site a helpful resource.

If you’ve done extensive work with CSS3, feel free to let us know via the contact form and perhaps you can provide us with a tutorial or review that we can feature on the site!

Leave us a reply in the comments below and let us know what types of information you’d like to see us providing this year.

Six Revisions put six questions to the estimable Eric Meyer on the subject of CSS3, and we get some nice link love.

Also (and I’m slightly late with this one) John Resig, creator of the jQuery library, runs an approving eye over the Advanced Layout Module. Webmonkey provide further context. We looked at the module back in 2006 (part one, part two), and my tongue-in-cheek prediction of a ten year wait to use it is now down to only eight years…

Opera have announced the first Alpha release of the next version of their browser. Codename Peregrine features version 2.2 of their Presto rendering engine, which boasts 100% Acid 3 compliance, a 30% speed boost on certain sites, and a number of new features for web developers.

As CSS enthusiasts it’s the latter we’re interested in, of course, and the notable CSS3 implementations are:

• Web fonts (OTF, TTF & SVG)
• HSLA & RGBA color values

There’s an overview of the new features on dev.opera.com.

For those of you not on the www-style mailing list, you may not be aware that Dean Jackson announced today that Apple have published updated proposals for Transitions, Animations and Transforms. This news comes after the recent decision by the CSSWG at their October F2F meeting that it is very likely that the CSSWG will accept to work on them [Apple's proposals].

Full details of what’s been changed in these updated proposals can be found in Deans email, however, the most significant changes are splitting 2D and 3D transforms into separate documents and adding a list of properties that can be animated (and how to interpolate different property types)

It’s worth noting that these documents are only proposals, are likely to change, and haven’t formally been accepted by the W3C.

There’s been an apparent need (voiced by the web community) for CSS-based Constants ever since the conception of CSS (even though there are many established server-side preprocessors in existance). From reading blogs and the like, people are either very much in favour or very much against the idea, but the feature’s mixed reception hasn’t stopped members of the CSSWG exploring and discussing the idea further, to the point where we now have two fairly detailed proposals from members of the Working Group. The aim of this post is to explore and then summarise the current state of both proposals (from an authors not a vendors point of view), comparing features of both.

Back in March this year, Dave Hyatt and Daniel Glazman combined forces and presented the first formal proposal for Variables to the Working Group, and (based on this spec) Hyatt subsequently implemented the module into Webkit nightlies; the implementation was distributed for around 5 months, but was later removed due to concerns regarding feature adoption by authors before the spec had any time to mature. In August this year, fantasai submitted a counter-proposal which detailed plans for a parse-time syntax for Constants (which are lost after the variables are parsed and therefore not mutable), compared to Hyatt’s/Glazman’s proposal which allowed for scriptable Variables.

Types of Constants

Fantasai’s proposal features three types of named Constants, ‘values’, ‘style-sets’ and ‘selectors’; a value constant represents a property value, a style-set constant represents one or more property declarations and a selector constant represents a selector. Each are declared using an @define rule and as fantasai explains, the syntax of an @define rule is the @define at-keyword, followed by either the values keyword (for declaring value constants) or the style-sets keyword (for declaring style-set constants) or the selectors keyword (for declaring selector constants), followed by a block. Examples (ripped straight from her proposal :)) showing the syntax for each of the three Constants are below:-

Values

@define values { textColor: black; bgColor: white; accentColor: silver; accentBorder: double silver 5px; }

Style-sets

define style-sets { noteBox { border-style: solid; padding: 1em; border-radius: 1em; } quoteBox { margin: 1em; } }

A feature of fantasai’s proposal is that constants are re-usable, so you can include ‘style-set templates’ which can be applied to multiple selector declarations, using different value constant values.

Selectors

Note that any selectors used in such a variable aren’t allowed to be grouped (using the comma-seperated grouping syntax), since we will have the ability to group selector variables anyway. Selector constants would be useful for repeatedly selecting child/grandchild etc elements deep within a complex DOM tree; consider this:-

@define selectors { deeplynestedelement: body.home > div#main.container ~ ul#navigation > li a[href="http"] span#child > span#imrunningoutofnames;}
deeplynestedelement u, deeplynested b{ color:red; }

And with the addition of a possible :match() pseudo class in Selectors Level 4, you could do something like this to make the above statement even more organised:-

deeplynestedelement:matches(u,b){ color:red; }

Instead Hyatt’s/Glazman’s proposal simply utilises a new @variables rule in which any type of variable (presumably) can be used, without the need for type keywords – their proposal isn’t actually clear on whether different types of variables can be parsed (or whether this proposal simply targets value constants), however, after looking at several test cases, the implementation seems like it was capable of at least parsing ‘style-sets’ constants too.

@variables { CorporateLogoBGColor: #fe8d12; }

div.logoContainer { background-color: var(CorporateLogoBGColor); }

Scoping

Two fairly major differences between the two proposals are their scoping behaviour. In fantasai’s proposal, by default, the scope of a named constant does not ordinarily cross @import boundaries; this essentially means that the use of variables declared in one @import are restricted to that particular stylesheet, unlike Hyatt’s/Glazman’s proposal where, by default, constants cross @import boundaries. However, using fantasai’s proposal, authors do have complete control over the scope by using one of three new keywords (which is placed between the @import keyword and the stylesheet URI), push, pull and sync; pull allows constants declared within the imported stylesheet to be used in the importing stylesheet; push allows constants declared above the @import rule in the importing style sheet to be used the imported style sheet; sync allows both of the previous, simultaneously.

The two proposals differ also in the way that constants relate to, and work with Media Types. In Hyatt’s/Glazman’s proposal, an optional Media Type keyword can be placed between the @variables keyword and succeeding block declaration. In fantasais proposal, constant declarations (placed within a @define block) can be nested within an @media block. However she metions, …if declared inside an @media rule, the scope of the declaration does not end with the @media block, meaning that constants can be used outside of the @media they’re placed in. It’s worth mentioning that the @media rule model/syntax differences could be trivially modified to use the other’s media type syntax.

From the October F2F CSS Working Group minutes (Apple’s proposal); Apple presented their proposals for Animations and Transitions, made remarks on Transforms, gradients, reflections. All four major browser vendors are interested in these proposals, and it is very likely that the CSSWG will accept to work on them. Exciting stuff!

Hakon presented a proposal for a border-parts property, which defines an on/off mask over the border as a series of lengths; you can check out his proposal in more detail on www-style. Note, this is still very much an unapproved proposal and the WG have stated that they are still unsure how usable/useful a solution such as this would be.

Dave Hyatt and Daniel Glazman initially came up with a proposal for CSS Variables, and fantasai has now created a counter-proposal detailing plans for a purely parse-time, non-scriptable solution. To help distinguish between the merits of both, I’ve come up with a brief article comparing and summarising both proposals.

An advantage of not posting for a while is that there are usually plenty of good subjects to talk about when you get back to it…

With a kind nod of the head to our post from way back in 2006, Andy Clarke has posted a screencast (with full transcript and code examples) of RGBa values in action on his website For A Beautiful Web.

Over at Javascript Kit they’ve produced an exhaustively in-depth look at structural pseudo-classes.

On the subject of Javascript, Eric Meyer has written about how it can be leveraged to extend CSS3 support across browsers.

And Helen from Helephant.com writes a good introduction to the box-sizing property.

Mozilla employee John Daggett has provided some try‐out builds of Firefox with support for the @font-face from CSS3′s web-fonts module. Currently available for Windows and Mac only—no Linux build yet—there remain several caveats as described in his comment on bug 70132, the most important of which being that the same‐site origin restriction is turned on by default, which means that most examples on the web will not work until you turn it off.

This information was released today on the Working Group blog and there looks to be some major updates.

• The shorthand syntax for border-radius has been updated so that you can now specify different irregular curves on an element – this was a well-known abiguity that Peter pointed out in the former Working Draft.
• Handy new background-position syntax for positioning offsets from corners other than the top left
• Spread values for box-shadow
• Box-shadows can now be inverted, to appear ‘inside’ an element thanks for the new inset keyword.
• Addition to background-color value syntax which means fallback colours can be specified
• Addition of no-clip value for background-clip
• Two additional background-size values (cover and contain; they both scale the image whislt retaining its intrinsic aspect ratio. The difference however, is that by using the cover keyword value, the image scales to the largest size such that both its width and its height can completely cover the background positioning area to. Whereas scale scales the image to the largest size such that both its width and its height can fit inside the background positioning area.
• New syntax for the background shorthand property

I’ll try and clarify some of these updates when I get some more time. All in all, some great new updates, though!