W3C home > Mailing lists > Public > www-style@w3.org > November 2012

[CSSWG] Minutes TPAC Sun 2012-10-28 AM III: Conditional Rules, Sizing

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 13 Nov 2012 22:30:47 -0800
Message-ID: <50A33A97.5080901@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
CSS3 Conditional Rules

   - Reviewed outstanding issues/edits

CSS3 Sizing

   - Reviewed scope and goals of the Intrinsic Sizing module

====== Full minutes below ======

CSS3 Conditional
Scribe: fantasai

   TabAtkins: dbaron and I just need to figure out exact edits. But that's
              the only issue.
   TabAtkins: Talked about it in a telecon already
   fantasai: Should do that this week, publish LC next week.
   fantasai: So get edits done so we can resolve on Tuesday?
   TabAtkins: yep
   florian: I raised an issue wrt grammar of @media and media queries
   fantasai: Florian and I discussed this and, I told that the best option
             would be for media queries to define the media_query_list
   fantasai: And css3-conditional to reference it, and define the @media
             rule productions
   fantasai: And I think that should solve that integration problem
   dbaron and Florian discuss what needs to be edited for this to happen
   Florian will update MQ4 to not define @media rule itself

CSS3 Sizing
Scribe: TabAtkins+fantasai (interlaced)

   -!- sylvaing changed the topic of #css to: CSSWG discussion: size matters
   fantasai: The Sizing spec hasn't had *much* changes, but we added rules
             for the intrinsic size of multicol elements.
   TabAtkins: The definitions there were derived by working through a case
              of multi-col inside a flexbox
   TabAtkins: http://dev.w3.org/csswg/css3-sizing/
   <stearns> http://dev.w3.org/csswg/css3-sizing/#multicol-intrinsic
   TabAtkins: This has to handle four cases independently
   TabAtkins: A multicol with only column count, only column width, or both
   TabAtkins: They size a little differently depending on how it works
   TabAtkins: As far as we can tell, this is the correct definition for
              handling in flexbox, so probably correct definition in general
   TabAtkins: We're wanting to take out parts of multi-col sizing rules in
              css3-multicol, defer to this
   SteveZ: Is howcome ok with this?

   Bert: Why do you need to split out the calculations for different types
         of boxes?
   Bert: multicol is just another type of block.
   fantasai: In a multicol element, if you want to make it as narrow as
             possible, but it says it's two columns, you need to be *double*
             the longest word.
   bert: You just find the narrowest width that doesn't overflow
   TabAtkins: We want it to not require full layout
   Bert: That doesn't help with Grid or Tables.
   fantasai: I think Bert is saying the same thing as us, but from a
             different angle.
   fantasai: He's explaining the terms in general, but we're just laying
             down the algorithms for actually determining that.
   fantasai: The goal is to result in the width that satisfies your definition.
   TabAtkins: Then that wouldn't be much of a spec. ^_^
   antonp: Is that needed in this spec?  It seems that this should just be
           the general definitions.
   dbaron: There are some cases that are genuinely ambiguous, so they do
           need definition.
   dbaron: particularly wrt floats
   Bert: There are some cases, like legacy tables, which are just weird.
   <antonp> i was thinking more about this spec being useful for where
            different layout aspects combine/conflict.  But other specs
            should handle the basics
   <antonp> for themselves
   Bert: What I'd like for Grid is a new layout algorithm that gives you
         better tables.
   Bert: But all you need to say is the general definition.

   TabAtkins: We want algorithms so that we have exact results
   Bert: There are better algorithms and faster algorithms, different
   TabAtkins: For example, browsers give different widths to a floated
              multicol element, even though theoretically there's a
              single correct answer for it. There's not a really obvious
              answer in some cases; haven't thought it through a ton.
              If we'd had a definition laid out against it, implementations
              can converge faster
   Rossen: From implementation perspective, need to figure it out for each
           layout type differently
   Rossen: Having it all summarized in one spot, is helpful
   Rossen: Nice if each individual layout model has a section defining
           intrinsic sizes for that model
   Bert: don't think it's needed
   Rossen: Implementations need it, need clear definitions
   Bert: Only algorithm that will give you the optimal answer will be
         trying all possible layouts
   TabAtkins: We just need a definition that gives the correct answer
   dbaron: Trying all layouts is not an answer. There are layouts that
           always overflow
   Bert: it's not no overflow, it's minimizing overflow
   TabAtkins: Trying all layouts is not a real answer.
   dbaron: Brings up question of whether it's np-complete
   Rossen: Shrink-to-fit with shapes :)
   Florian: An important question is there a single layout, or multiple
            layouts that solve the constraints
   dbaron discusses a W-shaped graph
   Florian: when there are multiple equal minimums, do we want to pick
            one normatively, or say any one is fine?
   TabAtkins: We want everyone to agree on the same answer
   Florian: Then pick an answer, and explain consequences

   TabAtkins: Say that here's an aglorithm, you can optimize it however
              you want
   TabAtkins: Algorithms are never normative except for their answers
   Florian: I think the most interesting part of working through the
            algorithms is saying which out of multiple answers is the
            right one
   glazou intervenes
   glazou: I'm not sure this is a very productive discussion
   jet proposes discussing the travelling salesman problem instead

   TabAtkins: Mostly we pulled from other specs, and just cleaned up
              definitions and put terminology other specs can hook into
   TabAtkins: New thing is mainly multi-col
   TabAtkins: If dbaron has a good definition for tables, we can put it in
   TabAtkins: otherwise we'll leave it to the next time someone reimplements
              table layout
   SteveZ: Can we resolve the goal we're trying to get to is an interoperable
           definitions of sizing?
   fantasai: There is still the issue that Bert was discussing, where you
             can have slightly better/worse results based on how much
             effort you're willing to put in.
   fantasai: For example, a multicol element with fixed height and
             all-spanners, and you want this to take up max-content size...
   fantasai: Figuring that out is iterative convergence, or you can do an
             estimation algorithm that is 3-pass and gets you close.
   fantasai: The different answers should be very close, but probably not
             exactly the same.
   szilles: What I was trying to get at with the resolution is that my
            observation is that users would prefer interoperable over better.
   Bert: Depends on how bad.
   arronei: Tables are bad, but interoperable.  People tweak until it looks
            right, and then can depend it to still be "right" for other
            browsers. Not a great situation, but worse than slightly better
            and not interoperable.
   plinss: There are cases like in print where you want things as pretty
           as possible, regardless of time, but that's not default.
   [talk about trading off constraints in printing]
   * Ms2ger would think that people need consistency even more in printing

   fantasai: I think we can say that this spec is the minimum definition.
             If people can do better, that's fine, but having a minimum
             definition makes it less likely that people don't accidentally
             miss the effects of various constraints.
   fantasai: esp when applied to complex layout models
   dbaron: The thing about this kind of pixel-perfect interop is that
           authors don't use tech quite the way we intend it.
   dbaron: The results when something is off may seem reasonable when the
           tech is used exactly as intended, but the reality is that it's
           used in lots of ways we didn't think of.
   dbaron: "Off" in odd situations can mean that the page completely
           overlaps, or overflows off the screen, or does something else
           that makes it unreadable.  That's a problem today.
   * fantasai would like to point out that pixel perfection is not achievable
              here anyway, due to variation in things like fonts, font sizes,
              viewport sizes, line-breaking algorithms, hyphenation, etc.
   ChrisL: The user doesn't care if, given infinite computing power,
           you could find a situation that slightly doesn't overflow.
   fantasai: Let's not pretend that we're going to pixel perfection -
             line breaking is still undefined, after all.
   <dbaron> yeah, pixel-perfect wasn't really what I meant
   <dbaron> more about getting the same layout concept

   fantasai: The goal of this spec is to define a minimum level of interop,
             and to make sure the consequences of complex layout models
             are handled properly when sizing at intrinsic sizes
   fantasai: We would like review that the spec here is sane and achieves
             this goal.

   Rossen: In section 3.1 where you're defining keywords, there is a note
           for how you resolve double dependencies when measuring in the
           case of percentages.  I'd like to see that become normative
           instead of a note.
   Rossen: All browsers resolve percentages to auto when they're computed
           against an intrinsic width.
   dbaron: FF does that for width, but not padding/margins.
   dbaron: We resolve the constrains backwards.
   <dbaron> <div id="computemyintrinsicwidth"><div style="width:100px;margin-left:10%"></div></div>
   <dbaron> Gecko makes the intrinsic width 111.11111px.
   Rossen: I don't want to go into too much details.  There are testcases
           which will break this pretty quickly.
   dbaron: Tables also do this inversion.
   Rossen: This is just one of the things in intrinsic sizing that is often
   Rossen: So this spec should define it.
   TabAtkins: Yeah, we can try to promote that note into something normative.

   Bert: I have a note about the organization of this spec.
   Bert: It defines the width/height properties.
   Bert: But there are keywords also defined in Box Layout.  Where should
         things be defined?
   fantasai: The old keywords are in 2.1.  Intrinsic sizing defines the
             new keywords.  I think Box will take both specs and combine
             them, superseding.
   fantasai: In the meantime, the Sizing spec is working "as 2.1, plus
             this stuff we're defining".
   florian: When Box is ready, it'll take over from both.
   szilles: It's no worse than 2.1, where bits are defined in other specs.
   TabAtkins: Eventually, Box can normatively say that it supercedes 2.1
              and Sizing for the definition of width/height.
   fantasai: And if necessary, we can rescind Sizing.
   leif: Is this why multicol sizing was here rather than Multicol?
   TabAtkins: yes.

   TabAtkins: btw, new keyword repudiate-floats needs a better name
   (everyone) stupid name!
   <dbaron> fill-inside-floats
   <antonp> squish
   (many longer and multi hyphenated names proposed, all of which suck)
Received on Wednesday, 14 November 2012 06:37:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:23 UTC