-
200908 Jul
Perhaps foreshadowed by Google’s adoption of HTML 5, Jeffrey Zeldman pointed out late last week; the future of XHTML 2 is no more. Obviously the selectors we use in CSS 3 depend on the underlying markup we work with, so this news is very interesting and we think timely. As CSS 3 support inches forward with each browser release and as JavaScript libraries supplement poor browser behavior, the need for web developers and enthusiasts to be able to focus their attention has become a paramount concern.
-
200917 Jun
Posted in News
Earlier this year we asked if you still want more out of CSS 3 and we found that you did. Of late, we are seeing the dialogue rekindled time and again with great posts being written on other major blogs. Smashing Magazine contributor Inayaili de Leon provides code samples and insight on: using browser-specific properties, selectors, RBGA and opacity, multi-column layouts, multiple backgrounds, word wrap, text shadow. @font-face attribute, border radius, border image, box shadow and more. Definitely great work by de Leon, that also earned a mention from ajaxian. So check out the post and enjoy! Well done Inayaili!
-
200914 Apr
Posted in News
So, the CSS Working Group is trying to wrap up the CSS3 Backgrounds and Borders Module and prepare it for Last Call. However, there are still some open issues we’d would like to get comments on.
Most of the open issues revolve around
border-image
. Brad Kemper knocked down several with his proposal and the CSS Working Group has adopted it in principle. (You can find it drafted into the latest unofficial Editor’s Draft on the W3C site.) We’re still ironing out the details on that, but there are a few others still open onborder-image
:First Issue: Several people have commented that they would like a way to clip out the center part of the image. There are two options for this: A) Keep the middle part by default (current behavior). Add an
empty
keyword that clips out the middle part. B) Make the middle part clip out by default. Add afill
keyword that keeps it. (It’s needed for stretch-tiling things like aqua buttons.) Of course we might also just keep the current solution, C) have authors make that part of the image transparent. Comments? What would you use?Second Issue: The syntax is particularly arcane. One commenter suggested breaking up
border-image
into multiple properties, leavingborder-image
itself as a shorthand. For example,border-image: url(...) 20% 40% / 10% 4em 20% / 0 1em;
would be equivalent to
border-image-source: url(...); border-image-slice: 20% 40%; border-image-widths: 10% 4em 20%; border-image-outset: 0 1em;
This would also allow the values to cascade independently, making it easy to e.g. swap just the image. There’s an overhead cost to more properties, however, so if we do this there needs to be a significant and useful advantage. Thoughts on this idea, or any other ideas for making border-image easier to understand?
Third Issue: There’s still an open question of how
border-image
should interact withbox-shadow
. The two proposals on the table are: 1.) Ignorebox-shadow
whenborder-image
is in effect. (The author can draw the shadow directly in the border-image.) 2.) Use the border-image as a mask to draw a shadow, but only draw the shadow where it appears outside the padding edge (inner border edge). Comments? Preferences?Fourth Issue: The next topic is fallback colors: the current draft has a feature that lets you specify a background color to use only if the bottommost background image fails to load. The WG wants to know, is this feature something authors really want? Several WG members have posted comments saying that it’s too hard to understand, that it’s not useful, and that the proposed syntax doesn’t make sense. What do you think?
Fifth Issue: The last issue is, the current draft specifies a
background-clip: no-clip
feature that lets a background image spill out of the border box. Implementors are concerned that it’s tricky to implement, and aren’t convinced that it would be useful. If this is something you want, show off a realistic example or two that demonstrates why it is needed.Off-topic Issue: While I’m here, the WG wanted me to ask what people thought of renaming the
block-progression
property toblock-flow
orblock-direction
and whether either was more understandable (or if anyone had better ideas). The property changes the direction of block layout, and the values aretb
(horizontal lines stacked top-to-bottom, like English text),rl
(vertical lines stacked right-to-left, like traditional Chinese text), andlr
(vertical lines stacked left-to-right). This is for vertical text layout, btw; it’s different from graphical rotation. See pages 2-5 of UTN 22 (PDF/HTML+SVG) for a definition.P.S. Could someone please fix the css3.info style sheet so it doesn’t effectively eat list markup? Thanks.
-
200911 Apr
Posted in News
The CSS Working Group had a face-to-face meeting in Tokyo last month and made a series of resolutions (which can be found on their blog). Most are fine technical points, but one of the more interesting is that the multi-column layout module is about to be reissued as a ‘last call’ document; after this, the module will be released as a candidate recommendation, meaning the authors are satisfied that the standard does what is needed of it, and will call for implementation.
As you may know, Webkit browsers (Safari, Chrome, etc) already support multi-column declarations (with a -webkit- prefix) and Gecko browsers (Firefox, Camino, etc) partially support it (with a -moz- prefix) – and fuller support will be forthcoming in Firefox 3.5. With those implementations in place, I’m hopeful that it will pass quickly through the recommendation process and become a standard.
Last week saw another layout proposal, the template layout module, reissued as an updated working draft. Previously known as the advanced layout module (and featured in our article How We’ll Lay Out Websites in 2016).
As a quick reminder, template layouts allow you to assign content to ‘slots’, which can then be laid out by declaring a grid using alphabetical characters. The following code would set up a two row grid, with the top row spanning the three individual columns of the bottom row:
body { display: 'aaa' 'bcd'; }
You could then match elements to each slot by using pre-existing selectors and the position attribute:
div#div1 { position: a; } div#div2 { position: b; }
And also use the new slot pseudo-class to apply styles:
body::slot(a) { border: 1px solid; }
This is probably the most radical proposal since the CSS standard was first created, allowing for very flexible template layouts, and I’m quite excited about it. However, it currently has no implementation, so is doubtless a long way off. Perhaps my satirical date of 2016 is not too wide of the mark after all.
-
200921 Jan
Posted in News
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.
- General questions about your CSS 3,
- Research for future-proofing your projects,
- Browser support issues and updates,
- Tutorials and how to’s on CSS 3 features,
- 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.
-
200815 Nov
Posted in News
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
. Examples (ripped straight from her proposal :)) showing the syntax for each of the three Constants are below:-@define
rule is the@define
at-keyword, followed by either thevalues
keyword (for declaring value constants) or thestyle-sets
keyword (for declaring style-set constants) or theselectors
keyword (for declaring selector constants), followed by a blockValues
@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
andsync
;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
, meaning that constants can be used outside of the@media
rule, the scope of the declaration does not end with the@media
block@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.
-
200815 Nov
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, whichdefines 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.
-
200810 Sep
Posted in News
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 forbackground-clip
- Two additional
background-size
values (cover
andcontain
; they both scale the image whislt retaining its intrinsic aspect ratio. The difference however, is that by using thecover
keyword value, the image scalesto the largest size such that both its width and its height can completely cover the background positioning area
to. Whereasscale
scales the imageto 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!
- The shorthand syntax for
-
200803 Jul
Posted in News
The beauty about working on a site that is specifically targeted for one the most popular mobile devices around (aka the iPhone) is that the vendor with the least CSS support (*cough* IE *cough*) doesn’t exist on it (purely because of its inadequate CSS support in this case).
Depending on the browser matrix you have to work with and the platforms you’re coding for, utilizing Level 3 (and some Level 2.1 in IE’s case) selectors simply isn’t realistic, although properties on the other hand can be used to progressively enhance an elements appearance in this particular context.
But what if a site was created to serve one specific handheld device in which Safari (along with its sufficient CSS3 support) was the default browser? Well, this is what Facebook has done with it’s iPhone-specifc UI. By peaking into their stylesheet you’ll notice that they’re implementing a number of Level 3 selectors, properties and property value additions. They include the:-
- User-select property (Webkit prefix)
- Negation Pseudo-class Selector
- RGBA color values (in conjunction with ‘background-color’ and ‘text-shadow’ properties
- Text Overflow property
- Box-sizing property (including Mozilla and Webkit prefixes)
- Border-image property (Webkit prefix)
- Text-shadow property
- Border-radius property
- Multiple Backgrounds
- Opacity
For comedy value, try viewing the site in IE.
Having this sort of free reign on selectors and properties is an interface developers dream in this day and age, and hopefully in a couple of years we’ll be able to structure a stylesheet with some similarly advanced features.
-
200826 Jun
Posted in News
This is just a quick note, to inform CSS3.info readers that the release candidate for Opera Dragonfly alpha 2 has just been released. Check out the Opera Dragonfly web site for download instructions, and the Opera Dragonfly Blog for more information on the release. There will be a short RC phase then alpha 2 will be uploaded to the main Opera Dragonfly URL that is built into Opera 9.5, and existing alpha 1 users will be upgraded automatically. The web site will also be updated to highlight the new features.
One feature of note for readers of this blog is the auto-complete feature for CSS properties and values in the Styles sidebar. Using the up and down arrows will cycle through the valid properties that Opera supports. This (in theory) will give a good indication of all the CSS3 properties that Opera 9.5 (and subsequent versions) has implemented. As CSS editing is live and immediate, it is a great way to test new features and play with the values.
Please give feedback on Opera Dragonfly alpha 2 using the usual channels.