WaSP Community CSS3 Feedback 2008

Selectors

Most requests falling into the "programmability" category are selectors.

Many requests, such as

• Selecting the nth or odd/even children
• Selector negation

have already been fulfilled in the Selectors Level 3 module.

Other requests include:

Nesting Selector/Declaration Blocks

Several comments requested some way to nest declaration blocks such that the outer selectors are connected to the inner selectors with the descendant combinator. The arguments in favor are "less typing" and "better structure" in the style sheet.

C L gives the following example:

#pageid {
    #content {
      blah: blah;
    }
    #nav {
      yada: yada;
    }
  }

instead of

#pageid #content {
    blah: blah;
  }
  #pageid nav {
    yada: yada;
  }

• Wilco
• C L
• mac
• Thomas Peklak

I'm not really convinced. "Better structure" can be given just as easily by comments and indentation, like I did with the mozilla.org style sheets. Less typing becomes significant mainly in the pathological cases, which could be solved by using constants that represent selectors. That would avoid complicating the nesting structure (which is a great way to introduce errors) or creating such a bias toward the inefficient descendant selector.

Constants and Variables

The most-requested feature was some form of constant or macro to ease style sheet maintenance. Daniel Glazman (Disruptive Innovations) and Dave Hyatt (Apple) have since begun work on a CSS Variables proposal, which addresses some, but not all, of the requests below. (The proposed "variables" currently can only represent property values.)

Petr Stanicek writes:

In fact, there is only one thing I'm missing in CSS. But I miss it virtually every day: a kind of reusable parameters. What does it mean? Very often, I create a large stylesheets for a large project. A color palette is given and color codes are repeated many times through the stylesheet. It would be very nice to be able to predefine those colors as parameters (or user-defined keywords) at the beginning of the stylesheet, and then only use these symbolic values.

If I need to replace a color in whole CSS, I could only edit one value in the @define section. If I want to change the color palette of the web site at once, I could edit only these predefined values.

Or, why use it for colors only? These substitutions could be useful in many ways.

@define {
   textColor: #003366;
   emphColor: #660000;
   canvasColor: #f0f0f0;
   baseFont: "palatino linotype", palatino, serif;
   titleFont: "Helvetica Narrow Black", Impact, Techno, sans-serif;
   stdPadding: 0.2em 2em 0.3em 1em;
   }
@define {
   stdBorder: 1px solid @textColor;
   }

body {
   color: @textColor;
   background: @canvasColor;
   font: 1em/1.67 @baseFont;
   }
h1 {
   color: @emphColor;
   font: 250%/1 @titleFont;
   }
.box {
   padding: @stdPadding;
   border: @stdBorder;
   }

Matt Wilcox writes:

CSS files can become very large, even when the cascade is used well. It is not uncommon to have CSS files in excess of 1,000 lines. In the real world, clients often want to 'freshen' their sites by having minor re-designs, for example by changing the colour scheme. It is not always possible to do a simple search/replace on the hex code (other items that should not change may share the same colour). The ability to declair constants/variables would greatly speed up the process.

...The idea is to allow maximum flexibility with the minimum effort. A system whereby calling the variable sets a number of CSS properties, which could then be over-written if required by re-declairing a property called via the variable would be even better.

• Petr Stanicek
• Sander Aarts
• Matt Wilcox
• Wilco
• Henry Francis
• Andy Budd is opposed
• Harald
• peter
• Ron Wenton
• Pavel Panchekha
• Stephanie Hobson
• Isaac Csandl
• Darko Laus

I agree with the comments here that CSS should include some form of constants or macros. I think a powerful-enough proposal would solve a lot of usability problems, including several others listed here. I'm skeptical of Hyatt and Glazman's variables proposal. I think defining variables rather than parse-time macros complicates the implementation and limits expressiveness: it optimizes for use cases that weren't even mentioned here, and doesn't address others that were. Either way, this feature has made the cut for the 2008 CSS Working Group proposed charter, and unless W3C management objects (unlikely) will be part of the final charter.

Inheritable Variables

Stephanie's variables proposal goes one step further by suggesting that the variables be declared in a style rule, associated with and inherited through an element. Then any style declarations that use the variable must dereference the assigned or inherited value.

I think this is unnecessarily complicated. Currently the cascading and assignment process is independent from inheritance, so suddenly combining them like this is probably not a very good idea. However the kinds of problems Stephanie's proposal seems to be solving could be easily solved by a constants/variables proposal very powerfully if the definitions are not document-global and scoping can be controlled somehow.

Explicit Inheritance of Declarations from Other Selectors

Several more comments discussed various concepts of explicit "inheritance" into one style rule of properties declared for another element. It is very unclear where this fits into the existing cascade and inheritance system.

• Paul B
• Björn Weinbrenner
• Phil Houghton
• Gus
• Ali Sattari
• Stephanie Hobson

For semantic subclassing like ".user_icon_button extends .standard button", using multiple classes is an existing way to go: style .button and .user_icon.button. For avoiding style declaration duplication, a macro system that can accept not just values but also selectors and property declaration lists can solve the problem without interfering with the cascade or inheritance. (A new "explicit inheritance" concept would only be needed if the use cases require a new intermediate step between cascading and inheritance, and that argument has not yet been presented.)

Scoped Style / Style Blocking

Several people requested the ability to block inheritance and/or cascading, to handle cases where content from one site is incorporated into another site or web application. Bernie Zimmermann explains this as whenever a UA rendered this type of element, it would use its default style rules (ignoring any that had been established via any external stylesheets, inline style rules, etc.).

