- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 13 Nov 2012 22:30:47 -0800
- 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
production
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
algorithms
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
overlooked.
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