Details element does not ignore width property when set to display inline
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: xlucas4956, Unassigned, NeedInfo)
Details
Attachments
(1 file)
|
1.11 KB,
text/html
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0
Steps to reproduce:
I had a <details> element with an inline style attribute specifying a width of 384px, and a stylesheet rule that set the display property of the element to inline. As expected, in the CSS toolbox the width rule was greyed out and showed a tooltip specifying that "width has no effect on this element since it has a display of inline".
Actual results:
Despite that, the element still displays at exactly 384px. If the width rule is disabled, it shrinks to its minimum size as would be expected in the first place.
Expected results:
If the width rule has no effect on an element set to display inline, then the rule should be actually be ignored and the <details> element should not display at a specified width greater than fit-content.
Hello, thank you for the bug report!
Would it be possible to provide a testcase that reproduces the issue?
Moving the Product to ‘Core’ and Component to ‘Layout’. Please change if there’s a better fit, thank you.
|
Reporter | |
Comment 2•2 years ago
|
||
|
|
Reporter | |
Comment 3•2 years ago
|
||
Comment on attachment 9403643 [details]
A simple HTML file demonstrating the bug
Here is a simple example of the bug in a standalone HTML document.
|
||
Comment 4•2 years ago
|
||
This is, as far as I can tell, the correct behavior right now:
https://html.spec.whatwg.org/#the-details-and-summary-elements:
The details element is expected to render as a block box.
See also bug 1856374 (we have a pref to support this properly), and https://github.com/whatwg/html/issues/9830 which is the relevant HTML specification issue.
David, this seems like a Blink bug where you somehow not paint the background properly? DevTools in Blink still says the element is 500px, but getBoundingClientRect says otherwise. Something seems very confused? Also, if you remove the <p>, the text doesn't flow next to the <details>, reinforcing the theory that Blink is just very confused about what that box is.
|
|
Reporter | |
Comment 5•2 years ago
|
||
If that is the correct behavior, then is the Inspector CSS Rules tool not incorrect for stating that "width has no effect on this element since it has a display of inline"?
|
|
||
Comment 6•2 years ago
|
||
That is a bug in the inspector, because this is a rather special case and it doesn't have code for it. Since it's a special case we want to remove as per the above I don't think adding that special case to the inspector is worth it.
Note that there are a bunch of Blink changes (see chromestatus entry) that are implemented but not yet shipped, but which I'm hoping to ship relatively soon (within the next few releases, I hope -- still needs a bunch of work to happen on the standards side and on the code side). You can enable them either with the experimental web platform features option (in settings or command line flag) or with --enable-blink-features=DetailsStyling.
I'm guessing you're talking about the Blink behavior without those changes. (That said, I'm not at my work machine right now so I can't test.)
|
|
||
Comment 8•2 years ago
|
||
Correct, I expect your changes to fix that.
Description
•