00:02:22 I am dialling in 00:03:23 murakami has joined #css 00:03:42 github-bot has joined #css 00:03:44 Florian has joined #css 00:12:37 astearns: is there also a webex link to connect directly (webrtc)? we are starting 9:15? 00:14:40 ChrisL has joined #css 00:16:28 Conference is not started yet 00:16:42 That is why, you only get noise from the room 00:19:54 trackbot, start meeting 00:19:57 RRSAgent, make logs public 00:19:57 Zakim has joined #css 00:19:58 Zakim, this will be Style_CSS FP 00:19:58 ok, trackbot 00:19:59 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 00:19:59 Date: 21 April 2017 00:20:07 myles has joined #css 00:20:07 present+ 00:20:08 present+ 00:20:09 present+ 00:20:10 present+ 00:20:14 tantek has joined #css 00:20:15 present+ 00:20:16 present+ 00:20:17 present+ 00:20:18 present+ 00:20:18 present+ 00:20:19 ScribeNick: Myles 00:20:19 present+ 00:20:20 present+ Surma, Google 00:20:21 present+ 00:20:23 present+ 00:20:28 present+ 00:20:33 present+ 00:20:36 present+ 00:20:36 present+ 00:20:38 Present+ 00:20:40 present+ 00:20:42 Topic: URL Discussion 00:20:44 present+ 00:20:46 present+ 00:20:57 Topic: Update on URL function discussions 00:21:17 plinss: url() - do they resolve to images or elements? 00:21:25 plinss: we had 4 options 00:21:43 https://dbaron.org/css/test/2017/mask-url 00:22:00 plinss: David looks into what Firefox does. But our resolution is contrary to that. We want to revisit to allow Firefox 00:22:23 dbaron: Firefox treats mask image with a URL. If it has a hash, we will look for a ref in it, whether its local or remote 00:22:29 dino has joined #css 00:22:29 present+ 00:23:02 dbaron: so, there are some cases where we will try to load it twice. If there is no hash, we don't attempt to look for a mask element, and load it as an image. If it's purely a local ref, we don't' attempt to load it as an image - we will only find a mask URL. But if it has a hash in the middle, we'll load it both ways. 00:23:10 fantasai: This is an optimization of loading twice in general 00:23:26 fantasai: a local reference is not going to be an image 00:23:29 dino: why not? 00:23:39 dino: it could be an SVG image, or a SVG root, or a canvas 00:23:45 dbaron: we dont' want infinite recursion 00:23:59 TabAtkins: pointing to canvases isn't allowed at all anywhere 00:24:08 dino: Someone might do it 00:24:27 dino: We could point as an image element in the document and using it as a mask 00:24:30 leaverou: that's not allowed 00:24:35 ChrisL: this is imaginary 00:24:53 dbaron: the mask property used to point to a mask element but we extended it to point to image 00:25:17 dbaron: when we do this, we ignore the other masking properties like mask-repeat, etc. 00:25:23 ChrisL: this is according to the spec, rights? 00:25:31 dbaron: i think so 00:25:44 leaverou: So, it's possible to have the Firefox implementation from the spec? 00:25:57 leaverou: We all agree that this is the most reasonable choice 00:26:07 Rossen: Can someone summarize what is going on? 00:26:23 plinss: You should know what's going on 00:26:44 leaverou: Hey tab, please type in the options again 00:27:00 https://log.csswg.org/irc.w3.org/css/2017-04-19/#e796988 00:27:23 1. Treat ambiguous cases as url reference into an SVG document, not treat as image and apply :target 00:27:28 2. Treat ambiguous cases as url, if it has a fragID treat as a reference, otherwise treat as an image 00:27:34 3. Treat ambiguous cases, load it twice -- first see if there's an appropriate reference, otherwise go back and reload as an image 00:27:39 4. Do something different per property 00:27:40 leaverou: ❤️ 00:27:53 dino: what does "ambiguous" mean? 00:28:08 plinss: if the property can handle both an element and an image, and the URL could be either 00:28:40 plinss: can we resolve to make this decision on whether it's a local or external URL? 00:29:03 myles: Firefox does 3, right? 00:29:17 leaverou: Basically. With some extra optimizations 00:29:33 plinss: Architecture says that you can only interpret what a fragment means until you get a content-type from the response 00:29:53 dbaron: The case where Firefox doesn't do the right thing is when there is a base URL and a url(#foo) 00:30:02 dbaron: This is probably not the only case where this occurs 00:30:21 dbaron: like scrolls within the current document 00:30:37 TabAtkins: CSS always treats a #url as a reference into the local document 00:30:47 plinss: That is a separate issue and an architectural violation 00:31:28 plinss: At the end of the day, I'm okay with browsers not handling everything exactly b/c of optimizations. What I'm not okay with is the spec stating you must violate architectural principles and Gecko must stop doing what it's doing 00:31:46 Rossen: Other thoughts? 00:32:10 Rossen: Proposed resolution: a mixture of #2 and #3 00:32:43 fantasai: By choosing to follow Moz behavior, you are deciding tha ta local reference will always be an element reference and not an image reference. Which is fine, but we should be explicit. 00:32:54 fantasai: We always have our image() and element() functions which can make the distinction 00:32:58 ChrisL: so you're not losing anything 00:33:09 TabAtkins: We know the content type of the current resource, so we can interpret the hash correctly 00:33:35 TabAtkins: I need confirmation from our loading people that this is implementable 00:33:41 TabAtkins: we will try 00:34:00 plinss: I'm okay with "should" or "must (but we know you won't)" 00:34:07 Rossen: "should" please. 00:34:20 Rossen: Proposed resolution: Option #3 with "should" 00:34:23 fremy has joined #css 00:34:31 TabAtkins: 👍 00:34:47 TabAtkins: (summarizes proposed resolution) 00:35:18 RESOLVED: Should treat ambiguous cases, load it twice -- first see if there's an appropriate reference, otherwise go back and reload as an image 00:35:21 RESOLVED: Implementations should treat 1ambiguous cases, load it twice -- first see if there's an appropriate reference, otherwise go back and reload as an image 00:35:52 Github issue: https://github.com/w3c/csswg-drafts/issues/383 00:36:13 RESOLVED: For ambiguous cases, UAs SHOULD first see if there's an appropriate reference, otherwise go back and reload as an image 00:36:33 Thanks leaverou 00:36:42 Rossen: RESOLVED: Let's stop resolving 00:36:58 Topic: split sessions 00:37:33 Florian: We found a number of places where we wanted to tweak the page floats spec 00:37:48 Florian: But then we spoke more, and alternatively to tweaks, we could do deeper changes, and that might be better 00:37:59 Florian: So we need a long deep session about page floats. 00:38:06 Florian: Otherwise, we should just take it off the agenda. 00:38:17 Rossen: What about rhythm? 00:38:39 Rossen: We need to break out. 00:39:30 TOPIC: Images 00:40:43 00:43:12 00:44:20 00:44:49 More like USB-C = beta-testing 00:45:20 00:45:28 https://drafts.csswg.org/issues?spec=css-images&doc=cr-2012 00:45:44 TOPIC: Images 3 Issues 00:45:50 1. Deprecating image orientation 00:46:38 leaverou: This isnt' about deprecating it. Someone said that angles in image-orientation are pointless. You'll never want to the same adjustment to all your images. So this is to fix the orientation of images which were taken eh wrong way. Proposal: drop all values except from-image 00:46:46 leaverou: and none 00:46:50 leaverou: which is now called 0deg 00:47:01 Is there a break out session on page floats and rythm or not, ultimately? If so; where is it minuted? 00:47:04 leaverou: the point is that the angles are pointless 00:47:05 that seems reasonable 00:47:13 leaverou: we agree but we need a resolution since it's in CR. Any objections? 00:47:28 fantasai: I'm okay with deprecating or obsoleting, but we need to keep them in the spec 00:47:39 fantasai: We have references coming into this from other non-W3C places 00:47:48 Florian: which ones? 00:47:53 fantasai: Printers. 00:47:58 I've been in favor of just from-image | none since "forever"... 00:48:10 fantasai: They have some idea of HTML & CSS because of their printers. 00:48:17 ChrisL: This is the XHTML print stuff 00:48:27 fantasai: These printers rely on this stuff 00:48:32 leaverou: angles? 00:48:34 fantasai: yes 00:48:39 wait was there a test case for angles? 00:48:46 fantasai: I don't know the details. I worked on testing this and it's used. 00:49:07 ok with "obsolete" 00:49:09 fantasai: From our perspective, browsers don't need to implement it. But it can't be removed. We can just say it's obsolete and not to implement it 00:49:12 TabAtkins: sounds good 00:49:22 https://www.w3.org/TR/xhtml-print/ 00:49:26 leaverou: resolution????? 00:49:36 dbaron: There needs to be a second piece which is to add "none" 00:49:40 dbaron: value 00:49:51 TabAtkins: Unless we want to say that it accepts an angle but only 0 00:49:57 four implementations in the implementation report https://www.w3.org/MarkUp/Test/xhtml-print/implementation/ 00:50:01 sounds good 00:50:06 RESOLVED: Deprecate in image-orientation and add a 'none' value 00:50:36 RESOLVED: Deprecate in image-orientation and add a 'none' value 00:50:53 leaverou: Interpolating percentages in cross-fade 00:51:10 leaverou: spec says if you do it that only differ by their percentage, then you just interpolate their percentage 00:51:54 The other cross-fade, the two arguments are not identical, so this would trigger the default generic interpolation 00:52:15 TabAtkins: theoretically you could detect this condition and fix it in the browser 00:52:21 leaverou: but there is arbitrary complexity here 00:52:54 TabAtkins: we could 1) resolve the current text is right, or 2) a more generic version where we interpolate the two argument images as well as the percentages 00:53:06 dino: this is 1 level or 2 levels but not n levels 00:53:32 TabAtkins: we interpolate the percentages, and the two first arguments and the second arguments, and it cascades down forever 00:53:45 dino: in the example, if instead of the first case said 1.png and the second case said 3.png 00:53:53 TabAtkins: then you would do a generic interpolation 00:54:03 dino: i don't mind what it is. Definitely 1 level is easier 00:54:05 TabAtkins: yes 00:54:17 TabAtkins: the "interpolate further down" case is more interesting but is more complicated. 00:54:23 TabAtkins: i can go either way 00:54:32 dino: how often will authors write nested cross fades 00:54:36 leaverou: it could come from variables. 00:54:43 leaverou: it's easy to get this with variables 00:54:54 dino: yes. This means that the variable itself might be animating, so you might be animating between two animations 00:54:58 Animations all the way down! 00:55:15 fantasai: we have other image functions in mind for the future, so introspection in general will be more useful for these future things. 00:55:29 fantasai: i have a variety of different ideas for extending this that it would be useful for 00:55:35 s/i/we/ 00:55:42 leaverou: introspection definitely yields the results the author wants, but it may be too hard to implement 00:56:07 fantasai: it depends on your internal representation. If it's simple, then matching it is easy. 00:56:24 dbaron: You could define the interpolation rules recursively 00:56:27 TabAtkins: that's the second options 00:56:49 TabAtkins: we interpolate the percentage, the first arg and the second arg separately 00:57:32 Leaverou: If you have a filter function and. You interpolate between a.png and a blur filter on a.png, you can interpolate between those. 00:57:51 TabAtkins: You could recursively interpolate between the two linear gradients in the first argument 00:58:26 TabAtkins: We need to decide which option. All in, or in 1. 00:58:35 dino: "all in" may require checking of many image types. 00:58:44 dino: the arguments may be interpolatable, other than a cross-fade. 00:58:49 TabAtkins: leaverou: yes. 00:58:59 dino: Do we already have a list of images you can interpolate between? 00:59:03 TabAtkins: leaverou yes 00:59:12 dino: implementation-wise, one level is easier, but meh 00:59:22 leaverou: Is there any implementations which have done it the other way so we can test it? 00:59:34 dino: we have a lot of bugs in cross-fade interpolation 00:59:38 dino: just random bugs 00:59:54 fantasai: we should do recursive, and if there are no implementations, we just mark it as undefined in level 4 01:00:14 fantasai: i mean, if we end up without implementations, then we push it out to level 4 and in level 3 say that it's undefined. 01:00:21 astearns: so we mark it at-risk immediately? 01:00:24 fantasai: yes 01:00:46 Florian: "at risk" means "for being pushed out" not for "being removed" 01:01:01 leaverou: If implementations care about it working by a cross fade and not other rules, then authors will depend on it. 01:01:05 fantasai: that's why we want recursion now 01:01:09 dbaron: how do they actually differ? 01:01:50 TabAtkins: in the example above, 1st argument stays as it is. Let's say the second argument is a linear gradient from black to wihite, and the next one is a gradient from black to white 50%, then it makes a difference 01:01:52 dbaron: okay 01:02:21 dino: The generic case means adding a cross-fade 01:02:34 dbaron: this example is confusing 01:02:42 dbaron: and uninteresting 01:02:50 binge has joined #css 01:02:55 leaverou: let's start with recursive and change it if there are no implementations 01:02:57 Rossen: ok 01:03:01 Rossen: any objections? 01:03:07 leaverou: it will be at risk 01:03:09 Rossen: yes 01:03:24 leaverou: cross fade is the only piece which isn't at risk 01:03:37 s/"at risk" means "for being pushed out" not for "being removed"/make it clear that it's "at risk of being undefined" not "at risk of being removed" (and therefore defined to do the opposite)/ 01:03:41 Dino: tabatkins: Chrome and WebKit implement image interpolation with cross fade 01:03:48 Rossen: no objections 01:03:50 (pre-fork, so one implementation) 01:04:10 RESOLVED: Do interpolations recursively on each argument, but mark it at risk 01:04:30 3! 01:04:38 leaverou: we have special rules for interpolation in gradients. 01:04:49 leaverou: 01:04:57 leaverou: do these rules apply to the color stops before or after fixup? 01:05:26 leaverou: you could have a gradient today that is white to black and a value of 0 gets fixed up to 20% 01:05:39 leaverou: color stops with no position get positioned between the adjacent ones 01:05:52 leaverou: color stops become equal to the previous one in some cases 01:06:03 leaverou: layout needs to happen because you need to compute some lengths to do the fixup 01:06:22 leaverou: so it's optimal to do interpolation to do on the fixed up positions, but it may be impossible b/c of layout 01:06:36 TabAtkins: 01:07:22 TabAtkins: if it's pre-fixup, then during the transition, the animation is not smooth 01:07:32 Post-fixup gives a more correct solution 01:07:59 TabAtkins: when you're making stripes, it's common to just put 0 as the position, because it forces it to be at the previous color stop's ending point. So fixing up is common. 01:08:09 TabAtkins: if we stick with pre-fixup, we break this content 01:08:18 fantasai: I'm not convinced that post-fixup is better 01:08:43 TabAtkins: but i just talked about the the 0 common technique (above) 01:09:03 leaverou: in the past, we needed layout. Today, we can use min() or max() 01:09:11 fantasai: min() doesn't exist today w/r/t images 01:09:28 dbaron: does "fixup" only mean positions of color stops, or elimination of redundant color stops 01:09:34 TabAtkins: elimination doesn't happen. This is well-defined 01:09:39 dbaron: that makes it easier 01:10:04 leaverou: many people use redundant color stops to force gradient interpolation instead of generic image interpolation 01:10:09 fantasai: they need it as a placeholder. 01:10:37 TabAtkins: dbaron, why do you think it's easier? 01:11:01 dbaron: there is extra complexity if you want to ignore the color stops. You need to know exactly which ones to ignore. But if the algo says to never ignore, then it's okay. 01:11:06 TabAtkins: yep. 01:11:10 w/r/t images -> as far as css-images-3 is concerned 01:11:22 TabAtkins: Both options are difficult 01:11:30 TabAtkins: We can represent the intermediate steps w/o layout by using max() 01:11:38 fantasai: we don't have that 01:11:41 leaverou: we will 01:11:41 Florian has joined #css 01:11:46 fantasai: there are 0 implementations. 01:11:52 fantasai: we can't rely on that here 01:12:07 fantasai: you can say "don't do any gradient color implemtnations until you implement min()" but that's a bad dependency 01:12:10 TabAtkins: or it may just be wrong 01:12:22 TabAtkins: you could just use calc() for the stops instead 01:12:42 fantasai: the goal is to get the spec to rec. min() won't be able to achieve this. So it's a bad dependency 01:12:52 TabAtkins: We should never do the bad thing because of process 01:13:07 fantasai: The existing behavior in the meantime is valuable 01:13:25 fantasai: Is it going to be okay to change the behavior of this property when browsers finally implement max() 01:13:27 ? 01:13:30 TabAtkins: nope 01:13:35 TabAtkins: but it shouldn't delay iot. 01:13:59 ChrisL: It's not process, it's that there are no implementations 01:14:06 TabAtkins: it doesn't matter when it gets implemented 01:14:06 Can someone test this in Edge 15? http://dabblet.com/gist/24224c83758444bf3be8b05fd7069a84 01:14:23 Florian: we can always change it, but it depends on the compat at that point 01:14:36 leaverou: if we say that interpolation happens pre-fixup, we will break things 01:14:45 fantasai: but we don't have a choice because there is no implemetnation of max() 01:14:50 leaverou: we should wait longer and get it right 01:15:01 fantasai: what will we do in teh meantime? 01:15:04 leaverou: we already waited 6 years 01:15:16 fantasai: what will the implementation do in the meantime until it implements max() 01:15:22 TabAtkins: it will be buggy 01:15:33 leaverou: this isn't the first tiem we've done this 01:16:24 fantasai: I want it to be deined what you do if you don't implement max() 01:16:42 TabAtkins: i don't want to have to cafrefully controll when we make a change to the spec based on when people implement min() and max() 01:16:49 fantasai: we need a definition for both cases 01:16:52 TabAtkins: soundsg ood 01:17:03 Florian: isn't it better that the intermediate behavior is buggy 01:17:08 TabAtkins: it doesn't matter 01:17:21 leaverou: why doesn't my example work in Edge???? 01:17:28 Rossen: i dunno 01:18:04 Rossen: fantasai: what resolution do you want? 01:18:14 fantasai: i dunno. I'm not convinced of what we're trying to do 01:18:24 leaverou: we could make max() required to implement this 01:18:38 fantasai: i'm not convinced that the theoretical best (if max() exists) is this behavior? 01:18:43 s/?/./ 01:19:02 leaverou: quick guess is that it uses explicit in one and implicit in other 01:19:23 fantasai: if we had color stops relative to the position of the previous color stop, we could do it 01:19:54 @leaverou: that one works: https://wptest.center/#/i4sli8 01:19:59 ChrisL: this would actually work with what authors want. When authors say "0" they actually are just using a placeholder. We could give them a keyhword 01:20:05 leaverou: Why would an author use a keyword? 01:20:26 leaverou: we could do the interpolation on teh declared list of color stops, but there is more existing content which it wouldn't work with 01:20:59 fantasai: walks across a curtain, or something???? 01:21:21 fantasai: Depending on what your goals are as an author, you might have different goals as an author 01:21:29 fantasai: both behaviors are valuable 01:21:49 s/valuable/reasonable/ 01:21:51 surma: most use cases will want to animate from whereve it is on screen 01:22:11 surma: rather than where it ought to be 01:22:36 leaverou: peopel can use whatever units they wnat in their color stops, and not worry about ordering. But now peopel will have to think about this stuff just to get the proper interpolation (and use min() or max()) 01:22:57 leaverou: content may do what UAs should be doing, themselves 01:23:04 leaverou: like a polyfill 01:24:11 leaverou: can we say that UAs that implement max() should do it according to these rules, but other ones should be abrupt? (So authors can fix it in the future) 01:24:23 TabAtkins: We can cut it down to things which would require layout (which is just percentages) 01:24:29 fantasai: percentages are common. 01:24:47 TabAtkins: if you're all percentages, you're fine. If youre none percentages, you're fine. THe only bad case is if you mix 01:25:14 leaverou: If you fall back to generic interpolation, which is cross fade, people will rely on it, because cross-fade looks nice. If its abrupt, people won't rely on it 01:25:18 fantasai: they could 01:25:28 leaverou: That's what happens now, so if you're right we shouldn't do this at all 01:25:43 fantasai: yeah but the point of the cross fade could be random, then they for real can't rely on it 01:26:04 Rossen: can we resolve? 01:26:20 Karen has joined #css 01:26:21 s/yeah but the point of the cross fade/then your cross fade vs abrupt transition/ 01:26:54 TabAtkins: Proposed resolution: In the one case where you need layout-time information to do fixup, if you don't implement max(), you must do an abrupt interpolation 01:27:00 leaverou: that works 01:27:06 Rossen: any objections? 01:27:09 TabAtkins: case is if you mix percentage and non-percentage stops 01:27:11 RESOLVED: In the one case where you need layout-time information to do fixup, if you don't implement max(), you must do an abrupt interpolation 01:27:50 leaverou: Backportin gradient midpoints to L3 because we have 3 ipmlementations 01:28:58 Ric implemented all the implementations so they are not independent so it doesn't qualify 01:29:36 s/Ric/Rik/ 01:29:57 Florian: independent implementations require independent authors 01:30:22 ChrisL: we have 3 impl., so edge will be pressured to do it. So edge will do it independently 01:30:51 Rossen: this will just hold up the level 3 spec for longer, to wait for another impl 01:31:03 fantasai: we don't know how to test gradeitns so we dont' have tests 01:31:11 Florian: we have some but not many 01:31:20 Florian: Opera has tests for gradients 01:31:47 Florian: they work by using a software implementation of canvas 01:32:17 ChrisL: Making a reftest for this is hard, becuse has to be pixel perfect 01:32:27 myles: +1 01:32:28 ChrisL: Can do a visual test, where a person says "yeah, that looks about the same" 01:32:41 Rossen: back on topic please 01:32:57 s/software implementation of canvas/software implementation in canvas/ 01:32:58 TabAtkins: we should reject b/c not independent 01:33:13 RESOLVED: Reject this proposal 01:33:49 TOPIC: Premultiplication in gradients 01:35:02 Fantasai: "transparent" keyword should compute to 2 color stops: one of the previous hue of the previous color, and the hue of the next color. 01:35:14 fantasai: currently transparent is just transparent black 01:35:33 s/Fantasai:/fantasai: Issue was saying/ 01:35:51 leaverou: instead of using premultiplied, we should special-case "transparent" since every case which needs this is due to transitions to or from transparent 01:36:05 leaverou: when you don't use transparent, you dont' want to lose the color information in your color 01:36:30 leaverou: there are gradients which are impossible to do in a premultipled RGBA space 01:36:37 TabAtkins: you are wrong. You can use dummy stops 01:36:56 TabAtkins: we do it in non-premultiplied, but we use dummy stops to emulate premultiplied 01:37:00 TabAtkins: b/c of Skia 01:37:35 TabAtkins: Problems! A) Transparent is equivalent to RGBA(0, 0, 0, 0) which disappears by computed value time. This changes that to make it special, whcih retains its identity 01:37:44 leaverou: or we special case RGBA(0, 0, 0, 0) 01:37:55 TabAtkins: this is worse beceause of rounding. Rounding could trigger this erroneously 01:38:31 ChrisL: this is an author convienience because people want ot go to and from transparent. We lumped together color and opacity together, which is unwise, and makes this hard 01:39:13 astearns: does special casing transparent as 2 stops makes transitions break becauuse the numberr of stops changes 01:39:22 ChrisL: so you would have to fix this up behind the scenes liek youd o now 01:39:32 TabAtkins: our internal data model retains the knowledge of the input number of stops 01:39:40 ChrisL: so yes, the implementation fakes the extra stops 01:40:03 TabAtkins: No, because you either have to keep transparent around longenough as independent value, to fake at paint time 01:40:15 TabAtkins: this requires a chagne to transparent across all colros which isn't good 01:40:21 leaverou: this also applies to transitions and gradients 01:40:27 TabAtkins: and the color: property 01:40:36 TabAtkins: because of serialization 01:40:57 TabAtkins: author code may depend on this (b/c they assume 4 tuples) would break 01:41:04 Florian: will this be fixed later when we switch the working color space? 01:41:13 ChrisL: the working colro space is independent of premultiplication 01:41:27 Rossen: proposed resolution: don't do this 01:41:34 Rossen: objections/ 01:41:34 ? 01:41:49 RESOLVED: Reject the proposal 01:42:18 skk has joined #css 01:59:07 rachelandrew has joined #css 01:59:29 Karen has joined #css 02:00:57 so we'll have the page floats breakout minutes on #houdini 02:07:14 ScribeNick: fantasai 02:07:20 Topic: CSS-SVG Box Correspondences 02:07:37 ScribeNick: flackr 02:07:48 tantek has joined #css 02:07:52 present+ 02:07:54 myles has joined #css 02:08:37 fantasai: issue is to have a standardized mapping between dash box keywords, bunch of properties take these kinds of keywords 02:09:06 present+ 02:09:27 s/dash box/*-box/ 02:09:52 Rossen: yesterday we partially covered issue, and agreed on mapping. content-box and padding-box map to fill-box. border-box maps to stroke-box 02:09:55 myles has joined #css 02:10:12 fantasai: we need something to go back in other direction 02:10:15 Rossen: for view-box? 02:10:44 TabAtkins: it's a box, but we don't have anything that let's you refer to it 02:10:47 murakami has joined #css 02:11:02 It seems we have three github issues on this: https://github.com/w3c/fxtf-drafts/issues/66 https://github.com/w3c/csswg-drafts/issues/999 https://github.com/w3c/csswg-drafts/issues/857 02:11:03 TabAtkins: we can map view-box to one of the element based boxes 02:11:33 Github issue: https://github.com/w3c/csswg-drafts/issues/857 02:11:40 fantasai: in fill and stroke module css ends up having all of these boxes, 02:11:47 Kitahara has joined #css 02:11:54 fantasai: are there places in other specs where we take these boxes? 02:12:35 TabAtkins: no, we only have these in fill and stroke because they talk about text, with geometry different than normal boxes 02:13:10