One way to solve this would be to introduce a new value (e.g. default or reset) that causes all previous declarations in that weight level to be ignored. That is, if the winning declaration is this new value, then the UA must look back to the previous cascade level to find a value. In the case of author style sheets, this would drop to the winning declaration in the user level. In the case of user style sheets, this would drop to the winning declaration in the UA style sheet. If there is no winning declaration, then the property would get its initial or inherited value, depending on what behavior was wanted. This would be something to consider for the Cascading and Inheritance module. Authors would need a shortcut to set all properties, e.g. *: reset.

Querying Layout Engine

Several people requested the ability to query the layout engine to eliminate the need for hacks.

Fyrd writes:

Just having a practical and official way to write different rules for different rendering engines would help prevent the use of unseemly hacks. Note that I’m not just talking about writing special fixes for IE etc. here, but also for when using new properties that only one or few browsers support, it would be very helpful to easily send just them certain rules, while sending others alternative rules.

Examples include issues where there’s no easy way to provide fallback, like text that would be invisible without a text-shadow (by having the text be the same color as the background), or an SVG background image where you would want to supply a different background image for browsers without support.

Brad Kemper writes:

Acknowledge that it will be many years, if ever, that UAs will have complete feature parity of CSS capabilities, and include a media-queries-based mechanism for providing different rules to different rendering engines. When this is not part of the official specification and software, then authors have to find their own way of accomplishing the same thing, via CSS hacks, JavaScript UA detection, or server-side UA detection. All those other methods have significant disadvantages over an officially supported method, but authors will resort to them if it is the only way.

• Fyrd
• Brad Kemper
• Dave
• Pavel Panchekha

There's been a lot of debate about this feature on the www-style list. Many browser implementors are opposed because it makes it very difficult for a new browser to enter the market when it's used to block unknown browsers and higher versions of existing browsers from accessing certain features of the site. My take is that CSS should have a "property: value" support query, where the UA passes if it thinks it has any usable level of support for "property: value". That wouldn't handle browser bugs, but it would take care of uneven CSS feature support.

Interdependent Styling

Several comments requested the ability to make the style of one element (such as its width) depend on the used style of another, arbitrary element.

Matt Wilcox writes:

div#container { width : 24%; }
div#excerpt {
  width : (div#container - 80px);
 /* because sometimes % and em just aren’t good enough when mixed with px */
}

Matt did not provide much of a use case. Ariel's comment included the use case of making two floated boxes the same height.

• Matt Wilcox
• Chris Jay
• Ariel

I think we'd need a lot of detailed use cases to understand exactly why something this complicated and this powerful is needed. To prevent loops, references would have to be restricted e.g. to ancestors and previous siblings. Ariel's use case would be more easily solved with layout systems designed to handle side-by-side boxes, like display: table or my display: tab proposal (which allows table-like height and width justification but lets the rows wrap like floats).

Shortcut for width and height

daembrace a shortcut to specify both the width and the height together: size: 450px 100%; that would be the same as width: 450px; height: 100%;

I'm not convinced this is useful. It doesn't add much except complexity, hardly saves any typing, and is not backwards-compatible.

Generated Boxes

Antti Rasinen would like to generate boxes inside and outside existing boxes to create multiple backgrounds, multiple borders, width calculations, etc.

I think the problems solved by this proposal should be tackled individually, e.g. multiple backgrounds instead of multiple elements with backgrounds. Generated boxes interfere with cascading in a way that property-based solutions do not. For more complicated situations, XBL can be used.

Indirect Selector Combinator

Pavel Panchekha requests a selector matching one element (such as the :hover above) allows rules to apply to another selector. The example given doesn't include markup, so it's unclear what exactly is wanted.

A full implementation of the :matches proposal would probably solve the use case, but it's hard to tell without the markup.

:line Pseudo-element

Manne suggests a :line(An+B) selector to select lines other than the first line. No use case was given.

Image Slices

Ben Millard wants to allow all decorative graphics to be taken from a single image file by being able to specify a specific region of an image in addition to its URL, to improve performance over HTTP.

Petr Stanicek wants to use clipped out pieces of a single image as individual background images:

I think this could go into Values and Units. We'd need a new <image> type that takes either a url or an image slice, and should also extend the concept to sound files. Alternatively we could write a spec that defines fragment identifiers for images.

Expressions

Expressions for length values that can combine various units and percentages:

• Ben 'Cerbera' Millard writes:

  [For] Horizontal Gaps in %-based Layouts ... Setting width as x% minus yem would enable slightly less markup, slightly more robustness and other slight gains.

• ailaG

There has been proposed syntax for this in the CSS3 Values and Units module for a while now. We just need to finish that module and publish a CR of it.

Text Decoration Controls

Better control over text decoration controls: specifically, colors, styles, and offset

• Neal
• Emil Ivanov

This will appear in CSS3 Text.

Combined Font Declaration

Two comments suggest coupling font-family with other font styles, particularly font-size.

Dave writes:

Declare entire font styles the way that font-family is currently used. Instead of something like “font-x, font-y, sans”, let me say “Family size line height”. For example “font-x 14px 1.3em, font-y 16px 1.2em, sans 14px 1.2em”. Should some solution offering more web fonts surface (which will probably happen in the very near future judging by potential) we need a way to work with the fact that different fonts are…different.

• Dave
• Stephanie

