[css-backgrounds] 'border' shorthand resets 'border-image' but can't set it

[therealglazou]

'border' shorthand resets 'border-image' but can't set it and this is a big problem because this is NOT web authors' expectation. I am getting a lot of user feedback about it, and pretty aggressive I must say. Please see https://lists.w3.org/Archives/Public/www-style/2017Nov/0018.html and thread for more details.

[css-meeting-bot]

The Working Group just discussed Shorthands resetting properties they cannot set.

The full IRC log of that discussion

<dael> Topic: Shorthands resetting properties they cannot set
<dael> github: https://github.com//issues/2108
<dael> glazou: With the intro of border-image and border resetting it but not setting it I started getting feedback from unhappy users where when the set the default border they don't get the border shorthand anymore. Even after I expl they don't accept it.
<fantasai> fwiw, I agree with fremy/Florian/AmeliaBr's comments on the www-style thread.
<dael> glazou: I got agressive feedback that the web is about border and no one cares about border image. Beyond the tone, they have a point. WE changed something that worked in one way for many years and it does impact how people edit the stylesheet.
<dael> glazou: border-image usage is almost 0. The designers that pinged me replied almost always no we don't use it.
<dael> glazou: It's a steamroller to kill a fly
<bradk> 😢
<dael> glazou: In the case of border I think we made a mistake. The argument about :blank was don't change things for web compat and here we changed a thing without caring about compat and we have a problem.
<dael> florian: What I'm struggling to understand...if we take into account the few people that use border-image it does make sense. Is the argument that we should remove border-image? I don't htink you're saying that. But if we don't I feel like the behavior for people who do use it is something we need to care about. Both situations are bad. I don't want to disagree but I feel alternative is worse.
<dael> glazou: Let's talk stats. border is on 99% of website, but border-image is 0.0something % and mostly with initial value. I think numbers should favor 99%
<Rossen> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/?q=border-image
<dael> florian: But within 99% it's a smaller group. It's those who manipluate in a certain way.
<AmeliaBR> Has anyone made a list of other shorthands that have similar behavior? Font is one (with respect to new font-variant properties), but I think it should be possible to allow the full font-variant options to be specified without breaking anything.
<dael> glazou: We're breaking habits of people writing the technology. They have the habit of being able to define 4 borders and ge the thoserhand. IT's not happening anymore. We're breaking the way they work.
<dael> florian: Not 99%. Not everyone uses graphical editors.
<dael> glazou: I agree, but anyone who manipulates OM gets a border-image.
<Rossen> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/border-image-repeat/
<Rossen> I suggest looking at the data a bit more before making the call
<dael> dbaron: Back whenwe changed border-image syntax and I'm guessing like in 2012 we had significant compat problems. That was 5 years ago. There's real usage and I don't see how we change this without causing as much problems today.
<dael> Rossen: Quick scan of border-image-repeat is used 63% with things like youtube, msn. I wouldn't say border-image isn't used.
<dael> glazou: But border-image source is almost unused.
<dael> glazou: I'm proposing to stop resetting border-image with border shorthand
<dbaron> my post from 2012, which I had to cite a lot in response to compat problems, was https://dbaron.org/log/20120612-border-image
<dael> fantasai: Alternative. Issue is we have boder:this rule then we use border top blue, why do we have to split it out? It seems like a lot of writing that doesn't need to happen.
<dael> florian: Through graphical tools people click on each border seperately and expect that to synth into shorthand.
<dael> florian: It's valid, I don't buy it's dominante
<dael> Rossen: In this use case I set only top border I do using the short hand? That makes no sense.
<dael> glazou: No, when you jsut do border top you use border-top. But when you want to do t/l/r/b you want to use the border shorthand.
<fantasai> border: thin solid red + border-top: solid blue doesn't need to split everything into longhands. It can just be serialized out as 'border: thin solid red; border-top: solid blue'
<dael> Rossen: There's one way to represent things during editing and represent fidelity of what's been changed. THere is a different case of what do you do when you export the final style sheet that you have serialized based on what the user did.
<dael> Rossen: If we're talking about the export and you want to re-importit and change it, because you export shorthands as much as possible, which is great, but if this is the motivational example where you have to round trip the shorthand, that is a stretch.
<dael> glazou: Motivation for change, there are quite a few projects embedding chrome or moz. to do specific positioning editors. All will hit this issue and all will need to impl a hack bc/ this is not what web designers expect. We have messages from web designers and we're not listening.
<dael> glazou: WE did this alone and did this at a time without wed designer feedback. Now we have it and we're not listening.
<dael> glazou: It strikes me that we're trying to gather web designer feedback at conferences, but here we have feedback and we'r enot lsitening.
<dael> fantasai: Feedback of outputting these longhands is reasonable. You should output something closer to how a hand user would od it.
<dael> glazou: This is not true. We changed a 21 year old behavior.
<dael> fantasai: It's been like that for a while. border and abackgrounds and border-image have been like that since we went to CR.
<dael> glazou: And people are seeing it only now. And people are really upset. They do not accept the explinations. It's the first time I got insults.
<dael> glazou: Do waht you want but we cannot ask for feedback, get agressive feedback, and say wellll
<dael> fantasai: It's not jsut border-image. There will be additional things and thye'll get output too.
<dael> glazou: We have a chance between resetting or putting a warning in the specsaying you should make sure you put out the right thing. WEb designers thought second was better.
<fantasai> http://glazman.org/tmp/border-shorthand.html shows the addition of a simple rule blows up the shorthand. Whether border-image is part of that blow-up or not, it still blows up.
<fantasai> The solution isn't to change what's reset, it's to not blow up the shorthand.
<dael> Rossen: Can I propose something? First, thank you for bringing this and being on the front of taking the heat. Sounds like this issue will become fairly lively on GH. I think the intro of the problem has been clearly stated. What if we discuss further on GH and try and get a broader WG audience after the holiday.
<dael> Rossen: I don't htink anyone is trying to say shut up we won't change or we won't listen because we decided in a vaccuum. I'm personally trying to think through actual use cases. If you give us a chance to read more and discuss perhaps we'll get close to consensus.
<fantasai> Changing the output of that case to #a { border-color: blue red red; border-style: solid; border-width: thin; -moz-border-top-colors: none; -moz-border-left-colors: none; -moz-border-bottom-colors: none; -moz-border-right-colors: none; }
<fantasai> isn't going to make it better.
<dael> glazou: Best us case case click on each of the four borders and you expect border shorthand to appear. I'll put that on GH.
<dael> Rossen: THis sounds like a great use case.
<dael> astearns: So we'll continue discussing this on GH. glazou please ask people to comment on GH and not www-style.

