- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 11 Jun 2010 09:48:22 -0700
- To: Paul Duffin <pduffin@volantis.com>
- Cc: www-style <www-style@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Fri, Jun 11, 2010 at 3:11 AM, Paul Duffin <pduffin@volantis.com> wrote: > All, > Thanks for your feedback. I have also come to the conclusion that treating ::outside as identical to simply wrapping the element with a real element with the same styles is the simplest to implement, easiest to explain and most flexible for the page author. > > ::inside may also be useful but as mentioned has issues with replaced elements. > > Some points to cover in the specification: > > The elements to which ::outside can and cannot be applied. > * Doesn't make much sense on table cells/rows/columns. Eh, sure it does. You can use ::outside, frex, to explicitly specify a table-cell wrapper rather than having one be auto-generated by the fixup algorithm. > * What about list-items? How would it behave on that, where would marker go? Markers are children of the list-items themselves, so nothing special. It would be just like wrapping a <div> around an <li> (which isn't allowed in HTML, but there's nothing wrong with it from a CSS perspective). > * What about around children of flexible box? Similar to tables - the ::outside would do the actual flexbox interaction, and the superior would just be descendant. > Some additional use cases for ::outside. > > Use Case #1 > =========== > > Wrap additional structure around a replaced element, either with explicitly specified dimensions, or intrinsic dimension, such that there is no gap between the edges of the replaced elements margin-box and the containing element's content-box. > > e.g. shrink to fit around an element that has a specific width/height, e.g. an image with following styles: > {box-sizing: content-box; width: 100px; height: 100px; border: thick solid red; padding: 2px} > > The width and height of the ::outside should be calculated so that it's content-box has the same size and position as the border-box of its superior parent. > > 'shrink-to-fit' can be achieved in certain cases (floats, tables, inline-block) but it always comes with some additional issues to handle. It would be nice to be able to specify that orthogonally to the other cases. e.g. Have width: shrink-to-fit, height: shrink-to-fit. Then auto keyword specified on width/height would behave as shrink-to-fit by default for floated elements, tables and inline-blocks. That case is being addressed in the fashion you describe in the last paragraph. It doesn't have a home in any draft yet, but David Baron has proposed (and implemented in Firefox behind the -moz- prefix) the three width/height values min-content, max-content, and fit-content. fit-content is the shrink-to-fit width. > Use Case #2 > =========== > > Expand the element to fill its ::outside element. The dimensions of the ::outside element is explicitly specified, either as fixed length, or percentage. > > 'expand-to-fill' can be achieved using either > {box-sizing: border-box; width:100%; height:100%} > or flexible box model. Hm. What does this add that you can't already do by just setting the width/height of the superior appropriately? I'm glad that you're trying out of an implemention of this. It'll shake out problems that we've missed. I'm particularly concerned that there may be some problems with the way inheritance works here in certain cases. ~TJ
Received on Friday, 11 June 2010 16:49:16 UTC