Bert Bos,
CSS contactLast updated $Date: 2009/04/14 16:44:34 $ GMT
(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.
No resolutions from this session, which took up the whole morning. It was a working session where the WG tried to come to a common understanding of automatic table layout's column width calculation in (almost) all its gory detail. You can see some of the gory details in this discussion on www-style and more extensively in David Baron's document and Microsoft's document.
Microsoft's team and Mozilla's David Baron have each put together partially-intersecting discussions of table layout, which we hope to put together into detailed spec of how automatic table layout should work for the CSS3 Tables module. The goals are to spec what's currently interoperable, and where there isn't interoperability, to spec what is partially interoperable and sensible.
General discussion and some resolutions on syntax issues:
image-orientation Value ParsingResolved: image-orientation accepts all angles, rounds to nearest increment of 90°, and spec says authors SHOULD NOT specify angles other than increments of 90°.
Rationale: Since a number followed by alphabetic is parsed as a length, we can't allow 90deg but not 90.0deg. If we allow radians, then what matches? 3.14rad and 3.14159rad are both approximations of 180°, but they are neither equal to 180° nor equal to each other. We could either allow only degree measurements (which would be odd because all other angle properties accept all angle units, just like all other length properties accept all length units) or accept all angle values and simply round to the nearest 0°/90°/180°/270° angle. The WG, to avoid changing parsing behavior and because it seemed more intuitive, opted for the latter.
Resolved: The following features will be in CSS Box Module Level 3 and the rest of the old box module will be shifted to CSS Box Module Level 4. (Note that CSS4 Box may be published before some parts of CSS3: i.e. CSS modules beyond CSS2.1 do rev independently.)
overflow-x and overflow-yResolved: The CSSWG will publish a document that collects together all the CSS specs that we consider stable, a profile that declares the scope and state of CSS at this point in time. It will include only specs that we consider stable in their definitions (i.e. we don't expect significant changes) and for which we have enough implementation experience that we are sure of that stability.
Resolved: The 2007 version of this document will include
Noted: The 2008 version of this document is likely to contain also CSS3 Paged Media and Media Queries, possibly also CSS Ruby and CSS3 Backgrounds and Borders depending on how those drafts progress.
border-radius Shorthand SyntaxResolved: The border-radius shorthand shall take 1–4 values that set each of the four corners to circular radii, as in the -moz-border-radius shorthand. That is,
border-radius: TL TR BR BL; border-radius: TL BL+TR BR; border-radius: TL+BR TR+BL; border-radius: ALL;
Bascially the syntax is TL TR BR BL (clockwise from top-left) and missing values are filled in by repeating the pattern, just as with border-style et al.
Rationale: The WG concludes from comments such as those on css3.info and from evaluating commonly-used effects such as tabs that designers are more likely to set different circular rounding effects on each corner than they are to set a common elliptical effect on all four corners. Therefore the border-radius shorthand should cater foremost to this usage.
This is recorded as issue 4.
Although we did discuss it, there is no resolution on an extended shorthand syntax for setting elliptical curves. (The WG is generally hesitant to add more punctuation to values without very strong rationale, and also there was no clear agreement on what punctuation should be used.)
Resolved: We agreed that we do not want to have pointy borders, but we have not resolved how to achive that.
Rationale: Web designer feedback.
Comments: There are many ways of eliminating a pointy intersection of two curves. Based on Brad Kemper's feedback, the best way would be to reduce the affected corners' x and y radii in proportion, as this will preserve the shape of the curve. We still need to investigate the exact (mathematical) formulation for this solution, particularly how multiple overlapping corners interact.
This is recorded as issue #5.
Resolved: The inner border radius is the outer border radius minus the border thickness. In the case where this results in a negative value, the inner radius is zero and in this case the inner curve's center may not coincide with that of the outer border curve.
Resolved: The center of color and style transitions are at an angle that is proportional to the ratio of the border widths. E.g. if the two widths are equal, the angle is 45deg, and if one is twice the width of the other the angle is 30deg. The line demarcating this transition is drawn between the point at that angle on the outer curve and the point at that angel on the inner curve.
Noted: There is no resolution on what the transition looks like. (We do seem to expect gradients for color transitions.)
We also discussed whether content should be fitted to the curve, and concluded that if the curve of the content edge needs to be known, it should follow the same principle we established for the inner and outer border edges. However it seems we don't really want content to fit to the curve as that makes border-radius affect layout and will thus prevent us from extending border-radius to take percentages in the future. Therefore some other mechanism for changing the containing block shape would probably be better.
We reviewed Steve's email and also an internal generic "transform" proposal from Hyatt (which Hyatt will hopefully post to www-style at some point), spending most of the day discussing exactly how "rotation" would fit into the CSS layout model.
Rotation is still at a very experimental stage in CSS, so the following are not final decisions.
width: auto on a rotated element means use the available width before rotation.width: max-intrinsic; rotate: rotate-to-fit-keyword enables the case where we shrinkwrap around the text to find its width and pick the smallest angle that will make that block fit.width: shrinkwrap uses the available space after rotation, starting with one line and making the block taller and narrower as more content comes in, until it reaches its minimum content width (or min-width).
The W3C has a Japanese Layout Task Force, which is a joint effort of the I18n, XSL, SVG, and CSS working groups. Their current goal is to document layout requirements for Japanese documents so that W3C working groups can incorporate them into their respective technologies. Most meetings are face-to-face in Japan in Japanese, but there was a bilingual F2F last week in Tokyo, and fantasai was able to attend for the CSSWG and report back. The intention of the task force is to create a W3C Note in English. So far only Part I, which mostly covers page-level layout, has been written and translated. The task force plans to finish most of parts II and III by the November 2007 W3C Technical Plenary.
max-height: none to be equivalent to max-height: 100vh (i.e. the height of the viewport) in this case. The analogous solution shall be applied to horizontal blocks in vertical flow.
Rationale: This preserves readability in the default case: the document can always be scrolled such that the lines fit within the viewport even though it may be a little awkward. The author can and should set more appropriate constraints. This follows the "DBaron Principle".
Comments: It was noted that a particularly elegant way to handle such blocks would take advantage of the multi-col module. However that module has a problem in that it doesn't define behavior for blocks with a totally unconstrained "width" (which so far hasn't ever happened in CSS) and an auto "height" with a max constraint (i.e. the parent's available width). This is recorded as issue 1 in the Multi-Column issues list.