Open BorisChiou opened 1 year ago
@BorisChiou It looks like browsers ended up implementing the current syntax. So it's probably too late to move <'offset-position'>
together with <'offset-anchor'>
. Though maybe an HTTP archive check could proof the opposite.
Do I understand you correctly that you want to change the syntax to the following?
<'offset-path'> [ <'offset-distance'> || <'offset-rotate'> ]? [ / [ <'offset-anchor'> || <'offset-position'> ]?
Sebastian
Yeah! The syntax you provided,
<'offset-path'> [ <'offset-distance'> || <'offset-rotate'> ]? [ / [ <'offset-anchor'> || <'offset-position'> ]?
looks much better than the original one because offset-position
is ignored if we don't have an valid offset-path
.
The design idea of the current shorthand syntax is because offset-position
may create a stacking context, and it could be used independently. However, we change its meaning in 2023 but we probably forgot to change the shorthand at the same time.
Ok, so this needs a check for whether the change is web-compatible, then. https://chromestatus.com/metrics/css/timeline/popularity/543 indicates a quickly growing percentage of pages using offset
.
Anyone able to do a more granular HTTP Archive query to get numbers on this?
What's needed is a check on usages of <'offset-position'>
value usages in the offset
shorthand property, or more precisely, the combination <'offset-position'> <'offset-path'>
.
Sebastian
After the updating of
offset-position
andoffset-path
, we have the offset transform (and create stacking context) only whenoffset-path
is notnone
.offset-position
is used only whenoffset-path
functions don't specify the offset starting position.So the current syntax of
offset
shorthand is out-of-date.The exclamation point (
!
) doesn't make sense now. It's not necessary to haveoffset-position
if we don't specifyoffset-path
. Perhaps we should always specifyoffset-path
, and moveoffset-position
together withoffset-anchor
or other places?