The main use case seems to be to adjust font-size and line-height to account for differences in font design. Coupling each font family with one or two factors (defaulting to 1) instead of with font-size and line-height would solve this while allowing line-height and font-size to be specified, scaled, and overridden in proportion.

Font-stretch

jive requests a "font-stretch" property, but doesn't define it or give any use cases.

There is a font-stretch property in the CSS3 Fonts draft. I don't know its status.

Hyphenation

Two comments suggest controls for hyphenation such as the ability to turn it on or off, and to set limits on the letters before/after the hyphenation point.

• Harald
• Jeroen Visser

Hyphenation controls are already proposed and drafted with the above functionality.

Styling List Markers

Several comments request more control over list markers, such as:

• Changing the marker's color
• Specifying a different bullet character
• 1 1.1 1.1.1 style numbering
• Numbering systems such as cyrillic

• Chris Kennish
• Lee Carré
• Stephanie
• Emil Ivanov
• Jeroen Visser

Additional control over list markers should become available with the proposed ::marker pseudo-class. More numbering systems are defined in CSS3 Lists; the main problem there is that the definitions for some numbering systems are known to be wrong, but the correct definitions are not known. This and the closely-related CSS3 Generated Content will need to be developed together. Hopefully I'll have time to work on them after CSS3 Backgrounds and Borders and CSS3 Paged Media are published as CR.

Styling Soft Breaks

Bruce Lawson wants to be able to style soft breaks differently from hard breaks, e.g. by indenting them or displaying a symbol. This would show the difference between hard breaks and line wrapping in poetry and code.

It's a good use case, and I hope we'll keep it in mind when designing any related features, but I don't think it makes the high-priority list for the WG right now.

More Fonts

greg wants more fonts reliably available on the Web. Ron Wenton suggests downloadable fonts.

Downloadable fonts are certainly on the CSSWG's radar, and syntax for them has been defined since CSS2 was originally published. John Daggett of Mozilla expects to continue working on the CSS3 Fonts spec that defines downloadable fonts. The major obstacles, besides spec details and implementations, are legal and security concerns.

Source-order Independent Layout

Two comments mention source-order independent layout mechanisms to improve accessibility and device-independence of documents.

AlistairC writes:

Although people seem to be getting excited that IE8 will include table CSS properties for layout, this is no better than minimal tables. Solid, source-order independent layout would make accessibility and device independence from one source actually possible.

Sander Aarts concludes his "combine absolute postioning and floats" layout proposal with:

This would make it possible to visually rearrange the order of the source code without the risk of elements overlapping when content or font sizes increase.

• AlistairC
• Sander Aarts

The CSS3 Template Layout module defines a layout system that can do reordering. Comments on syntax and capabilities would be appreciated, but there doesn't seem to be much implementor interest right now.

Snap to Increment

Andy Ford would like to be able to snap widths and heights to a given increment. The use case he suggests is making a tiled background fit without clipping.

The new space and round repetitions should help with that particular use case. In general, a snap-to-grid ability that takes a grid and a particular box edge (top border edge, bottom content edge etc) and makes the box edge snap to the grid would be another way to solve this problem.

Contain a Float

Several comments request a non-hacky switch to make an element contain all its descendant floats.

thinsoldier writes:

There needs to be an explicit attribute to command an element to surround it’s floated children other than relying on overflow:hidden/overflow:auto

There are time when I want to expand an element around its floated children only and just ignore it’s grand-children but with overflow:hidden the grand children won’t be fully visible if they partially extend below the bottom of their floating parents. And with overflow:auto the grand-children activate the scrollbar

I would like a property meaning the element it applies to expands vertically to include all floated elements within it. E.g My container div visually contains the two floated divs (without having an extra element after the two floated divs which has clear: both).

Stephanie writes:

The problem

Elements with floated elements inside them need to have extra HTML code added that the end in order to completely contain the floated element. This might be a div with style="clear:both;" or it might be added dynamically using the .clearfix method.

What happens:

Text

Text text.

What we might want:

Text

Text text.

What it might look like

A new attribute to indicate that containers should clear their floats before they end.

#box{
overflow:contain;
or
clear:contents;
}


ailaG lists:

floats that do matter for the parent’s height / width, to avoid all these “clearfix” elements that are, in fact, design. (e.g. a picture gallery with all the thumbs floated would require clearing at its end, that should be native to css)

• thinsoldier
• peter
• Stephanie
• ailaG

This makes a lot of sense, and there was a proposed clear-after property in an earlier draft of the CSS3 Box Module. The main argument I've heard in the WG against adding it is that there are already so many ways to get this effect, do authors really need another one.

Wrap Text Around Positioned Elements

Several comments request the ability to wrap text around absolutely-positioned elements. One comment suggested the opposite: better positioning of floats.

• thinsoldier
• Sander Aarts
• Brad Kemper
• Stephanie

The absolute-positioning layout algorithms rely on knowing the size of the containing block, whereas wrapping text around a float affects the containing block. Simply combining these two features is not possible. We need a much more detailed examination of what layouts the designers making these proposals are attempting to achieve, to figure out if there's another way to solve the problem. Adapting floats to be able to shift up and down in addition to left and right could possibly solve some of these layout problems without breaking assumptions that the layout algorithms need.

More Wrapping Options

Stephanie's comments on positioning and text wrapping included a lot of other wrapping options for absolutely and relatively positioned elements. No explanation of what real-world examples suggest these different options are necessary.

Positioning Relative to Another Element

Matt Wilcox and Isaac Csandl both mention positioning an element relative to another element (that is not its direct ancestor). No examples are given of what layouts this feature is needed to achieve.

A feature like this would be extremely complex and difficult to design and implement. Without concrete use cases to define the problem, there no way to even understand the requirements for creating such a feature--nor is there a way to suggest an alternate feature that would solve the problem without that level of complexity.

Positioning By Center

Brad Kemper and Stephanie mention positioning an element from its center rather than its sides.

Combining Fixed and Absolute Positioning

Georg wants to combine fixed and absolute positioning so that the scrolling behavior matches fixed positioning in one dimension and absolute positioning in the other:

the ‘fixed’ right column can be reached by scrolling horizontally. It works in IE6 because I’m using an IE-expression to fake ‘position: fixed’. In Firefox the right, fixed’, column is lost outside the viewport on very narrow windows, as it would otherwise end up overlapping the main, scrollable, column.

Easier Fluid Layout

Several commenters would like to see CSS layout easier to understand and use.

Christopher writes:

I would like CSS3 to focus more on layout techniques that are easy to understand. The current CSS2 implementation is useless for creating fluid layouts unless you have an IQ above 300.

Dave lists:

Better general layout tools. I’ve gone from hardcore standards & semantics fanatic back to someone who appreciates that tables are the only or easiest way to achieve some of the most desired layouts. Any new layout tools that don’t offer everything tables did with the same ease as tables is truly an incremental step that is just wasting everyone’s time.

cynglas writes

“Tables are the only or easiest way to achieve some of the most desired layouts”. Eric Meyer says the same thing in several books. So we need dedicated layout tools that are capable of the speed, intuitiveness and stability that tables gave to onscreen layout, without the disadvantages for accessibility and multi-agent deployment.

Specifically we need:

• that can be quickly be set and remain associated in parallell across a screen (to form a grid-like framework that does not have to contain “tabular data”).
• Parallel that can be grouped to auto adjust to the same height as the longest in the group (according to its variable content).

...A cognitive suggestion for CSS3 planning: stop thinking of web “documents” on the model of just Word processors (like the awful Microsoft Word) and start thinking of flexibly designed spaces, more like DTP (eg. InDesign).

Mark Wales writes

Proper layout functionality: shouldn’t have to use float for page layout (other than for actually floating images and such). There should be an easy way to get a side-column to be the same height as everything else.

• Christopher
• Dave
• cynglas
• Mark Wales

Support for CSS table layout and Media Queries should go a long way toward making fluid CSS-based layout easy. For layouts that require reordering, the CSS3 Template Layout module aims to make that easy.

Vertical Text

Two comments asked for vertical text. hawken king's use case was Japanese text.

• jive
• hawken king

Basic vertical layout, such as that used in Japanese documents, has been a CSS3 draft for years. IE has implemented vertical text layout, but we're missing a second implementor and, more significantly for getting to CR, the drafts that contain the layout definitions need intensive, detailed review by someone very knowledgeable about the CSS box model.

Siblings Same Height

An over-arching layout problem that was repeated in many comments and implied in layout proposals is equal-height columns.

• Sander Aarts
• peter
• Ariel
• cynglas
• Alexandre Falcoeiras
• Ben Millard

This is already solved by using display: table-cell: once IE supports it equal-height columns should be very easy to do.

Better Layout Support for Horizontal Tab Bars

Oldřich Vetešník wants to be able to create right-aligned horizontal navigation bars without having to re-order the source <ul>.

My proposal for a new display type would solve this problem. I'm told the FlexBox proposals can, too, but I haven't seen that for myself. There are quite a few layout problems with using floats for these kinds of navigation bars: I agree we should make sure they are easily solved.

Box-sizing

Two comments asked for box-sizing capabilities.

ailaG writes:

BOX MODEL: give us a way to mix border-box and content-box on a whim. I read about a suggestion for ‘border-width’ and ‘content-width’, that.

• Stephanie
• ailaG

There's a box-sizing property and another proposal for adding box-sizing keywords to width and height. See ... for a discussion of this issue.

Multi-col

Stephanie wants to present lists in multi-column format.

This is already covered by the Multi-Column Layout module.

Shrink-to-fit Keyword

Stephanie illustrates a use case for a min-intrinsic width keyword:

Miminum box sizing based on contents

The problem

Image captions shouldn't push the container they share with the image wider

If I have a 200px wide image. I want my caption to wrap at 200px, but I don't want to have to hand code the image width on every container div on the site.

Current:

This would be the caption for the image, I would like it to wrap at 214px but not have to tell it that.

Desired appearance:

This would be the caption for the image, I would like it to wrap at 214px but not have to tell it that.

What it might look like

A property that could be set on the parent div to make it the minimum width possible:

.contentimage{
width:minimum;
or
text-wrap:force;
}


A propery that could be set on .caption which would prevent it from forcing the container larger:

.caption{
width:parent;
}


We resolved to add a min-content keyword to the width properties at the November 2007 face-to-face meeting. That should solve this use case (which is the same as the one Jason drew on the board at that meeting).

Baseline Alignment

Jeroen Visser requests the ability to specify alignment with respect to baselines:

Most importantly: a true baseline grid, with an option to specify the distance from the first baseline to the top of the element’s box. This would greatly enhance legibility and design consistency within a site (for instance: lining up two content columns, or making tag clouds’ keywords stick to a common baseline).

