Open Bug 1237150 Opened 4 years ago Updated 3 years ago

[css-align] Store 'safe'/'unsafe' <overflow-position> as a boolean value

Categories

(Core :: CSS Parsing and Computation, defect, P4, trivial)

defect

Tracking

()

Tracking Status
firefox46 --- affected

People

(Reporter: mats, Unassigned)

Details

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.)
Priority: -- → P4
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.