Skip to content

[css-backgrounds-4] Initial value of 'background-position-y' should be 'top' #1208

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.

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

Closed
kuoe0 opened this issue Apr 12, 2017 · 4 comments
Closed

Comments

@kuoe0
Copy link

kuoe0 commented Apr 12, 2017

I found the initial value of background-position-y defined in spec is wrong. I think it should be top.

See: https://drafts.csswg.org/css-backgrounds-4/#background-position-longhands

@LeaVerou
Copy link
Member

Yup, that's certainly a spec bug. For those wondering: The current value listed is ...left 😂

@cdoublev
Copy link
Collaborator

cdoublev commented Sep 8, 2022

This has been fixed in eca3884 therefore this issue can be closed, but I would like to take this opportunity to ask why the initial background-position-inline|block value is not start (ie. the position where you start reading) instead of not applicable (initial value comes from physical property)?

@SebastianZ
Copy link
Contributor

You're right. All other specs that define logical properties also specify their initial values. So I went ahead and changed it to 0% in 39e7612. I chose 0% rather than start because all other logical properties also use the initial value of their physical counterparts.

Sebastian

@cdoublev
Copy link
Collaborator

cdoublev commented Sep 9, 2022

Thanks. Indeed, resolving the writing mode at specified value time seemed problematic to me. For example, when background: center appears in a style sheet, background-position-block|inline must reset to its initial value.

Other logical properties seem to be mostly defining distance values, not a position like background-position, mask-position, or scroll-start. The latter has scroll-start-block|inline defined with auto as its initial value but there is no associated definition. Shorthand encompassing both flow-relative and physical properties should map to their physical sub-properties after their flow-relative sub-properties, therefore the initial value of the latter will not affect the formers. But anyway, 0% is fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants