23:10:54 RRSAgent has joined #css 23:10:54 logging to https://www.w3.org/2018/07/03-css-irc 23:10:56 RRSAgent, make logs public 23:10:56 Zakim has joined #css 23:10:58 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 23:10:58 Date: 03 July 2018 23:11:19 rrsagent, this meeting spans midnight 23:13:56 heycam has joined #css 23:17:15 myles has joined #css 23:17:19 Present+ 23:18:37 present+ 23:19:00 ericwilligers has joined #css 23:19:00 present+ 23:19:01 present+ 23:19:02 present+ 23:19:03 present+ 23:19:03 present+ 23:19:03 present+ 23:19:04 present+ 23:19:04 present+ 23:19:04 present+ 23:19:05 present+ 23:19:09 dino has joined #css 23:19:15 present+ 23:19:20 present+ 23:19:29 Topic: in should default to currentColor 23:19:39 present+ 23:19:52 Github: https://github.com/w3c/csswg-drafts/issues/2766 23:19:53 chris has joined #css 23:20:02 present+ 23:20:08 Fantasai: any objections? 23:20:25 rrsagent, here 23:20:25 See https://www.w3.org/2018/07/03-css-irc#T23-20-25 23:20:31 Rossen: We need to make sure the people who care have a chance to look 23:20:51 xidorn: the issue is that if it isn’t specify, the used color is taken from the current property 23:21:04 xidorn: I think the text should just be “it defaults to currentColor” 23:21:18 dbaron: the spec may have evolved from something that was more flexible 23:21:41 chris: let’s say it’s user defined 23:21:52 Rossen: are we okay with the proposed resolution? 23:22:00 Rossen: any objections? resolved 23:22:03 s/let/(sarcastically) let/ 23:22:08 RESOLVED: Accept the proposal 23:22:24 frremy has joined #css 23:22:36 s/Accept the proposal/ in should default to currentcolor 23:22:58 chris: There’s also the same problem with drop-shadow as well as shadow 23:23:13 leaverou: it doesn’t work that way already? 23:23:23 Rossen: any additional comments? 23:23:37 Rossen: Any objections? 23:23:52 RESOLVED: drop-shadow and shadow will also default to currentColor 23:24:22 Topic: Inconsistent position serialization 23:24:30 Github: https://github.com/w3c/csswg-drafts/issues/2274 23:24:54 ericwilligers: For one of the properties, the spec is explicit about serialization, and that’s different from all the other ones 23:25:06 ericwilligers: another inconsistency is that all the browsers behave differently from one another 23:25:29 ericwilligers: suggestions? 23:25:40 leaverou: don’t we have a principle that shorter serializations are better? 23:25:42 TabAtkins: yes 23:25:49 leaverou: if we follow that, 50% should not be introduced 23:26:00 leaverou: do that mean if it was specified explicitly, it should be introduced? 23:26:20 dbaron: there are cases where you do need it to be disambiguated. center 10% and 10% center are different 23:26:40 dbaron: someone should go through, figure out what the compatible behavior is, figure out what the same behavior is, and figure out what should actually happen. This table is rather large for going through in the WG meeting 23:26:52 ericwilligers: the one that’s different from the others, is that a mistake and they should all the consistent? 23:27:02 emilio: yes 23:27:48 dbaron: some of these things are very easy to write as a spec editor, but we should be careful to stick them in when they cause inconsistencies like this. Implementors should be suspicious of them too, if they say to do something different from everything else 23:28:00 emilio: Can we resolve on the special case being outside? 23:28:08 fantasai: All the cases should be the same 23:28:10 s/outside/removed 23:28:12 Rossen: yes 23:28:37 ericwilligers: we should think about transform origin and background position, because transform origin is 3D, and background position accepts the 3 value grammar. So “left 10% top” 23:28:44 fantasai: we’re trying to get rid of 3 values 23:29:19 fantasai: we can resolve on 2 things: 1) all the serializsations should be the same, 2) we never serialize to the three value serializations, unless one of the three values is center, and 3) 23:29:57 ericwilligers: What about always serialize to a valid 23:30:13 fantasai: bgposition should not be allowed in serialization 23:30:17 Rossen: objections? 23:31:21 RESOLVED: 1) All the positions serialize the same way (background-position,m object-position, etc.) 2) All of them resolve as . Background-position 3-value syntax’s are not allowed. 23:32:02 fantasai: We have more questions. 1) Do we ever serialize to a 1-value syntax? Eric made an amazing chart of compat data. Edge takes the shortest backwards-compatible serialization principle very seriously, and when it can, drops down to a single value. The other implementations will always have at least 2 values 23:32:07 Rossen: yeeeeeup 23:32:25 fantasai: Should we ask Edge to change? To match everyone else? Or are one-value serializations actually good 23:32:31 TabAtkins: This decision applies to typed OM too. 23:33:12 fantasai: I think two-value syntax is more understandable to work with. Because if you happen to land on 50% arbitrarily, it would be awkward otherwise. And we have 3 implementations this way. So, because of minimizing the amount of work, we should standardize on 2-values 23:33:57 heycam: Is this a general principle? Like pairs of numbers that are coordinates, they should always be serialized as two-values? 23:34:01 fantasai: I don’t think that’s valuable 23:34:24 s/Rossen: yeeeeeup// 23:34:39 dbaron: One reason position is different is that it has a relatively complicated set of rules, where you’re allowed to do X Y order, or Y X order much of the time but not all of the time, which makes it complicated to figure out which values will round-trip correctly if you reduce it to just one 23:34:54 fantasai: a more important reason is the transform-origin syntax, which becomes ambiguous if you only have one value 23:35:33 fantasai: You wouldn’t be able to consider position as a single value without considering whether or not you have a Z component. That creates a serialization of position cannot be self-contained 23:35:52 fantasai: The proposal: always serializes at least two values 23:35:58 TabAtkins: I’m down with that 23:36:08 Rossen: It means some work for us, but ... 23:36:16 TabAtkins: It means some work for all of us because we’re inconsistent 23:36:24 Rossen: okay. 23:37:04 RESOLVED: All the values serialize to at least two values. 23:37:26 heycam: Is there a way to tell for a given property whether or not we have considered its serialization and what’s in the spec is a considered decision? 23:37:29 fantasai: not really 23:38:01 fantasai: In most cases, you follow the general principle of “shortest most backwards-compatible serialization” and the exceptions are where we will have to explicitly say something. The spec says “it’s probably this” but you need to check in case there’s some legacy something 23:38:08 heycam: I don’t like having to check 23:38:13 fantasai: Are you volunteering to do the checking? 23:38:16 heycam: No 23:38:29 heycam: We should reflect our discussions back in the spec so we don’t have to check 23:38:42 ericwilligers: We may not be testing in all 4 browsers 23:38:52 heycam: So tests may serve this purpose? 23:39:17 fantasai: When we have a 4-value syntax, do you serialize it out to 4 values or do you compress it using calc to two values 23:40:00 Rossen: I looked at this a year ago int he context of object-position. Most of the testing I did cross browsers suggested that almost all implementations attempt to serialize down to calc for computed values on getComputedStyle(), and were inconsistent as described in this one for style serialization 23:40:36 emilio: I don’t think we synthesize calc in any case for computed value serialization. If you specify it as calc(), and we cannot simplify it, but I dont’ think we should use calc to shorten the result 23:40:45 ericwilligers: We’re just talking about serialization, not computed value 23:40:51 emilio: It’s essentially the same thing 23:40:54 fantasai: yeah 23:41:03 fantasai: We’re talking about specified values, not computed styles 23:41:10 ericwilligers: Blink would never give you a keyword as a computed value 23:41:20 s/fantasai/ericwilligers/ 23:41:37 Rossen: What are we thinkging about in terms of 4 value serialization? 23:41:44 Rossen: Should we attempt to do 2 when possible? 23:41:55 plinss: Turning a non-calc into a calc seems weird 23:42:24 astearns: Ifwe can simplify a 4-value into a 2 value without calc, that makes sense, but if you have to use calc, then it’s not a simplification 23:42:46 dbaron: I agree as well, though the principle that would say to use calc() is the most compatible syntax principle, because calc() got implemented in background-position background to the 4-value syntax 23:43:11 dbaron: So for a while you were able to do the effects of the 4-value syntax with calc, without the real 4-value syntax. BUt for now we shouldn’t do it because it’s less compatible 23:43:56 astearns: We went through this when we were deciding how to use these values in basic shapes. What I thought we were doing was coming up with general principles that would generally be applied to other things than basic shapes. Basic shapes prefers two values, if you can express it without calc, so we may look to that as what we were trying to do years ago 23:44:04 fantasai: Eric, do you have the test you used for the 4-value syntax? 23:44:35 fantasai: Can you modify it from bottom right to top left to see if the values get dropped, or if we keep the 4 value syntax even in that case 23:44:45 ericwilligers: It takes me a while to get results because I use browser stack. 23:44:54 ericwilligers: If you tell me what you want to know, we can figure it out 23:44:55 in basic shapes is paragraph 2 of https://drafts.csswg.org/css-shapes/#basic-shape-serialization 23:45:03 top 10% left 20% 23:45:31 ericwilligers: With the suggestion that we go down do two unless it introduces a calc, what effect would that be fore background-position? 23:45:47 Rossen: The minute you have top 10% and then center .. 23:45:55 ericwilligers: Peopel were saying “we should never ever go to three” 23:46:04 ericwilligers: right 10% top wil go to 4 23:46:33 ericwilligers: 1 more question: right 10% top should serialize differently from left 10% top??? 23:47:06 fantasai: That was the question I wanted to ask. We should see what the output is. If there is consensus, we tend to go with that. So I think we should investigate this question a little more over the break. And then go on to the issue of whether to serialize out keywords when you put serialize as a percentage 23:47:12 Rossen: but this is after the discussion int eh morning? 23:47:16 fantasai: no, we can do it now 23:47:32 s/int eh/in the/ 23:47:36 fantasai: Looka t the 3rd table: 30px center. Some of the serializations use 50%, some use the keyword center 23:47:48 fantasai: The table after that: 40px top, some use 0% and some use the keyword top 23:48:03 fantasai: So the question is, do we resolve on outputting the keyword when the percentage would work? 23:48:24 dbaron: The bulk of the boxes are they keyword except 3 of them 23:48:42 dbaron: That said, I don’t know if we should try to go through all of this 23:49:15 fantasai: 2 questions: 1) How do we deal with keywords, both if the author supplies them and do we turn 50% into center, and 2) the two-value vs 4-value question 23:49:26 fantasai: We can look into that over the break. 23:49:51 Rossen: This is where we are going to get a lot more calcs in percentages 23:49:59 Rossen: okay that’s everything for this for now 23:50:14 Topic: Issues for listifying border-color 23:50:26 Github: https://github.com/w3c/csswg-drafts/issues/2532 23:51:46 leaverou: There’s a very detailed write up in the issue of everything I’m going to say 23:53:15 leaverou: Do people remember the issues with listifying border-color? A few meetings ago, we resolved to listifying border-colors, because 1) Authors wanted multiple borders, but primarily a11y needed borders that are both white and black so that they are visible over any background. So we listifying border-color with the goal of listifying alt he border properties 23:53:38 leaverou: BUt when I actually tried to listifying border-color, there were several issues. 23:54:25 leaverou: 1) Because of the way listified properties work, if the lists are mismatched, the shorter lists are padded with the last term, which means if you have a border-width of 10px, and say 3 border colors, then 10px becomes 10px, 10px, 10px, which gives you a width of 30px. So setting border-color has the effect of tripling your border width. Weird, and this is the first time 23:54:34 heycam: Wouldn’t this happen with any other listified properties? 23:54:50 leaverou: Others don’t stack. Backgrounds and animations are independent. But border-width, they stack, they aren’t independent. 23:55:05 tantek: Or you have to do weird math, which is worse. 23:55:54 leaverou: Other issue: based on how other properties were listified, the property got almost the same syntax it already had, but you could add more with commas. So, previously it accepted 4 colors, you could have 1-4 colors, then commas, then 1-4 colors, etc. This inverts the relative power of white space and commas, which is not how authors think 23:56:02 leaverou: You can see an example in the issue 23:56:08 leaverou: It’s quite unexpected. 23:57:54 leaverou: For those reasons, fantasai and I were thinking of an alternative way to do multiple border colors, because there aren’t many use cases of multiple colors with different styles. All use cases for multiple borders are essentially cases for multiple colors on a solid border. So we were thinking how can we have multiple colors on existing borders. The idea is to define a function, we called 23:57:54 it stripes(), which lets people define a 1-dimensional image which is weird but we already have 0-dimensional images, and it can be used in border-color, and it has to be 1-dimensional image because otherwise it would be difficult to define how it works around border-radius. To cover the most prominent use cases it would include lengths and percentages, and would work with fr values 23:58:09 Lea's proposal looks like an improvement to me 23:58:48 leaverou: I have a list of the use cases we tried to cover in the issue, and a table of what the different syntaxes would look like. We also considered letting border-color accept a sequence of color stops, but that’s not convenient, because with borders, people usually wants stripes not gradients, and it’s hard to make stripes with the gradient syntax 23:58:55 fantasai: You don’t want absolute positions 23:59:32 s/positions the way gradient stops do them, but rather widths that stack/ 23:59:42 leaverou: We also considered using a new border-stripes property. But it has weird affects. It combines with border-color in a confusing way, because unless there are transparent stripes, you dont’ see border-color. In general, having properties that disable other properties is some fo the most confusing parts of css 23:59:54 emilio: Firefox used to have multicolor border support, by using a new property 23:59:59 leaverou: Yep, and it was confusing 00:00:08 chris: We decided not to do it the Firefox way 00:00:20 dbaron: It was a hack to create a certain button style without making extra dives 00:00:28 leaverou: I used it 10 years ago to simulate box shadow 00:00:30 TabAtkins: I like it 00:00:48 astearns: What happens when the total sum of the width exceeds the border width? 00:00:58 TabAtkins: You just only render the border-width of the stripes 00:01:19 leaverou: We can just scale it down. We do it with border-radius, if the total radii overlap, then it gets clamped 00:01:40 S/clamped/scaled equally across the entire box/ 00:02:05 astearns: That could work, but what about fractional widths? Those go to 0? So you have a 2px white fractional black, 2px white 00:02:24 TabAtkins: *describes another example* 00:02:30 fantasai: It’s better than clamping. 00:02:48 fantasai: It gives you reasonable behavior when you grow and when you shrink 00:03:00 TabAtkins: We already have mechanisms (percentages) to do this. 00:03:26 TabAtkins: This allows you from putting in more stripes than you need 00:03:52 TabAtkins: So if you alternating 1px stripes, you just make a super long one, and no matter how wide the border happens to be, it will just work (in the clamping situation) 00:04:09 frremy: Animations work better too 00:04:22 leaverou: If you want to reveal stripes, you could always animate them from 0 00:04:30 TabAtkins: Not if we scale the values 00:04:47 leaverou: Non-zero lengths will be scaled down, but if you want to progressively animate, 00:04:56 TabAtkins: You can alreadya chive accordian effect 00:05:14 fantasai: What if you want 2px red, 2px white, 2px red. If the border grows, you want the white to grow 00:05:32 s/alreadya chive/already achieve/ 00:05:33 fantasai: When you scale up, you want red on the outside, you preserve the red, white, red 00:05:39 TabAtkins: use min() and max() instead. 00:05:58 leaverou: What do we do if we want a thinner width than what we have? In fantasai, what if our border is 10px 00:06:05 TabAtkins: We follow gradients. The last color continues 00:06:11 fantasai: Or the last color could be transparent 00:06:17 TabAtkins: But then the border doesn’t look thick 00:06:26 fantasai: If you want it to be thick, put 1fr at the end 00:06:45 TabAtkins: When this is used in a 2 dimensional context, then this should be a gradient in some arbitrary direction 00:07:10 fantasai: I don’t think he testing and implementation effort of making stripes in 2d only for an arbitrary direction makes any sense 00:07:16 TabAtkins: Here we’re just talking about stretching and scaling 00:07:20 Rossen: What if we repeat the pattern? 00:07:26 leaverou: We can introduce that later. Let’s keep it simple. 00:07:35 fantasai: It answers the question of what to do if you dont’ have enough stripes 00:07:48 TabAtkins: Don’t be arbitrarily different. Do what gradients do 00:07:53 fantasai: no 00:07:56 TabAtkins: no 00:08:03 TabAtkins: be consistent 00:08:10 fantasai: this isn’t gradients 00:08:16 TabAtkins: this is gradients 00:08:20 fantasai: this is stripes 00:08:32 leaverou: Gradient color stops are defined absolutely, and there is no fr 00:08:51 Rossen: stop. Are we trying to add this to backgrounds-4? 00:08:52 All: yes 00:08:57 Rossen: We can work this out later 00:09:18 Rossen: Was there anything else you wanted to go over technically as part of the proposal? 00:09:22 leaverou: no 00:09:34 Rossen: Should we add this? Are there still too many open issues for it to be added? 00:09:47 TabAtkins: Using the stripes functions as a border color and not listifying border color makes more sense than what we already have 00:10:12 agreed 00:10:20 fantasai: This is a better solution. My question: whether to use border stripes or to add this to border color. In general, colors cannot take a 1d image. Any property that ends in -color takes a color. This is not a color, it accepts a 1d image 00:10:25 astearns: border-color-stripes? 00:10:30 fantasai: border-stripes is okay 00:10:36 leaverou: What about the confusing interactions? 00:10:40 fantasai: its okay. 00:10:50 astearns: The behaviors fall out of the description 00:11:11 s/The/Some/ 00:11:25 astearns: e.g. might answer question of what to do when you run out of stripes 00:12:14 frremy: That isn’t great because if you pad a border stripes with the border color, the issue is that the border color by default is non transparent, but your stripes may be transparent, then should you display the border-color under the stripes? If you do, you lose the whole point of having transparent stripes 00:12:21 fantasai: You should show border underneath this property 00:12:40 leaverou: You often want them to stack, to have a fallback that you don’t have to repeat it in your gradient 00:12:57 xidorn: I dont’ understand the integration here 00:13:11 fantasai: border stripes and border color will disappear when you use border-image 00:13:17 chris: This will need some good examples 00:13:29 TabAtkins: Or we just do stripes() and we don’t have to deal with this stuff 00:13:32 leaverou: yep 00:13:35 fantasai: yep 00:13:47 leaverou: If we do it with a stripes function and not a separate property, we can extend this to other properties 00:14:09 fantasai: The other properties need a 0-dimensional color, or a 2-dimensional image. If you applied stripes to those other places, you would need to also specify a direction and turn it into a 2-d thing 00:14:16 leaverou: i said “if it’s needed” and it may not be needed 00:14:28 fantasai: We could re-use the syntax. It doesn’t have to be a functional notation 00:14:37 leaverou: We would have to add a new property for each of those cases 00:14:39 fantasai: That’s okay 00:14:50 Rossen: Do we prefer the stripes functions? Or a new property 00:15:01 fantasai: border-stripe 00:15:06 TabAtkins: stripes function 00:15:10 stripes function 00:15:16 stripes function 00:15:36 astearns: One reason to have the function is that we noted that listifying properties is confusing. Stripes() makes specifying these stripes more comprehensible. If we use a property, we’re back to a list. 00:15:38 leaverou: yes 00:15:54 s/all a/allow a 00:16:05 Rossen: Another benefit is you can have the border color and the stripes in the same definition, so you can have your border color as defined green, but you can also define the stripes on top that may or not have green 00:16:14 leaverou: So you can do them both in the same property 00:16:17 Rossen: Yes. 00:16:20 TabAtkins: Why do you need that? 00:16:33 Rossen: So you can have the last value be transparent, and the default shows through 00:16:42 Is stripes a subset of gradients? 00:16:55 fantasai: The main benefit of the border color being separate is so that they can cascade independently. If theyr’e not cascading independently, then there’s no point 00:17:23 chris: The original reason for this was because a11y wanted to have a black and a white outline, and outline is defined in term of border. With this syntax, you say “black white” and you’re done. 00:17:29 chris: Let’s not make a new property. 00:18:11 tantek: Is stripes just a subset of gradients? 00:18:12 tantek: No, gradients are 2D images. Also, gradient color stops define positions, not widths. 00:18:26 Rossen: Proposal: adding stripes() to border-color and outline-color 00:18:39 Rossen: Any additional concerns? Comments that would change this resolution, or objections? 00:18:48 florian: How does it interact with border-style: double 00:18:54 fantasai: You clip out the border shape. 00:19:04 Rossen: Just like it would work with gradients 00:19:14 leaverou: I think he’s asking about double borders ,not dotted and dashed. 00:19:21 chris: It’s a clip mask effectively. 00:19:39 leaverou: Double has two different colors, and inside and an outside 00:19:48 florian: nope, that’s something else 00:19:51 leaverou: You’re right 00:20:26 dbaron: We could say that inset outset groove and ridge would just get treated as solid because you’re picking your colors yourself now and that overrides those styles. 00:20:34 florian: You can use it as fallback. 00:20:37 leaverou: right! 00:20:41 leaverou: I like that 00:20:43 chris: yeah. 00:20:50 Rossen: Any objections? 00:21:02 RESOLVED: Add stripes() to border-color and outline-color 00:21:18 tantek: It's *substantially* more work, yes, *and* it doesn't work well with border-radius either. 00:21:20 Rossen: Do we now publish a new working draft? 00:21:29 fantasai: I don’t know what state the rest of the draft is in 00:21:39 leaverou: we’ve published a working draft before, right? 00:21:43 fantasai: nope 00:21:46 (You can't supply separate images for each border, just a single border-image that's 9-sliced to supply all the border regions.) 00:21:50 Rossen: This is level 4, right? 00:21:58 leaverou: yes, that needs lots of cleanup 00:21:59 And yeah, probably so, which is fine with em. 00:22:05 Rossen: Let’s not publish 00:22:18 Just "gradient(...)" 00:22:22 Topic: color-filter 00:22:36 Github: https://github.com/w3c/csswg-drafts/issues/2875 00:23:05 Topic: color-filter 00:34:07 myles has joined #css 00:49:01 github: https://github.com/w3c/csswg-drafts/issues/2875 00:49:07 Restaurant tonight is Long Chim 00:49:15 myles has joined #css 00:49:18 dino: Some background... 00:49:25 ScribeNick: fantasai 00:49:33 address for Long Chim: Corner of Pitt Street &, Angel Pl, Sydney NSW 2000 00:50:19 dino: Same way that Windows has done for decades, Apple's latest OS has a “dark theme” 00:50:29 dino: Where user has a checkbox where they can choose between light or dark mode 00:50:34 dino: You can see my browser is in dark mode atm 00:50:44 dino: System apps have implemented this 00:50:47 dino: Seems pretty popular 00:50:55 dino: This is about how you can apply something like that to the Web 00:51:08 dino: Particularly relevant to us for mail messages 00:51:11 dino: which are web pages 00:51:20 dino: What we wnated to do was automatically ocnvert a page to dark mode 00:51:30 dino: To do that, you want white to go to black, but you want hues to stay the same 00:51:34 dino: e.g. blue shouldn't become orange 00:51:39 dino: We had the idea to use color-filter 00:51:47 dino: This takes filters just like 'filter' 00:51:53 dino: But doesn't have ability to omove pixels 00:52:04 dino: It's a paint-time effect 00:52:18 chris: Is this a straight 255 minus effect? 00:52:19 dino: Yes 00:52:34 dino shows off invert() 00:52:46 dino: It's not like a regular filter. No stacking context. Just applies to colors 00:52:57 dino: colors of gradients, anywhere a appears 00:53:03 dino: DOesn't affect images 00:53:30 dino: Because when you switch to dark theme, you don't want to have images invert 00:53:37 dino: or emoji colors to invert 00:53:39 etc. 00:53:48 dino: We don't actually wantto just invert the colors 00:54:09 dino: Here's an example - invert(0.83) hue-rotate(180deg) saturate(3) 00:54:40 dino: white goes to dark gray, bump saturation to compensate for grayishness, and then hue-rotate gets our colors back to what they would be without inversion 00:54:58 dino: Works nicely. Better on my laptop than on the projector here. 00:55:46 dino: This other column does some additional tweaks using JS, to look a little better. 00:56:01 dino: Anyway, this is what we're using to display mail messages now 00:56:21 dino: We have heuristics, if a marketing mail sets bgcolor, we won't do it 00:56:35 dino: but for plaintext or simple HTML messages, we'll apply the filter 00:56:43 dino: What we've got here is not Web-exposed, just in Mail 00:57:03 dino: We can talk more later about Media Queries and how to interact with the Web 00:57:30 dino: But a Web page could e.g. change colors manually in response to a media query, or they could use color-filter 00:57:39 dino: It's just maths on red/green/blue channels of the colors 00:57:43 dino: images are untouched 00:57:49 dino: No stacking context 00:57:57 dino: It's inherited, so you can undo it in a subtree 00:58:12 chris: Initial value? 00:58:13 dino: none 00:58:24 chris: You say not images, but some parts of CSS are s... 00:59:04 dino: Gradients is a good example. If your bgimage is a gradient, you apply it to the coors in the image 00:59:12 leaverou: What about color variables? 00:59:19 fantasai: Gets applied when you apply the color 00:59:28 TabAtkins: But you don't want to double-apply for typed variables 00:59:29 ... 00:59:35 s/What about color variables?/What about custom properties that have been defined to accept ?/ 00:59:38 xidorn: Is it applied during cascading or what? 00:59:42 emilio: Computed value is not affected 00:59:48 fantasai: used-value time operation 01:00:28 astearns: currentColor 01:00:30 fantasai: probalby fine 01:00:37 heycam: