- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 5 Apr 2017 19:13:10 -0400
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Telecon for Transforms & fill-stroke ------------------------------------ - The inaugural call between the CSSWG and those interested in SVG will be 6 April at 9pm UTC. REC Steps --------- - Fonts 3: Myles was actioned to make the changes to the test font requested by ChrisL and Rossen. - Cascade: The edits to drop scoped styles were made. - Values & Units: smfr was actioned to review the <position> edits. - RESOLVED: Update motion draft on TR 2017 Paris f2f dates - can we decide exactly? --------------------------------------------- - RESOLVED: Meeting Houdini Aug 1, CSS Aug 2-4 in Paris Move underimplemented features to Images 4 ------------------------------------------ - RESOLVED: Move everything with no impl to next level and mark everything with 1 impl as at risk. Grammar of grid-row-start and friends is ugly and harms value space for line names ------------------------------------------------------------------- - Everyone agreed that limiting the name space was bad and should be avoided in the future. Unfortunately, it is too late to fix this issue. - RESOLVED: No change on issue 1137 (https://github.com/w3c/csswg-drafts/issues/1137) Definition of `column-span` should say what happens without an ancestor multicol --------------------------------------------------------------------- - RESOLVED: Have column-span elements create a bfc even if not in a multi-col container. - Florian will clarify the spec in the form of a note. New feature - scroll-boundary-behavior (an extension of -ms-scroll-chaining) -------------------------------------------------------- - RESOLVED: Create a WICG repo for this new feature and work there for now. ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2017Apr/0014.html Present: Rossen Atanassov Tab Atkins David Baron Tantek Çelik Dave Cramer Benjamin De Cock Elika Etemad Simon Fraser Daniel Glazman Tony Graham Dael Jackson Brad Kemper Peter Linss Thierry Michel Michael Miller Simon Pieters Anton Prowse Melanie Richards Florian Rivoal Geoffrey Sneddon Alan Stearns Lea Verou Greg Whitworth Steve Zilles Regrets: Rachel Andrew Scribe: dael Telecon for Transforms & fill-stroke ------------------------------------ astearns: Let's start. Any extra items? fantasai: Yes. fantasai: There was a suggestion to have a separate SVG call for transforms & fill-stroke. I sent an email about that yesterday. fantasai: Current proposed time slot is tomorrow during SVG time slot. That depends on who is interested in making it. I'd be interested to take a quick IRC survey. dbaron: What time is that in clock time? fantasai: Let me grab the link <fantasai> https://www.timeanddate.com/worldclock/fixedtime.html?month=04&day=06&year=2017&hour=21&min=00&sec=0&p1=0 fantasai: 9pm UTC, 5pm East US, 11pm Paris, 7am Sydney, 6am Tokyo astearns: So could people interested in meeting at that time tomorrow put in IRC if they can make it? fantasai: Topic for tomorrow is transforms. fantasai: I want to know if you care about transforms, fill-stroke, or both. And then I want to know if you can make it. <dbaron> I'm somewhat interested in transforms, but can't make that time tomorrow fantasai: If you're interested in one of those, please type T, F, or Both in IRC. <Rossen> T <dbaron> T <TabAtkins> Both <ChrisL> both <gregwhitworth> T <smfr> Both <fantasai> T if you're interested in Transforms, F, if you're interested in Fill-Stroke, Y if you can make it N if you can't make it tomorrow astearns: Please now type if you can make it tomorrow. <Rossen> interested<T> Sure(); <bradk> Interested, but can't make it <ChrisL> Both Y <TabAtkins> Y <smfr> Y <dbaron> N <tantek> cannot make it to the telcon <tantek> N <gregwhitworth> N astearns: I expect some of these issues should be on the F2F agenda. astearns: So we'll also have F2F discussion and we can meet after the F2F. fantasai: dbaron and gregwhitworth would a different week work? dbaron: For me a different week would work...but let me think between now and f2f. fantasai: smfr is out next week. <gregwhitworth> I'm just pretty booked at the moment, I can make tomorrow work if necessary. dbaron: For time tomorrow I'm on plane to Asia and will be there through the F2F. Rossen: Can we keep it tomorrow? Go with the time. A number of people can join. If we have pending decisions for FF and there's no rep we can make those resolutions pending review. But it would be good to get on the phone and make progress. <gregwhitworth> that sounds fine <fantasai> birtles, Can you make it tomorrow? Rossen: dbaron is that okay with you? And whoever else can't make it? dbaron: That's okay. fantasai: I'll take minutes. Rossen: Thanks for organizing fantasai. astearns: This will be the inaugural and we'll continue these to get transforms done. REC steps --------- astearns: That's was the item for transforms. There's a bit on fonts 3 and Rossen was to investigate a font issue in Edge? Rossen: I did look yesterday. The font that was prepared wasn't prepared in a way that works with dwrite. Rossen: I did send a message to those on the original email. Rossen: Summary was if you're asking for zero horizontal progress we'll make 0. ChrisL: Well, the CSS font has it's own duplicate set of metrics. Some browsers will respect that and some won't. Rossen: It depends on if you're calling back on dwrite or not. Rossen: But I believe what's in the email was actionable. ChrisL: Yes. I can patch the font to do that. myles could do it better. Rossen: Okay. smfr: I think myles is out this week. ACTION myles to respond to the dwrite issue and ChrisL's asks for font edits. <trackbot> Created ACTION-838 astearns: Cascade. There's an item to drop scoped styles. Did that edit get made fantasai? fantasai: I think TabAtkins and I did that two weeks ago, yes. astearns: V&U astearns: It has <position> edits. <astearns> https://lists.w3.org/Archives/Public/www-style/2017Mar/0054.html fantasai: They're done. We're waiting on review by somebody. astearns: Is there a person you'd like to action to review? fantasai: I have no idea. Does anyone care? Maybe smfr since he has to integrate into transforms? smfr: I missed that. fantasai: We made edits to <position> for transform-origin. smfr: Sure, I can do that. ACTION smfr look at <position> edits <trackbot> Created ACTION-839 fantasai: Are there plans to update motion draft on CR? <tantek> +1 fantasai update it please astearns: Good question. TabAtkins: Yeah, sure. It wasn't on my immediate to do list, but it should be done. ACTION TabAtkins update motion draft <trackbot> Created ACTION-840 fantasai: We'll need to update backgrounds & borders once the <position> edits are published and that will need a resolution. astearns: Right. There was another item on backgrounds & borders about fixing test. That was on tmichel. tmichel: I haven't made progress. I have to investigate how to change those tests. astearns: That's fair. astearns: Last thing is changes to tests for UI. They were reviewed and Florian was going to update the tests. Florian: I'm waiting for a review from fantasai on an update I did. astearns: So, fantasai, will you have time soon to look? fantasai: Probably not, but I can try. Florian: Should be quick since I think I did everything you asked for. fantasai: I think there was one that was a long thing. Florian: Is gsnedders on? gsnedders: Yes. Florian: I think there's one PR that has been migrated, but one hasn't. What's the status there? gsnedders: There's three left on the old repo that have comments which are hard to move over. So yeah, I should be able to do that soon. Florian: Yeah, one PR is in the new, one will go soon. gsnedders: Yes, there's 3 still on the old platform total. astearns: And fantasai mentions we need a resolution to publish motion. This is just an update, it's not in CR? fantasai: Correct. This is merging in round display and other changes. ChrisL: It's an auto publish? fantasai: The old one was on the old system but yes. astearns: Objections to updating Motion draft? RESOLVED: Update motion draft on TR 2017 Paris f2f dates - can we decide exactly? --------------------------------------------- <astearns> https://github.com/w3c/csswg-drafts/issues/1165 astearns: I thought dates were exact, Aug 1-4 where one is a Houdini. tantek: Which one? astearns: We usually do Houdini first. Aug 1 houdini, 2-4 is CSS. tantek: Can we get a resolution on the record? * fantasai couldn't find it either astearns: I think we were waiting on confirmation from Mozilla they can host. tantek: We can confirm we have the space. Rossen: We don't tend to have formal resolutions on F2F days. fantasai: We do usually. Rossen: I don't recall, but sure. gsnedders: There were two lines in the minutes on the F2F. astearns: Yeah, the discussion was longer than the minutes. <fantasai> It appears there was no minute-taker for that discussion astearns: Obj to resolving to meeting Aug 1-4 in Paris? <fantasai> rossen, resolution on dates = https://lists.w3.org/Archives/Public/www-style/2017Mar/0021.html RESOLVED: Meeting Houdini Aug 1, CSS Aug 2-4 in Paris tantek: astearns can you make the page? astearns: I will set up a page stub for you to fill in details. I'll copy what I can. tantek: dbaron myself and Jet will work on that. Move underimplemented features to Images 4 ------------------------------------------ <astearns> https://github.com/w3c/csswg-drafts/issues/1148 leaverou: I was looking at the last CR. There are many features that have wide impl, but there are some that are none or 1. leaverou: First is image(). Unless someone plans to implement I would suggest deferring. TabAtkins: I agree. leaverou: Another feature without impl is image-resolution. Is anyone planning on impl? TabAtkins: I thought we had an impl of that. I could be wrong. <leaverou> http://dabblet.com/gist/33ac15e3d6372b2d97b17061783eb40f leaverou: Since we don't have tests I had to make a quick one. This is what I used ^ <smfr> webkit does not have image-resolution <dbaron> Gecko does not have image-resolution leaverou: It just tests parsing so if the browser doesn't recognize I assume it's not impl. TabAtkins: Ah, I was thinking image-rendering. Florian: image-resolution has partial implementation in Viviostyle. I'm not sure we fully comply. TabAtkins: That's still compatible with going to level 4. leaverou: Do we agree with deferring? Yeah. leaverou: Image-orientation is only Gecko. leaverou: Any plans to impl? <tantek> there's web author demand for image-orientation <tantek> especially in the IndieWeb community TabAtkins: I could have sworn safari had something. smfr: On iOS we respect it and on mac we don't and this is terrible. We need to pick one. If we had this the author could force, but we don't have an impl yet. TabAtkins: We also have an issue that we want to kill everything except from image and initial because the rest aren't really CSS appropriate. <zcorpan> https://bugs.chromium.org/p/chromium/issues/detail?id=158753 fantasai: The other values were added for printer impl. That's why it's in a spec. ChrisL: If you only have those two values it's a true/false with lengths. TabAtkins: Nothing wrong with a property only having two reasonable values. ChrisL: It does mean if you want 270deg rotate you have to edit the image. TabAtkins: Or you use a transform. Florian: Or a writing mode <zcorpan> writing-mode doesn't affect images? <fantasai> writing-mode doesn't affect images ChrisL: Yeah, okay. astearns: Given there's only on impl and there's question on values it seems it could move. leaverou: I agree. <leaverou> http://dabblet.com/gist/d2c5b3d1beba1dd514f505ab8e3ad219 leaverou: There's gradient interpolation. I did a test ^ leaverou: None of the UAs seem to support. I heard Edge 15 might have, but I don't have one here to test. <MaRakow> yes, edge supports gradient interpolation for some time now fantasai: Back to image-orientation I'd prefer to keep it in. It's referenced from other specs. If it keeps us from PR we can drop at that point. TabAtkins: Mark as at risk <ChrisL> mark it as at-risk, then TabAtkins: And MaRakow says Edge does support [gradient interpolation]. leaverou: We have 1. Florian: It's a good feature, but depends on how fast people will get to it. fantasai: I think we need to clean up what's clearly not going to get impl. We can mark the others as at-risk. leaverou: It's been there over 5 years though. TabAtkins: Let's punt the things with 0, things with 1 get an at-risk. <tantek> +1 tabatkins. drop 0 impls feats. at risk 1 impl feats. leaverou: I think we can get a resolution. The rest have 2 depending on if you consider blink and webkit different. TabAtkins: In this case I think those are pre-fork.. astearns: So they're at risk. <fantasai> either way, using just those two as implementations is questionable, because they share architecture and code astearns: Move everything with no impl to next level and mark everything with 1 impl as at risk. <glazou> +1 to what astearns said leaverou: Yes, and can we then resolve on an updated CR? Florian: You need a DoC. ChrisL: Could we only resolve once the supporting documents are done? fantasai: Yes, I agree with that. astearns: Objections to the resolution on edits? astearns: proposal: Move everything with no impl to next level and mark everything with 1 impl as at risk. tantek: Can we ask for that to be in a changes section? TabAtkins: Of course. fantasai: Changes and DoC haven't been compiled. RESOLVED: Move everything with no impl to next level and mark everything with 1 impl as at risk. astearns: We'll make the edits and then update the draft once it's all in place. astearns: Anything more on images 3? leaverou: Nope. Grammar of grid-row-start and friends is ugly and harms value space for line names ------------------------------------------------------------------- <astearns> https://github.com/w3c/csswg-drafts/issues/1137 glazou: I made that comment because I found the issue when I started impl the properties. I understand this is too late, but I wanted to highlight it. We narrowed the value space for no reason. glazou: It's something we should not do again and it's unfortunate that I couldn't see it before. TabAtkins: I agree in general that having custom idents live in an overlapping value space with specified idents is often clumsy. I thought it was reasonable at the time, it's probably too bad we cut out values. I agree in the future we should minimize situations where this happens. glazou: It's not minimizing. I really think we should get rid of this kind of issue. If we keep this kind of thing we're only thinking about engines. Editors will have to provide UI mechanism to disable for these values. It's bad design. We're responsible for the whole system. We should not do it again. TabAtkins: Yeah, sure. <fremy> +1 TabAtkins: I won't say we'll never do it again because we may have to deal with it for compat, but I want to avoid it. astearns: And we're talking about combining keywords and custom idents. glazou: Yeah. astearns: I'll put it on our list of css mistakes page. astearns: Just to be clear, you're okay closing no change glazou? glazou: Yeah. astearns: Since this is on CR we need a resolution. Objections? RESOLVED: No change on issue 1137 Definition of `column-span` should say what happens without an ancestor multicol --------------------------------------------------------------- <astearns> https://github.com/w3c/csswg-drafts/issues/1074 Florian: If I remember we reached where if column-span should do anything not in the multi-col. Both sides were hanging in terms of author friendliness. Florian: One set of people said if you're not in multi-col you don't expect it to do anything so it shouldn't. The other side is that the content of the multi-col is usually styled the same as other block layout and if you do remove the multi-col you're likely to forget to remove it and you'd want the rest of the style to stay. Florian: So are we looking for predictable and consistent model or one that does things the way you want if you forget to remove something. Rossen: To confirm you're calling predictable and consistent where when you have remaining values in a layout system that no longer matches, that's what you mean? Florian: If you're not in a multi-col, multi-col properties don't apply. Rossen: I'm in favor of that one. <bdc> FWIW as an author, the typical thing I'd do is to use multicol for wide viewports and just kill it in a media query for mobile/etc. <bdc> would be very unexpected/annoying to revert multiple props TabAtkins: We took as a general principle that a one col or one row grid should act the same as a flexbox, basically. Similarly a single column multi-col is basically identical to a flow-root container so having the differences minimize would be good. So having this property that has the sole effect of making a child a block container is fine with me. Florian: You disagree with Rossen? TabAtkins: Yes. Let's make col-span continue being a block container. Florian: Interesting thing is you're both arguing against what your browsers are doing. Florian: Edge does what TabAtkins wants and Chrome does what Rossen wants. astearns: Chrome is the odd one out? <Rossen> https://jsfiddle.net/Ld86cuwk/ <Florian> https://github.com/w3c/csswg-drafts/issues/1074#issuecomment-289172502 Florian: Safari and Edge create a bfc. Rossen: Is that the right link? Florian: Yeah. fantasai: I'd like to point out the irc comment from bdc [reads] Rossen: What we're currently doing seems like a bug, even though it matches what you're saying. That's an easy bug to fix. astearns: But if you fix it and it breaks the author expectations... Rossen: Can we rename this property to please make me a bfc? Because this will go into css tricks as the main way to make a bfc. <dbaron> We did add display:flow-root! Florian: You can use flow-root for that. astearns: This behavior has worked this way in several browsers for years and that hasn't happened. Florian: And I think the MQ argument strengthens the argument. Switching multi-col on or off is a very reasonable use case. Having a single thing to switch is much more author friendly. Florian: I was neutral but am starting to join TabAtkins and fantasai. <bradk> So to make a flow root, { column-count:1; } on parent and { column-span: all } on child. astearns: Another thing to note is we have a browser with a different behavior that is willing the change. Florian: I think currently the spec isn't very explicit. But it does correspond to making a bfc if you read it carefully. Rossen: I don't formally object, but I'm not going to agree. astearns: Would anyone else object to having column-span elements create a bfc even if not in a multi-col container? RESOLVED: Have column-span elements create a bfc even if not in a multi-col container. Florian: The spec needs to be clear that this is intentional, so I'll add a note. New feature - scroll-boundary-behavior (an extension of -ms-scroll-chaining) -------------------------------------------------------- <astearns> https://github.com/w3c/csswg-drafts/issues/769 fantasai: This was requested by someone... TabAtkins: Majid, he's one of our implementors. fantasai: And someone from Facebook. TabAtkins: Microsoft has a feature already where you can dictate what happens when you're scrolling inside a scroller and you hit the end. Do you capture or do you move the rest of the scroll action upwards in the page. <tantek> what about the scroll-bounce? TabAtkins: They have an explicit control. It's ms prefix. We'd like to standardize this idea, we like it. THere's a lot of discussion of what to capture and how to do so. That's cool. Basic ask is does the WG feel this is worth doing a spec? Should we do this in WICG? fantasai: I think it's already in WICG. Question is do we add it to a draft and which? fantasai: There's a lot of question so we're in a place where we want to be able to have individual issues on each question. TabAtkins: Yeah. Do we believe this is mature enough to bring into the group or leave in WICG and make sure it has a repo there. Rossen: I didn't read the whole WICG topic, but I remember there being breakouts on this. I would be in favor of moving it in, especially if there's interest from others. Rossen: Maybe Overflow? Something along those lines. fantasai: Makes sense to me. TabAtkins: Or we can support it getting a WICG repo. Then when we do get agreement there we can pull into overflow. fantasai: Open discussion on syntax has not stopped us from putting things into a draft before. If there wasn't feature clarity I would say more discussion, but this seems as well defined as a lot of stuff in drafts already. astearns: I'm interested to experiment with WICG process. I'd be interested to have an official repo and go through that process. astearns: So why don't we try the official WICG incubation process and move it in once it's in a good state? Florian: One problem is define a good state TabAtkins: There's success criteria in WICG. They've worked for webapps. If there are issues we will be in there and we can provide feedback on how to improve for csswg. It seems valuable to experiment and this seems like a good thing to do it with. Rossen: There has been quite a bit of discussion on this and on our side the people most involved on initial implementation have had discussion with Majid. Most technical discussion is closed. If we're only talking syntax I think we're ready to move. Rossen: Although, as I said, if others want to continue in WICG and you believe you have strong technical additions or objections to what is done so far I'm fine continuing there. ChrisL: I'm hearing 3 or so viewpoints. I heard astearns say he wants to experiment with WICG. I hear Rossen say it's mature enough and let's move now. I hear TabAtkins say that there is a process to move and we haven't made that. Is that correct? TabAtkins: I'm in astearns' camp. astearns: I think that is true, though, that there is a process that says you set up a repo and work there until it's ready for standards. If this is mature enough it can skip repo, maybe that's feedback for WICG when working with us. Florian: The point where a spec is ready to graduate if we work together cannot be dictated from one side. They can say we're only comfortable working until as late as something and we can say we won't work until a point. But we need to agree on a certain point in between. TabAtkins: We don't have to send signals, we're the ones that lead the WICG CSS forums. Florian: It's overlapping with us, but it's not us. TabAtkins: I don't want to get into a WICG discussion with one minute left. astearns: I'd like to continue experimenting with WICG, get a repo, and see if that was a useless step so we can figure out what to do in the future given this experiment. astearns: Are there objections to creating a WICG repo for this near feature and working there for now. <ChrisL> no objection <leaverou> no objection <dbaron> needs to leave for another meeting, and is fine with experimenting with this in WICG for a bit Florian: I'm not super enthusiastic about the whole thing, but if we're going to experiment this is a good thing to do it on. RESOLVED: Create a WICG repo for this new feature and work there for now. Rossen: We're less that 2 weeks from F2F and there's nothing on the agenda. Please add topics. astearns: Yes, please do. Thanks everyone for calling in. <fantasai> astearns, so do we close the issue in our repo and ask ppl to re-open when they're ready to move over or what? <astearns> fantasai: I think we leave the issue open, and add a link to the WICG repo <astearns> once everything in that issue is addressed, or added to WICG issues, we can close it <fantasai> doesn't like having untagged issues in the repo, they tend to get lost <fantasai> can we assign it to a module at least? <astearns> it's tagged with overflow and cssom-view now <fantasai> ok
Received on Wednesday, 5 April 2017 23:14:17 UTC