[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
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

Difference between alias and mapping #220

Open
cdoublev opened this issue Nov 3, 2022 · 9 comments
Open

Difference between alias and mapping #220

cdoublev opened this issue Nov 3, 2022 · 9 comments

Comments

@cdoublev
Copy link
Contributor
cdoublev commented Nov 3, 2022 •
edited
Loading

Sorry to draw attention to such a small detail, but the difference between alias and mapping is not clear to me.

CSS Cascade defines that an alias is replaced by its target and both have the same syntax.

legacy name aliases: when the old property’s value syntax is identical to that of the new property, the two names are aliased with an operation on par with case-mapping: at parse time, the old property is converted into the new property. This conversion also applies in the CSSOM, both for string arguments and property accessors: requests for the old property name transparently transfer to the new property name instead.

The definition of property value aliases is similar, eg. -webkit-image-set() is turned into image-set().

In contrast, browsers preserve mapped values:

style.cssText = '-webkit-align-items: center; -webkit-box-align: center; display: -webkit-box;'
style.cssText;       // 'align-items: center; -webkit-box-align: center; display: -webkit-box;'

I think -webkit-device-pixel-ratio, @-webkit-keyframes, and -webkit-*-gradient() are not aliases, but maps to the corresponding value (media feature name, rule, function).

EDIT

Sorry, both Chrome/Firefox handle -webkit-*-gradient() and -webkit-device-pixel-ratio as mapped values, but Chrome handles @-webkit-keyframes as a mapped rule but Firefox handles it as an alias, which makes me think that the spec is clear but browsers are not always conformant.
@cdoublev
Copy link
Contributor Author
cdoublev commented Nov 3, 2022

Also confusing:

3.4.3. Non-aliased vendor prefixed properties

Note: This section used to specify the -webkit-appearance property. This is now defined in CSS Basic User Interface Module.

But in CSS UI

For compatibility with legacy content, UAs must also support -webkit-appearance as a legacy name alias of appearance.

https://drafts.csswg.org/css-ui/#propdef--webkit-appearance

@karlcow
Copy link
Member
karlcow commented Nov 4, 2022

About -webkit-appearance I wonder if it's because of specs edit

The spec was saying
w3c/csswg-drafts@f78b9c1#diff-cc2f666bf7d93dcefcc3fffc4761793a54fba00c03b53b9dbdf81f5056f0b56eR2242-R2243

Due to substantially different behavior, naïve aliasing of 'appearance' and of ''-webkit-appearance'' is unlikely to work.

So I guess the course has changed.

And probably, we should change this for -webkit-appearance and move it to the aliased properties?

@karlcow
Copy link
Member
karlcow commented Nov 4, 2022

The previous edit in compatibility was done by @zcorpan c497226

Do you agree with moving -webkit-appearance to aliases?
https://compat.spec.whatwg.org/#css-simple-aliases

@karlcow karlcow changed the title Difference between alias an mapping Difference between alias and mapping Nov 4, 2022
@cdoublev
Copy link
Contributor Author
cdoublev commented Nov 4, 2022 •
edited
Loading

So I guess the course has changed.

You are right. Sorry, I did not searched more, if only for the note on the history of the feature, saying that this previously existed in prefixed form in most browsers. This note also says that each browser had its own syntax, so I think it should be treated as a legacy shorthand. EDIT: never mind, appearance accepts all values that CSS UI or browsers defined with their own syntax, so it is fine to make it a simple alias.

As for the other confusing cases, I would be fine with closing this issue by defining the exact meaning of mapping. Specifically, I would like to know if the mapped value should appear in serialization.

@gsnedders
Copy link
Member

The previous edit in compatibility was done by @zcorpan c497226

Do you agree with moving -webkit-appearance to aliases? https://compat.spec.whatwg.org/#css-simple-aliases

If we already have a definition of -webkit-appearance in CSS UI, why also have it defined in Compat?

@cdoublev
Copy link
Contributor Author
cdoublev commented Nov 4, 2022

If we already have a definition of -webkit-appearance in CSS UI, why also have it defined in Compat?

Yeah, I also think that -webkit-apperance should stay in CSS UI, and that the following change would have avoided my confusion on this.

- Note: This section used to specify the -webkit-appearance property. This is now defined in CSS Basic User Interface Module.
+ Note: This section used to specify the -webkit-appearance property. This is now defined in CSS Basic User Interface Module as an alias of `appearance`.

@miketaylr
Copy link
Member

Seems like a useful addition.

@karlcow
Copy link
Member
karlcow commented Nov 8, 2022

If we already have a definition of -webkit-appearance in CSS UI, why also have it defined in Compat?

It's not defined in Compat spec. There's a placeholder redirecting to where it is defined. So people who are following historical links are properly redirected to the right place.

@zcorpan
Copy link
Member
zcorpan commented Nov 8, 2022

I'm OK with moving text around in the compat spec :)

@cdoublev cdoublev mentioned this issue Dec 3, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@miketaylr @gsnedders @zcorpan @karlcow @cdoublev