[ewilligers]

Could we serialize border as ... / <border-image> iff <border-image> is not its initial value?

[therealglazou]

Best use case : a web page (inside an app or a standalone browser) offers to set the borders for an element. The four of them. User sets the four, one by one, to same style color and thickness because that's hyper-common. Expects then a 'border' shorthand to appear. Won't happen because of 'border-image'... Will happen only if 'border-image' is reset too. Most web designers don't use border-image and seen from stats, most ignore it since values other than initial/none/inherit/unset for border-image-source are all < 0.1% usage and some are even < 0.01%

[fantasai]

Why wouldn't it happen because of 'border-image'? It's the app that makes a decision of when to coalesce the user's instructions into a single shorthand. It can certainly make that call if it wants to.

I would also expect that if the user takes an element with a border image on it, and tells the app to make the border a solid red line instead, that it disables the border image so that you can see that solid red line. This logic is exactly why the border shorthand sets border-image.

[lespacedunmatin]

So border would reset border-image and not border-radius ? Note that it leads to misunderstandings in French documentation of border on MDN (loosy translation by myself): “border can be used to reset any property link to the border defined before in the cascade. W3C intends to keep that reset mecanism.”

[bradkemper]

Border-radius is not a border property; it’s just badly named. It’s main reason for being called that is because it’s measured on the border box, and ends up being a smaller radius for the padding box and content box.

[lespacedunmatin]

Yep, realized that it should have been named box-corner-radius.

[bradkemper]

Anyway, I’m an author who is not confused by the resetting. Of course, I’m biased, being a co-author, but this resetting happens in other shorthands too, right? It seems pretty simple to me. But I don’t see why you have to write everything out in longhand because of it. That seems like an odd choice. Why not just ignore border-image in the UI and in the CSS you write, when it is not changing anything (changing all border-image-* properties from initial to initial)?

[bradkemper]

Co-editor, I meant to say.

[AmeliaBR]

Here's a use case for the other side of the equation:

In my design system, I have a class big-warning-button. It applies a very large red border:

button.big-warning-button {
  color: darkRed;
  background: lightSalmon;
  border: solid 5px;
}

But then, someone down the line changes the theme styles for default buttons to use a border-image instead of a regular border:

button {
  border-image: url(/assets/fancy-border.png) 10 10 stretch;
}

If the border shorthand worked as proposed in this issue:

My big warning buttons are now broken. I check dev tools. The border width and border color are still there. So is the border-image property, but it's assigned with a simple tag selector. Why is it overriding the border I set with a class selector? I thought I understood CSS! This isn't how it's supposed to work! Why must everything be so darn complicated!!! Stupid border-image keeps breaking everything. No wonder we never use it.

[AmeliaBR]

PS, pulling out a comment I made on IRC earlier:

Has anyone made a list of other shorthands that have similar behavior?

