Open Bug 1237150 Opened 4 years ago Updated 3 years ago
[css-align] Store 'safe'/'unsafe' <overflow-position> as a boolean value
We currently use two separate bits (NS_STYLE_ALIGN_SAFE/UNSAFE) to encode a 'safe'/'unsafe' <overflow-position>. This is no longer necessary since 'unsafe' is now the default for all box types (and thus there is no need to encode the absence of a value). We should keep NS_STYLE_ALIGN_SAFE being set to mean 'safe' was explicitly specified, and the bit being zero for 'unsafe' was specified or no <overflow-position> was specified. It might be worth waiting a while before making this change though, until CSS Align have stabilized. (I wouldn't be surprised if the spec changes this again in the future.)
I got a mail from fantasai saying that they might revert the decision to make 'safe' the default everywhere, so we should wait changing anything related to that (including this bug) for a while.
Following up on comment 1 -- the spec currently says: > <overflow-position> = unsafe | safe > [...] > If the overflow alignment isn’t explicitly specified, > the default overflow alignment is similar to 'unsafe' [...] however [...] https://drafts.csswg.org/css-align-3/#overflow-values So, it still considers "the absence of a value" as a distinct state (different from safe|unsafe) with its own distinct behavior. ALSO, the whole <overflow-position> feature is marked as at-risk (and the absence-of-a-value behavior is also called out separately): > The following features are at-risk, and may be dropped during the CR period: > [...] the <overflow-position> keywords, the scrollable-area safety trigger > into safe mode when no <overflow-position> is specified So, this bug might be INVALID (either because our current behavior is correct, or because the feature as a whole is punted from this level of the spec, in which case we might want to toggle <overflow-position> support off).
You need to log in before you can comment on or make changes to this bug.