Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Replaced content percentage height resolution inside tables #46

Open
mstensho opened this issue Jun 18, 2019 · 3 comments
Open

Replaced content percentage height resolution inside tables #46

mstensho opened this issue Jun 18, 2019 · 3 comments

Comments

@mstensho
Copy link

There's an undocumented quirk regarding percentage block-size replaced elements inside table cells. This quirk is implemented by EdgeHTML, Chromium, and WebKit (but not Gecko, it seems, at least not with the test I'm presenting here):

<!-- quirks mode -->
<style>
  .cell {
    display: table-cell;
    width: 400px;
    height: 400px;
    background: red;
  }

  .descendant {
    display: block;
    margin: 0;
    border: none;
    padding: 0;
    width: 100%;
    height: 100%;
    background: green;
  }
</style>

<p>Green square below?</p>
<div class="cell">
  <div>
    <iframe class="descendant"></iframe>
  </div>
</div>

The percentage height specified on .cell is used to resolve the height of .descendant. This doesn't happen if .descendant is a DIV instead of an IFRAME.

This quirk is not documented at https://quirks.spec.whatwg.org/
@zcorpan
Copy link
Member

zcorpan commented Jun 18, 2019

Interesting. Is the quirk needed for web compat?

@mstensho
Copy link
Author

I don't know. Chromium only has two tests that depend on this [*]:

  • tables/mozilla/bugs/bug137388-2.html
  • tables/mozilla/bugs/bug137388-3.html

[*] I tried to remove it to see what happened: https://chromium-review.googlesource.com/c/chromium/src/+/1662410

Pretty interesting with "mozilla" in the name, since I just suggested that this quirk doesn't exist in Gecko. I guess it does / did, to some extent, then.

Following the bug number in the name of those tests:
https://bugzilla.mozilla.org/show_bug.cgi?id=137388

So.. I guess this mattered 17 years ago, at least. :)

Digging through the change log of Blink could potentially provide some hints (I know we've attempted to fix table compat issues recently (I mean this decade), and probably crossed paths with this quirk), although test coverage is rather poor.

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jun 18, 2019
@mstensho @chromium-wpt-export-bot
[LayoutNG] Skip "replaced % resolution" quirk on ortho-roots.
7e9aa74 
This is about an undocumented quirk. I raised
whatwg/quirks#46 for it.

LayoutNG currently cannot handle this situation, because we don't store
the inline-size to use in replaced percentage resolution (only the
block-size). However, I find it hard to believe that there'd be any
specific expectations to how this is supposed to work if a table cell
has a definite block-size, and a descendant establishes an orthogonal
writing-mode root. So just ignore it and use regular percentage size
resolution in these cases.

Bug: 967069
Change-Id: Iac61abe80f4f949017cc161855b2223ec4503812
Merged
@zcorpan
Copy link
Member

zcorpan commented Jun 18, 2019

https://quirks.spec.whatwg.org/#the-percentage-height-calculation-quirk basically avoids defining what should happen with tables. Now that https://drafts.csswg.org/css-tables/ exists, it could maybe be better defined.

aarongable pushed a commit to chromium/chromium that referenced this issue Jun 18, 2019
@mstensho
[LayoutNG] Skip "replaced % resolution" quirk on ortho-roots.
3aafabb 
This is about an undocumented quirk. I raised
whatwg/quirks#46 for it.

LayoutNG currently cannot handle this situation, because we don't store
the inline-size to use in replaced percentage resolution (only the
block-size). However, I find it hard to believe that there'd be any
specific expectations to how this is supposed to work if a table cell
has a definite block-size, and a descendant establishes an orthogonal
writing-mode root. So just ignore it and use regular percentage size
resolution in these cases.

Bug: 967069
Change-Id: Iac61abe80f4f949017cc161855b2223ec4503812
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1664075
Reviewed-by: Ian Kilpatrick <[email protected]>
Reviewed-by: Christian Biesinger <[email protected]>
Commit-Queue: Morten Stenshorne <[email protected]>
Cr-Commit-Position: refs/heads/master@{#670126}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jun 18, 2019
@mstensho @chromium-wpt-export-bot
[LayoutNG] Skip "replaced % resolution" quirk on ortho-roots.
a0ea38f 
This is about an undocumented quirk. I raised
whatwg/quirks#46 for it.

LayoutNG currently cannot handle this situation, because we don't store
the inline-size to use in replaced percentage resolution (only the
block-size). However, I find it hard to believe that there'd be any
specific expectations to how this is supposed to work if a table cell
has a definite block-size, and a descendant establishes an orthogonal
writing-mode root. So just ignore it and use regular percentage size
resolution in these cases.

Bug: 967069
Change-Id: Iac61abe80f4f949017cc161855b2223ec4503812
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1664075
Reviewed-by: Ian Kilpatrick <[email protected]>
Reviewed-by: Christian Biesinger <[email protected]>
Commit-Queue: Morten Stenshorne <[email protected]>
Cr-Commit-Position: refs/heads/master@{#670126}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jun 18, 2019
@mstensho @chromium-wpt-export-bot
[LayoutNG] Skip "replaced % resolution" quirk on ortho-roots.
361912d 
This is about an undocumented quirk. I raised
whatwg/quirks#46 for it.

LayoutNG currently cannot handle this situation, because we don't store
the inline-size to use in replaced percentage resolution (only the
block-size). However, I find it hard to believe that there'd be any
specific expectations to how this is supposed to work if a table cell
has a definite block-size, and a descendant establishes an orthogonal
writing-mode root. So just ignore it and use regular percentage size
resolution in these cases.

Bug: 967069
Change-Id: Iac61abe80f4f949017cc161855b2223ec4503812
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1664075
Reviewed-by: Ian Kilpatrick <[email protected]>
Reviewed-by: Christian Biesinger <[email protected]>
Commit-Queue: Morten Stenshorne <[email protected]>
Cr-Commit-Position: refs/heads/master@{#670126}
marcoscaceres pushed a commit to web-platform-tests/wpt that referenced this issue Jul 23, 2019
@mstensho
[LayoutNG] Skip "replaced % resolution" quirk on ortho-roots.
e1472e7 
This is about an undocumented quirk. I raised
whatwg/quirks#46 for it.

LayoutNG currently cannot handle this situation, because we don't store
the inline-size to use in replaced percentage resolution (only the
block-size). However, I find it hard to believe that there'd be any
specific expectations to how this is supposed to work if a table cell
has a definite block-size, and a descendant establishes an orthogonal
writing-mode root. So just ignore it and use regular percentage size
resolution in these cases.

Bug: 967069
Change-Id: Iac61abe80f4f949017cc161855b2223ec4503812
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1664075
Reviewed-by: Ian Kilpatrick <[email protected]>
Reviewed-by: Christian Biesinger <[email protected]>
Commit-Queue: Morten Stenshorne <[email protected]>
Cr-Commit-Position: refs/heads/master@{#670126}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jul 24, 2019
@mstensho @jgraham
Bug 1560872 [wpt PR 17381] - [LayoutNG] Skip "replaced % resolution" …
1fd6c22 
…quirk on ortho-roots., a=testonly

Automatic update from web-platform-tests
[LayoutNG] Skip "replaced % resolution" quirk on ortho-roots.

This is about an undocumented quirk. I raised
whatwg/quirks#46 for it.

LayoutNG currently cannot handle this situation, because we don't store
the inline-size to use in replaced percentage resolution (only the
block-size). However, I find it hard to believe that there'd be any
specific expectations to how this is supposed to work if a table cell
has a definite block-size, and a descendant establishes an orthogonal
writing-mode root. So just ignore it and use regular percentage size
resolution in these cases.

Bug: 967069
Change-Id: Iac61abe80f4f949017cc161855b2223ec4503812
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1664075
Reviewed-by: Ian Kilpatrick <[email protected]>
Reviewed-by: Christian Biesinger <[email protected]>
Commit-Queue: Morten Stenshorne <[email protected]>
Cr-Commit-Position: refs/heads/master@{#670126}

--

wpt-commits: 361912dbe4ef692ea256b6f5bc0d74c0668ccdf5
wpt-pr: 17381
xeonchen pushed a commit to xeonchen/gecko that referenced this issue Jul 25, 2019
@mstensho @jgraham
Bug 1560872 [wpt PR 17381] - [LayoutNG] Skip "replaced % resolution" …
a5bb8da 
…quirk on ortho-roots., a=testonly

Automatic update from web-platform-tests
[LayoutNG] Skip "replaced % resolution" quirk on ortho-roots.

This is about an undocumented quirk. I raised
whatwg/quirks#46 for it.

LayoutNG currently cannot handle this situation, because we don't store
the inline-size to use in replaced percentage resolution (only the
block-size). However, I find it hard to believe that there'd be any
specific expectations to how this is supposed to work if a table cell
has a definite block-size, and a descendant establishes an orthogonal
writing-mode root. So just ignore it and use regular percentage size
resolution in these cases.

Bug: 967069
Change-Id: Iac61abe80f4f949017cc161855b2223ec4503812
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1664075
Reviewed-by: Ian Kilpatrick <[email protected]>
Reviewed-by: Christian Biesinger <[email protected]>
Commit-Queue: Morten Stenshorne <[email protected]>
Cr-Commit-Position: refs/heads/master@{#670126}

--

wpt-commits: 361912dbe4ef692ea256b6f5bc0d74c0668ccdf5
wpt-pr: 17381
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Oct 4, 2019
@marco-c
Bug 1560872 [wpt PR 17381] - [LayoutNG] Skip "replaced % resolution" …
e873489 
…quirk on ortho-roots., a=testonly

Automatic update from web-platform-tests
[LayoutNG] Skip "replaced % resolution" quirk on ortho-roots.

This is about an undocumented quirk. I raised
whatwg/quirks#46 for it.

LayoutNG currently cannot handle this situation, because we don't store
the inline-size to use in replaced percentage resolution (only the
block-size). However, I find it hard to believe that there'd be any
specific expectations to how this is supposed to work if a table cell
has a definite block-size, and a descendant establishes an orthogonal
writing-mode root. So just ignore it and use regular percentage size
resolution in these cases.

Bug: 967069
Change-Id: Iac61abe80f4f949017cc161855b2223ec4503812
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1664075
Reviewed-by: Ian Kilpatrick <ikilpatrickchromium.org>
Reviewed-by: Christian Biesinger <cbiesingerchromium.org>
Commit-Queue: Morten Stenshorne <mstenshochromium.org>
Cr-Commit-Position: refs/heads/master{#670126}

--

wpt-commits: 361912dbe4ef692ea256b6f5bc0d74c0668ccdf5
wpt-pr: 17381

UltraBlame original commit: 404f92fcf1dd5294fae238edc14f184e1cdcd6a0
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Oct 4, 2019
@marco-c
Bug 1560872 [wpt PR 17381] - [LayoutNG] Skip "replaced % resolution" …
1b589f7 
…quirk on ortho-roots., a=testonly

Automatic update from web-platform-tests
[LayoutNG] Skip "replaced % resolution" quirk on ortho-roots.

This is about an undocumented quirk. I raised
whatwg/quirks#46 for it.

LayoutNG currently cannot handle this situation, because we don't store
the inline-size to use in replaced percentage resolution (only the
block-size). However, I find it hard to believe that there'd be any
specific expectations to how this is supposed to work if a table cell
has a definite block-size, and a descendant establishes an orthogonal
writing-mode root. So just ignore it and use regular percentage size
resolution in these cases.

Bug: 967069
Change-Id: Iac61abe80f4f949017cc161855b2223ec4503812
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1664075
Reviewed-by: Ian Kilpatrick <ikilpatrickchromium.org>
Reviewed-by: Christian Biesinger <cbiesingerchromium.org>
Commit-Queue: Morten Stenshorne <mstenshochromium.org>
Cr-Commit-Position: refs/heads/master{#670126}

--

wpt-commits: 361912dbe4ef692ea256b6f5bc0d74c0668ccdf5
wpt-pr: 17381

UltraBlame original commit: 404f92fcf1dd5294fae238edc14f184e1cdcd6a0
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Oct 4, 2019
@marco-c
Bug 1560872 [wpt PR 17381] - [LayoutNG] Skip "replaced % resolution" …
36b3902 
…quirk on ortho-roots., a=testonly

Automatic update from web-platform-tests
[LayoutNG] Skip "replaced % resolution" quirk on ortho-roots.

This is about an undocumented quirk. I raised
whatwg/quirks#46 for it.

LayoutNG currently cannot handle this situation, because we don't store
the inline-size to use in replaced percentage resolution (only the
block-size). However, I find it hard to believe that there'd be any
specific expectations to how this is supposed to work if a table cell
has a definite block-size, and a descendant establishes an orthogonal
writing-mode root. So just ignore it and use regular percentage size
resolution in these cases.

Bug: 967069
Change-Id: Iac61abe80f4f949017cc161855b2223ec4503812
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1664075
Reviewed-by: Ian Kilpatrick <ikilpatrickchromium.org>
Reviewed-by: Christian Biesinger <cbiesingerchromium.org>
Commit-Queue: Morten Stenshorne <mstenshochromium.org>
Cr-Commit-Position: refs/heads/master{#670126}

--

wpt-commits: 361912dbe4ef692ea256b6f5bc0d74c0668ccdf5
wpt-pr: 17381

UltraBlame original commit: 404f92fcf1dd5294fae238edc14f184e1cdcd6a0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@zcorpan @mstensho