Option 1: Flex and grid items resolve percentages in margin-top and margin-bottom against the height of the element’s containing block.
Option 2: Flex and grid items resolve percentages in margin-top and margin-bottom against the width of the element’s containing block.
Option 1 makes vertical margins consistent with horizontal margins (which resolve percentages against the width of the element’s containing block). This is a theoretically simpler model, and works well with Flexbox and Grid’s dimension-agnostic layout concepts. However, it is inconsistent with CSS block layout, and causes the margins to collapse to zero when used in an auto-height container.
Option 2 is consistent with the behavior of vertical margins in block and table layout. It has usable behavior in auto-height boxes, and enables the “aspect ratio hack”. However, it is a less obvious behavior, and means the layout interactions change based on whether a flexbox is “row” or “column”.
(For more background, see discussion on www-style.)
We’re looking for comments from authors explaining which behavior they think is better for Flex and Grid layout, and why. Do you have use-cases that can only be achieved with one behavior or the other? Show us!
The CSSWG has published an updated Working Draft of CSS Box Alignment Level 3. This module extends the Flexbox alignment properties to apply to all layout models and adds additional controls for logical positioning, space distribution, and handling overflowing elements.
This is the vertical centering module, people.
This module’s syntax and functionality is in the process of stabilizing now and we need your feedback. Think of all the cool things you could do with the new alignment properties! Imagine them! Examine them! Make examples! Write rants! And tell us what is awesome and what is stupid so that we can fix it to be better before it gets locked down in shipped browsers.
Changes since the last Working Draft are listed in the Changes section.
Please send feedback! Comment here, post to the (archived) public mailing list [email protected] with the spec code (
[css-align]) and your comment topic in the subject line, write a blog post and send us a link, or, if you’re shy, email one of the editors directly. Ranting somewhere else in the ether and expecting us to find it by magic, however, won’t work.
Tab Atkins and I published an updated Working Draft of CSS Image Values and Replaced Content Level 3 this month. We anticipate that this will be the last draft before Last Call, which we aim to publish in January. If you have an interest in this draft, please review it and send in your comments.
The CSS Working Group just published a Last Call for Comments Working Draft of CSS Backgrounds and Borders Level 3. Please review the draft and send your feedback. We’ll be accepting comments through 17 November 2009. (Note that feature requests are likely to be deferred to CSS4.) The best place for feedback is the CSSWG’s official mailing list [email protected], but we’ll also look at any comments posted (or linked to) here on CSS3.info.
There are a couple issues we’re specifically looking for feedback on:
Rounding vs. Scaling Down
border-image-repeatresizes images to fit the nearest whole number of tiles, rather than always scaling up or always scaling down. Rounding keeps closer to the intended size and, in the case where one dimension is fixed (e.g. in ‘border-image’), keeps the image closer to the intended aspect ratio. This is almost certainly the best solution for vector images and high-resolution raster images. However, if the given image is a low-resolution raster image, it will require interpolating pixels, which can look bad. See Rounding Extremes for illustrations.
The workaround is to specify a higher-resolution image (e.g. by shrinking from the original with
border-image-width). Possible spec solutions include introducing a separate keyword that always scales down, and changing the algorithm so that we force scaling down whenever interpolation would be required for scaling up. So the options here are
- Leave the spec as-is (always round to nearest): the workaround is good enough for me.
- Trigger forced downscaling when interpolation is needed: avoiding interpolation is important to me and I don’t mind that the exact number of tiles is unpredictable and the resulting aspect ratio might skewed a little extra.
- Default to rounding for
round, but I want an extra keyword to force downscaling in all cases (including vector images) because [...].
- Something else?
Please comment on what you prefer and why. (The more specific you can be “for example, this image that I would want to use [...]“, the easier it will be for us to understand your point.)
The previous draft included two properties for controlling behavior at box breaks (line breaks / column breaks / page breaks):
border-breakfor controlling whether the border is drawn at the break, and
background-breakfor controlling whether the background is drawn for each box individually or for the whole element as if it were broken after painting.
Hyatt suggested merging the two, so the current draft has a single
box-breakproperty instead. The two values mean, basically, “render backgrounds and borders for this box, and then slice it up” and “break the box and then render backgrounds and borders for each box individually”. The value names aren’t particularly clear, however, so we were wondering if anyone has better ideas.
So take a look at the new draft and send us your comments! This is your last chance to give feedback on this module: if all goes well, we’ll be publishing the Candidate Recommendation in time for Christmas, and given the state of experimental implementations right now, I expect things to move rapidly from there.
Over the past few weeks I’ve received a number of emails from visitors to CSS3.info regarding CSS3 validation errors when using vendor specific extentions, for example -moz, -webkit, to implement CSS3 in their websites.
This certainly isn’t a new topic, and in fact Joost de Valke first raised the issue on this website back in January 2007, however a glance over the W3C mailing-list archive highlights that this debate is still going strong, with a number of interesting ideas raised, and I thought it would make an interesting discussion point for the CSS3.info community.
Jason Cranford Teague has volunteered to edit the CSS Basic UI, CSS Hyperlink Presentation, CSS Fonts and CSS Web Fonts modules and is looking for feedback from users on the latter two. He asks:
Tell me what you think are some of the font styles and features missing from the current specification. What do you expect to be able to do with typography on your Web pages that you can not do now? What are you doing now with kludges that you would like to see simpler ways of doing?
Leave a comment on his blog if you have any ideas; and why not leave a comment here, too, to let us know what your opinions are? No deadline has been given, but I suppose it’s the sooner, the better.