CSS WG Blog front page
Resolutions 2008-01-08
-
Resolved: CSS2.1 Issue 19 (case-sensitivity) proposal accepted, issue closed.
-
Resolved: Agreed to spec Firefox 3’s behavior on this testcase to resolve CSS2.1 issue 27. Still need wording, though.
-
Resolved: Agreed to publish on the website a list of individual members of the CSSWG. This will be opt-in, so anyone who doesn’t want his/her name published or who isn’t paying attention won’t be listed. List will include name and affiliation.
- The paged media draft is getting close to another Working Draft or Last Call Working Draft publication. The next version will include many changes that make things more specific.
- The CSSWG charter and centering were added as topics for the March F2F.
- Apple’s animations and transitions proposal is out-of-scope for the current charter, but Apple can use our public space to make progress for now. (The current charter expires this year.)
- Several open issues for CSS2.1 still need proposed text to move forward.
Discuss on www-style
Signal to Noise
Some people seem to think that Opera’s recent legal action against Microsoft will cause relations in the CSS Working Group to deteriorate and thereby damage our group’s ability to function. But neither Håkon Lie nor the Microsoft reps foresee any problems working together because of Opera’s antitrust complaint.
From Alex Mogilevsky (Microsoft):
As far as Microsoft is concerned, I have not received any instruction to change my participation in W3C in any way because of this or any other lawsuits. Personally, I love working with Håkon and all CSSWG members… whatever Opera’s intentions are, I can’t imagine it involves not being interested in working together on a standard that is worth implementing. I am certainly interested and plan to keep doing that, to the best of my abilities and any time that I can afford to invest.
From Håkon Wium Lie (Opera):
You are absolutely correct. I very much enjoy working with Microsoft representatives and would like to continue doing so. I also hope the work will result in better standards support in IE.
David Baron on Designing CSS
I thought David Baron’s reply to Andy Clarke’s recent speculation was extremely well-written and had a lot of important things to say about the CSS Working Group. I believe most of the working group members would agree with his statements. I’m quoting it here so more people can see.
I disagree with the claim that browser developers only want small improvements in standards. Many of us—particularly those of us whose interests are aligned with seeing the Web as a successful platform—want both small improvements and big steps forward.
We want small improvements in the details of the spec because we get complaints every time something works differently in different browsers, and we need something that says who’s right and who’s wrong, and a forum to discuss the issue when the existing spec isn’t clear. This lets us actually improve browser interoperability rather than each hiding in our respective corners and saying “the spec isn’t clear, and *our* way is better.” This refinement doesn’t stop: as standards become more mature, authors expect more precise interoperability, because *somebody* is always pushing the edges of what can be done with any heavily used Web technology.
We also want big improvements too. We want these so we can make the Web a better place for users and a better place for authors to reach those users (easier for authors to produce content, easier for *more* authors to do so, etc.). Building entirely new capabilities into standards is a lot of work. Going from “we want to be able to do X” or “we want a better way to do Y” to having the best way to do X in place and usable by authors is a lot of work. First, you need to figure out what exactly the best way to do X is, where best is determined by how easy it is for authors to use, how good the result is for users, and how long it will take to get that result in place (spec writing and implementation). There are lots of hard trade-offs involved. Then you need to write a spec, and (if you want interoperability) a test suite, and then (if you succeed in getting implementations) you need to continue through many cycles of the refinement process I described above.
As Mozilla’s representative to the CSS working group, and one of a relatively small number of active people on the group (although not as active as some other people), I find all the things to do here overwhelming. There’s a long list of things that I think the CSS working group should do immediately, but I just can’t do all of them. Given that standards work is only a part of my job (currently, at least), I often don’t have time to do any of them.
I strongly agree that the group should become more public and try to change so that it is welcoming to contributions. That said, potential contributors need to understand that developing a successful spec is hard work and might not be quite what they expect. And I don’t think trying to kick the browser makers out will help you any—you’ll lose a lot of expertise about existing specifications *and how they interact with each other*, and you’ll find it harder to get implementations of specs whose design didn’t take cost of implementation (and thus time-to-wide-deployment) into account.
CSS Drop Shadows
I’m working on the CSS3 Backgrounds and Borders module with Bert Bos, and
I’d like to start a new Q&A series because I think we need some help: This
time I’ll ask the questions, and you give me answers. Ok? 🙂 Since the CSS
Working Group Blog currently doesn’t accept comments, CSS3.info and W3C’s
Karl Dubost have kindly allowed me to cross-post so that you can write
back. The first issue is a complicated one, so I’ll start with an easy
question. The topic is drop shadows.
In the latest public working draft we have a box-shadow
property. The point is, obviously, to be able to draw a drop-shadow for a
CSS box. It starts to get complicated once you ask “what happens when there
are semi-transparent parts of the box?” At first we figured ‘box-shadow’
should just draw the shadow as if the box was opaque. Then Dave Hyatt, who
had started implementing this, started questioning that logic. We’ve got
proposals for a ‘border-shadow’ property to shadow just the border and a
‘background-shadow’ property to shadow just the background color (but not
the image?), etc. We could also just “shadow everything drawn in this element”.
This all sounds rather complicated to me so I want to step back and ask:
What do you, the web designers of the world, want to do with shadows?
What’s the end result you want to get?
Show me. Post a few links to stuff from your portfolio that uses anything
beyond pure text shadows, even if it’s all done with pure Photoshop(/Painter/GIMP)
graphics. Draw (or explain) a picture of what you want to achieve. Then
maybe we can figure out how best to make it happen in CSS.
Discuss on www-style,
CSS3.info, W3C Q&A.
Case-Insensitivity in CSS
Case-insensitivity in CSS is currently not precisely defined. The meaning of “case-insensitive” is pretty obvious in ASCII, but it’s not so obvious in Unicode. Some characters map differently based on the locale, some characters can’t round-trip a case mapping operation so you get different matches depending on whether you map to lowercase, uppercase, or “case-fold” case, etc.
There was a recent discussion about this problem on www-style. Martin best summarized the problem and its constraints in his message on November 8th.
There are two issues here:
- What the case mapping should be for CSS-defined identifiers such as property and keyword names.
- What the case mapping should be for user-defined identifiers such as counters and page names.
For the first issue, since CSS-defined identifiers only use characters
in the ASCII range anyway, ASCII case-insensitivity would be sufficient.
It would also prevent strings containing characters outside the ASCII
range from unexpectedly matching CSS keywords (which could cause
security problems).
For the second issue, we could adopt the Unicode case-folding algorithm,
which is at least well-defined. However a test shows that
implementations already treat counter names as case-sensitive. This is
interoperable across all four major CSS counters implementations:
Firefox, Opera, Safari, and PrinceXML (an HTML/XML + CSS -> PDF
converter).
Also because it’s much more straightforward than case-insensitivity in
Unicode, case-sensitivity is more likely to be interoperable going forward.
The downside is that case-sensitive counters could be more confusing for
authors used to case-insensitive CSS.
The CSS Working Group proposes to adopt the following changes:
- “All CSS style sheets are case-insensitive” -> “All CSS syntax is case-insensitive within the ASCII range (i.e. [a-z] and [A-Z] are equivalent)”
- “Counters are denoted by identifiers” -> “Counters are denoted by case-sensitive identifiers”
These would
- Define case-insensitivity of CSS-defined identifiers as ASCII
case-insensitivity: i.e. a-z and A-Z match, but no other
characters outside that range will ever map into that range.
- Define counter names as case-sensitive in CSS2.1, which would
also set case-sensitivity as the precedent for user-defined
identifiers introduced in future specs.
Unless there are objections that cause us to reconsider, we plan to
formally resolve this issue on 8 January 2008. Please send any comments
before then.
Discuss on www-style
Resolutions 2007-12-11
CSS2.1 Issues
Discussed CSS2.1 Issue 19 (case-sensitivity in CSS) and resolved to adopt the proposed changes on January 8th unless there are objections.
CSSOM Views
Anne van Kesteren is preparing the CSSOM View specification for publication as a First Public Working Draft.
Media Queries Syntax and Parsing
Spent a lot of time discussing the issues Anne van Kesteren and
Henri Sivonen have brought up recently. CSS parsing involves a
lot of things that we’re not sure should be part of media queries
as used in other languages (e.g. in HTML’s media="...".
Issues include:
- Differing interpretations of “white space”
- CSS comments: are they allowed in media queries outside CSS?
- CSS backslash escapes: are they allowed in media queries outside CSS?
- Should parsing media queries outside CSS match parentheses and quotes when parsing invalid queries?
- Should parsing media queries outside CSS append closing parentheses and quotes when parsing incomplete media queries?
Anne has started a discussion on www-style to come up with proposed text, so reply to his messages if you’ve got comments!
Resolutions 2007-12-04
CSS2.1 Test Suite
We discussed the CSS2.1 test suite today, particularly how to incorporate Ian Hickson’s tests and Microsoft’s tests into the test suite. Arron (Microsoft) and fantasai (HP) will be working together on that project.
Licensing was brought up: the HTMLWG recently adopted the MIT license for their tests, whereas the CSS tests are currently licensed under the W3C Document License. We could relicense the tests or license new tests under the MIT license if necessary, but we’re not sure if that’s needed. If you have any thoughts on that, please post to public-css-testsuite@w3.org or otherwise contact a member of the CSS Working Group.
Directing People to CSS2.1
- Resolved: Republish CSS2.1 with REC-CSS2 as an additional “Previous Version” link.
- Resolved: Point
/TR/CSS2 to CSS2.1.
- Resolved: Republish REC-CSS2 with the following paragraph added to the top:
<p style="border: solid thick red; padding: 1em"><strong>
Note: <em>This paragraph is informative.</em>
This document is currently not maintained. The CSS Working Group is
developing CSS Level 2 Revision 1, which corrects many errors and
omissions in this document as well as making a few other changes as
documented in the changes section. The CSS Working Group encourages
authors and implementors to reference CSS2.1 instead of this document
and when features common to CSS2 and CSS 2.1 are defined differently
to follow the definitions in CSS2.1.
</strong></p>
This text makes no changes that affect conformance to REC-CSS2, so should qualify as a Class 2 Change under the W3C Process.
- Resolved: Republish REC-CSS1 with the following paragraph added to the top:
<p style="border: solid thick red; padding: 1em"><strong>
Note: <em>This paragraph is informative.</em>
This document is currently not maintained. The CSS Working Group is
developing CSS Level 2 Revision 1, which has much more precise and
Web-compatible definitions of the features described here. The CSS
Working Group encourages authors and implementors to reference CSS2.1
instead of this document and when features common to CSS1 and CSS 2.1
are defined differently to follow the definitions in CSS2.1.
<strong></p>
This text makes no changes that affect conformance to REC-CSS1, so should qualify as a Class 2 Change under the W3C Process.
- Resolved: Create
/TR/CSS and point it at the CSS2.1 spec, which is the latest and most mature CSS specification. (In the future it will point to the latest Snapshot.)
Box Module: the horizontal centering problem
CSS level 1 introduced two ways to center things horizontally: the
‘text-align’ property centers each line in a paragraph
individually, and ‘auto’ values on the left and right margins of a
paragraph center the paragraph as a whole. People sometimes have
trouble finding the margin properties the first time they are
looking for a way to center a block, but the auto margins fit well in
the box model.
Unfortunately, when we revised CSS level 2, we discovered that many
browsers imposed a limit on what could be centered. In particular,
centering something that was wider than its containing block didn’t
work. The reason, probably, was that the browsers’ scrollbars
were programmed to grow to the right, but never to the left. (See the
illustration.)
The effect of centering with auto margins.
Indeed, seeing that the majority of implementations had this bug, we
decided to declare it a “feature” instead.
But that means that CSS no longer has a way to center blocks. The
auto margins only work if the inner block is narrower than the outer
one. So how should CSS center all blocks?
- Add a new property ‘alignment’ with values ‘center’ and
‘auto’.
- Ditto with values ‘center’, ‘auto’, ‘left’ and
‘right’.
- Add a keyword ‘any’ to ‘margin’, which is like
‘auto’, but without the size restriction on centered blocks.
The first option complicates the box model, but works reasonably
well with old implementations. If you want to center a block, you can
use: ‘margin: auto; alignment: center’. An
implementation of level 3 would see ‘alignment’ and ignore the
‘auto’ keywords. An older implementation would ignore
‘alignment’ but would still center most boxes.
The second option gives users a single property for all alignments,
but makes the already complex box model even more complex.
‘Alignment’ ignores certain auto values on the margins, and thus,
e.g., ‘width: 20em; margin-left: auto; alignment:
left’ would align the block to the left. (Currently, that
aligns to the right.)
This option and the first one allow centering and margins.
This has a subtle, but possibly important effect on the preferred size
of centered tables.
The third option avoids adding more properties to the box model and
works well with fallbacks: ‘margin: auto; margin: any’
will work in both old and new implementations. (In old implementation
only for narrow boxes, obviously.) On the other hand, after a while,
people may wonder why there is an ‘auto’ keyword that does almost
the same as ‘any’ And, people may make the mistake of trying, e.g.,
‘line-height: any’.
At this time, January 2008, we believe we do need to add something
to CSS, but we don’t know what yet.
Resolutions 2007-11-27
Past few telecons haven’t been very well attended, so there isn’t much to report for this month in general.
No official resolutions for 2007-11-27, but the CSS3 Backgrounds and Borders editors did agree to adopt Anne’s border-radius extended shorthand syntax proposal.
We discussed the status of REC-CSS1 and REC-CSS2 and how to put some kind of colorful notice at the top about those specs being obsolete and needing to refer to CSS2.1. There seem to be a lot of process-related difficulties with this.
We also discussed putting up a public copy of the CSS2.1 Editor’s Draft, but it’s a lot of extra manual work for Bert, so we’ll revisit that question when there are more errata and Bert’s had a chance to think about a strategy for automating some of the work. (It has a complicated build system that isn’t practical to port to dev.w3.org.) Right now it’s not really that important, since there aren’t that many errata, but Melinda and I expect more errors and omissions will turn up as we make progress on the test suite.
Planet Future-of-CSS
Inspired by Richard Ishida‘s Planet i18n, the WHATWG Blog, css3.info, complaints by bloggers that they don’t want to subscribe to www-style, and my own trouble keeping up with the times, we’ve set up as a joint project with css3.info an aggregate feed on the w3.org site: The Future of Style.
Currently it pulls in the CSSWG Blog, css3.info, and the experimental CSS3 Soapbox.
The goal of all this is to create a running blog conversation on the future of CSS, using a stage where anyone can step up to talk and be heard.
If you have a post you want to add to this feed, post a link (or the whole thing)
on the CSS3 Soapbox. If you own a blog with frequent posts about the future of CSS, and want to be added to this aggregator, contact fantasai.
If you want to follow the Planet feed by email, there are some RSS->email services out there. (I’ll probably have to go this route.)
Discuss on www-style
Archives
Browse by date:
Browse by category:
![[Photo: group photo of the CSS working group in San Francisco]](/Style/CSS/csswg-2016.jpg)
Contact: