Re: [css-writing-modes] Orthogonal parent's logical width

Talked with fantasai, fixed some text[1] and added a note[2] (the note
isn't reviewed yet).

[1]
https://github.com/w3c/csswg-drafts/commit/71c704375225558d3981a107ed360ed045a0ae2c
[2] http://dev.w3.org/csswg/css-writing-modes-3/#orthogonal-shrink-to-fit

On Mon, May 4, 2015 at 2:20 PM, Koji Ishii <kojiishi@gmail.com> wrote:

> On May 4, 2015, at 04:39, Gérard Talbot <www-style@gtalbot.org> wrote:
> >
> > Le 2015-05-03 09:37, Koji Ishii a écrit :
> >> I read Orthogonal Flows[1] several times but as far as I understand, it
> >> does not define how to calculate parent's logical width (i.e.,
> children's
> >> logical height.) It describes relationship of children's logical width
> and
> >> parent's logical height though.
> >> I'm assuming, after children was layout and children's logical height
> was
> >> determined, it becomes both min-content and max-content of logical width
> >> for the parent. Is this correct?
> >
> > Koji,
> >
> > Huh... I am trying to understand your question and I am unsure. In your
> sentence, what is "it" ? I believe your "it" is the children's logical
> width …
>
> Sorry that I wasn’t clear, allow me to retry.
>
> So the case I’m wondering is when I need shrink-to-fit width behavior, and
> therefore need min-content and max-content, and its child is orthogonal.
> This occurs when calculating the width for inline-block or table-cell, and
> its child is orthogonal.
>
> The only reasonable behavior I can think of is to layout the child, then
> take its content height, but I have trouble to find it in the spec.
>
> Does this make it clear?
>
> > Ideally, I think creating a test exposing the problem and assisting your
> question could be helpful here.
>
> Right, here are test cases:
>
> http://test.csswg.org/shepherd/search/name/orthogonal-parent-width-min-content/
>
> > I have a bug in Blink related with this,
> >
> > Which issue number? Is it
> >
> > Issue 459583: 'height: auto' property does not work in vertical-layout
> > https://code.google.com/p/chromium/issues/detail?id=459583
>
> No, this is about http://crbug.com/410320
>
> >> appreciate to know if my
> >> understanding above does not seem correct.
> >> [1] http://dev.w3.org/csswg/css-writing-modes-3/#orthogonal-flows
> >
> > I would appreciate reading, examining an example of auto-sizing in
> orthogonal flow in the spec.
> >
> > "
> > Issue 3: What is this section trying to say? I can’t remember. :(
> > "
> > §7.3.1 Available Sizes in Orthogonal Flows
> > http://dev.w3.org/csswg/css-writing-modes-3/#orthogonal-auto
> >
> > I understand much better the auto-positioning phase though.
> >
> >> /koji
> >
> > §7.3.1 Available Sizes in Orthogonal Flows
> > http://dev.w3.org/csswg/css-writing-modes-3/#orthogonal-auto
> >
> > goes like this:
> >
> > "
> > It is common in CSS for a containing block to have a definite inline
> size, but not a definite block size. This typically happens in CSS2.1 when
> a containing block has an auto height, for example: its width is given by
> the calculations in 10.3.3, but its block size depends on its contents.
> > "
> >
> > I actually believe that I understand the above 2 sentences. But I think
> the adjective "definite" and "indefinite" maybe should be reviewed or
> reconsidered. I would replace "indefinite" by "undefined". Often, in
> CSS2.1, when referring to a block's height dimension which depends on its
> content, the spec would say it's *undefined* at parse time and not
> indefinite.
> >
> > "
> > In such cases the available inline size is defined as the inline size of
> the containing block; but the available block size, which would otherwise
> be the block size of the containing block, is infinite.
> > "
> >
> > The available block size is not *infinite* (the sentence above does not
> make sense to me) but is rather *undefined* at parse time. The block size
> (height) should grow to accomodate content.
> >
> > 'height: auto' in horizontal-tb context and according to CSS2.1 section
> 10.6 [1] and 10.6.3 [2] is often meant or described as "take (or occupy)
> only as much as you need and no more". A sort of an "shrink-to-fit-height".
> >
> > 'width: auto'  in horizontal-tb context and according to CSS2.1 section
> 10.3 [3] and 10.3.3 [4] is often meant or described as "take (or occupy) as
> much as you can". A sort of a
> "use-all-available-width-from-containing-block”.
>
> Yeah, I read them all and I think I understand, but not sure which part
> this case applies.
>
> Can you help?
>
> /koji