- From: Ojan Vafai <ojan@chromium.org>
- Date: Wed, 23 Mar 2016 05:06:30 +0000
- To: Levi Weintraub <leviw@chromium.org>
- Cc: Florian Rivoal <florian@rivoal.net>, Paul Lewis <paul@aerotwist.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
- Message-ID: <CANMdWTu9-k2Gv7A1tCVt=vn0W8mrPyWHJMbAJXzZ6VjhyNf8uw@mail.gmail.com>
On Tue, Mar 22, 2016 at 1:26 PM Levi Weintraub <leviw@chromium.org> wrote: > On Mon, Mar 21, 2016 at 12:06 PM, Ojan Vafai <ojan@chromium.org> wrote: > >> >> >> On Mon, Mar 21, 2016 at 2:29 AM Florian Rivoal <florian@rivoal.net> >> wrote: >> >>> Splitting sizing from layout makes sense to me. >>> >>> As for one property vs two, I think the key question is, as it often is >>> when we run into this debate, do these two things benefit from the ability >>> to cascade separately. >>> >>> If you're using them on (web) components, I don't think there's a >>> benefit. Which type of containing might be different on different >>> components, but for each component you'll want to decide on all 4 aspects >>> of containment. >>> >>> On the other hand, if you do want to use the containments other than >>> sizing in a heavy handed way all across your page, and separately add >>> sizing containment without changing the other aspects of containment, then >>> it makes sense. >>> >>> Would you? I can see adding all-but-sizing all over the place, and >>> specifying some-specific-combo-which-may-include-sizing on components in >>> the same page. But would you do all-but-sizing all over the place, and ADD >>> sizing without wanting to change whatever the rest was in specific parts? >>> If the answer's yes, then two properties are better, but what's the use >>> case? >>> >> >> This seems extremely rare to me. I think the 99.99% use case is to use >> one of strict or strict-compatible. Hence my thinking that we should have a >> single property. >> >> >>> - Florian >>> >>> On Mar 19, 2016, at 09:50, Ojan Vafai <ojan@chromium.org> wrote: >>> >>> There are two important use-cases here: >>> 1. A simple way to get strong containment without needing to understand >>> the intricacies of the platform and of each vendor's implementation. This >>> is "style layout paint size". >>> 2. A simple way to get soft containment that can be used broadly (e.g. >>> via "* { contain: strict }"). This is "style layout paint". >>> >>> #1 is an extension of #2 and I think it should read that way. Also, it's >>> really critical that #1 be very simple. It's just so draconian that it >>> can't be used as the 90% use-case. But it's really critical for that other >>> 10%. >>> >>> It seems to me that we just have a naming problem here, but that we can >>> still have a single property. I think "strict" is a good name for #1. We >>> just need to make a name for #2 that sounds like the pre-cursor to #1. >>> >>> Here's a few proposals: >>> a) strictish >>> b) strictable >>> c) strict-candidate >>> d) pre-strict >>> >>> How about e) content? I'm not a huge fan of implying strict when we're > not strict. > I like it! It's about how it contains all it's content whereas strict is that it contains all it's content *and* it doesn't affect stuff around it when it's content changes. > FWIW, I agree that we should have a property for both strict and > whatever-we-call-strict-without-size. I think Ojan is right that one or the > other will work well for the majority of use cases. > > >> >>> I prefer (c), but would be happier with any of these than splitting this >>> up into two properties. >>> >>> On Fri, Mar 18, 2016 at 11:24 AM Paul Lewis <paul@aerotwist.com> wrote: >>> >>>> Thanks for the clarification! SGTM. >>>> >>>> Seems like a good addition irrespective of containment. Mainly I'm >>>> happy if strict doesn't require explicit widths and heights. If there's a >>>> way to ensure that independently then yay. >>>> >>>> On Fri, 18 Mar 2016, 18:18 Tab Atkins Jr., <jackalmage@gmail.com> >>>> wrote: >>>> >>>>> On Fri, Mar 18, 2016 at 11:14 AM, Paul Lewis <paul@aerotwist.com> >>>>> wrote: >>>>> > If we go with a separate property then that restores the clarity of >>>>> contain, >>>>> > which is good. >>>>> > >>>>> > The concern I would have then is what this other property looks >>>>> like. I >>>>> > guess it comes like flex properties, which only apply when the >>>>> parent is >>>>> > display: flex? >>>>> > >>>>> > So I guess, yeah, if a developer sets this additional property along >>>>> with >>>>> > width and height (does it need both?) then there's an extra >>>>> constraint >>>>> > applied, but for the main case "strict-ish" just got promoted to >>>>> "strict" >>>>> > and we make this sizing property, in conjunction with the other, the >>>>> "super >>>>> > strict" option? :) >>>>> >>>>> Nah, the idea is that you'd have something like "height-foo: auto | >>>>> pretend-you-are-empty;" (all names subject to change, obviously). It >>>>> would be completely disconnected from 'contain', and it applies to all >>>>> elements at all times. If you set it to "pretend-you-are-empty", then >>>>> you need to either provide a value for 'height' as well, or your >>>>> element will break in an obvious way, as it immediately collapses to >>>>> zero height. Similar for 'width'. >>>>> >>>>> ~TJ >>>>> >>>> >>>
Received on Wednesday, 23 March 2016 05:07:08 UTC