w3 :: #css

21 Apr 2017
00:02nainarI am dialling in
00:03* dbaron github-bot, status
00:03* github-bot I currently have data for the following channels:
00:03* github-bot #css (no topic data buffered)
00:03* dbaron github-bot, status
00:03* github-bot I currently have data for the following channels:
00:12johanneswilmastearns: is there also a webex link to connect directly (webrtc)? we are starting 9:15?
00:15* johanneswilm can only hear noise on the webex line
00:16* Florian johanneswilm, only background conversations so far, nothng has started. Is that what you're hearing, or actual white noise?
00:16kudoConference is not started yet
00:16kudoThat is why, you only get noise from the room
00:16* nainar can hear people talking, but its pretty legible :)
00:18* johanneswilm florian, yeah, background conversations. not sure this line is good enough. Do we have a webex meeting number?
00:19* fantasai forgot power cable, might need to borrow one from Mozilla folks at some point today?
00:19* johanneswilm kudo?
00:19Rossentrackbot, start meeting
00:19* trackbot is preparing a teleconference.
00:19trackbotRRSAgent, make logs public
00:19RRSAgentI have made the request, trackbot
00:19trackbotZakim, this will be Style_CSS FP
00:19Zakimok, trackbot
00:19trackbotMeeting: Cascading Style Sheets (CSS) Working Group Teleconference
00:19trackbotDate: 21 April 2017
00:20philipwaltonpresent+
00:20flackrpresent+
00:20eaepresent+
00:20rbyerspresent+
00:20TabAtkinspresent+
00:20murakamipresent+
00:20Rossenpresent+
00:20SimonSapinpresent+
00:20iank_present+
00:20mylesScribeNick: Myles
00:20tantekpresent+
00:20surmapresent+ Surma, Google
00:20kawakubopresent+
00:20fantasaipresent+
00:20mylespresent+
00:20xidornpresent+
00:20jihyepresent+
00:20leaveroupresent+
00:20dbaronPresent+
00:20ChrisLpresent+
00:20mylesTopic: URL Discussion
00:20astearnspresent+
00:20rachelandrewpresent+
00:20RossenTopic: Update on URL function discussions
00:21mylesplinss: url() - do they resolve to images or elements?
00:21mylesplinss: we had 4 options
00:21* TabAtkins does github-bot understand regex comments?
00:21dbaronhttps://dbaron.org/css/test/2017/mask-url
00:22mylesplinss: David looks into what Firefox does. But our resolution is contrary to that. We want to revisit to allow Firefox
00:22mylesdbaron: 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:22plinsspresent+
00:23mylesdbaron: 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:23mylesfantasai: This is an optimization of loading twice in general
00:23mylesfantasai: a local reference is not going to be an image
00:23mylesdino: why not?
00:23mylesdino: it could be an SVG image, or a SVG root, or a canvas
00:23mylesdbaron: we dont' want infinite recursion
00:23mylesTabAtkins: pointing to canvases isn't allowed at all anywhere
00:24mylesdino: Someone might do it
00:24mylesdino: We could point as an image element in the document and using it as a mask
00:24mylesleaverou: that's not allowed
00:24mylesChrisL: this is imaginary
00:24mylesdbaron: the mask property used to point to a mask element but we extended it to point to image
00:25mylesdbaron: when we do this, we ignore the other masking properties like mask-repeat, etc.
00:25mylesChrisL: this is according to the spec, rights?
00:25mylesdbaron: i think so
00:25mylesleaverou: So, it's possible to have the Firefox implementation from the spec?
00:25mylesleaverou: We all agree that this is the most reasonable choice
00:26mylesRossen: Can someone summarize what is going on?
00:26mylesplinss: You should know what's going on
00:26mylesleaverou: Hey tab, please type in the options again
00:27plinsshttps://log.csswg.org/irc.w3.org/css/2017-04-19/#e796988
00:27leaverou1. Treat ambiguous cases as url reference into an SVG document, not treat as image and apply :target
00:27leaverou2. Treat ambiguous cases as url, if it has a fragID treat as a reference, otherwise treat as an image
00:27leaverou3. Treat ambiguous cases, load it twice -- first see if there's an appropriate reference, otherwise go back and reload as an image
00:27leaverou4. Do something different per property
00:27mylesleaverou:
00:27* astearns I think that's what I said (with 4 added) :)
00:27mylesdino: what does "ambiguous" mean?
00:28mylesplinss: if the property can handle both an element and an image, and the URL could be either
00:28mylesplinss: can we resolve to make this decision on whether it's a local or external URL?
00:29mylesmyles: Firefox does 3, right?
00:29mylesleaverou: Basically. With some extra optimizations
00:29mylesplinss: Architecture says that you can only interpret what a fragment means until you get a content-type from the response
00:29mylesdbaron: The case where Firefox doesn't do the right thing is when there is a base URL and a url(#foo)
00:30mylesdbaron: This is probably not the only case where this occurs
00:30mylesdbaron: like <a href=&quot;#foo&quot;> scrolls within the current document
00:30mylesTabAtkins: CSS always treats a #url as a reference into the local document
00:30mylesplinss: That is a separate issue and an architectural violation
00:31mylesplinss: At the end of the day, I&#39;m okay with browsers not handling everything exactly b/c of optimizations. What I&#39;m not okay with is the spec stating you must violate architectural principles and Gecko must stop doing what it&#39;s doing
00:31mylesRossen: Other thoughts?
00:32mylesRossen: Proposed resolution: a mixture of #2 and #3
00:32mylesfantasai: 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:32mylesfantasai: We always have our image() and element() functions which can make the distinction
00:32mylesChrisL: so you&#39;re not losing anything
00:33mylesTabAtkins: We know the content type of the current resource, so we can interpret the hash correctly
00:33mylesTabAtkins: I need confirmation from our loading people that this is implementable
00:33mylesTabAtkins: we will try
00:34mylesplinss: I&#39;m okay with &quot;should&quot; or &quot;must (but we know you won&#39;t)&quot;
00:34mylesRossen: &quot;should&quot; please.
00:34mylesRossen: Proposed resolution: Option #3 with &quot;should&quot;
00:34mylesTabAtkins:
00:34* plinss https://tools.ietf.org/html/rfc6919
00:34mylesTabAtkins: (summarizes proposed resolution)
00:35leaverouRESOLVED: Should treat ambiguous cases, load it twice -- first see if there&#39;s an appropriate reference, otherwise go back and reload as an image
00:35mylesRESOLVED: Implementations should treat ambiguous cases, load it twice -- first see if there&#39;s an appropriate reference, otherwise go back and reload as an image
00:35dbaronGithub issue: https://github.com/w3c/csswg-drafts/issues/383
00:35* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/383.
00:36leaverouRESOLVED: For ambiguous cases, UAs SHOULD first see if there&#39;s an appropriate reference, otherwise go back and reload as an image
00:36mylesThanks leaverou
00:36mylesRossen: RESOLVED: Let&#39;s stop resolving
00:36dbaronTopic: split sessions
00:36* github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/383
00:37mylesFlorian: We found a number of places where we wanted to tweak the page floats spec
00:37mylesFlorian: But then we spoke more, and alternatively to tweaks, we could do deeper changes, and that might be better
00:37mylesFlorian: So we need a long deep session about page floats.
00:38mylesFlorian: Otherwise, we should just take it off the agenda.
00:38mylesRossen: What about rhythm?
00:38mylesRossen: We need to break out.
00:39mylesTOPIC: Images
00:40myles<projector issues>
00:43myles<more projector issues>
00:44myles<projector seems busted>
00:44tantekMore like USB-C = beta-testing
00:45myles<projector starts working>
00:45leaverouhttps://drafts.csswg.org/issues?spec=css-images&doc=cr-2012
00:45mylesTOPIC: Images 3 Issues
00:45myles1. Deprecating image orientation
00:46mylesleaverou: This isnt&#39; about deprecating it. Someone said that angles in image-orientation are pointless. You&#39;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:46mylesleaverou: and none
00:46mylesleaverou: which is now called 0deg
00:47fremyIs there a break out session on page floats and rythm or not, ultimately? If so; where is it minuted?
00:47mylesleaverou: the point is that the angles are pointless
00:47tantekthat seems reasonable
00:47mylesleaverou: we agree but we need a resolution since it&#39;s in CR. Any objections?
00:47mylesfantasai: I&#39;m okay with deprecating or obsoleting, but we need to keep them in the spec
00:47mylesfantasai: We have references coming into this from other non-W3C places
00:47mylesFlorian: which ones?
00:47mylesfantasai: Printers.
00:47dbaronI&#39;ve been in favor of just from-image | none since &quot;forever&quot;...
00:48mylesfantasai: They have some idea of HTML & CSS because of their printers.
00:48mylesChrisL: This is the XHTML print stuff
00:48mylesfantasai: These printers rely on this stuff
00:48mylesleaverou: angles?
00:48mylesfantasai: yes
00:48tantekwait was there a test case for angles?
00:48mylesfantasai: I don&#39;t know the details. I worked on testing this and it&#39;s used.
00:49tantekok with &quot;obsolete&quot;
00:49mylesfantasai: From our perspective, browsers don&#39;t need to implement it. But it can&#39;t be removed. We can just say it&#39;s obsolete and not to implement it
00:49mylesTabAtkins: sounds good
00:49ChrisLhttps://www.w3.org/TR/xhtml-print/
00:49mylesleaverou: resolution?????
00:49mylesdbaron: There needs to be a second piece which is to add &quot;none&quot;
00:49mylesdbaron: value
00:49mylesTabAtkins: Unless we want to say that it accepts an angle but only 0
00:49ChrisLfour implementations in the implementation report https://www.w3.org/MarkUp/Test/xhtml-print/implementation/
00:50tanteksounds good
00:50leaverouRESOLVED: Deprecate <angle> in image-orientation and add a &#39;none&#39; value
00:50mylesRESOLVED: Deprecate <angle> in image-orientation and add a &#39;none&#39; value
00:50mylesleaverou: Interpolating percentages in cross-fade
00:51mylesleaverou: spec says if you do it that only differ by their percentage, then you just interpolate their percentage
00:51mylesThe other cross-fade, the two arguments are not identical, so this would trigger the default generic interpolation
00:52mylesTabAtkins: theoretically you could detect this condition and fix it in the browser
00:52mylesleaverou: but there is arbitrary complexity here
00:52mylesTabAtkins: 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:53mylesdino: this is 1 level or 2 levels but not n levels
00:53mylesTabAtkins: we interpolate the percentages, and the two first arguments and the second arguments, and it cascades down forever
00:53mylesdino: in the example, if instead of the first case said 1.png and the second case said 3.png
00:53mylesTabAtkins: then you would do a generic interpolation
00:54mylesdino: i don&#39;t mind what it is. Definitely 1 level is easier
00:54mylesTabAtkins: yes
00:54mylesTabAtkins: the &quot;interpolate further down&quot; case is more interesting but is more complicated.
00:54mylesTabAtkins: i can go either way
00:54mylesdino: how often will authors write nested cross fades
00:54mylesleaverou: it could come from variables.
00:54mylesleaverou: it&#39;s easy to get this with variables
00:54mylesdino: yes. This means that the variable itself might be animating, so you might be animating between two animations
00:54mylesAnimations all the way down!
00:55mylesfantasai: we have other image functions in mind for the future, so introspection in general will be more useful for these future things.
00:55mylesfantasai: i have a variety of different ideas for extending this that it would be useful for
00:55fantasais/i/we/
00:55mylesleaverou: introspection definitely yields the results the author wants, but it may be too hard to implement
00:56mylesfantasai: it depends on your internal representation. If it&#39;s simple, then matching it is easy.
00:56mylesdbaron: You could define the interpolation rules recursively
00:56mylesTabAtkins: that&#39;s the second options
00:56mylesTabAtkins: we interpolate the percentage, the first arg and the second arg separately
00:56* dbaron implemented ignoring of present+ lines in https://github.com/dbaron/wgmeeting-github-ircbot/commit/cc9235e61801bc7a4730c974b5d797c1990e0eab
00:57* fantasai :)
00:57mylesLeaverou: 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:57mylesTabAtkins: You could recursively interpolate between the two linear gradients in the first argument
00:58mylesTabAtkins: We need to decide which option. All in, or in 1.
00:58mylesdino: &quot;all in&quot; may require checking of many image types.
00:58mylesdino: the arguments may be interpolatable, other than a cross-fade.
00:58mylesTabAtkins: leaverou: yes.
00:58mylesdino: Do we already have a list of images you can interpolate between?
00:59mylesTabAtkins: leaverou yes
00:59mylesdino: implementation-wise, one level is easier, but meh
00:59mylesleaverou: Is there any implementations which have done it the other way so we can test it?
00:59mylesdino: we have a lot of bugs in cross-fade interpolation
00:59mylesdino: just random bugs
00:59mylesfantasai: we should do recursive, and if there are no implementations, we just mark it as undefined in level 4
01:00mylesfantasai: i mean, if we end up without implementations, then we push it out to level 4 and in level 3 say that it&#39;s undefined.
01:00mylesastearns: so we mark it at-risk immediately?
01:00mylesfantasai: yes
01:00mylesFlorian: &quot;at risk&quot; means &quot;for being pushed out&quot; not for &quot;being removed&quot;
01:01mylesleaverou: If implementations care about it working by a cross fade and not other rules, then authors will depend on it.
01:01mylesfantasai: that&#39;s why we want recursion now
01:01mylesdbaron: how do they actually differ?
01:01mylesTabAtkins: in the example above, 1st argument stays as it is. Let&#39;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:01mylesdbaron: okay
01:02mylesdino: The generic case means adding a cross-fade
01:02* astearns interpolatinterpolationon
01:02mylesdbaron: this example is confusing
01:02mylesdbaron: and uninteresting
01:02mylesleaverou: let&#39;s start with recursive and change it if there are no implementations
01:02mylesRossen: ok
01:03mylesRossen: any objections?
01:03mylesleaverou: it will be at risk
01:03mylesRossen: yes
01:03mylesleaverou: cross fade is the only piece which isn&#39;t at risk
01:03Florians/&quot;at risk&quot; means &quot;for being pushed out&quot; not for &quot;being removed&quot;/make it clear that it&#39;s &quot;at risk of being undefined&quot; not &quot;at risk of being removed&quot; (and therefore defined to do the opposite)/
01:03mylesDino: tabatkins: Chrome and WebKit implement image interpolation with cross fade
01:03mylesRossen: no objections
01:03dbaron(pre-fork, so one implementation)
01:04mylesRESOLVED: Do interpolations recursively on each argument, but mark it at risk
01:04myles3!
01:04mylesleaverou: we have special rules for interpolation in gradients.
01:04mylesleaverou: <enumerates the special rules>
01:04mylesleaverou: do these rules apply to the color stops before or after fixup?
01:05mylesleaverou: you could have a gradient today that is white to black and a value of 0 gets fixed up to 20%
01:05mylesleaverou: color stops with no position get positioned between the adjacent ones
01:05mylesleaverou: color stops become equal to the previous one in some cases
01:06mylesleaverou: layout needs to happen because you need to compute some lengths to do the fixup
01:06mylesleaverou: so it&#39;s optimal to do interpolation to do on the fixed up positions, but it may be impossible b/c of layout
01:06mylesTabAtkins: <describes a case where this happens>
01:07mylesTabAtkins: if it&#39;s pre-fixup, then during the transition, the animation is not smooth
01:07mylesPost-fixup gives a more correct solution
01:07mylesTabAtkins: when you&#39;re making stripes, it&#39;s common to just put 0 as the position, because it forces it to be at the previous color stop&#39;s ending point. So fixing up is common.
01:08mylesTabAtkins: if we stick with pre-fixup, we break this content
01:08mylesfantasai: I&#39;m not convinced that post-fixup is better
01:08mylesTabAtkins: but i just talked about the the 0 common technique (above)
01:09mylesleaverou: in the past, we needed layout. Today, we can use min() or max()
01:09mylesfantasai: min() doesn&#39;t exist today w/r/t images
01:09mylesdbaron: does &quot;fixup&quot; only mean positions of color stops, or elimination of redundant color stops
01:09mylesTabAtkins: elimination doesn&#39;t happen. This is well-defined
01:09mylesdbaron: that makes it easier
01:10mylesleaverou: many people use redundant color stops to force gradient interpolation instead of generic image interpolation
01:10mylesfantasai: they need it as a placeholder.
01:10mylesTabAtkins: dbaron, why do you think it&#39;s easier?
01:11mylesdbaron: 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&#39;s okay.
01:11mylesTabAtkins: yep.
01:11fantasaiw/r/t images -> as far as css-images-3 is concerned
01:11mylesTabAtkins: Both options are difficult
01:11mylesTabAtkins: We can represent the intermediate steps w/o layout by using max()
01:11mylesfantasai: we don&#39;t have that
01:11mylesleaverou: we will
01:11mylesfantasai: there are 0 implementations.
01:11mylesfantasai: we can&#39;t rely on that here
01:12* dino leaverou++ for imminently not momentarily
01:12mylesfantasai: you can say &quot;don&#39;t do any gradient color implemtnations until you implement min()&quot; but that&#39;s a bad dependency
01:12mylesTabAtkins: or it may just be wrong
01:12mylesTabAtkins: you could just use calc() for the stops instead
01:12mylesfantasai: the goal is to get the spec to rec. min() won&#39;t be able to achieve this. So it&#39;s a bad dependency
01:12mylesTabAtkins: We should never do the bad thing because of process
01:13mylesfantasai: The existing behavior in the meantime is valuable
01:13mylesfantasai: Is it going to be okay to change the behavior of this property when browsers finally implement max()
01:13myles?
01:13mylesTabAtkins: nope
01:13mylesTabAtkins: but it shouldn&#39;t delay iot.
01:13mylesChrisL: It&#39;s not process, it&#39;s that there are no implementations
01:14mylesTabAtkins: it doesn&#39;t matter when it gets implemented
01:14leaverouCan someone test this in Edge 15? http://dabblet.com/gist/24224c83758444bf3be8b05fd7069a84
01:14mylesFlorian: we can always change it, but it depends on the compat at that point
01:14mylesleaverou: if we say that interpolation happens pre-fixup, we will break things
01:14mylesfantasai: but we don&#39;t have a choice because there is no implemetnation of max()
01:14mylesleaverou: we should wait longer and get it right
01:15mylesfantasai: what will we do in teh meantime?
01:15mylesleaverou: we already waited 6 years
01:15mylesfantasai: what will the implementation do in the meantime until it implements max()
01:15mylesTabAtkins: it will be buggy
01:15mylesleaverou: this isn&#39;t the first tiem we&#39;ve done this
01:16mylesfantasai: I want it to be deined what you do if you don&#39;t implement max()
01:16mylesTabAtkins: i don&#39;t want to have to cafrefully controll when we make a change to the spec based on when people implement min() and max()
01:16mylesfantasai: we need a definition for both cases
01:16mylesTabAtkins: soundsg ood
01:17mylesFlorian: isn&#39;t it better that the intermediate behavior is buggy
01:17mylesTabAtkins: it doesn&#39;t matter
01:17mylesleaverou: why doesn&#39;t my example work in Edge????
01:17mylesRossen: i dunno
01:18mylesRossen: fantasai: what resolution do you want?
01:18mylesfantasai: i dunno. I&#39;m not convinced of what we&#39;re trying to do
01:18mylesleaverou: we could make max() required to implement this
01:18mylesfantasai: i&#39;m not convinced that the theoretical best (if max() exists) is this behavior?
01:18myless/?/./
01:19fremyleaverou: quick guess is that it uses explicit in one and implicit in other
01:19mylesfantasai: if we had color stops relative to the position of the previous color stop, we could do it
01:19fremy@leaverou: that one works: https://wptest.center/#/i4sli8
01:19mylesChrisL: this would actually work with what authors want. When authors say &quot;0&quot; they actually are just using a placeholder. We could give them a keyhword
01:20mylesleaverou: Why would an author use a keyword?
01:20mylesleaverou: we could do the interpolation on teh declared list of color stops, but there is more existing content which it wouldn&#39;t work with
01:20mylesfantasai: walks across a curtain, or something????
01:21* astearns note to self, curtain-themed analogies for for Florian
01:21mylesfantasai: Depending on what your goals are as an author, you might have different goals as an author
01:21mylesfantasai: both behaviors are valuable
01:21* astearns s/for for/work for/
01:21fantasais/valuable/reasonable/
01:21mylessurma: most use cases will want to animate from whereve it is on screen
01:22mylessurma: rather than where it ought to be
01:22mylesleaverou: 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:22mylesleaverou: content may do what UAs should be doing, themselves
01:23mylesleaverou: like a polyfill
01:24mylesleaverou: 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:24mylesTabAtkins: We can cut it down to things which would require layout (which is just percentages)
01:24mylesfantasai: percentages are common.
01:24mylesTabAtkins: if you&#39;re all percentages, you&#39;re fine. If youre none percentages, you&#39;re fine. THe only bad case is if you mix
01:25mylesleaverou: 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&#39;t rely on it
01:25mylesfantasai: they could
01:25mylesleaverou: That&#39;s what happens now, so if you&#39;re right we shouldn&#39;t do this at all
01:25mylesfantasai: yeah but the point of the cross fade could be random, then they for real can&#39;t rely on it
01:25* astearns hey look! I found a neat trick to turn on stuttery transitions!
01:26mylesRossen: can we resolve?
01:26fantasais/yeah but the point of the cross fade/then your cross fade vs abrupt transition/
01:26mylesTabAtkins: Proposed resolution: In the one case where you need layout-time information to do fixup, if you don&#39;t implement max(), you must do an abrupt interpolation
01:27mylesleaverou: that works
01:27mylesRossen: any objections?
01:27fantasaiTabAtkins: case is if you mix percentage and non-percentage stops
01:27mylesRESOLVED: In the one case where you need layout-time information to do fixup, if you don&#39;t implement max(), you must do an abrupt interpolation
01:27mylesleaverou: Backportin gradient midpoints to L3 because we have 3 ipmlementations
01:28mylesRic implemented all the implementations so they are not independent so it doesn&#39;t qualify
01:29fantasais/Ric/Rik/
01:29mylesFlorian: independent implementations require independent authors
01:30mylesChrisL: we have 3 impl., so edge will be pressured to do it. So edge will do it independently
01:30mylesRossen: this will just hold up the level 3 spec for longer, to wait for another impl
01:31mylesfantasai: we don&#39;t know how to test gradeitns so we dont&#39; have tests
01:31mylesFlorian: we have some but not many
01:31mylesFlorian: Opera has tests for gradients
01:31mylesFlorian: they work by using a software implementation of canvas
01:32fantasaiChrisL: Making a reftest for this is hard, becuse has to be pixel perfect
01:32mylesmyles: +1
01:32fantasaiChrisL: Can do a visual test, where a person says &quot;yeah, that looks about the same&quot;
01:32mylesRossen: back on topic please
01:32Florians/software implementation of canvas/software implementation in canvas/
01:32mylesTabAtkins: we should reject b/c not independent
01:33mylesRESOLVED: Reject this proposal
01:33mylesTOPIC: Premultiplication in gradients
01:35mylesFantasai: &quot;transparent&quot; keyword should compute to 2 color stops: one of the previous hue of the previous color, and the hue of the next color.
01:35mylesfantasai: currently transparent is just transparent black
01:35fantasais/Fantasai:/fantasai: Issue was saying/
01:35mylesleaverou: instead of using premultiplied, we should special-case &quot;transparent&quot; since every case which needs this is due to transitions to or from transparent
01:36mylesleaverou: when you don&#39;t use transparent, you dont&#39; want to lose the color information in your color
01:36mylesleaverou: there are gradients which are impossible to do in a premultipled RGBA space
01:36mylesTabAtkins: you are wrong. You can use dummy stops
01:36mylesTabAtkins: we do it in non-premultiplied, but we use dummy stops to emulate premultiplied
01:37mylesTabAtkins: b/c of Skia
01:37mylesTabAtkins: 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:37mylesleaverou: or we special case RGBA(0, 0, 0, 0)
01:37mylesTabAtkins: this is worse beceause of rounding. Rounding could trigger this erroneously
01:38mylesChrisL: 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:39mylesastearns: does special casing transparent as 2 stops makes transitions break becauuse the numberr of stops changes
01:39mylesChrisL: so you would have to fix this up behind the scenes liek youd o now
01:39mylesTabAtkins: our internal data model retains the knowledge of the input number of stops
01:39mylesChrisL: so yes, the implementation fakes the extra stops
01:40mylesTabAtkins: No, because you either have to keep transparent around longenough as independent value, to fake at paint time
01:40mylesTabAtkins: this requires a chagne to transparent across all colros which isn&#39;t good
01:40mylesleaverou: this also applies to transitions and gradients
01:40mylesTabAtkins: and the color: property
01:40mylesTabAtkins: because of serialization
01:40mylesTabAtkins: author code may depend on this (b/c they assume 4 tuples) would break
01:41mylesFlorian: will this be fixed later when we switch the working color space?
01:41mylesChrisL: the working colro space is independent of premultiplication
01:41mylesRossen: proposed resolution: don&#39;t do this
01:41mylesRossen: objections/
01:41myles?
01:41mylesRESOLVED: Reject the proposal
02:00astearnsso we&#39;ll have the page floats breakout minutes on #houdini
02:07fantasaiScribeNick: fantasai
02:07fantasaiTopic: CSS-SVG Box Correspondences
02:07RossenScribeNick: flackr
02:07tantekpresent+
02:08flackrfantasai: issue is to have a standardized mapping between dash box keywords, bunch of properties take these kinds of keywords
02:09skkpresent+
02:09dbarons/dash box/*-box/
02:09flackrRossen: 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:10flackrfantasai: we need something to go back in other direction
02:10flackrRossen: for view-box?
02:10flackrTabAtkins: it&#39;s a box, but we don&#39;t have anything that let&#39;s you refer to it
02:11dbaronIt 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* github-bot Because I don&#39;t want to spam github issues unnecessarily, I won&#39;t comment in that github issue unless you write &quot;Github topic: <issue-url> | none&quot; (or &quot;Github issue: ...&quot;).
02:11flackrTabAtkins: we can map view-box to one of the element based boxes
02:11dbaronGithub issue: https://github.com/w3c/csswg-drafts/issues/857
02:11* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/857.
02:11flackrfantasai: in fill and stroke module css ends up having all of these boxes, <points to content, padding, border, stroke>
02:11flackrfantasai: are there places in other specs where we take these boxes?
02:12flackrTabAtkins: no, we only have these in fill and stroke because they talk about text, with geometry different than normal boxes
02:13flackrfantasai: fill-origin property, which takes these keywords can be set on any element. it&#39;s not applied to text, applied to an element and takes that object&#39;s geometry for settting the fill origin for images
02:13flackrfantasai: if we don&#39;t have transform-box or other box properties use that same definition, then if you set coordinates in transforms and set the same in fill or stroke, you would get different results
02:14flackrfantasai: we didn&#39;t run into a use case while working on transforms that we needed these text based bounding box concepts, but we should use this same concept in all of our boxes whereever fill or stroke appears
02:14flackrfantasai: for example for setting a mask image with the same origin when set to fill-box as a fill with origin set to fill-box
02:14flackrTabAtkins: possible
02:15flackrTabAtkins: problem is that mask, transform, and shapes
02:15flackrfantasai: shape doesn&#39;t have fill and stroke
02:15dbaronreading https://github.com/w3c/csswg-drafts/issues/999#issuecomment-277024658
02:15* github-bot Because I don&#39;t want to spam github issues unnecessarily, I won&#39;t comment in that github issue unless you write &quot;Github topic: <issue-url> | none&quot; (or &quot;Github issue: ...&quot;).
02:16flackrdbaron: the notion that some of the properties are doign different things does make some sense because they can&#39;t reasonably map into the same property
02:17flackrfantasai: didn&#39;t discover we needed fill and stroke box until we did this module
02:17fantasais/this/fill-stroke/
02:18dbaronhttps://drafts.fxtf.org/fill-stroke/
02:18fantasais/until/in CSS until/
02:19flackrfantasai: view-box is on transform-box property?
02:19flackrTabAtkins: just on transform-box
02:19flackrChrisL: the view-box declared on the closest svg element
02:19flackrRossen: kind of like initial box of the svg
02:20flackrTabAtkins: I don&#39;t agree in general we should match fill-box and stroke-box to same meaning
02:20flackrTabAtkins: because these properties are dealing with text and these properties are talking about properly filling and stroking that text
02:20flackrTabAtkins: whereas for svg they are in a different context, it depends on the property you are interpreting for
02:22flackrfantasai: if you have element with some text, and the fill box is bigger, then when you draw an image and add a mask, these need to use the same coordinate system
02:22flackrfantasai: but if you&#39;re saying fill-box is not available for mask origin can&#39;t make these line up
02:23flackrTabAtkins: it&#39;s still a matter of which concept you&#39;re talking about, the box&#39;s geometry or the geometry of the text
02:23flackrfantasai: it should create the same coordinate system that it does if you set fill-origin on that element
02:23flackrRossen: in css boxes internally, this is going to be an overflow box
02:24flackrfantasai: it&#39;s text only
02:24flackrfantasai: it&#39;s the outline of the glyphs, so not quite the inline text box
02:24flackrfantasai: i think we need consistent coordinate systems, fill-origin and mask-origin should have the same behavior for the same keywords
02:24flackrfantasai: if those have same behavior for same keywords, transform-box should too
02:25flackrTabAtkins: yeah, but other properties such as mask-origin, when using svg keyword on css stuff will have a changed meaning
02:25flackrfantasai: hopefully people aren&#39;t doing that
02:25flackrChrisL: how much of a breaking change is this?
02:25flackrTabAtkins: might be minor, might be major, depends on content
02:26flackrfantasai: initial value might need to be some kind of auto keyword that depends on whether it&#39;s svg or css
02:26flackrChrisL: i&#39;d rather avoid making breaking changes unless we have to
02:26fantasaifantasai: or a UA stylesheet thing
02:26flackrTabAtkins: initial value of border-box for svg is view-box
02:27flackrTabAtkins: transforms and svgs default to the top-left corner
02:27flackrTabAtkins: i guess i&#39;m okay with this
02:27flackrTabAtkins: with fill-box used in css meaning what&#39;s defined in fill and stroke
02:28flackrRossen: we don&#39;t care about view-box?
02:28flackrfantasai: this is another issue i think
02:29flackrTabAtkins: think we added auto keyword
02:29fantasai[confusion about what the resolutions actually were]
02:30flackrfantasai: if I specify transform-box: border-box on svg element what do i get?
02:30flackrfantasai: If i specify transform-box: view-box on a CSS box what do i get?
02:31flackrTabAtkins: maps down to border-box, it&#39;s the closest you can get
02:31flackrfantasai: what&#39;s the initial value?
02:31flackrTabAtkins: something different, forget what specifically
02:31dbaron(answer to the previous question was border-box -> stroke-box on SVG)
02:31flackrfantasai: make initial value view-box to get behavior we want it to have
02:31flackrChrisL: that seems fine
02:32fantasaiResolutions from yesterday, presumably were
02:32fantasai* border-box in SVG is treated as stroke-box
02:32fantasai* view-box is in CSS is treated as border-box
02:32fantasai* initial value is view-box
02:33fantasaiFrom today: fill-box and stroke-box for CSS are as defined in fill-stroke
02:33fantasaifor completeness, content-box and padding-box in SVG are treated as fill-box
02:34flackrRossen: view-box and stroke-box resolve to the same as boxes defined in svg fill-stroke
02:35flackrRESOLVED Initial value of transform is view-box
02:35flackrRESOLVED: Initial value of transform is view-box
02:35fantasaiRESOLVED: view-box and stroke-bo resolve to the same as boxes defined in fill-stroke module
02:35fantasais/stroke-bo/stroke-box/
02:36flackrTopic: Color properties
02:36* github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/857
02:37dinoGithub Topic: https://github.com/w3c/csswg-drafts/issues/300
02:37* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/300.
02:37flackrdino: idea is that document will have working color space, some kind of css syntax to say what it is, default is srgb
02:37flackrdino: there was some discussion as to what does the value if you specify background-color: rgb(255, 0, 0) what space are they in?
02:38flackrChrisL_: this is in sRGB
02:38flackrdino: this didn&#39;t matter because everything was in sRGB. we think older style colors should be in working color space
02:39flackrChrisL_: downside is if you view source and copy some of their style and document the colors become different
02:39flackrChrisL_: also, one reason to change working color space is because you&#39;ve got some bit of content you want in a different color space, like a video
02:39flackrChrisL_: you don&#39;t want your existing colors to change because you have a new element needing a wider gamut
02:39flackrdino: adding the new element doesn&#39;t necessarily change colors
02:40flackrChrisL_: if you then want to have a gradient you need to change working color space
02:40flackrdino: i propose we change default working color space away from srgb but to be the same as it
02:40dbarons/the same as it/extended sRGB/
02:41flackrChrisL_: in SRGB you&#39;ve got 0-255 and we used to say you could theoretically go below 0 or above 255 but it was undefined what the transfer code was
02:41flackrChrisL_: there was defined a transfer space called ?? which was a linear mapping which was tried in HTML context for a while but it didn&#39;t work well
02:41dbarons/??/scRGB/
02:42flackrChrisL_: you need a wider gamut. going for an older model which isn&#39;t compatible with color management systems isn&#39;t going to work well
02:43flackrdino: concern that ChrisL_ is bringing up is that you would end up with a band as you clamped at the edge of your color space