Lining up two content columns can be done with vertical-align if the columns are given as table cells (using display: table-cell, which has been supported by Mozilla, Opera, and Safari for years and will be supported by IE8. As for tag clouds, they will share a common baseline if the tags are given as regular inline elements, so I'm not sure what the problem is here. There are other effects you can only get by actually defining a baseline grid (like aligning everything to the grid so lines of text on facing pages always line up), but there was no mention of them in this comment.

Transformations, Especially Rotations

Eight comments mentioned transformations, particularly rotation.

• Chris Jay
• Chris Griego
• Ryan Groth
• Matt Wilcox
• Fyrnd
• Brad Kemper
• Stephanie

Apple is working on a proposal for transformations, and the CSSWG has also spent some time discussing some of the tricky issues over the past year. Expect more work on this over the next charter period.

Text on a Path

A couple thinsoldier and couple Dominic Shiells requested text on a path

My response would be to use SVG... or use JavaScript or XBL to wrap SVG around text coded in HTML.

Non-rectangular containers

thinsoldier and Andy Budd want non-rectangular boxes. thinsoldier suggests referencing an SVG shape.

Something I'm sure the CSSWG wants the consider at some point, but not in this charter period.

Non-rectangular floats

Harald mentions non-rectangular floats.

This idea has been floating around for a long time. Bert's post describes the concept as simple to specify, but notes that implementation would be more difficult. This would be a candidate for the Box Module or some derivation of it.

Animation

Several comments mentioned animation, but did not explain very well what they wanted to use it for and, aside from Fyrd, did not explain why it belonged in CSS.

• Chris Jay
• Chris Griego
• Fyrd writes:

  Many javascript libraries offer easy ways to do animation, usually just for visual effects (rather than actual behaviour). Seems to me like something designers want to do easily, so it makes sense for CSS.

Toggleable States

Soon-il DDang requests pseudo-classes for toggling an element between different states, e.g. for collapsible menus.

There has been some discussion on this in the CSSWG in the past, but no conclusions. An important question is whether and how the toggle states are represented in the DOM. I think they certainly should be represented there, and in that case we need a spec for the DOM interfaces that we can then link to CSS pseudo-classes. Another important question is how the states are triggered, and accessibility is important here. It's not a simple question of defining pseudo-classes. However, I'm sure the CSSWG would be interested in adding pseudo-classes for a proposal that defines the relevant DOM (and possibly also markup) interfaces.

Other Visual Behaviors

Rayne Van-Dunem requested "greater behavioral capabilities", but it's not clear what exactly is wanted other than smooth scrolling:

Greater behavioral capabilities, such as the ability to click a button which will dynamically scroll to another section smoothly. Currently, it can only be done in JavaScript, but I think it could fit in with the idea of giving CSS the ability to style the page without interfering with the basic readability of the webpage with, say, a voice reader.

Color Gradients

A lot of people mentioned color gradients.

• Fyrd argues for the "need to create them easily in CSS" rather than as separate images.
• Dominic Shiells
• Neal writes: The ability to create gradients using only css and to choose where the midpoints fall.
• Chris Jay
• Brad Kemper
• Ron Wenton (ps)
• Greg
• Webmac
• David Storey comments on using SVG for this
• Gradients
• Lea Verou
• Stephanie

In addition to the above, Rayne Van-Dunem specifically calls out the ability to define gradients for text.

A lot of people seem to think that it's possible to simply replace every <color> value with a gradient, but it's not that simple. A color is zero-dimentional. Gradients are either 1D or 2D. To use a fill that has dimensions means defining its "bounding box", not just its painting (or clipping) area. Imagine, for example, applying a gradient to the text of a <span> broken across two lines. Do you apply the gradient to each part individually? Glue them together as if they were all on one line first? Draw a rectangle around both parts and apply the gradient to that? (CSS3 Backgrounds and Borders has a control for this.) This would be something to consider for CSS3 Values and Units. The spec would need to consider the "bounding box" problem and specify for which CSS2.1 properties gradients are valid.

Multiple Backgrounds

Multiple people requested multiple backgrounds:

• thinsoldier
• Andrew Senter
• Simon Lilja
• Johan De Silva
• Mark Wales
• Stephanie
• ailaG
• Ben 'Cerbera' Millard

This functionality is already described in the CSS3 Backgrounds and Borders module and has high implementor interest. It will be listed as high priority in the CSS Working Group charter.

Image Borders / Shapes

Several people mentioned image borders:

• thinsoldier
• Christian Norton
• Dave

A border-image property is already described in the CSS3 Backgrounds and Borders module, which has high implementor interest and will be listed as high priority in the CSS Working Group charter.

Control Over Border Dots and Dashes

johan kim wants controls over the gap and width/height of dots and dashes in borders.

I think the benefit of this is not anywhere near worth the complexity it would add to CSS. It would be better for implementors to put their efforts towards making those dots and dashes look good.

Background Image Sizing

thinsoldier requested the ability to resize background images.

A background-size property is already described in the CSS3 Backgrounds and Borders module, which has high implementor interest and will be listed as high priority in the CSS Working Group charter.

Foreground Images

Stephanie suggested the idea of foreground images, which are like background images except they layer in front of the content. Use cases include watermarks, corner decorations, and translucent overlays.

It's an interesting idea I don't think the CSSWG has discussed yet. It would be a very heavy feature property-wise if it were done by duplicating the background properties, but otherwise very easy to spec and implement. (Do a second pass with the background-rendering code.)

Background Positioning from Bottom Right Corner

Several comments requested the ability to position background images from the bottom right corner as well as the top left.

• Sander Aarts
• Matt Wilcox
• Stephanie
• ailaG

I've added some proposed syntax in the new CSS3 Backgrounds and Borders draft. We'll be asking for feedback on that. Also unless your design needs to depend on the writing direction (ltr vs. rtl), the calc() proposal in CSS3 Values and Units should also be able to handle this (by subtracting from 100%).

Repeat in One Direction

Webmac requests "support of x-repeat with non-zero start-position".

This would be fairly simple to specify, but we'd need some convincing real-world examples to show that it's needed and worth defining and implementing.

"Shrink-to-fit" Background Image Sizing

Simon Fraser requests "shrink-to-fit" sizing for background images:

“Shrink to fit” would reduce the scale of the image until both height and width fit in the background, while maintaining aspect ratio. Currently, it’s only possible to do either width or height.

Bert and I have added this to the CSS3 Backgrounds and Borders editor's draft. Expect to see it in the next official publication.

Image Mirroring

thinsoldier suggested a way to mirror images to cut down on the number of image files.

This would be something to consider for the CSS3 Values and Units module, along with image slices.

Drop Shadows

Several comments mentioned drop shadows:

• Neal
• ryan groth
• Mark Wales
• Webmac
• Ben 'Cerbera' Millard doesn't see a need

There aren't any concrete plans to add true shadows (although Robert O'Callahan's proposal for applying SVG properties to CSS layouts might be able to do that), but text-shadow is specified for the CSS3 Text module, and box-shadow is part of CSS3 Backgrounds and Borders. Expect both of those to be widely implemented in the near future.

Rounded Corners

Three comments mentioned rounded corners:

• ryan groth
• hawken king
• Simon Fraser wants to clip contents, not just the background, to the curve of the border

Rounded corners is in the CSS3 Backgrounds and Borders drafts as border-radius. I recently clarified the draft to say that setting overflow: hidden clips the contents of the element to the curve of the border.

Diagonal (Bevelled) Corners

Stifu would like a way to define diagonal borders.

Something like a border-corner-shape: round | slant property in conjunction with border-radius would be able to handle this. The tricky part is figuring out what to do when the corner joins two borders of different colors or styles. We could propose this for the CSS3 Backgrounds and Borders module and see if there is any interest from implementors.

Multiple Borders

Stephanie Hobson requested multiple borders:

Multiple borders

The problem

Sometimes we want multiple borders around an element.

Text.

What it might look like

Multiple borders, following the multiple background image model:

    #box{

      border:2px 20px 10px 10px, solid, #fff, #000, #fff799,#aba000;

    }

