Open Bug 1230975 Opened 9 years ago Updated 2 years ago

percentage width is huge in orthogonal flow (writing-mode)

Categories

(Core :: Layout: Block and Inline, defect)

defect

Tracking

()

People

(Reporter: MatsPalmgren_bugz, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: testcase)

Attachments

(1 file, 1 obsolete file)

Attached file testcase (obsolete) (deleted) —
STR 1. load the attached testcase ACTUAL RESULTS The horizontal block has a huge width (I'm guessing 30% of nscoord_MAX). EXPECTED RESULTS the width should be ~30% of the viewport width (Chrome Canary renders this as I would expect, fwiw)
Attached file testcase (deleted) —
Simplified testcase.
Attachment #8696501 - Attachment is obsolete: true
> EXPECTED RESULTS > the width should be ~30% of the viewport width Actually, it should probably just be ignored since it's a percentage of an unconstrained size. So shrink-wrapping the width (like width:auto) might be the correct layout.
Blocks: writing-mode
> Simplified testcase. attachment 8696502 [details] is not a perfectly simplified test because <div class="parent"> itself is a block in orthogonal context. - - - - - - - http://www.gtalbot.org/BugzillaSection/Bug1230975-percentage-width-orthog-flow.xht In Chrome 57.0.2950.4, the rendered width of <div id="child-htb"> varies depending on, depends on the height of the browser viewport. Right now, it is not clear to me what the expected rendered layout should be.
Doesn't the second paragraph of 7.3.1 apply here? https://drafts.csswg.org/css-writing-modes/#orthogonal-auto The inner 30% would be resolved against the ICB because the available space is infinite.
> Doesn't the second paragraph of 7.3.1 apply here? > https://drafts.csswg.org/css-writing-modes/#orthogonal-auto Yes, 2nd parg should apply. In my opinion, section 7.3.1 seems like the verbal justification and explanations of equations of section 7.3.2. The closest test I created that resembled Mats' test is: http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s732-sizing-orthog-htb-in-vlr-008.xht and Firefox 53.0a1 (buildID=20161222030229) passes. Mats' test uses a nested orthogonal block. > The inner 30% would be resolved against the ICB because the available space > is infinite. Yes. contraint: min(available space, initial containing block's size) available space: this is either a measurement of its containing block (if that is definite) or an infinite size (when it is indefinite). https://drafts.csswg.org/css-sizing-4/#available In Mats' test, div.parent's width is 'auto', so it is indefinite. In the constraint equation, this is considered infinite. Since the width of the containing block is indefinite in this test, then constrain is the width of initial containing block which is, in this test, equal to the width of the viewport. Again, Firefox 53.0a1 fails, as far as I can see, because of nested orthogonal blocks; otherwise, it passes s732-sizing-orthog-htb-in-vlr-008.xht and other sizing-orthog-htb-in-vlr tests[1] involving inline-size set to a percentage (50%) applied to an orthogonal block. [1]: http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s732-sizing-orthog-htb-in-vlr-004.xht (has 1 sentence before and after) http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s732-sizing-orthog-htb-in-vlr-020.xht (has 1 sentence before and after and <body> has 0px horizontal margins) http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s732-sizing-orthog-htb-in-vlr-024.xht (has no sentence before and after and <body> has 0px horizontal margins)
> In my opinion, section 7.3.1 seems like the > verbal justification and explanations of equations of section 7.3.2. I got that wrong. Only section 7.3.1 refers to percentage; section 7.3.2 only refers to 'auto' inline-size. This distinction is very important here. > The closest test I created that resembled Mats' test is: > > http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s732-sizing- > orthog-htb-in-vlr-008.xht > > and Firefox 53.0a1 (buildID=20161222030229) passes. Mats' test uses a nested > orthogonal block. > > > The inner 30% would be resolved against the ICB because the available space > > is infinite. > > Yes. Yes. The inner 'width: 30%' (and not the outer edges: that's section 7.3.2... a real source of possible confusion IMO) should be resolved against the width of the ICB. > contraint: min(available space, initial containing block's size) > > available space: this is either a measurement of its containing block > (if that is definite) or an infinite size (when it is indefinite). > https://drafts.csswg.org/css-sizing-4/#available > > In Mats' test, div.parent's width is 'auto', so it is indefinite. In the > constraint equation, this is considered infinite. > > Since the width of the containing block is indefinite in this test, then > constrain is the width of initial containing block which is, in this test, > equal to > the width of the viewport. > > Again, Firefox 53.0a1 fails, as far as I can see, because of nested > orthogonal blocks; otherwise, it passes > s732-sizing-orthog-htb-in-vlr-008.xht and other sizing-orthog-htb-in-vlr > tests[1] involving inline-size set to a percentage (50%) applied to an > orthogonal block. > > [1]: > http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s732-sizing- > orthog-htb-in-vlr-004.xht > (has 1 sentence before and after) > > http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s732-sizing- > orthog-htb-in-vlr-020.xht > (has 1 sentence before and after and <body> has 0px horizontal margins) > > http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s732-sizing- > orthog-htb-in-vlr-024.xht > (has no sentence before and after and <body> has 0px horizontal margins) I need to work on those tests and then place them in section 7.3.1 and not section 7.3.2.
> I need to work on those tests and then place them in section 7.3.1 and not > section 7.3.2. Just a quick follow-up on that comment, mostly for Mats Palmgren. I created and submitted 32 tests in section 7.3.1 and 80 tests in section 7.3.2: Re: [css-writing-modes-3] 112 new sizing orthogonal tests in section 7.3.1 and section 7.3.2 http://lists.w3.org/Archives/Public/public-css-testsuite/2017Jan/0001.html Mats Palmgren's test (attachment 8696502 [details]) in this bug report is a special case of nested orthogonal blocks and, by itself, it is a special case of sizing orthogonal block with a percentage value.
OS: Unspecified → All
Hardware: Unspecified → All
Version: unspecified → Trunk
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: