Skip to content

[css-borders-4] Add slashes between individual border-color values #8026

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
SebastianZ opened this issue Nov 6, 2022 · 6 comments
Closed

Comments

@SebastianZ
Copy link
Contributor

SebastianZ commented Nov 6, 2022

As mentioned in the change to add the stripes() function, I believe it makes sense to follow the example of grid-area and separate the different longhand values of border-color via slashes.

This makes it easier to distinguish them, especially in regard of the aforementioned new function. And it makes the syntax also more future-proof for further extensions.

The existing one-to-four <color>s syntax still needs to be supported, of course. Though all new features like the <1d-image> values require the values to be separated by slashes. So the suggested syntax is:

<<color>>{1,4} | [ <<color>> | <<1d-image>> ] [ / [ <<color>> | <<1d-image>> ] ]{0,3}

Examples:

border-color: red / yellow / lime / blue;
border-color: stripes(white, silver) / stripes(white, silver) / stripes(black, gray) / stripes(black, gray);
border-color: red / stripes(yellow, orange) / lime / stripes(blue, navy);

Sebastian

@cdoublev
Copy link
Collaborator

cdoublev commented Nov 6, 2022

Aside: maybe a slash ellision rule and/or a multiplier equivalent to # but for / separated values instead of , separated values, could be defined, in order to make writing and parsing these basic syntaxes easier.

@Loirooriol
Copy link
Contributor

Any reason to use [ <<color>>? <<1d-image>>? ]! and not <<color>> || <<1d-image>>?

@SebastianZ
Copy link
Contributor Author

Any reason to use [ <<color>>? <<1d-image>>? ]! and not <<color>> || <<1d-image>>?

The syntax given in the initial comment was actually wrong. It was taken from when I thought of <color> as a fallback value for <1d-image>. Though we concluded that this doesn't have strong use cases and rather complicates the syntax. So I corrected it to be <<color>> | <<1d-image>>.

Sebastian

@SebastianZ
Copy link
Contributor Author

Putting this on the agenda to discuss whether adding slashes - or in general make the syntax more extendable - makes sense.

Sebastian

@SebastianZ SebastianZ changed the title [css-backgrounds-4] Add slashes between individual border-color values [css-borders-4] Add slashes between individual border-color values Aug 8, 2023
@fantasai
Copy link
Collaborator

fantasai commented Aug 9, 2023

I'm a bit confused. If the syntax of border-*-color is <color> | <1d-image>, then why isn't border-color: <'border-top-color'>{1,4} sufficient?

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-borders-4] Add slashes between individual `border-color` values, and agreed to the following:

  • RESOLVED: close no change
The full IRC log of that discussion <fantasai> SebastianZ: My point was that we're adding more features to the border-color shorthand
<fantasai> SebastianZ: to make the syntax more future proof, I suggested to change the syntax for when using features to add slashes between the different values for different sides
<fantasai> SebastianZ: or could be something else, but we already use slashes in border-image and grid-area
<fantasai> SebastianZ: we already added stripes() function, for example; this would make it clearer that they are different values
<emilio> fantasai: I don't think this is necessary, because stripes() is an image
<Rossen_> ack fantasai
<emilio> ... I think if we're going to make border-color more complicated we might want to pull it out into different longhands
<emilio> ... if we want to provide something like you'd do with backgrounds then we should have something else
<emilio> ... in most cases I don't anticipate that people will mix stripes() with other things
<oriol> +1 to elika
<fantasai> Rossen_: seems like good reason to not do this just yet
<fantasai> Rossen_: SebastianZ, anything to add?
<fantasai> Rossen_: otherwise we can resolve no change for now
<fantasai> SebastianZ: I think it's fine. My suggestion was to make it future-proof now rather than later
<fantasai> Rossen_: Proposed resolution is no change
<fantasai> Rossen_: we can return to it later if needed
<fantasai> RESOLVED: close no change

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

5 participants