Resolutions 2007-09 Beijing Part IV: CSS3 Borders
border-radius Shorthand Syntax
-
Resolved: 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.)
Overlapping Radii
-
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.
Inner Border Radius
Style Transitions
-
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.
Resolutions 2007-09 Beijing Part III: Rotation
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.
- Resolved: Margins specified on an element apply to its anonymous container, not the rotated block itself. However the behavior of margins for “tight-wrapped” blocks is not quite settled.
- Consensus: There are two types of rotation: rotation that happens during layout (and pushes aside content below it), and rotation that happens after layout.
- Resolved: Overflow of the border box due to rotation has the same effect as overflow of the border box due to relative positioning. Margins by themselves should never trigger overflow.
- Noted: Tight wrap discussions have been deferred to later, however the WG observes that in many cases one will want a fixed offset from the edge of the relevant polygon. This should follow the shape of the border edge, and might not be the margin edge. However the tight-wrap settings will probably also need a way to use the margins as applied to the border box instead of using only a fixed offset.
- Resolved: Rotation that affects layout creates a new “block formatting context”. Rotation that doesn’t, doesn’t necessairly.
- Rotation: applies to all elements within the containing block: absolutely-positioned descendants that are positioned with respect to an ancestor containing block are not affected by the orientation.
- Resolved:
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).
Resolutions 2007-09 Beijing Part II: Japanese Layout and Vertical Text
Status
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.
RESOLVED
- The CSSWG resolved to create a parallel document that explains how CSS can or plans to accomplish each of the requirements in the JTF document and highlights places where CSS currently does not handle the requirements. This document will be written on the wiki.
RESOLVED
- The shift direction (direction of superscripts wrt the baseline) in vertical text by default is left to right, i.e. consistent with the default orientation of Western scripts.
- The breadth (e.g. line length) of an auto-height vertical block in horizontal flow shall be limited by default to the height of the viewport. This is accomplished by defining
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.
- DBaron Principle
- The DBaron Principle states: If the most important cases are handled by a reasonable specification, then the remaining edge cases can be treated by a simple rule that everyone agrees to implement interoperably, even if that rule is not ideal in all cases.
Resolutions 2007-09 Beijing Part I: CSS2.1 and CSS Validator
The CSS Working Group has about three face-to-face meetings a year. This September we had one in Beijing. Since our face-to-face meetings are approximately 24 hours of solid discussion (split across three days), I’m going to break the resolutions reports up by topic.
RESOLVED
- Tentative Resolution: In CSS2.1 section 8.3.1 bullet 6 subbullet 2, change “non-zero top border” to “non-zero bottom border” pending Hixie’s ok. Recorded as issue #6.
Status
- We already have agreement on the test format.
- HP has started contributing tests.
- Microsoft wants to contribute tests, but is stuck waiting for the lawyers.
Other notes
- The test suite would benefit from a way for anyone to run tests and contribute to their browser’s pass-fail report.
- For testing open-ended multi-value properties, what should be the testing limit? Settled on test author assuming “reasonable” limit, documenting that the tests assume a “reasonable” limit, and suggesting that the specific assumption used in a test can be put in the test assertion.
RESOLVED
- Validator should emit warnings, not errors, for profile mismatches.
- (again) The default for validation should be all the properties that are in a draft the WG considers stable. Users may ask for a specific profile to be used instead.
- The validator should not offer a CSS2 profile. Features in CSS2 that are not in CSS2.1 can be validated against the default profile, just as if they were in a CR-level draft.
- The validator should no longer offer a CSS1 profile.
Backlog: Resolutions
As I mentioned before, the CSS Working Group has adopted a policy of posting an unattributed summary of the resolutions and rationale for each decision
to www-style. Richard Ishida recently suggested I also post these to the weblog, so as a start, here’s a blacklog for the past few telecons.
RESOLVED
- The Markus Principle: In CSS3, if a behavior cannot be mandated due to practical constraints, we will at least define a preferred behavior
- We will not add xml-stylesheet to the CSS Mobile Profile 1.0 to match the OMA profile as it is out-of-scope for CSS.
- We agreed to publish new working drafts of CSS3 Box Module and CSS3 Advanced Layout.
- We will set up a directory on www.w3.org for editor’s drafts, where the spec editor can publish unofficial working drafts in between official ones.
Other notes
RESOLVED
- Future publications of CSS modules will conform to the names in the table at the top of the current work page with the addition of the word “Module”, e.g. “CSS Foo Module” or “CSS Foo Module Level 3” for modules that have predecessors in CSS1/2.
Other notes
- We also discussed Media Queries this week, but as Håkon was absent, we did not adopt any formal resolutions.
RESOLVED
Other notes
- Talked about Media Queries, but decided we want more information on use cases and also we need a better idea of how to deal with ratios and rounding since 4/3 devices might not be exactly 4/3 etc.
- Talked about rotation, expect more on that from Steve Zilles.
RESOLVED
- CSS Validator should use no special profile by default: the default should be to include all features defined in a CR level draft.
- Media Queries shall
- add
aspect-ratio in addition to device-aspect-ratio, both with the same #/# syntax.
- add
landscape and portrait as stand-alone keywords
- mark both
aspect-ratio and device-aspect-ratio as at-risk for removal during the CR period
- To handle non-square pixels in Media Queries, the fantasai’s wording proposal was accepted.
- Media Queries shall not include any normative requirements on re-evaluating media queries in responses to changes in the environment, but shall include a note explaining that a UA is expected to re-evaluate and re-layout the page in response to viewport resizing.
Other notes
- Discussed publishing new Grid Layout proposal.
- Discussed splitting GCPM into more coherent modules. Håkon doesn’t expects many features there to move to other drafts or be dropped, but thinks there will still be some print-centric features that stay.
- Discussed CSS Validator features, HTML upload capability was suggested.
- Discussed topics for upcoming F2F (2 weeks from now).
Backlog: New Drafts
The following drafts were recently published and announced, but not announced here, so I’m announcing them now and hoping our editors will announce their own drafts in the future.
- CSS3 Basic Box Model
- This module describes the box layout of CSS documents in visual media, i.e. the foundation of the CSS visual formatting model. It should be equivalent to chapters 8, 9, 10, and appendix E in CSS2, minus positioning and generalized to describe vertical layout as well. It also includes some new features: overflow-x, overflow-y, marquee, and rotation.
- CSS3 Advanced Layout Module
- This module defines a template-based layout model that allows visual ordering independent of document order, positioning and alignment of user interface widgets, and page and window grids.
- Media Queries
- This module allows more precise media queries. Rather than just ‘screen’ vs. ‘print’ vs. ‘handheld’, you can also query based on device’s height, width, aspect ratio, resolution, and color depth, among other things.
You can find a list of all our other CSS drafts on the current work page.
CSS Validator UI
The W3C recently had two interns working on the W3C CSS Validator. One of them will be returning in September to work a bit on the user interface, and the W3C wants to know what other UI improvements should be made to the validator. So far our list includes:
- Changing the default profile to “No specific profile”, to include all CSS features that have so far made it to Candidate Recommendation stage.
- Adding HTML upload capability.
Anybody else have suggestions? Trackbacks are enabled, or send feedback to www-validator-css.
New W3C CSS Working Group Mailing List Policy
The W3C has two mailing lists dedicated to CSS: the public www-style, and the W3C-internal w3c-css-wg. Today the CSS Working Group formally adopted the following policy:
- www-style shall be used for all technical discussion, excepting that which discusses confidential information.
- w3c-css-wg shall be used only for administrative discussion and for sharing confidential information.
- Members of the working group are responsible for reminding each other of this policy and shifting misplaced discussion accordingly.
- The agenda and minutes of each meeting shall continue to be posted to w3c-css-wg.
- An unattributed summary of the resolutions and rationale for each decision shall be posted to www-style. [In general fantasai is responsible for this; in her absence the minute-taker shall be responsible instead.]
- The working group shall solicit any necessary IP statements for significant contributions before formally accepting proposals from non-WG members.
CSS 2.1 is a Candidate Recommendation
The CSS WG published the new Candidate
Recommendation (CR) for CSS level 2 revision 1, with the firm
intention that there won’t be any more working drafts.
There is no doubt that we will still find (small) bugs in the
specification, but given the type of errors we fixed recently, we have
reason to believe that the spec is good enough for implementers and
users alike. We want people to start implementing and using CSS 2.1
for real (and tell us about any remaining problems, of course).
Given that the test suite isn’t complete yet and our information
about implementations is therefore largely based on anecdotal
evidence, we expect that it will be some time before we have enough
tests and enough test reports to progress the specification to
Recommendation. And even if we get more tests rapidly, we will leave
the specification in Candidate Recommendation status for the rest of
this year (2007).
(There is a mailing list dedicated to testing CSS:
<public-css-testsuite@w3.org> If you’re involved in testing,
or want to be, please join
that list.)
As usual, the preferred place for comments on CSS 2.1 is the
mailing list
<www-style@w3.org>, and if you send something, please,
prefix the Subject line with [CSS21].
We are in particular looking for input from implementers: if you
write software for (some part of) CSS 2.1 and you run into problems,
we want to hear about it.
The changes relative to the old CSS2 Recommendation are in appendix C and the last set of issues solved since the last working draft are in a separate document.
CSS is still growing and we expect to add new features, but further
specifications will be in the form of smaller, partial specifications,
called
Modules. (Several already exist and more are coming.) Those
modules will progressively replace CSS 2.1. But the way it looks now,
that will be several years of work.
Anyway, I’ve treated my colleagues to champagne today, to celebrate
CSS 2.1. I hope you enjoy the new spec, too.
Rotations and non-rectangular floats
Aaron Gustafson asked last week in an article called
“Wouldn’t it be nice?” for rotation of text over arbitrary angles
and for wrapping text around non-rectangular floating images.
![[image of a table with diagonal column headers]](https://www.w3.org/Style/2007/diagonal-headings)
Diagonal column headings save space and make the
table easier to read.
I remember discussing diagonal text when the CSS WG first added
support for tables. It often makes tables with many column easier to
read when the column headers are vertical or diagonal.
At the time, we didn’t expect rotated text to be possible in many
browsers soon. We also thought that at some point vertical text would
be added, because of languages such as Japanese, and we were happy to
leave angles other than 90° to SVG. (We are also going to have 90°
rotations of images.)
Although it was (and is) not yet clear how to put a diagonal
heading on an HTML table with the help of SVG, from the point of view
of modularity and because of the extra possibilities that SVG
promises, we decided to focus CSS on typography and leave graphic
design for later, possibly to SVG. (It is difficult to draw the line,
but there are clearly things that are better done with one than with
the other.)
Reasons of usability may still make it desirable to add some cases
to CSS, but rotation is not a simple thing to add. The easiest may be
to rotate an element after layout and not care about overlapping other
elements (the same way relative positioning doesn’t affect other
elements). It is not clear if that is enough to put diagonal headings
on tables, though.
We will probably add a proposal for rotated blocks to the Box
Module, but we’ll have to see how much chance it is has of being
implemented.
![[Image of a
flower with text wrapping around the right side]](https://www.w3.org/Style/2007/contour)
An example of text wrapping around a
non-rectangular floating image.
Polygonal margins (instead of rectangular ones) around
floating elements is also something that was first discussed long ago.
Traces of that discussion can still be found in drafts of CSS
level 1.
One idea was to describe the shape of the float in CSS (as in
Aaron’s proposal). That is a powerful way to describe a shape, but it
is not so easy for the designer. Finding the error if the shape
doesn’t work as expected can be tedious. And every image needs its own
rule in the style sheet.
In most cases, the shape is the shape of the image and a more
direct and visual way is thus to put the image on a transparent
background and let the CSS renderer determine the shape by itself. A
single rule
img {float: left contour}
is then enough to wrap text tightly around all images, no matter
what their shape.
Non-rectangular floats are simple enough for the writer of a CSS
style sheet, especially with the ‘contour’ keyword, but implementing
them is a bit more difficult. With rectangular floats, determining
where to break a line is a matter of looking at the width of words.
But adding or removing a word from a line may change the line’s height
and when floats are not rectangular, a tall line may not fit where a
lower line would. And imagine putting one floating image next to
another… (Not that that is a common thing to do, but a browser still
has to be able to handle it.)
There are some questions about how margins are added to irregularly
shaped floats, but I think ‘contour’ is still relatively easy to add,
and I would support any lobbying to get it implemented.
![[Photo: group photo of the CSS working group in San Francisco]](/Style/CSS/csswg-2016.jpg)
Contact: