• 201505 May

    The CSS Working Group has reached an impasse on the issue of percentage margins (and padding) in flex and grid layout, and needs your input to help decide it.

    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!

  • 201419 Dec

    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.

  • 200916 Oct

    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

    The round option for background-repeat and border-image-repeat resizes 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 background-size or 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

    1. Leave the spec as-is (always round to nearest): the workaround is good enough for me.
    2. 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.
    3. Default to rounding for round, but I want an extra keyword to force downscaling in all cases (including vector images) because […].
    4. 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.)

    box-break naming

    The previous draft included two properties for controlling behavior at box breaks (line breaks / column breaks / page breaks): border-break for controlling whether the border is drawn at the break, and background-break for 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-break property 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.

    Conclusion

    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.

  • 200931 Aug

    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.

OUR SPONSORS

Advertise here?
TAG CLOUD