Or we could have the ability to define a second box around the element dynamically as suggested in comment 31.

#box:outer{border:20px solid #000;}
    #box:outer:outer{border:10px solid #fff799;}

The CSS Working Group discussed this idea and decided not to add it for CSS3. The usefulness of the feature didn't seem strong enough compared to the cost of complicating the border properties. You should be able to use SVG as a border-image to get a similar effect.

Alpha Channel Image Masks

thinsoldier proposes allowing a grayscale image to function as an alpha channel affecting the visibility of an element:

Ability to use a grayscale image as an “alpha channel” to affect the visibility of an element. This could be used in place of create a new .png for multiple things

http://www.facilities.ohiou.edu/cats/images/Bus-Stop-Sign-oval-blur.gif …I know I know I know…… :( “But in the right hands it could be used for good!”

img#mainPhoto {
    alpha: url(/gray/oval.gif)
  }

Use: I have a left column with a photo at the top the fades out towards the bottom to blend into the background color AND TEXTURE of the column. Instead of having to a. save a new .jpg with the photo + blend into texture/color for EVERY photo i plan to use b. save a transparent .png for Every photo I plan to use I only need to save the transparency itself as a greyscale file and reuse it as alpha on the photos on every page.

Sounds like a neat idea. We'll have to see what implementors think. Apple is doing a lot of graphical effects, they might have an opinion.

Filters

Emil Ivanov would like to see filter effects in CSS. Fenring comments that this is available in SVG, and CSS should be able to point to it rather than duplicating functionality.

Robert O'Callahan (Mozilla) seems to have a proposal that should satisfy both constraints: he proposes extending the SVG properties to apply to CSS boxes as well.

Styling Form Controls

Two comments mentioned styling form controls:

• Neal
• Art Clark writes

  When can we start to style form field elements:

  option.item1
  {
  background-image: url(item1.png);
  margin-left: 30px /*white space so that background image icon is visible */
  }

Because form controls are complex and their look is so platform-specific, it is unlikely that the CSS WG will add anything more than the abilities defined in the CSS3 Basic UI module. That module does allow text, border, and background colors to influence the UI: it is up to browser and platform developers to make this possible.

Styling Scrollbars

Five comments mentioned styling scrollbars, with one commenter firmly against.

• Neal writes:

  Ability to change scrollbar colors (I know IE and opera support this, why not just make it a standard, its part of the presentation)

• Andy Budd writes:

  I will cry if we have: Coloured scroll bars

• thinsoldier writes:

  The scroolbar of the main window chrome MUST NEVER BE STYLED.

  However, I strongly believe than any scroll-bar on an overflow:auto element WITHIN _MY_ page should obey my wishes and allow me to style it however I want.

  Use Case: A website for old people with poor eye-sight and motor skills.

  Using a couple scrolling areas on a single page so they don’t have to bother with all the complicated “back button” tom-foolery and style the scroll-bars to be FAT and impossible to miss or have trouble using.

  Also, I’ve seen interesting layouts that had their “artistic vibe” completely destroyed by the OS X shiny scroll-bars. We should be allowed to style scroll-bars _within_OUR_ layouts for visual consistency with the overall appearance of OUR CROSS-PLATFORM WEB-APP.

• Phil Houghton
• Soon-il DDang

Unlikely. It's not a high priority, and most people I've talked with consider this a bad idea stylistically, usability-wise, or both.

Styling Tooltips

Two people suggested styling for tooltips:

• Neal
• Stephanie Hobson writes:

  The problem

  Tool tips may clash with the design of a website.

  Websites designed for low vision users have small tool tips with regular contrast text.

  What it might look like

  A pseudo class to allow styling of tool tips

  img:tip
    background-color:#000;
    color:#FFF;
    font-size:2em;
  }
  
  abbr:tip{
    background-color:#00A;
    color:#FFF;
    font-size:2em;
  }

This is something the Working Group has discussed before, but the discussions didn't really go anywhere. If an implementor is interested and has a proposal that others like, then we are more likely to work on it.

Consistent Default Styles

Several people asked for a consistent set of default styles in the UA style sheet:

• Dave writes:

  Defined defaults for margin and padding on all elements (or perhaps, for all attributes). Right now, CSS authors must use a Reset stylesheet everywhere. If everyone is using Reset stylesheets everywhere, wouldn’t it make more sense to build some foundation into CSS itself? I would further suggest that the defaults aim for “0″ rather than semi-arbitrary “this will make a page look nice when people don’t know what they’re doing. I hate to make CSS3 an experts-only club, but if we try to juggle what experts need with what newbies need done for them, I think we all lose.

• cynglas writes:

  "0" margin and padding on all elements rather than “this will make a page look nice when people don’t know what they’re doing’. The most frustrating case in point is the “collapsing border” model. Ditch it and let the designer set the aesthetic spacing between block elements as they see fit. What we currently have is built-in defaults arbitrarily demanding white space that breaks out of the unless you set an invisible “border” etc. etc. In other words give the end user full control of the layout tools without CSS trying to second guess what is good design. That approach just creates confusion and endless workarounds.

• greg

Several people involved in the HTML5 effort have talked about writing a spec for what CSS should be applied to HTML elements. The CSS spec has a sample style sheet as an appendix, but it's just an example and isn't consistent enough with the styling in real-world browsers to be useful. There's definite interest in doing something like this, but no one's stepping up to do the work. The spec wouldn't be able to reset much to the defaults, though, only to make things consistent across browsers: too many pages rely on legacy default styling for HTML.

Faster Progress

Four comments mentioned faster progress on the CSS standards:

• Rick writes:

  What do I want from CSS3? I’m not really sure. I’m still far enough down on the learning curve for CSS2 that I can’t see what I’m missing or what I’d need/like.

  What I do want from the CSS3 WG is a solid set of deliverables with a clear timeline. No more of this ‘we’ll get to it in about 2010 or so, if my real job doesn’t interfere too much. If it does, then 2030 or so.’ This means the group will have to have enough enthusiastic and committed participants to actually get some work done, instead of the apparent three or four bodies/minds working on the current draft. More people means there needs to more and better leadership, something that currently is missing. And something that is hard to come by.

• Jens Grochtdreis writes;

  I hope for CSS3 in the near future. Please make an end to the discussions and finalize the now known CSS3. THEN go straight on and work on CSS3.5 or CSS4. And finalize this work within two years. Don’t hear our pleas for new functions in the next version. Just do it. Just make an end to the discussion.

• Andy Budd writes:

  But mostly I would like the CSS-WG to finish what they already have without adding more features. CSS4 anybody?

• Dwight L. Stegall writes:

  It doesn’t matter to me what you put in it. But I really don’t want to wait another 7 years for you to implement it. I’d like to use it sometime before I die. It’s time to stop dragging your feet and finish it. :(

I think I'll let the new WG chairs address this point. :P They're doing their best to get things completed.

Avoid Duplication

Four comments discussed duplication of functionality across different web standards:

• David Storey writes:

  I see a lot of requests to do things in CSS that can already be done in SVG. That is an issue for a couple of reasons: a) most web developers don’t know much about SVG and b) most major browser engines have already implemented something that will do what web developers are asking for and c) If they are added to CSS it bloats the browser engine as it has to be implemented twice if the engine is to be CSS and SVG compliant.

  As the things that are often asked for (gradients, rotation, text following paths, animation) are often fairly trivial to do in SVG (I’m in the process of writing one or two articles showing how easy it can be), then I’d propose that either CSS allows SVG to be attached to it or used inside CSS (this may be difficult as CSS isn’t XML), HTML elements can be selected from inside SVG (much like foreignObject, but just selecting that HTML element instead of actually including the HTML in the SVG file - or including SVG in the HTML file), or for a subset of SVG, have a CSS syntax that can be used to apply that SVG. The first two would be more powerful as you could do anything SVG does, while the last would be easier as it would be transparent to the designer, and they’d just need to learn a new CSS property for each new functionality. For the later to work it would have to take in the same arguments as SVG, or just allow a subset of what the equivalent SVG would do.

  For things like gradients, it is very easy to use the SVG as it is at the moment. Just create a SVG background-image. You can even specify the colour of the gradient using the SVG extensions to CSS. For rotation and animation it is more tricky. If you want to rotate a HTML element, it can’t be done directly. You have to either wrap the HTML is SVG in the XHTML file (it has to be XHTML, as HTML isn’t XML) or include the HTML in the SVG file. To me this isn’t good enough as you are mixing content with style. You can most likely do it with scripting of course, but this isn’t ideal. Allowing SVG to be attached by CSS or being able to select HTML elements in a SVG file would solve this. If you can do this already then I don’t know how to do it.

  This is not all directly relating to CSS or the CSSWG, but as they are being asked to add quite a few stuff that is already possible, they should perhaps work with the SVG WG to this stuff to be easier or allow both standards to work together better.

