(This page uses CSS style sheets)
W3C and the CSS Working Group publish information about the specifications under development in various ways. This page is the working group's weblog (blog). Other places to find information are the “current work” page, the www-style mailing list.
caretRangeFromPoint
to be added to CSSOM View and marked at-risk; the CSSOM spec will then be republished as LC.Discussed media queries, should be ready for LC soon, but still has a couple open issue. Main one is whether to use
@media (portrait) { ... } @media (landscape) { ... }
or
@media (orientation: portrait) { ... } @media (orientation: landscape) { ... }
Discussed CSS2.1 Issue 8. Anne needs to come up with better wording before we discuss the two wording proposals. Seem to have agreement on the end result.
Discussed CSS2.1 Issue 24. Interest in making {(['"
matching style sheet global, need a wording proposal to continue discussion.
Resolved: For CSS2.1 Issue 31 David Baron's proposal is accepted.
Resolved: For (CSS2.1) ISSUE-1, second wording proposal is accepted:
Insert before "It is recommended that the reference pixel be..." the sentence "It is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel."
Resolved: Add John Daggett (Mozilla Corporation) as CSS3 Fonts module editor.
Resolved: Take CSSOM View spec to last call after edits described in the minutes are made.
Noted: General agreement that the current CSSOM is badly designed and should be extended, but standardizing existing interfaces is the priority right now.
Resolved: CSS specs below CR level should add canonicalization info to their property definitions once a canonicalization table for existing properties has been created.
Resolved: If the CSSWG chooses to specify CSSOM interfaces for editors, that will be a separate spec from the main CSSOM.
Highly experimental brainstorming-level stuff. No resolutions, just notes.
Discussed tree lists styling prompted by Andrew Fedoniouk.
Noted: Solution should satisfy 80-90% case; no point in adopting if it only solves 10%.
Noted: Designers will want control over color, width, style of lines. Using 'outline' or 'border' precludes giving the element a real outline or border.
Idea: A pseudo-element could provide a place to put styling.
Idea: One possible model is each list item has a T-shaped or L-shaped marker that connects with the previous.
Idea: Another possible model is each list item has a horizontal bar marker and the vertical line belongs to the parent.
Idea was to have two pseudo-classes, one :normal and one :alternate. UA toggles between styles. (N styles also possible.)
Existence of the pseudos makes the element toggleable. There were strong reservations about that.
Bert's writeup is still Member's only.
Idea was that a selector accepts a JavaScript function that returns true or false, determining whether the selector matches or not. VERY strong reservations about this from implementors: executing functions during selector matching is scary, particularly if those functions are allowed to modify the elements during matching!
Alternate idea is to define a set of tokens on the element node, allow scripts to add and remove tokens, and match against that set.. thereby avoiding the execution of any functions during style matching.
Clear use case for importing colors from a site-wide style sheet. CSSWG wants more concrete use cases for anything beyond that.
fantasai points to webstandards.org comments and suggests macros for selectors, values, and declaration sets would fulfill most requests there.
CSSWG will post a simple proposal macros for values only, and see if that will cause web designers to post real examples of where more powerful macros are needed.
Suggested to add this to Selectors 4. Need implementors' "strong interest".
Steve reports on conclusions from joint meeting with Paul and fantasai: plan is to introduce text-orientation
, which operates on runs of tex--unlike XSLFO/SVG's glyph-orientation
, which operates on individual glyphs. Glyph-orientation's behavior causes characters to be in the wrong order for some of its values. text-orientation will take keywords for common effects in vertical text.
Noted: It was proposed that the overflow and marquee properties be split off to form their own module. These properties are needed by the Mobile Profile and are reasonably independent of the box model details. Splitting them off allows them to move forward to CR without being held back by the rest of the box module, which is quite complex and will need significantly more review. There seemed to be consensus on this idea, but no formal resolution was made.
Noted: fantasai's proposal for adding box-sizing keywords to the 'width' and 'height' properties was discussed. Most of the working group was strongly in favor, 1/2 of one company's representation was opposed. No resolution was recorded wrt adopting the proposal.
Resolved:: That should the proposal be adopted, its keywords must be consistent with box-sizing
.
Noted: That the proposed keywords are applied to min-width
, max-width
, width
, min-height
, max-height
, and height
.
Noted: That the proposed keywords, like box-sizing, have no effect on the behavior of auto
, fit-content
, min-content
, max-content
, and none
(max-width/height only) values for these properties.
There was much discussion of horizontal and vertical centering, but no resolution on the issue. The discussion closed with fantasai and Alex assigned to write concrete proposals for horizontal and vertical alignment, respectively.
For horizontal centering, there seem to be two distinct use cases:
<CENTER>
tag. The <CENTER>
tag centers all its children, but not itself, and this centering behavior is inherited.For vertical centering, it was agreed that alignment affects the element's children (because there's no way to center an element in its parent without taking it out of the normal flow). Also, it was agreed that vertical alignment of an element's children should cause it to create a new block formatting context. This greatly simplifies things by avoiding margin-collapsing and float complications. The default value of the new property will need to be a special value that doesn't turn the block into a BFC.
A proposal to change the way page-break-inside
affects descendent elements was discussed.
Bert reported that designers want non-rectangular regions, to put images in corners or in the center. However, auto-sizing non-rectangular slots (such as a C shape that has as much text above as below) is very difficult. In the interest of moving forward and getting implementations, fantasai suggested leaving the slots rectangular for this version.
Resolved: Rename CSS Advanced Layout Module to CSS Template Layout Module.
Noted: To avoid overlapping constraints, width and height should not apply to slots, only to columns and rows respectively.
Resolved: David Baron's proposal accepted as editorially amended by fantasai.
Rationale:
Authors are used to CSS allowing spaces almost everywhere, and will most likely expect them to work here as well. Alsocalc()
will either allow or require spaces, and :nth-child()
's syntax should be consistent with that.
Resolved:: Copy attribute selector wording from Selectors into CSS2.1 to resolve incompatibility.
Resolved:: *=
, ~=
, ^=
, $=
all accept the empty string, but match nothing. Note that this overrides a previous resolution which stated that such attribute selectors are invalid.
Rationale:: These selectors are meaningless. This resolution matches existing implementations for ~=
, which was introduced in CSS2.1, and makes *=
, ^=
, and $=
, which were introduced in Level 3, consistent with that.
[Note:
see also Alan Gresley's comment which was posted in response to this resolution]Resolved: When we get to a point where the CSSWG agrees the test suite is "good enough" for entering PR, we use that version (snapshot) of the test suite to enter PR, then continue to work on the test suite and errata.
Rationale: Question was "when do we stop working on the test suite?" We will always find deep technical issues. At some point we have to stop, publish the REC, and use the errata system from there. Some people argued that there should be concrete criteria for when the test suite is "done", but no one offered any usable criteria. We have some tools to index the tests, but ultimately it will need to be a judgement call. It was further argued that work on the test suite should not stop just because we want to enter PR: the test suite will continue to be useful for driving interoperability and uncovering spec problems even after REC, and use of the test suite for PR transition should not prevent other uses of the test suite.
Once all of the tests written by Microsoft and by Hixie are reviewed and checked in, we will have a much better view of what remains to be done for the CSS2.1 test suite.
Noted: Specs should include a link to the official test suite, whether it is complete or not.
Resolved: The intent of the CSSWG is to post two copies of the test suite, one with the W3C Document license and one with the BSD 3-clause license. The copy with the W3C Document License will be the official conformance test suite.
Rationale: While the W3C Document License is fine for a test suite whose sole purpose is checking conformance claims, the amount of work that goes into this test suite does not justify limiting its use to that. Several major contributors do not want to contribute tests if these tests are not freed for other uses. These tests would be very useful in particular during the implementation development process, and the members of the CSSWG would like to make the tests in the test suite accessible for such uses. This requires placing them under a liberal open source license, and the BSD 3-clause license was chosen by consensus.
Resolved: Mobile Profile can move to CR as long as marquee and overflow are tagged as at-risk.
Resolved: The marquee and overflow properties are in the Box Module, which is still only a working draft. As long as they have not progressed to CR they block the Mobile Profile from reaching PR.
Resolved: em
and ex
units in media queries must be relative to the initial values of the font properties, not to values on the root element (since style sheets can change those).
Resolved: Media Queries shall be published as a Last Call Working Draft.
Resolved: The editor's draft of Media Queries to be moved to dev.w3.org.
No resolutions were recorded. :( See minutes for discussion; we went through dbaron's issues list. Assuming dbaron kept track of the discussion, any WG resolutions should appear in the issues list.
This spec should be ready for Last Call soon.
The chairs chose for political reasons not to make any resolutions. The CSSWG hopes to, with the XHTML2WG's approval, morph the XHTML2WG's request for removing default namespaces into a request for clarification/guidance on the use of default namespaces in conjunction with Selectors and resolve the issue by adding an XHTML2WG-approved note to CSS Namespaces.
Note: The current CSSWG charter expires at the end of June. The new one must be written and submitted to W3C for approval by the end of April.
Note: Daniel Glazman and Peter Linss are co-chairing the CSSWG starting with this face-to-face meeting. Bert Bos remains as the CSS Working Group's W3C Staff Contact.
Resolved:That the CSSWG's IRC channel shall be perpetually and publicly logged. That these logs are for us and for the public to see our work in progress, and that they are NOT for the official record. That any important information in the logs MUST be summarized and forwarded to the mailing list (along with, but not substituted by, a pointer to the IRC logs and/or a pasted snippet) by the people involved in that discussion so that no one needs to track the IRC logs to keep up with the group.
Resolved: That the IRC logs shall have a disclaimer explaining that
Noted: The CSSWG discussed opening up process-related discussions into a new public mailing list, but there was no consensus on that. The current private process / public technical split will be kept until further notice.
Resolved: Given that the IRC logs will be public, the CSSWG minutes shall also be public. (The CSSWG minutes are usually typed into IRC rather than into a text file.)
It may take awhile to set up perpetual logging. Public minutes will take effect starting on 2007-03-27.
Resolved: CSSWG Telecons have moved from noon in Boston on Tuesdays to noon in Boston on Wednesdays. They still last one hour.
Resolved: Members are expected to call in five minutes before the scheduled time. The telecon will start promptly on the hour.
Resolved: The agenda for the telecon is due the Monday before the telecon, specifically, before the agenda-writer goes to sleep that night or the sun comes up at his location the next day, whichever comes first.
Resolved: If a member cannot make the meeting, then s/he must send regrets by the day before the meeting (which should be after the agenda is sent) or risk bad standing.
Resolved: Participation over IRC is acceptable for telecons in exceptional circumstances. Participation over IRC means reading the minutes in IRC and participating back, not merely being online at the right time.
Resolved: First topics on agenda must be about resolving issues that require consensus: later topics can be more exploratory discussions.
Resolved: Attendance at first part of telecon is mandatory, where the first part is defined by the agenda and expected to take 20 minutes.
Noted: When a decision is made, we need to make sure it is recorded.
Noted: Issues should come to the telecon with a proposal and a testcase (if appropriate). Issues that need some exploratory discussion before a proposal can be written should be limited to 5-10 minutes discussion.
Noted: WG discussion should be kept at the technical level. We are not marketers, lawyers, etc. Our job is to push CSS forward.
Resolved: To stay in the charter, a module must have both
Resolved: The chairs shall prepare a prioritization report that explains our priorities for each module, indicates which modules have been cut from the charter, and explains the rationale for these decisions. The report shall include for each module whether it has an advocate and how many implementors have no/some/strong interest in implementing the module. This report will be posted to www-style for feedback.
Noted: Items may be added to our work list only if
Resolved: That Apple's proposals for animations, transitions, and filters are in scope for CSS and may be added to the next charter if they pass the same criteria all modules must pass to stay in the charter.
Resolved: Add Web fonts to charter as coordinated effort with SVG group
Noted: The "at-risk" feature of CR status should be used more often.
Resolved: Publicly-available releases, whether of shipped, beta, or nightly status, may be used -- at the CSSWG's discretion -- to qualify a spec for PR. Unofficial releases (betas, nightlies, etc) may only be used a minimum of one month after the build has shipped to give testers time to find any major compatibility problems due to the features implemented.
Noted: The CSSWG discussed and rejected the idea of creating a separate "primer" document parallel to the spec to explain rationale and give examples. Instead the CSSWG feels that the current practice of combining explanations, rationale, and examples into the spec itself benefits implementors, authors, and spec writers alike.
Rationale: Splitting this information into two documents
Keeping the informative rationale and explanations in the spec
Noted: The above should not be taken to mean that the CSSWG wants less distinction between normative and informative content: the CSSWG encourages sharp distinctions between these two types of spec content.
Noted: The CSSWG discussed the idea of scheduling a 2009 F2F in conjunction with a web conference. Several members expressed opposition to the idea on the grounds that aligning a CSSWG F2F with a web conference lends that conference an implicit association with the W3C and the W3C should be a neutral party. It was suggested that conferences could instead invite some individual members of the CSSWG, such as the chairs or the staff contact, to represent the group instead.
Jason Cranford Teague is working on a redesign of the CSS homepage. He presented a work-in-progress at the F2F.
Resolved: Jason will run a contest for a new CSS logo. Jason's "no missing squares" CSS logo will be used until a new one is chosen.