font is one (with respect to new font-variant properties), but I think it should be possible to allow the full font-variant options to be specified without breaking anything.

Another: The mask-border property and its longhands are currently spec'd to be reset by the mask property. But last I checked, no one had implemented mask-border, so there's no compat issue to changing it.

Although really, I don't think any shorthand is as confusing as the border shorthand: even separate from border-image, there's the way it can be decomposed into two different sets of middlehands (border-style/-width/-color vs border-top/-right/-bottom/-left). So authoring tools are going to need special logic for handling it, regardless.

[bradkemper]

I’m actually surprised that text-decoration doesn’t reset text-decoration-skip. I would expect it to, given its name and the fact that it isn’t in the shorthand.

[bradkemper]

Same for text-emphasis and text-emphasis-position.

[frivoal]

@bradkemper I think this was discussed quite extensively, and the decision to not link them was due to the fact that they are typically independent decisions: you set text-decoration / text-emphasis on a per element basis, but you're fairly likely to set text-decoration-skip or text-emphasis-position on a broader basis, possibly for the whole page. Linking the two in the same shorthand would turn normal usage in an ugly specificity fight, and that's no fun.

[therealglazou]

So authoring tools are going to need special logic for handling it, regardless.

My goodness, no they are not! You are missing the point here: authoring tools do not reinvent the wheel and rely on the serialization rules ALREADY implemented in the CSS OM of the rendering engine they use. AFAICT from my tests and implementations, this works very well for both specified (in stylesheets or inline styles) and computed style in all engines available today on the market. That's why setting the four borders never outputs 'border' any more, breaking 20+ years of common practice. If editing tools are expected to be able to deal with this, it means:

1. they're working around the spec
2. it's clearly a hack
3. they're re-implementing serialization - and they should not do that

For your test case above, we should not have changed 'border'. We should have added an extra shorthand for both the line border and the image border. The way we changed the spec was a hack. CSS 2.1 said shorthands "allow authors to specify the values of several properties with a single property". We changed that.

[bradkemper]

@frivoal I thought there must be a reason that I didn’t remember or didn’t pay close attention to at the time. I just meant that it seemed like an exception, rather than the rule. In general, aside from unfortunate naming mistakes like border-radius, I would expect a foo shorthand to reset all foo-* properties.

I suppose if text-decoration-skip could be an exception, then so could border-image, but I think changing it now would likely break too much, as @dbaron indicated. And as @AmeliaBR indicates, people intuitively expect border images to be reset by border (since otherwise, border-image hides the regular border). I think they just don’t expect extra rules written out in their editor (or browser developer tools) when it happens.

[bradkemper]

@therealglazou It seems to me that the issue is really with the serialization, and practically it boils down to two choices: change how the serialization works (which might break some sites, but probably fewer than if we changed a significant detail of how the shorthand itself works), or change how you deal with the serialization (which you would consider a hack).

I don’t really see why the serialization has to work the way it does. Why can’t thin black solid be returned and just imply all the border image resets? Is that somehow worse? Is that harder to deal with for people that read the serializations?

[fantasai]

Agenda+ to mark as WONTFIX, since I don't really see any way to fix this.

[TalbotG]

Suggestion: rename 'border-image' .
If the default border image area is the border-box, then how about renaming 'border-image' to 'border-box-image' ?
If the border image area can even extend beyond the border box, then how about renaming 'border-image' to 'box-image' or some other better descriptive property name?
By renaming the property, we would elegantly avoid this 'border' shorthand reset problem. 2 problems with 1 fix.
Right now - just a hunch - , 'border-image' is not widely used on the web.

[tabatkins]

I haven't checked yet, but given the length of time it's been around, I would be extremely surprised if it was web-compatible to rename border-image. Without evidence to the contrary I'm prepared to reject that out-of-hand.

[css-meeting-bot]

The CSS Working Group just discussed [css-backgrounds] 'border' shorthand resets 'border-image' but can't set it, and agreed to the following:

• RESOLVED: Close as won't fix for lack of ideas on how to properly fix it. If someone comes up with a workable idea we can re-open

The full IRC log of that discussion

<dael> Topic: [css-backgrounds] 'border' shorthand resets 'border-image' but can't set it
<dael> github: https://github.com//issues/2108
<dael> fantasai: I don't have any idea what we can do about this other then going back in time to change. I think there's logic behind behavior and we dont change it now
<dael> TabAtkins: Agree. Change would make shorthand unusable. I think it's won't fix
<dael> astearns: I don't think not usable, but not useful addition to the shorthand
<dael> astearns: Prop: Close as won't fix for lack of ideas on how to properly fix it. If someone comes up with a workable idea we can re-open
<dael> astearns: Concerns about closing won't fix?
<dael> RESOLVED: Close as won't fix for lack of ideas on how to properly fix it. If someone comes up with a workable idea we can re-open