• Gérard Talbot writes:

  Above all, what CSS 3 must ... avoid duplicating what is already defined, covered and addressed by other specifications. E.g. text-path is already covered by SVG

• Ben 'Cerbera' Millard writes:

  Main things from my perspective as an author are ... avoiding a proliferation of features which all do very similar things in CSS3;

• Fenring writes:

  But I’m more concerned about HOW you will implement these features. Will you add yet another way to do things we already do? Please don’t. I agree with David Storey. ...

Define the undefined

Gérard Talbot wants us to focus on defining the ambiguous and the explicitly undefined parts of CSS:

The first thing CSS 3 should do is clarify or specify or define the obscur points and issues remaining as such and stated as such in CSS 2.1. One can easily find some 20 of those points just by running a text string search for “undefined” (or “future” or “later” or “unspecified” or “unknown”, etc) in the CSS 2.1 sections of the specification.

We've codified this as the Markus Principle.

Test Suites and Interoperability

Another two people want to prioritize test suites and driving interoperability on existing functionality:

• Arjan writes:

  I currently have no cool features, but I find it very important the CSS3 WG also provides proper test suites. If there are test suites, user-agents that want to implement (parts of) CSS3 can easily test if they’ve implemented it right.

  At this moment no browser fully supports CSS2.1. I think that’s because there is no good test suite for it. I don’t think many people want a repetition of lots of time waiting for good implementations.

• Ben 'Cerbera' Millard writes:

  Widespread implementation of the useful things CSS2.1 defined years ago. ... CSS2.1 defines a lot of really useful things. If only implementation was widespread.

  Tabular values of the display property would help with ease, accuracy and robustness of layout ... We shouldn’t need brain surgery for this effect! Tabular display ftw.

Performance Barriers

Brad Kemper argues for considering designers' desired functionality over expected performance obstacles, pointing out that designers are already starting to use JavaScript to make up for missing native CSS functionality:

... In other words, “tell us what you need, and we will tell you why we refuse to implement it, despite popular demand.” ... Effects on incremental rendering should be just one consideration; they should not override all other considerations.

What does it do to processor usage or incremental rendering when authors start turning to huge JavaScript libraries to accomplish what the CSSWG steadfastly refuses to provide? (JQuery, for instance, has many more pseudo-classes and pseudo-elements than CSS does, including parent selectors, and authors can use it to select elements and add style to them.) The result of using JS for basic styling is that the page takes longer to load, and the styling does not finish rendering until after the page load is already otherwise complete (not to mention all the other problems associated with relying on a scripting language to do styling).

Yet authors will use such complex work-arounds in order to achieve the designs that they want, rather than limit themselves to the designs that the WG engineer-types and design-hostile-types are willing to consider as valid efforts. Even basic things like centering often require extra markup, more complex rules to achieve, and sacrificing layout liquidity. Yet this is somehow considered preferable by the CSSWG than to, say, allowing authors to position an element by its center instead of just by its edges.

The same sort of situation occurred in the 90s, when authors were told by the HTML purists that style and design were not important, and that authors should not try to make Web pages resemble other visual media. Well, the designers and their employers disagreed, and they discovered unsanctioned ways to wrest more design control into their pages than what the HTMl wonks considered appropriate. Thus were born invisible tables and transparent, single pixel GIFs as a layout tool and as a means for creating borders, padding, and margin. “Font” tags and the various “table” tags started to account for the vast majority of the markup on any page.

It was these excesses of HTML abuse that directly lead to a recognition of a need for CSS, to get all that extra markup out of the html and into shared, style-centric files. Now authors are turning to JavaScript, complex twisting of CSS rules, and multiple embedded Flash files in order to be able to achieve the creative freedom that CSS can’t quite handle. Although the working group asks for designer feedback, the design freedom that designers care about most is never considered as important as “incremental rendering” or the anti-designer rhetoric that is allowed to drown out all other voices in the mailing list.

Statistical Surveys

Ron Wenton suggests using statistical techniques and survey existing existing sites to see what functionality web authors need.

Take a tip from HTML5 here and see what they are doing. They look at *what is the common things out there that has no markup*. column to replace floating div, menu to replace ul’s with CSS fixes, and so on.

It's a good idea, and I'm sure that if the CSSWG received a report detailing e.g. common design archetypes and how they should relate to the markup, we'd take a serious look at it. But I'm not sure how we'd go about soliciting such a report. Maybe WASP could spearhead such an effort.

Ease of Use

Two commenters want CSS to be easier to use to achieve the designs authors commonly desire:

• Emil Stenström
• Ben 'Cerbera' Millard

Community Liaison

Eric Meyer suggests assigning one person to do community outreach, to function as a liaison between the Working Group and the design community.

Any volunteers willing to donate their skills and time (and willing to try to follow hours of extremely technical discussion for the purpose of understanding and explaining its effect on the average web designer)?