-
Notifications
You must be signed in to change notification settings - Fork 16
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.
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
Replaced content percentage height resolution inside tables #46
Comments
Interesting. Is the quirk needed for web compat? |
I don't know. Chromium only has two tests that depend on this [*]:
[*] 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: 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. |
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
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. |
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 <ikilpatrick@chromium.org> Reviewed-by: Christian Biesinger <cbiesinger@chromium.org> Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#670126}
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 <ikilpatrick@chromium.org> Reviewed-by: Christian Biesinger <cbiesinger@chromium.org> Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#670126}
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 <ikilpatrick@chromium.org> Reviewed-by: Christian Biesinger <cbiesinger@chromium.org> Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#670126}
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 <ikilpatrick@chromium.org> Reviewed-by: Christian Biesinger <cbiesinger@chromium.org> Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#670126}
…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 <ikilpatrick@chromium.org> Reviewed-by: Christian Biesinger <cbiesinger@chromium.org> Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#670126} -- wpt-commits: 361912dbe4ef692ea256b6f5bc0d74c0668ccdf5 wpt-pr: 17381
…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 <ikilpatrick@chromium.org> Reviewed-by: Christian Biesinger <cbiesinger@chromium.org> Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#670126} -- wpt-commits: 361912dbe4ef692ea256b6f5bc0d74c0668ccdf5 wpt-pr: 17381
…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
…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
…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
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):
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/
The text was updated successfully, but these errors were encountered: