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

[css-position] Confusing conditions in "§4.1. Automatic Sizes of Absolutely-Positioned Boxes" #6580

Closed
Loirooriol opened this issue Sep 4, 2021 · 3 comments
Closed

[css-position] Confusing conditions in "§4.1. Automatic Sizes of Absolutely-Positioned Boxes" #6580

Loirooriol opened this issue Sep 4, 2021 · 3 comments
Labels
Closed Accepted as Obvious Bugfix Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-position-3 Current Work

Comments

@Loirooriol
Copy link
Contributor

https://drafts.csswg.org/css-position/#abspos-auto-size

↪ If its self-alignment property in the relevant axis is stretch
↪ If it is normal and the box is non-replaced and has no auto inset in the relevant axis
    Its automatic size is its stretch-fit size.

↪ If its self-alignment property in the relevant axis is not stretch
↪ If it is normal and the box is replaced
↪ If it is normal and has at least one auto inset in the relevant axis
    Its automatic size is its fit-content size.

The 3 last conditions are confusing, because:

  • "If its self-alignment property in the relevant axis is not stretch" overlaps with the previous "If it is normal and the box is non-replaced and has no auto inset in the relevant axis" which has a different definition.
  • "If it is normal and the box is replaced" and "If it is normal and has at least one auto inset in the relevant axis" are a subset of "If its self-alignment property in the relevant axis is not stretch" so they seem useless.

Seems it should just be

↪ If its self-alignment property in the relevant axis is stretch
↪ If it is normal and the box is non-replaced and has no auto inset in the relevant axis
    Its automatic size is its stretch-fit size.

↪ Otherwise
    Its automatic size is its fit-content size.
@Loirooriol Loirooriol added the css-position-3 Current Work label Sep 4, 2021
@Loirooriol
Copy link
Contributor Author

Or if you want to keep the explicit conditions,

↪ If its self-alignment property in the relevant axis is stretch
↪ If it is normal and the box is non-replaced and has no auto inset in the relevant axis
    Its automatic size is its stretch-fit size.

↪ If its self-alignment property in the relevant axis is not stretch ***nor normal***
↪ If it is normal and the box is replaced
↪ If it is normal and has at least one auto inset in the relevant axis
    Its automatic size is its fit-content size.

@bfgeek
Copy link

bfgeek commented Sep 8, 2021 •
edited
Loading

The conditions at the moment are a little incomplete.

E.g. tables should shrink-fit, also the "semi-replaced" elements, e.g. <button>s.

<!DOCTYPE html>
<div style="width: 100px; height: 100px; border: solid; position: relative;">
  <div style="position: absolute; background: hotpink; inset: 0;">block</div>
</div>

<div style="width: 100px; height: 100px; border: solid; position: relative;">
  <div style="display: table; position: absolute; background: hotpink; inset: 0;">table</div>
</div>

<div style="width: 100px; height: 100px; border: solid; position: relative;">
  <button style="position: absolute; background: hotpink; inset: 0;">button</button>
</div>

Edit:
(for the <button> I agree with WebKit's rendering here, we may have regressed this).

(for the <button> we should move to be consistent between axes, i'd prefer a table like handling).

tabatkins added a commit that referenced this issue Oct 27, 2021
@tabatkins
[css-position-3][editorial] Be less specific about conditions so they…
2af18d0 
… don't confusingly overlap with preceding ones. #6580
tabatkins added a commit that referenced this issue Oct 27, 2021
@tabatkins
[css-position-3] Per #6580 (comment), tables need to shrink-wrap as w…
c69b21a 
…ell.
@tabatkins
Copy link
Member

@Loirooriol We went ahead and just collapsed the secondary conditions to "otherwise" as you suggested. The point of listing them out was to be a little clearer about what exactly triggers that case, but having to be overly-specific to avoid clashing with the preceding conditions negates that somewhat.

@bfgeek Added the table case. For buttons and inputs, behavior seems inconsistent across browsers; in particular, it seems WebKit just treats buttons (and inputs) like any other box, so seems like that would be a reasonable direction to go in given the other browsers are very inconsistent? In any case, should be a separate issue if we need to address anything in the spec.

@Loirooriol Loirooriol added Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. and removed Commenter Response Pending labels Oct 27, 2021
@bfgeek bfgeek mentioned this issue Nov 2, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Accepted as Obvious Bugfix Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-position-3 Current Work
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@tabatkins @bfgeek @Loirooriol