- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Nov 2016 16:55:37 -0500
- 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. ========================================= CSS2.2 plan to CR and test review request ----------------------------------------- - gsnedders and gregwhitworth offered to review the test suite. Anyone with interest in a section of CSS 2.2 was also asked to review at least that section. - In addition, anyone with interest was asked to review the edits made to CSS 2.2. - fantasai will start a thread on the member e-mail list to discuss how best to keep the CSS 2.X specs updated quickly as items become interoperability implemented. - For CSS 2.2 individuals should put issues in where they think there should be a link to another spec. In CSS 2.3 there will be work done to integrate all relevant links. - The group agreed to a goal of getting CSS 2.2 to CR within a week after the Seattle F2F. - Review requests will be sent to the appropriate groups noting that are errata only to help them prioritize. Remaining Grid Issues --------------------- - Rossen & TabAtkins agreed to review the conversation on github around the new definition for 'normal' https://github.com/w3c/csswg-drafts/issues/523 Need clarification on `auto` margins for abspos flex children ------------------------------------------------------------- - RESOLVED: For all layout modes when you're figuring out static position of an abspos child treat auto margins as 0 regardless of normal positioning rules. Computed value of currentColor ------------------------------ - Everyone agreed that the proposed edits should occur, but Florian will bring his proposed text to the group as there are many specs that will need changes. Should caret-color apply to any element? ---------------------------------------- - RESOLVED: Change the applies to line to all elements - RESOLVED: Add an informative note as to what is a caret and what is not. ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2016Nov/0115.html Present: Rachel Andrew Rossen Atanassov Tab Atkins David Baron Bert Bos Bo Campbell Tantek Çelik Dave Cramer Elika Etemad Dael Jackson Brian Kardell Peter Linss Myles Maxfield Rachel Nabors Simon Pieters Anton Prowse François Remy Florian Rivoal Geoffrey Sneddon Alan Stearns Greg Whitworth Steve Zilles Regrets: Daniel Glazman Scribe: dael Note on the call: Due to problems with the conference bridge, the meeting began late. All conversation around the conference bridge has been removed, but specific topic discussion in IRC before a bridge was established is left as-is below. CSS2.2 plan to CR and test review request ========================================= <astearns> SO - the first topic is CSS 2.2 <fantasai> Wrt CSS2.2... I think dbaron said some of the edits are actually incorrect, so it needs to be verified that things are correct. <astearns> who will do that verification? <Florian> Were the incorrect edits identified? Bert: 2.2. My goal is to get a plan for getting 2.2 to CR and then PR. Bert: It's only FPWD officially but I believe everything is implemented or close to. To get there I made a number of items to discuss. Test Suite ---------- Bert: First is test suite. Bert: I tried to make tests for all things that are different in 2.2 from 2.1 I submitted and saw gsnedders is reviewing. Bert: Are my tests correct? Do we need more tests? Bert: If gsnedders could weigh in on that. <astearns> gsnedders: have you been able to connect? [he has not, but is joining] <dbaron> is there a diff-marked version of the spec relative to 2.1? <fantasai> dbaron: https://www.w3.org/TR/CSS22/changes.html Bert: Or can anyone check the test coverage? I think I have at least one test for everything normative but I may have missed. Rossen: Can we turn this into an action for people that want to review and give them a week or two? <gregwhitworth> I will review it in the next week or so fantasai: Bert can you link the tests from the changes page? fantasai: I think it would help because then this becomes the implementation report. Bert: Yes, I linked to the doc section, but I can link to the changes. That will take a few days. gsnedders: As far as to the tests they're in the 2.1 test suite because Sheppard doesn't know about the fragment IDs in the changes list. astearns: So are you asking if there should be a 2.2 suite? gsnedders: Most of our tooling is built around the test suite and at the moment most of these test wouldn't be put into any test suite because Sheppard doesn't know the fragment IDs plinss: We could have 2.2 but that would only include the 2.2 test. Which may be sufficient. astearns: It might be preferable. plinss: That's trivial to spin up. I can do that today Bert: Do I need to do anything? plinss: If the tests have links to the 2.2 spec we're fine. Bert: Okay. <dbaron> Are the tests visible as files somewhere, or only inside the pull request in https://github.com/w3c/csswg-test/pull/1139 ? <gregwhitworth> yes <gsnedders> dbaron: http://csswg-test.org/submissions/1139/ <gregwhitworth> I would love to look at just the tests for these changes <gsnedders> dbaron: though obviously that's the whole testsuite <gregwhitworth> gsnedders: can you get me the link to the 2.2 tests, I don't run shepherd and there aren't many here to quickly go through - I'd like to have bugs filed on Edge for these <gsnedders> gregwhitworth: there's nothing better than https://github.com/w3c/csswg-test/pull/1139 and looking at the list of files there quickly <gregwhitworth> gsnedders: awesome thanks :) <gsnedders> gregwhitworth: I can probably create a quick list at some point later today, if that helps <gsnedders> gregwhitworth: like, list of links to the new tests <gsnedders> https://github.com/w3c/csswg-drafts/issues/412 definitely needs edits Bert: Were the tests correct? gsnedders you were looking. I think I answered all your comments. Did you look? gsnedders: Not really. I also haven't looked to see if the tests matched the changes to the spec. I was doing a quick high level review. astearns: Are you planning on looking more detailed, gsnedders? gsnedders: I can...some of them I'm not competent to review. astearns: It would be useful if you can and it looks like gregwhitworth has offered to look. gregwhitworth: Yes, yes. I'll help as needed. Rossen: My ask for everyone is given that CSS 2.1 is what everyone on the web depends on it's in our best interest to make sure 2.2 is as interop as quickly as possible. Especially for implementors changing behavior to align better it's my ask to make sure these are testing what they're supposed to test. Rossen: Nothing new in the ask, but more action. I believe this is the largest impact to interop in the short term. astearns: Can anyone else commit to taking a look at these tests and see how well they match? astearns: If there is a particular errata in 2.2 you were involved in I'd like you to at least look at those bits. Process for publication ----------------------- gsnedders: How many outstanding edits are there on 2.2? Bert: fantasai pinged me one thing. That's the only one I know of. fantasai: It was a baseline alignment issue. I don't think it's interoperability implemented and I just put an issue against the errata. fantasai: I'm happy this is happening and I think we need a process that lets us make edits on 2.2. If we try and address every thing, though, we'll never get there. Going forward we need a copy of css 2 that's only the changes implemented across browsers and a second copy that's changes decided and not implemented. <tantek> agreed with fantasai: need CSS2.x that reflects interop reality, and another CSS2.x that reflects that *plus* CSSWG consensus decisions on fixes/issues fantasai: We'll need a multi-stage release process. There's going to be a lot of issues not addressed in this draft. We do need to have a way of getting this draft to rec on a continuous basis. This is a good start to have the errata that are passed. <gsnedders> we have git cherry-pick and similar if we want to move edits, but that doesn't work with stacked edits, obviously astearns: I think this is important. I don't want to spend too much time talking process today. Could we do something like have these edits not implemented in as at risk and once they're implemented we take the at risk off. And once we move forward we move them out to the next level. <tantek> or go into the next +0.1 Florian: When they're changes to a sentence how do you have a sentence at risk? fantasai: For the old process we used to be able to go from WD to PR if you had fulfilled the requirements. We may want a WD copy and a PR copy and only include the changes implemented in the PR and have a trunk branch with all the decided changes and cherry pick the ones implement. fantasai: We'll skip the CR cycle <gsnedders> https://www.w3.org/community/w3process/wiki/Rectracktimeline implies you need a CR <tantek> or we use that CR cycle to set expectations of what is going into the PR, and have a convention of no at-risk items there <tantek> CR is only 4 weeks anyway <tantek> and that's good time to verify tests <tantek> and get broad review astearns: Let's start a thread on the member list to decide how to manage 2 going forward. fantasai can you start that thread? fantasai: Sure. <tantek> fantasai, in general I agree with your approach, see above for how a minimal CR could be useful astearns: Any more topic on 2.2 test suite? Wide Review ----------- Bert: Two things more. 1 is to go to CR you have to prove wide review. There hasn't been a lot of comments, but that's not so strange. So we need some way to prove this has had enough review. If you have ideas for the arguments let me know and I'll put those in the transition request. astearns: Are there other groups we should notify and ask for review? tantek: Web platform. Bert: Yes. a11y normally. tantek: Yes, but with the note that these are errata only. Same with i18n. astearns: We can send out that standard e-mail for review. tantek: We didn't drop any feature either, right? Bert: I don't think so. astearns: Early in the conversation fantasai raised a concern about incorrect edits. Have we had internal review? fantasai: I don't remember what it is, I remember that last time we talked dbaron mentioned there were incorrect edits. Rossen: So in addition to reviewing tests, please review the changes. dbaron: I'll try and look. I may not have time in the next few weeks. Linking to other specs ---------------------- Bert: I was hoping that you could be more concise about the links of other specs requested. It's harder to make links from chapter definitions. I saw SimonSapin made rough links. How far do we go in making links to level 3 in the document? Florian: I think when we have a level 3 entirely replacing a section it should be linked. When it's a little bit it's more tricky. astearns: I wonder if this link replacement could go into 2.3 since 2.2 is close to done. I'm not sure I want to add this to slow the CR and PR down. Bert: That's a possibility. Make a copy, call it 2.3 and start editing there. tantek: Depends on whether we can get CSS 2.2 into CR by next Tuesday (week?) right? fantasai: I think we should go with the edits here and not add anything. Mainly let's start and get a chunk through. That way this isn't a big issue and we can push though a set a year. gsnedders: We have interop on some of the changes in syntax so we may want to include them. We don't have interop on the 2.1 and current 2.2 behavior anymore. fantasai: That's fair. we should fix them. astearns: Can they be issues? gsnedders: They are. gsnedders: Should we add a 2.2 label on github for things that should go in there? astearns: Makes sense. astearns: tantek mentioned postponing the links to 2.3 is dependent on getting 2.2 to CR on Tuesday. I'm not sure that's the case. If we don't make the deadline and have to publish the CR in Jan I think it's useful to get out as quickly as we can and postpone the link replacement. tantek: I think that's good in general. I think we should file issues for each link replacement and we can decide case by case. I was thinking of the box model width and height calc are strongly patched in the CSS3 UI box-sizing section which makes lots of changes and anyone impl should be reading that. tantek: I'm just raising that there may be things worth putting in if we aren't going to make the 2016 deadline. astearns: So we'll add the 2.2 label on github. I'm pretty sure we're not going to make the end of the year CR given that people are still reviewing edits and test suite. Bert: That's no problem. I didn't ask for CR by the end of the year, just something soon. astearns: Anything else on 2.2? Bert: That's the end of my list. Timing ------ tantek: Are we trying to CR before Seattle? astearns: I think that's achievable tantek: Or is that where we make a final decision on in or out? fantasai: I think the later is more achievable. astearns: Let's see what we can do before Seattle and anything left over we decide in person. tantek: So we're giving ourselves a deadline of publish CR of 2.2 no later then a week after Seattle F2F? astearns: Yep. Florian: How does the asking other people to review work with that? astearns: We should ask for wide review now; there's enough bulk in the errata that people will take time. If we wait for everything is done it add another month to the process. I'd rather get 2.2 out and start on 2.3. tantek: Reasonable. Should we resolve to publish a WD that include the current status of all the edits and send that for review? Bert: I don't think I have anything different then current WD. astearns: So current WD has all the edits. Bert: Right. astearns: So that's what we'd send out. tantek: So no changes in the ED. Bert: I'll check, but I don't think so. no. <SteveZ> sending for Wide Review now is what we should do because the existence of Wide Review is an entry condition for CR Remaining Grid Issues ===================== astearns: I'm not sure what's left. fantasai do you have things? fantasai: There's been discussion. There was a set of edits for new normal behavior; we resolved that normal preserved the aspect ratio. It used to be a synonym for stretch. There's been additional discussion on that. I've made the edits, I'm looking for review astearns: Do you have the issue link? <fantasai> https://github.com/w3c/csswg-drafts/issues/523 fantasai: There's discussion on what if you have normal in one direction and stretch in the other. Also just the edits are in and need review. I'm not caught up on the github conversation. astearns: Can someone involved in grid look at this? TabAtkins: Yes. Rossen: I'll do it on our end. <fantasai> thanks :) astearns: What else for grid? fantasai: I think that's the main thing. Let me flip through and look for anything else. You can move to the next topic. astearns: I think we just did the next topic. I'm going to take the "Grid Layout Issues" topic off the agenda; it had a lot of things. If we need those discussed let's raise them separately. Need clarification on `auto` margins for abspos flex children ============================================================= <astearns> https://github.com/w3c/csswg-drafts/issues/665 TabAtkins: Mats brought this up a while ago. TabAtkins: When you have an abspos child you lay it out like the container. Presumably that means they work like they do for flexbox. Chrome and Edge don't do that; they do it as 0. If an abspos child of a block container has auto margins it also gets treated as 0. This is just to determine static position. TabAtkins: Because everyone seems to agree, the proposal is in position draft or in flexbox we define that when finding static position the margins are 0. Rossen: I think I made that change and commented. TabAtkins: There wasn't anything on the issue. Rossen: I may be thinking about a different issue. [looks] I was. Rossen: I can take the action to make the edits if the WG agrees. fremy: works for me <tantek> sounds like it makes children that are abspos, their auto-margins more predictable / consistent, so that seems reasonable TabAtkins: prop res: For all layout modes when you're figuring out static pos of an abspos child treat auto margins as 0 regardless of normal positioning rules fantasai: This also needs to go in CSS 2.1 Rossen: Sounds like we need this in errata and positioning spec. TabAtkins: Yes. astearns: obj? RESOLVED: For all layout modes when you're figuring out static position of an abspos child treat auto margins as 0 regardless of normal positioning rules. ACTION bert make the change to 2.1 for the abspos resolution <trackbot> Created ACTION-804 Computed value of currentColor ============================== <astearns> https://github.com/w3c/csswg-drafts/issues/741 Florian: We've defined in css color 4 that currentColor is supposed to compute to currentColor, but css 3 UI doesn't invoke that text. It instead says that caret color resolves to inherit. Are we okay to fix it so that currentCcolor computes. <tantek> can we just update to reference css-color-4? TabAtkins: I agree the wording should be changed, but I don't like the actual wording. I would prefer we define an algorithm for doing the color like we do with links made absolute phrasing and you invoke that. tantek: I'd agree with TabAtkins. Florian: We have text in Color 4 that says how currentCcolor computes in general. Florian: Should I come back to the call once I have better phrasing? fantasai: Whatever you choose we need it to be same for a whole bunch of other stuff. So please bring it to the group. Florian: Are all the other specs inherited? fantasai: Text decoration does. Currently says as spec in computed value. Florian: Okay. I'll try and come up with a wording. fantasai: All the specs need to be updated, so please base it off of level 3 of color. Florian: I'll try. Useful wording is in level 4. TabAtkins: We can pull it back if we need to. fantasai: we'd resolved to update L3...not sure if it's done yet. Florian: I'll come back with a suggestion. astearns: My ask is for Florian and TabAtkins to work on the wording in the issue and have you both agree. Florian: yeah. TabAtkins: Sure. Should caret-color apply to any element? ======================================== <astearns> https://github.com/w3c/csswg-drafts/issues/725 Florian: Currently the edit talks about caret. There's a bunch of browsers with a caret navigation mode. The question raised is if caret color applies to that. Since caret nav isn't defined we can be explicit and say it's undefined. TabAtkins: Just doing that doesn't work because the property says it applied to editable elements. TabAtkins: I'd prefer adding it to all elements and have a note that anything caret-like, for example nav caret, should be effected. Informative note. Florian: I don't think it can be normative because caret nav isn't defined. tantek: Tab are you asking for the normative change to change the applies to? TabAtkins: Yeah. Applies to doesn't have any normative meaning. <fantasai> +1 to fixing applies-to tantek: I'm just worried if we are in CR does this mean more tests. TabAtkins: Nope. You can't test an applies to line. It's impossible. tantek: I in general agree, but we did have a case in CSS 1 where that happened. TabAtkins: It's a behavioral change. The applies to doesn't case that. tantek: In CSS 1 it did happen. <fantasai> +1 to tantek <fantasai> It does make a difference. In some cases it's not detectable, and in others it is. Florian: There is no difference between applies to and applies and does nothing. If you have a caret for another reason we make it so it can apply. tantek: I'm concerned we'll mislead authors. If it applies to all elements and I see the text selection cursor I'd expect it to change colors. TabAtkins: But then that applies to current editable elements. It doesn't and we don't expect confusion. tantek: I'd add a normative note that it's only to the actual caret, not the text cursor. Florian: People are frequently confused between caret and cursor so that's not a bad idea. astearns: I headed three things. 1) normatively change applies to line 2) add an informative note able nav carets and caret-like things 3) add a note that says really only carets, not things like cursor. Florian: For the 2nd it is this may apply or should? TabAtkins: It's normative so it's pointing out there are other things like carets. tantek: Which is why I pointed out the text cursor. astearns: I think 2 and 3 should be one note. TabAtkins: That sounds reasonable. Florian: sgtm astearns: Objections to changing the applies to line? RESOLVED: Change the applies to line to all elements astearns: Objections to the proposed note? myles: Can we clarify should or may? TabAtkins: It's informative so doesn't matter. RESOLVED: Add an informative note as to what is a caret and what is not. astearns: Thanks everyone. fantasai: We're publishing an update to box alignment soon so if you're interested please take a look.
Received on Wednesday, 30 November 2016 21:56:43 UTC