- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Dec 2014 20:43:57 -0500
- To: www-style@w3.org
Shrink-to-fit
-------------
- There was no agreement on the best behavior to create
interoperability for layout. Everyone seemed to like their
own approach.
- Several people were tasked with writing e-mails to the list
describing their float layout for intrinsic sizes in order to
try and create an agreement for how the sizing approximation
works and then spec that.
Sizing
------
- No one had a perfect solution for how to resolve intrinsic sizes
of non-replaced blocks when the width isn't definite.
- Assuming the value is 0 was raised and garnered some interest,
but there was a desire to ensure that the description is
correct.
- The interested parties will work together offline for a solution.
===== FULL MINUTES BELOW ======
Scribe: dael
Shrink-to-fit
-------------
plinss: Let's get started.
glazou: Is fantasai around for sizing?
dbaron: Can someone text her?
plinss: Who put this on the wiki?
TabAtkins: I assume fantasai.
plinss: Let's skip to inline-box?
<gregwhitworth> http://jsfiddle.net/xzt063uv/2/
gregwhitworth: IE does layouts and we want to get interoperability.
We want to figure out a way to do it without
layout, but we often get live sites that don't
render correctly. We'd like some feedback from
others who don't want to change their system.
<dbaron> https://lists.w3.org/Archives/Member/w3c-css-wg/2006AprJun/0170.html
dbaron: I managed to dig up last time we discussed this issue.
dbaron: In the above minutes.
dbaron: We didn't have a conclusion then.
dbaron: A bunch of us have made architectural decisions that we
don't do layout for this. We don't have major
compatibility issues. It would be nice to have and
agreement on what the rules are.
dbaron: Gecko code and webkit/blink code is somewhat different and
I don't think coming to an agreement between those is hard
and I think it would be web compatible.
gregwhitworth: I agree. We have a lot of problems with what we do.
I think a lot of people don't test us. We don't
want to switch because people layout the same until
shrink to fit.
dbaron: That's not ignoring the spec. It doesn't define behavior.
gregwhitworth: At the end of the day we just want websites to work.
We could say match us, but technically you're right
that when you push down isn't defined. As an author
I would expect the same layout and shrunk.
dbaron: There's no laying out.
gregwhitworth: They literally...if you look at the layouts
personally I think they should be the same.
dbaron: Prior to 2006 or so we did it, but we stopped because it
had tons of bugs and was slow. We decided webkit was
surviving with doing what it was doing so that was
compatible for web content.
gregwhitworth: Let me track down the thread. I think it was
someone from Opera who said Presto is doing it
differently.
florian: I think that was morten on the list.
gregwhitworth: We don't have huge performance issues. I think most
authors would expect our behavior. What's the
working group's consensus? I don't want it to
stagnate because we have a few bugs.
SimonSapin: What does it mean to do layouts...it depends on how
much width is available, but we don't always have that
information.
dbaron: In the old days, all the layout code had a mode where you
could execute that code with a value for available width.
It would then place everything as if there was no width
constraint. We would place floats along those lines.
Rossen: When we run in unconstrained width we really run it
unconstrained. Obviously you can't resolve percentage
because they're meaningless.
SimonSapin: What do you do with percentages?
Rossen: You can backwards resolve or resolve against a computed
shrink to fit size.
dbaron: The what do you do with x, the answers are always what are
you doing when computing intrinsic widths. They just use
the layout code to do that instead of separate code.
Rossen: So there's pretty much no difference in the two codes.
gregwhitworth: It feels like again we all like our thing. I'm
looking for a just deal with it.
dbaron: The algorithm I wrote was for the approximation stuff.
dbaron: I would vastly prefer not to go back down the trying to do
layout path. I think IE is the only major engine doing that
gregwhitworth: Putting aside interoperability and implementation
details, do you not find it odd as an author that
the layout is completely different?
dbaron: It's no different than if the absolute element had the
same width. The only difference is the width for the
abspos element. Yes it is a little weird but...
gregwhitworth: I don't know where else to take this. If everyone
else is holding fast.
Bert: One other thing. I'd like to have for things like tables and
grid layout, you do layout where the width you want is the
one that minimizes the height, that gives you most compact
tables as possible.
Bert: Maybe there should be a switch somewhere to use a different
algorithm and then you really search for the smallest way to
pack the content.
Bert: Smallest in this case is smallest height
Rossen: So that's your max content. It's shrink to fit.
Bert: It's more complex than the basic approximation like two
floats could fit together. You may have to do the layout
multiple times. I've seen it done and you get beautiful
tables. You may need a fast computer if you want it
interactive.
Bert: I don't know how it works with animation. I guess you turn
it off. It's something to keep in mind and it may be a
future way. For print especially you can get better layouts.
Rossen: So, dbaron, you mentioned performance as an issue.
dbaron: A lot of the gains came from how we do invalidation. We
didn't permanently maintain the layout data so we would
have to redo layout. I'm guessing you don't have that
problem?
Rossen: No.
Rossen: In our case we have ways of reusing that data when we
identify that it will be the same result so you only do
the necessary overrides.
gregwhitworth: Again, I point to the example where there's room in
the container for that stuff to fit. In the test
case your constraint is the viewport. It shouldn't
be pushed because technically there's room to fit.
gregwhitworth: I'm leery to say match when it's a different result.
Rossen: Given the content that's out there, does it make sense to
have a higher quality of implementation? So the user
expectation will match regular layout more? Or is this an
edge case enough so we would go and change how we behave.
gregwhitworth: I'd say 50/50.
Rossen: I've seen bugs that argue both. The ones that suck are on
the outer level of websites that control their layout
through floats. That's where we have broken layout inside
shrink to fit layouts.
Rossen: Hopefully with grid and flexbox they'll move away from
that practice, but in the meantime we're stuck with broken
behavior.
Rossen: One question is, dbaron, is this an idea you guys would
even entertain, is to do something from approximation or a
different way to do layout? If it's out of the question
there's no reason to do this.
dbaron: I think going back is pretty out of the question. I
couldn't justify probably at least one person year of
engineering time when what we have now is web compatible
and works.
Rossen: So if this is the case, can we at least spec that?
dbaron: Spec the way the approximation works? I can do that. At
one point I think I posted to the list what we do. I'd be
interested in seeing what webkit does.
smfr: We do the same as Gecko in this case.
dbaron: There are some differences. They're subtle, but we
sometimes get bugs.
gregwhitworth: So can we action that or...?
dbaron: I can write up the Gecko behavior.
gregwhitworth: Anyone willing to write up others?
TabAtkins: I can try and ping our people that know the details.
Rossen: So where would we put that?
gregwhitworth: Sizing?
Rossen: It could be.
plinss: Is the current text vague or silent?
Rossen: It's basically a lot of hand waving.
Rossen: Okay. I think we're done with that issue.
ACTION TabAtkins: spec their float layout for intrinsic sizes
<trackbot> Created ACTION-659
ACTION dbaron: spec their float layout for intrinsic sizes
<trackbot> Created ACTION-660
Percentages and Indefinite Sizes
--------------------------------
TabAtkins: fantasai, did you put sizing on the agenda?
fantasai: No.
SimonSapin: I did.
SimonSapin: In the sizing spec for the intrinsic sizes of
non-replaced blocks - there are different cases
depending on if the repeated width is definite or not.
SimonSapin: If it's not definite...
dbaron: What does it mean for definite?
SimonSapin: Fixed length or a percentage that's against
something definite.
dbaron: So definite is a length or a percentage that resolves to
length.
fantasai: Could be resolving against ICB, but it doesn't have to
do layout, just drill down.
florian: Including calc?
fantasai: If the things being calc are definite.
SimonSapin: When it's not definite the spec says:
<SimonSapin> If the computed inline-size of a block-level box is
min-content, max-content, or a definite size, [...]
Otherwise, if the computed inline-size of the block
is fit-content, auto, or fill, its min-content inline-
size contribution is its min-content inline-size plus
any inline-axis margin, border, and padding.
<SimonSapin> http://dev.w3.org/csswg/css-sizing/#block-intrinsic
dbaron: So you're saying it should say what to do with percentage
size and padding?
SimonSapin: Yes.
dbaron: It should.
dbaron: I guess different browsers do different things. I believe
this is a thing where Gecko does it different than other
browsers.
SimonSapin: I haven't tested.
<dbaron> http://dbaron.org/css/intrinsic/#mbp-adjust
dbaron: I wrote the above when trying to write this up.
dbaron: I did write a definition that inverted the percentage in
padding and margin. I believe Gecko does that, but not
other browsers.
Rossen: We don't for sure.
dbaron: Gecko not for width, but padding and margin.
SimonSapin: For some reason I thought the answer was treat
percentage as 0.
Rossen: That's what I do.
fantasai: Maybe that was just in grid layout.
Rossen: That would make sense.
dbaron: The other interesting thing is that it does that for
preferred width, but treats it as 0 for minimum.
SimonSapin: Is there a reason?
dbaron: Web compatibility. The reason for 0 as min content. The
preferred width is because it works better.
Rossen: I'd be surprised if webkit's did that. We don't.
dbaron: The compatibility was the min-width. I guess I'm okay with
dropping inversion if that's what everyone else does.
fantasai: If it gives clearly better results, might be worth
considering.
dbaron: I'm okay with doing 0. I think everyone else has been
doing that for a while.
plinss: Is that specified?
dbaron: No.
plinss: So add it to sizing?
fantasai: I think 0 makes sense if it ends up being 0. If you
calculate assuming 0 and then calculate percentage
against that size we have a problem.
dbaron: And that exists in all the other browsers.
fantasai: If we're making it 0 or intrinsic size we should make it
0 for everything.
gregwhitworth: That's the argument we just made with floats.
dbaron: The other thing is hopefully people will be using floats
for layout less over time.
fantasai: And intrinsic sizing goes into everything.
fantasai: If you special case floats, it doesn't make sense.
dbaron: Floats are the only concept in CSS 2.1 that requires you
to do layout to compute an intrinsic size.
dbaron: They're the only place where you need height info to
determine intrinsic widths. What Microsoft wants to do you
need to know the height of every float to calculate the
intrinsic width to layout. You're doing layout of lines.
dbaron: To determine if two floats are next to each other you need
to know the height of each line. It adds a lot of
information to be able to calculate without a lot of value.
fantasai: So if we're assuming 0 for intrinsic size, we should
assume 0 for layout.
dbaron: I'd argue that because layout is interoperable.
Rossen: So you're okay with dropping to 0?
dbaron: Yeah. I mean, everyone else is doing it.
fantasai: So your ideal would be the opposite of Microsoft? So
floats are extra complex, but lets do it for all these
other things because it makes sense. And Microsoft
argues the opposite that we want to do this for floats,
but everything else is 0.
Rossen: Percentages are funky when you backwards resolve so if you
have many table cells that are percentage in width,
backwards resolving most of the time is unreasonable.
dbaron: Tables do resolve backwards, but only for table layout,
that's interoperable. But we're not talking about table
layout right now.
SimonSapin: I don't know how much of an argument this is, but the
way Servo does layout, we can't have any results from
layouts for intrinsic width. We compute them all
before we start layout for the heights.
fantasai: I think Servo needs to change its architecture.
Rossen: I don't think...I can probably come up with grid layout
scenarios that would have a similar dependency. Rows that
are fragment dependent. Vertical text is another one.
Rossen: I'm not sure how we got to that discussion.
gregwhitworth: Because the resolution is what I was trying to
argue so I hijacked it.
plinss: I'm not sure if I'm hearing consensus.
dbaron: One other point. The argument for wanting to try and do
this the right way and invert the percentages is kind of
weak because it's only web compat in 1/3 of the cases. We
can look at width padding and margin. For web compat we
can only do it for margin and padding.
fantasai: This is block layout?
dbaron: Yes.
fantasai: It may be we have to cut our losses for this and do it
correctly for grid and flexbox.
plinss: So have a layout mode that authors can opt-into?
dbaron: I'd be happier about trying to do it the right way in
layout modes then adding mode switches.
fantasai: I think that's probably fine. Block layout is really
about stuff in the flow. Fancy sizing isn't its forte.
plinss: Will you get prettier answers the other way, for example
like ebooks?
fantasai: I definitely want to look into trying to figure it out
for flexbox and grid.
dbaron: I'm not sure I'm comfortable changing flexbox that much at
this point.
fantasai: They should be consistent.
dbaron: The last substantiative change to flexbox had a lot of
problems.
fantasai: Is that flex-basis? The resolution was "let's change the
spec to this and get feedback" and then it was suddenly
implemented.
fantasai: That was also syntactic, not a layout issue.
dbaron: So are we leaning toward we want these all 0 for block and
try to do the inverting for new layout modes?
fantasai: Makes sense.
Rossen: I wouldn't change flex at this point.
dbaron: Then we get to argue about what's new and what's old.
Rossen: They're both old for us.
TabAtkins: Given the problems table layouts had when we wanted to
add new functions, like we can't do min/max. You
objected on tables. You had to do a piece-wise linear
function.
dbaron: We should investigate that, yes.
plinss: So what's the resolution?
fantasai: I'd like it if you said "make my box as wide as it need
to be to not wrap", you get that.
Rossen: In all cases?
fantasai: Ideally yes. If we can't because compatibility then we
have a problem. I think we should honor the request to
not wrap. And if the internet is dumb and we can't do it
in some cases, then we can't, but if we can do it we
should try and do it.
plinss: So again...do we have a resolution, do we need to
investigate more?
fantasai: I don't know. I think we should stick four of us in a
room with a whiteboard and the sizing spec.
Bert: What FF does looks better than what Safari does. FF
currently calculates that if you want everything on one line
you get everything on one line. It really looks better. I'm
trying to see about others. Prince puts you on one line but
makes it bigger than it needs to be.
Bert: So I'd rather not make it 0.
plinss: So cage-match tonight with a whiteboard?
dbaron: Do we have a whiteboard?
plinss: We can ask.
<fantasai> The meeting room is non-conformant wrt CSSWG meeting
room specs...
<fantasai> ACTION fantasai: Put IE's nearest-scrollable-box
behavior into orthogonal flows spec
<trackbot> Created ACTION-661
plinss: So we'll loop back tomorrow? Folks will work this out
offline?
Rossen: Sure.
SimonSapin: My understanding of intrinsic sizing is that it's
intrinsic and doesn't depend on the context around it.
SimonSapin: When we have a writing mode it isn't how intrinsic
sizing is supposed to work. In particular the
intrinsic block size.
Rossen: What we do, basically the obvious pitfall is we say it's
shrink to fit, assuming you do layout for shrink to fit.
If you, let's assume you have one long line of text. You
don't want shrink to fit that's one long line of text.
Rossen: I believe there's text in writing modes that spec if you
have no height in the orthogonal switch you cap that to
the viewport. We do nearest scrollable box of viewport.
Rossen: We discovered with orthogonal flow, the cases are mostly
having some kind of webpage where you scroll down and find
an example of vertical text. The idea is you want to be
able to see that in your screen. You don't want to have to
scroll both ways. In our implementation we cap the size of
the vertical orthogonal content to be the min of your
nearest scrolling ancestor and your viewport.
Rossen: With that in mind you can go and compute your min and max
size. You need to define that. Max size can be the layout
that you would produce when you cap content at the min.
Rossen: The min of the content would be the cap size, the viewport
or nearest scrolling.
Rossen: That's a fairly good result in almost all practical cases.
I'm pretty sure you're looking to avoid where you have the
min and max to be one line height.
SimonSapin: Should sizing describe all of this whenever it talks
about min/max block content size?
Rossen: It's a split between writing modes and sizing. I think
fantasai and I spoke about this, but I would expect it
defined in one of the two or both specs.
SimonSapin: Does it make sense to talk about that for things that
aren't flows?
fantasai: There's a couple things. If you set the keywords on the
height you need some kind of result. There's also if you
support writing modes it's not just the immediate
orthogonal flow thing, you have to be able to compute
the content size.
SimonSapin: Once you're inside the block direction because the
length direction.
SteveZ: It seems to me it isn't totally writing modes. In
principal you could have something else that changes
direction like if you do rotating with layout. So it
should be covered as a change in block direction.
SimonSapin: How is that different?
SteveZ: It's basically what you get with tabs on the sides.
fantasai: We're implementing that in terms of writing modes.
SteveZ: There's no reason to assume writing mode is the only place
we'd want to change the block direction. Or we can say it
is.
fantasai: That's kind of what we landed on.
fantasai: Unless we want to do 45 degree rotations.
SteveZ: I think we should decide if it's with the orientation and
in that case it goes with writing modes, but there's no
harm in having a reference.
fantasai: Oh yeah, there isn't.
SteveZ: There's other things like a sequence of inline images.
Like in vertical form it lays out and we have the same
issue.
Rossen: We had a similar issue with flex with intrinsic size of
images in vertical flex versus horizontal flex. It's
arguably the easiest to deal with it in writing modes and
deal with just this weird case.
Rossen: So SimonSapin, was your main point to figure out where
this should go or what the expected behavior is or is
there anything else we need to define?
SimonSapin: If this is the behavior, it should be in the sizing
spec.
SimonSapin: I'm worried that this would prevent some layout.
Rossen: Well, maybe.
SimonSapin: Do you think we can still do parallel layout with
this case?
Rossen: Depends on what you would do and the type of inputs you
would take.
Rossen: From pure user standpoint, not having this dependency in
orthogonal flows doesn't make sense. It's just going to
produce wrong results, unfortunately.
plinss: Any more on this?
Received on Thursday, 18 December 2014 01:44:24 UTC