(Past being the operative word.)
First, note that the W3C have released a document listing various suggestions for future versions of CSS. There is some overlap with this document, but not all suggestions on the W3C document are noted on this page, and vice-versa.
Note also that this page is woefully out of date, and I am not likely to update it any time soon. Most of the content uses obsolete markup and might not even validate, who knows.
Finally, note that there are various things I do not add to this list. They are mainly either things which are better done using scripting or XSL (such as content reordering), things which can already be done, or things which are plain silly (for example, I wouldn't include a suggestion that CSS should be able to cook nettle soup, however useful that may be).
Here are ideas people have mentioned or suggested on the www-style mailing list.
The list is now sorted roughly into seven categories:
tooltip property This idea is makes use of a tooltip property to
change the content of the "bubble help" tooltips that appear above
elements when the mouse is allowed to hover for a short time. Using a
property instead of a pseudo-class as was originally suggested makes
it easier to implement and leads to greater consistency for the UA's
interface (a pseudo-element would do things like let you set colours
for tooltips, which is probably not the most user friendly thing
possible). To go with tooltip, the status property would have it's content
drawn in the status line area.
The tooltip and status properties would
take the following values:
none | auto | [ attr(x) || string ]+ | inherit
And the default would presumably be:
* { tooltip: attr(title); }
[href] { status: "Link to " attr(href); }
(Improvement suggested by Christian Kaufhold.)
Originally mentioned by Bert Bos as an example of how the style sheet spec could go too far, I considered it to be an ideal suggestion. The advantages are actually numerous:
This generated a lot of feedback. The field was roughly split into two parts. Some said they thought it would complicate it too much, I disagree since no one is forcing style sheet authors to use regexp. Furthermore, Bill explained that implementing regexp in applications was not terribly difficult and that he has done it many many times on many different platforms.
At the last count, 10 people were for and 10 against (although
there was less enthusiasm from the "for" camp near the end
of the discussion). I have suggested a compromise, whereby regexp are
added to the spec but flagged as an optional sections, like
:first-line, which implementors do not have to
program to claim CSS3 compliance. This is because most implementors
(including Chris Wilson of Microsoft and Sho Kuwamoto of
Macromedia) said that they wouldn't write support for regexp, at least
not in their second generation parsers/renderers.
Regexp would allow for colouring links based on parts of the uri, for example.
An extension of this idea, first seen on the NOTE-CSS-potential page, is to allow the simple selector to have a regexp brother too.
Examples:
/H[1-6]/ { font-weight: bolder; }
A[href/="^http://.*"] {
padding-right: 16px;
background-image: url(offsite.png);
background-position: center right;
}
[class/=".+"] {
font: inherit ! important;
color: inherit ! important;
background: inherit ! important;
margin: inherit ! important;
padding: inherit ! important;
border: inherit ! important;
}
Where "/" is used to indicate a regexp search, and where the background-position property is allowed to apply to inline elements (suggested below).
The first makes all headers bolder. The second adds an icon to absolute links (presumably offsite ones). The third removes many of the most visible properties on any elements with a class.
An idea from Daniel Glazman.
Newspapers often print bigger the first letter of a paragraph, the following characters floating on the right (or left for some non western scripts) of the first letter. The :first-letter pseudo makes it possible in CSS. But newspapers also often use a size of font for the lines floating at the right of this first letter which is not the normal size of the paragraph. The National Geographic Magazine for instance uses extensively this feature (see article on Denmark in July [1998] issue for instance). This for the moment impossible in CSS which only allow access to the :first-line of a paragraph. What about :first-lines(n) or :floating-lines?
:first-word pseudo-elementSuggested by Tim Baggot, to complement :first-letter
and :first-line.
This was quite a long thread, which you can read here. The conclusion is at the bottom of the file. This idea has since then resurfaced quite a few times.
Here are some examples to make it clearer, in order of clarity (clearest first):
FORM:matches(BUTTON[onclick]) INPUT[type=submit]
{ display:none; }
/* Hides INPUT element of type submit when there is a BUTTON
element with an onclick handler in the same form. */
BASKET:matches(APPLE):matches(PEAR):matches(BANANA):before
{ content: "Basket contains all three types of fruit." }
BODY:matches(BLOCKQUOTE P IMG.signature)
{ status: "This page contains a signed document" }
/* Uses another CSS3 suggestion to change the status line text
of documents containing 'signed documents'. */
GARDEN:matches(TREE:matches(BIRD) + TREE:matches(CAT)) SIGNPOST:before,
GARDEN:matches(TREE:matches(CAT) + TREE:matches(BIRD)) SIGNPOST:before,
{ border: red double; content: "DANGER!"; display: block;
text-decoration: blink; }
/* Posts a warning if a cat in a tree is adjacent to a bird in a
tree. */
Later discussion discovered that the suggestion could be expanded to allow a sibling or child selector to precede the entire expression. For example:
SEA:matches( > FISH[size=small]) SIGNPOST:after { content: "Still some live small fish"; }
/* Would not match a SIGNPOST in a SEA that contained only FISH with size=small inside
other FISH of size=big. */
H1:matches( + P) { margin-bottom: 0; } /* decrease margin on H1s before Ps */
Original Text:
I
think that CSS should have a pseudo
Author: Russell O'Connor.element class for elements that
have an ID of the fragment
identifier of the current URL. So if I follow a link to a specific
paragraph in a piece of text, then that paragraph can be
highlighted.
This was liked and will probably appear in CSS3. Suggested names
were :youarehere, :target, and
:fragment.
:access-key pseudo-element An :access-key would highlight a part of the
content of the HTML4's LABEL element. (suggested by Liam
Quinn)
Negated pesudo-class or attribute selectors would be used to
match on the lack of a match. For example, the absence of an
attribute, or the fact that the element is not
:focused.
An idea from Daniel Glazman. Note - IMHO, this could be better done by regexp matching the HREF attribute, as per the suggestion above.
I'd like to be able to give different styles to anchors depending on the fact that the link is local to the current document or not. Example: different cursors. A pseudo-class valid for links ':local-link' or ':no-cx-link' (no connexion) would be just fine... This is also very important for printed documents' readability.
George Lund said that it would be useful to have a CSS property (or an existing one could modified) that determines whether an underline is applied to spaces between words or not. Other people have mentioned that it would be nice to have different underline styles (double underline, squiggle underline, and so on).
Nicolas Lesbats proposed a new value for the
font-style property, named toggle by Daniel
Glazman, which would have the following behaviour:
This would allow a simple, user-stylesheet proof, method of emphasising text. A typical rule:
cite { font-style: toggle; }
David Baron suggested that some properties should exist to control the minimum and maximum computed font sizes.
Sjoerd Visscher suggested
the background-size property. If a background image
has been specified, this property would specify its size. This can be
used to stretch images (eg, by giving a size of 100% 100%). It can
also be used to make the image tile four times, for example (50%
50%).
Eric Meyer suggested
that the background-repeat property take four new
values: repeat-up, repeat-right,
repeat-down, and repeat-left.
David Baron suggested
on www-style that the background-attachment property
should also have a way of fixing with respect to the parent of
elements, for cases where the content can scroll (in addition to the
current options of either scrolling with the content or being fixed
with respect to the viewport).
An idea from Daniel Glazman.
The border of a block is defined in CSS by four edges: top bottom right and left but there is no way to access corners. If you want to make a text look like...
------------ | Hello there, | | what's up? | ------------...removing the four corners, you nowadays have to use a table. There is also no way to use rounded corners for instance. What about new properties for corners? Used in conjunction with CSS2 visual effects (dynamic outlines for instance), it would be just great!
Braden N. McDaniel suggested the possibility of introducing a
new notation for color: hsv(). (His suggestion is
around mid way through, in a set of brackets.)
MWhisman also suggested CMYK (cyan, magenta, yellow, black) and HLS (hue, luminance / lightness, saturation) colour models, as well as a way of declaring new colour names within a style sheet. He also asked for tint (x% of a base colour), shade (100% of a base colour + x% black; note: subtract black% if in RGB), and transparency properties, amongst a great deal of other mainly print-related colour options. See his main suggestion.
Braden N. McDaniel suggested the possibility of introducing alpha values for color, that is, partial transparency.
white-space: nocollapseIt
was suggested that an additional keyword be added to the
white-space property, namely, nocollapse.
This value would prevent user agents from collapsing sequences of
whitespace, as for 'pre', but lines would be broken as necessary to
fill line boxes. Additional line breaks could be created by
occurrences of "\A" in generated content (e.g., for the BR element in
HTML).
See also the suggested minor change white-space.
Daniel Glazman suggested some properties analogous to the
page-break-* properties, but for line breaks.
Note. Content Reordering is the realm of XSL, and suggestions of that sort will not make it to this list.
Steffen Gldner and Holger Maier submitted a quite comprehensive suggestion for how CSS could be used to specify the format of data (numeric, boolean, datetime, and so on) in documents.
This is quite a complicated subject, so here are various excerpts from posts on the subject:
Will CSS3 offer a way of refering to another elements counter? I need to mention an image's caption. This is how I would mark it up (I've used an imaginary XML language since I can't see of any way of doing this in HTML4):
<IMG SRC="apicture.png" ID=thepic/> <PARA>Here we discuss the points raised in <REF REFID=thepic/>. There is nothing special to mention.</PARA>Using the following style sheet:
PARA { display: block; } IMG { float: left; background: url(attr(SRC)); counter-increment: figures; padding: 10px; } IMG[SRC="apicture.png"] { width: 200px; height: 200px; } IMG:before { content: "Fig " counter(figures); } REF:before { content: "figure " proxycounter(attr(REFID), figures); } /* proxycounter is the only addition here, all the rest is valid with CSS2-REC.... with the possible exception of "background: url(attr())", which is suggested below. */Would hopefully make something looking like:
+----------+ Here we |*Fig 1 ** | discuss |*** ***| the points |**** ****| raised in |**********| figure 1. +----------+ There is nothing special to mention.
That's what I originally said. Bert Bos then wrote:
I hope so. This is on my list under the general notion of cross-references. They may refer to counters, but also to page numbers ("see equation 6 on page 23" or "see equation 6 on this page")
Garth Wallace then added his views, and the list of possible ways of addressing an element grew to the following (this is not an exhaustive list):
An idea from Daniel Glazman, closely related to the Cross Reference idea above.
if a document contains a local anchor
<A HREF="#toto">..</A> ... <A NAME=toto>..</A>There is no simple way to print it and keep track of the link between the two anchors. I'd like to be able to print just after the source of the link the page number of the target of the link, or add a counter information before the named anchor and a reference to this counter value after the href anchor.
This would greatly increase the readability of a printed document.
An idea from Daniel Glazman.
CSS 2 allows to retrieve the value of an attribute carried by the selected element of a rule. I'd like to be able to retrieve the value of any attribute carried by any element of the document. (I know that this influences progressive rendering. But I want it!)
[I presume other elements would be referred to by id. Reference to elements relative to the current element leads to extremely complicated syntax. - IEH]
Discussion on www-style resulted in the following
extended syntax for the content property:
<uri> := "url(" [ <string> | attr(X) ] ")"
<replaced> := "replaced(" <string> | attr(X) ] ")"
<text> := [ <string> | <counter> | attr(X) |
open-quote | close-quote |
no-open-quote | no-close-quote ]
content := [ [ [ <replaced> | <text>* <uri> [ <text> | <uri> ]* ] , ]*
[ <text> | auto ] ] | inherit
The suggested content property syntax takes a series
of uris to be used as replaced content and mixtures of uris and text
which would flow as the content property defined in CSS2.
Each item brought in as replaced() should be used as a
source file for making the element into a replaced element.
The UA should try to display each of the given possibilities in turn until it finds one that has all referenced uris (if any) (a) available and (b) supported. The keyword "auto", which is allowed as the last item in the comma separated series, indicates that the UA should display the contents of the element, if any.
The "simplest" way of resizing each of the contents individually would be to allow comma separated values for width/height, each applying to the respective entry in the content property that is used. If there is no entry in the width/height list then "auto" would be used (going the other way doesn't matter, since height/width is decided based on content, not the other way around).
Examples:
IMG { content: replaced(attr(src)), attr(text);
width: attr(width), auto; height: attr(height), auto; }
OBJECT { content: replaced(attr(data)), auto; }
IFRAME { content: replaced(attr(src)), replaced(attr(longdesc)), auto; }
#TITLE { content: replaced("welcome_and_logo.mov"),
replaced("welcome_and_logo.jpg"),
"Welcome to " url(logo.gif) " !!",
"Welcome to CSS!!";
width: 256px, 300px, auto;
height: 64px, 80px, 58px; }
Note, when height and width are given but there are less heights/widths than contents, missing values are assigned "auto". Note that when height/width are *not* given, then the cascade may give them a value anyway, and so "auto" might not be assumed.
If the height and width properties are
set to specific values (not auto), then:
If the content has an inherent size then the box should be resized and the contents should be scaled to fit the box. For example, images (bitmapped or vector).
overflow property.If the height and width properties are
set to auto and the replaced content does not have an
inherent size, such as a vector graphic, then the results are (for the
moment) undefined by this suggestion. Also, some types of replaced
content need scaling that preserves the aspect ratio - video for
example, see the SMIL spec and the Note on SMIL and CSS.
Eric W. Sink suggested a way of describing page layout (columns, frames, reflowing, etc). The full text is rather long, so instead of inadequately summarising it here, I suggest you read the original article from the www-style mailing list archives.
An idea from Daniel Glazman.
The @page at-rule allows to create named pages. If two contiguous blocks belong to two different named pages, a page break is inserted in the flow.
I'd like to be able to define named pages that are extracted of the normal flow sent to the printing engine, and sent to this engine after the print of the normal flow. Then the following sheet :
@page normal { size: 19cm 27.7cm } @page toc { size: 19cm 27.7cm } @print { H1, H2, H3, H4, H5, H6 { pages: normal, toc } }using a property 'pages' defining on which page(s) the element has to be printed, will automatically generate a table of contents...
An earlier CSS2 draft had headers and footers, but was removed from the final specification. There are a couple of implementations (Lotus eSuite, Intranet Writer) that define CSS extensions for h&f. These needed to be evaluated and there just wasn't time to do so (ie the functionality was too late to make it into the final CSS2)
I wonder whether there are tabulators in CSS current spec or it is planned for the future spec versions? Under tabs I mean some entity that has a set of numbers (like a rule) and can be adjusted with respect to user needs.
E.g.:
TAB { tab-example: 1cm 2.5cm 5cm 10cm }Thus data delimited by corresponding tag (namely
<TAB/>) will be located at specified positions:a<TAB/>b<TAB/>c<TAB/>will result in:
a b c ....
The ability to link multiple declarations so that if one is overruled by a later (or eariler!) rule in the cascade, then all related declarations are ignored too.
The challenge is to simplify a stylesheet like the following:
P { color: black; background: white; }
Q { color: black; background: yellow; }
P A:link { color: blue; background: white; }
P A:visited { color: navy; background: white; }
Q A:link { color: blue; background: yellow; }
Q A:visited { color: navy; background: yellow; }
...so that there are only four rules, but without compromising the 'safeness' of the rules. In other words, one cannot simply make it:
P { color: black; background: white; }
Q { color: black; background: yellow; }
A:link { color: blue; }
A:visited { color: navy; }
...since with this sheet we are faced with the possibility of another
stylesheet in the cascade applying a background to the A
element, and making the document unreadable.
Similar problems occur with table elements, italics on nested elements, and the counters in CSS2. These problems have been often discussed on www-style, see the archives for more details.
The current "solution" is for authors and users to be responsible in their authoring...
CSS allows CDC (i.e., -->) delimiters in CSS.
However, in HTML, CDC can have whitespace between the dashes and the
angle bracket. This post suggests that the CSS grammar be
relaxed to allow this in CSS as well.
I suggested that the root element rules forbidding positioning and floating the root element be removed. Read the complete post for more information.
style attributeDavid Baron suggested that the specificity of the
style attribute be increased to 1000 instead of 100.
Read the
complete post for more information.
font-size-adjust propertyDavid Baron has pointed out some problems with the
font-size-adjust property and has suggested some suitable
changes that would correct them.
Read the
complete post for more information.
It has been suggested to allow more than one pseudo-element at the end of each selector.
Consider the following (technically illegal) code:
P:first-letter:before { content: "[" }
P:first-letter:after { content: "]" }
This could surely come in useful, but is not currently allowed if
we follow section 5.2
(One
pseudo-element may be appended to the last simple selector in a
chain
) - only one pseudo element is allowed per selector. If it
was allowed, it should simply insert square brackets around the first
letter of every paragraph. The selector "P:before:first-letter" might
be more even useful, if it applies to the first-letter of the inserted
content.
This suggestion was rebutted by Bert Bos and Daniel Glazman
for being too complicated to consider
.
It has also been suggested that pseudo-classes be allowed after
pseudo-elements, allowing selectors such as
:before:active.
background-position' - allowing inline
levelCurrently background-position applies only to block
level elements. It has been suggested that it should apply to
everything. An in-depth but short discussion on this topic cleared up
the potential problems. See messages
One,
Two, and
Three
of this thread for more details.
A discussion on which properties should apply to the root element of the document and how to actually access this root element briefly played through on September 30th, 1998. You may wish to read it, although no very clear consensus developped.
@page in @mediaCurrently this is not allowed, at least, according to the grammar. There were no objections to allowing this. For example:
@media print
{
@page { margin:3cm; size:landscape }
h1 { page-break-after:avoid }
}
white-space: nowrap to inline blocksCurrently, whitespace only applies to block-level elements. It has
been suggested that the nowrap attribute of this property
be made to apply to inline elements too.
See also the suggested extension to white-space.
url() notation to
accept nested attr().This was first formally suggested at the same time as a technique for specifying replaced content, but actually people have been assuming that this should be allowed for a while now. The following is an example of how this could be used:
PARA { background-image: url(attr(HREF)); }
The slab-serif and hand-script
families have been suggested as additional generic font
families.
David Baron has done much work in the field of suggesting improvements to the floating element rendering rules.
Posts of note are:
line-height rulesDavid Baron also suggested changes to
line-height's definition.
The three posts of note are:
I have pointed out some apparent anomalies regarding margins around CSS tables, however there have been no comments on this.
The border properties cannot be set by percentage. It has been suggested that this should be allowed.
In a post to www-style, David Baron gave a comprehensive treatment of problems with CSS2's vagueness regarding scroll bars. Here is an extract:
When CSS2 defines the overflow property, it doesn't specify where the scrollbars, if used, are to be placed. [...] I think the scrollbar should be placed between the border and the padding (on the appropriate side, which depends on whether it is horizontal or vertical and possibly on the direction of the text) so that the padding edge, rather than touching the inside of the border, touches the scrollbar.
The following posts mention errors in CSS1 and CSS2 that have not yet been corrected or noted in errata documents.
If you are a member of www-style and cannot see your suggestion in the list above, please feel free to tell me about it. I probably missed it!