- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 23 Jul 2015 07:51:14 -0400
- To: www-style@w3.org
CSS Cascade 4 Publication -------------------------- - RESOLVED: Publish new WD for CSS Cascade Level 4 Selectors 4 Update ------------------ - The group discussed a the e-mail from fantasai regarding what portions of Selectors 4 should be deferred or discussed as Selectors 4 is prepared to move to CR - The entire group received an action to read and respond to the entire e-mail - Most of the conversation centered around :has() - There is some disagreement about how :has() should work and there are no implementations to date and therefore it was suggested that :has() shouldn't be in CR. - It was agreed to put it at-risk for now with a note indicating what the disagreement is. - There was a feeling that :has() has been discussed so many times and that developers want has so much that just deferring it to the next level would reflect poorly on the group. - It was expressed that if :has() is dropped or deferred the group needed to publicly post an explanation in order to help the community that is so excited to understand the process of the decision. - In the meantime, several people will post and talk about :has()'s at-risk status in order to encourage the community to push for implementation if they really care about having it. - The draft still needs an updated WD publication, but fantasai expressed that she needed more time to do a through review of the spec. - There is a hope that the publication will be ready for voting next week. CSS 2015 prose and prefixing policy ----------------------------------- - There was a desire to have more time to read the small details of the proposed text before any resolutions. - Some browser vendors expressed concern about the language aimed at limiting prefixing was imprecise and perhaps too harsh, though no one was disagreeing about trying to limit prefixing. - RESOLVED: add Florian as an editor to the snapshot - RESOLVED: add TabAtkins as an editor to the snapshot CSS Break --------- - fantasai's proposal to drop cloned margins at any break seemed to be right to everyone, but the topic will wait a week for people to review the exact wording and look at examples. user-select: none ----------------- - RESOLVED: user-select: none is a useful feature and we won't drop it. ===== Full Minutes Below ====== Present: Tab Atkins David Baron Bert Bos Adenilson Cavalcanti Tantek Çelik Dave Cramer Alex Critchfield Simon Fraser Daniel Glazman Tony Graham Koji Ishii Dael Jackson Brian Kardell Brad Kemper Philippe Le Hégaret Michael Miller Shinyu Murakami Edward O'Connor Anton Prowse Florian Rivoal Simon Sapin Alan Stearns Regrets: Rossen Atanassov Sanja Bonic Chris Lilley Peter Linss Hyojin Song Lea Verou Scribe: dael glazou: Let's start glazou: We have a few additions to the agenda. There was a message from fantasai, I think a few hours ago, clarifying the two additions. glazou: We're adding CSS cascade and selectors 4 to the agenda. glazou: She'd also like to remove one item that's answered and one that's F2F. Anything else? Florian: Just a clarification, the two items that are if I sent a mail, I haven't. CSS Cascade 4 Publication -------------------------- <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JulSep/0035.html fantasai: We had one outstanding issue on level 4 which was to rename default, we picked revert. I'm proposing a new WD and treat it as a LC. There's no more issues and only 2 additions from level 3. revert and support syntax for @import. fantasai: If there's no comments between publication and the F2F we can go to CR. <glazou> +1 for a new WD <plh> +1 for new WD <bkardell> +1 <Florian> +1 glazou: I'm in favor. comments? <astearns> +1 plh: Question from me. Oh, wait. Mine is for selectors. * plh :) glazou: Other comments? glazou: Objections? RESOLVED: Publish new WD for CSS Cascade Level 4 Selectors 4 Update ------------------ <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0296.html glazou: plh sent a message about a new WD for selectors 4 because the one of TR is large and the time is too long. glazou: fantasai posted a proposal for features to keep and to defer/drop glazou: There was a proposal about deferring :has() to level 5 that had a lot of conversation on the mailing list. * bkardell wonders if glazou will recount the thrust of his comments on thread? <glazou> bkardell: I could, yes plh: I said that because the DOM spec was linked to Selectors 4. I was also wondering about the stability of the path. plh: For the purpose of defining query-selector and query-selector all how to deal with scoped elements we don't use a :scope selector, but we do talk about scope selection so I was wondering if those parts are stable or nowhere near stable and will move to 5 for example. fantasai: Is there anything specific you needed to keep that wasn't on my list? plh: We didn't talk about the parsing of selectors. Is that kept? fantasai: Yes. All the other stuff will be kept. We'll keep everything that wasn't on the defer list. plh: And the scoped selector? fantasai: Absolutely. glazou: For the people that missed it on the mailing list, I would like to repeat what I said about :has() glazou: The proposal from fantasai is to defer to level 5. The proposal for this feature is >15 years old. We've put it in documents several times and we've been advertising it for years and we've been so vocal that web authors are demanding it. Deferring now would give a bad picture of the working group. <gregwhitworth> I haven't been here for 15 years, can someone summarize why its sat for 15 years? glazou: It's a question of the image of this WG. In the past we had a bad image because we couldn't deliver. I'm afraid deferring :has() will give us that image. We have to deliver or say we can't and drop it. TabAtkins: It's not any different status than yesterday. We're dropping out the parts that aren't stable so we can push to CR. We're not doing anything different with :has() than we were doing yesterday. glazou: To answer gregwhitworth's question, its been on and off for 15 years because [missed] It was at risk and then people proposed again and its just been a cycle. gregwhitworth: So it's not implementation complexity? glazou: No, the initial refusal was implementation complexity. That's why I'm saying in the ML that the current argument to refuse it is the same as 15 years ago and if we can't implement we have to drop it. It's not fair to let web authors expect this if we can't do it. <dbaron> This is what happens when the reaction to "not sure if we can implement it" is "well, let's put it in the spec and see what happens". <glazou> dbaron: absolutely <tantek> I thought it was "let's put it in the spec for broader review / feedback" bkardell: Two things. First is going into a little bit more of the history of this. To do it in CSS as originally proposed- it's really difficult. We have ideas, but they will take a long time. Conceptually it's plain as day you want that feature. But it is really hard and that's what kept it out. In the meantime we've come up with qsa and variants that let you do this in JS. bkardell: Query has had :has() and people have been clamoring for it more. Because it's conceptually obvious that people want this, this has been a long running thing. Any time it's mentioned people get excited. Doing it in the static profile isn't very complex. It's a couple of days work by an impl. bkardell: That was hard fight to get that far. My second point: I feel like it sends bad messages to authors. Dropping, I mean, deferring it seems to send subtle signals. If it's in level 5 people think it's not as important. <tantek> just mark it at risk and let's move on TabAtkins: It can't be in the CR because it's not stable. It's either dropped or in level 5. <tantek> how is it not well defined?!? <tantek> what are the open issues on :has() ? fantasai: We're going to CR. That doesn't mean every feature has to be completely implemented. If everyone says they will implement and don't expect issues, we can keep it in the draft. fantasai: What concerns me more about :has(), there have been discussions about having different syntax from query or something like that. As long as that's not resolved the feature isn't stable. If the discussion about what we're going to do isn't final we have a consistency problem. fantasai: I would like for us to work through the issues before :has() is in CR. If we want to leave it for now and drop it if we can't work through the issues before everything else is done that's fine. fantasai: :has() hasn't existed in a CSS draft before it was in JQuery glazou: I proposed on the ML to keep working on :has() until the Aug F2F and make a decision at that time. fantasai: That's possible, but it depends on the rate of discussion on the ML. fantasai: The other features in the draft that we want to keep, if we remove everything else that's unstable, publish with :has() and then work on all the open issues, as it happens we can discuss has and we can decide to drop at CR transition. We can leave a note saying that if the issues aren't resolved we'll drop at CR transition. fantasai: There is still some refining for the rest of the draft anyways. <bkardell> +1 to that plan glazou: I prefer that plan, I think. <tantek> I am for keeping more features in CR and labeling them at-risk, especially if *anyone* has expressed implementation interest. Florian: Agreeing with something fantasai said earlier, as to if something without implementation can go to CR depends on the issues. In the list of things to defer to level 5 I think there are things to keep. :focus-within has a reasonable chance of implementation soon and it's straight forward enough to keep at-risk. I think there are more things like :read-only. I don't think we'll change and we might implement soon. <tantek> Thus I support Florian's proposal to keep :focus-within, and general criteria. Florian: That's the criteria I'd apply here. plh: +1 to what Florian said. We can keep it at-risk and push to CR sooner because we can still drop. <tantek> putting things into CR is a way to iron out issues too - because some issues are only ironed out when implementations try to build it! fantasai: A lot of the things on this list were because they had open issues or we're not sure because we didn't have enough feedback to know if the issues had a chance to be ironed out. fantasai: If people have thoughts on any individual thing I'd like them to reply and talk about it. <bkardell> the static profile is actually a compromise between the two (authors and vendors) ACTION everyone to review this document and make comments. glazou: Both bkardell and I made a comment about the image of the WG. If we do decide to drop :has() I'd like to work with plh to craft a blog as to why we decided to drop it. plh: Sure, I agree with you. I wasn't a part of the debate before, but one of the comments W3C hears a lot is that we're not listening to devs enough. Devs want :has() and we're not getting implementations of this. I don't know why there's such discrepancy. tantek: So that's why we should not drop :has() from CR. Since there is high demand the right answer is don't politically drop it, leave it in CR at-risk and put up a proactive blog post saying that it's at-risk because there's 0 implementations and if you want this feature you need to go rally your favorite browser and push the community to push the implementors and that the WG is a conduit to the communication. If the community cares they can rally for it. tantek: Then the browser vendors prioritize and it's hard or they don't prioritize and explain why. <bkardell> +1 to tantek's comment <bkardell> well said <Florian> +1 to tantek, IF we are sure that it is specified the way we want it <glazou> +1 too fantasai: I'd 100% agree with you if the reason not to include it in CR is implementation issues. The reason I'd drop if we were going to CR tomorrow, it's that there are issues as to if the impl even want to go in that direction. It's not like we have a feature and they're proposing to add a different feature, it's also about what about doing it this way instead and that's an open issue about the design of the feature. tantek: If it is documented as an open issue, that should be documented in a blog post today. :has() might not make it because there's open issues and if you care help us resolve it. glazou: I'm hearing a majority that doesn't want to drop :has(). Second, we need some time to work on this and push on implementors or devs. It's another signal saying lets give us a few weeks and publish a CR with better feedback. We have a F2F in Aug and that's the time to do this. tantek: If we agree to decide in Aug, anyone blogging now should point out that timeline to the community. Say 'hey we're going to make a call at this meeting and you need to give feedback before that'. glazou: I'll use my superpower of chairmanship to publish that on my blog and draw that attention. <gregwhitworth> just made a MS Edge uservoice: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8977591--has plh: I believe you have all the rights to publish on the W3C blog too if that helps. <bkardell> https://twitter.com/briankardell/status/623892832953200641 plh: I'm happy with the plan, but in the meantime can we update the WD in /tr? I'm not asking for CR- just updating the issues draft and publish it in CR. <tantek> +1 updated WD <tantek> is Selectors still using the old pub system? fantasai: The next publication will be a WD and we'd rather do it soon, but I need to go through the draft. Before we publish I want to make sure everything is correct. I think we might want to defer non-controversial things so there's less to review. We'll keep :has() in the next WD, but I'd like us to go through some of the other items. plh: If you can do it in the week that would be nice. The draft in tr is just too old. The sooner we can update the better. fantasai: A week isn't reasonable because it takes a week to publish and I have to review. Maybe 2 weeks. plh: I was asking you to give a +1 to publish next week. fantasai: If I go through the entire document and there's nothing that needs fixing we can resolve to publish next week. I likely will have a bunch of issues and have to push it off. tantek: What's the delay with another WD? fantasai: I don't know of anyone else that was reviewed the changes in this WD over the last years. I'd like someone to review it to make sure that nothing has been dropped. glazou: Publishing the WD is a call for the review. fantasai: I'm an editor and either we can remove me as an editor or we can wait until I review. dbaron: A bunch of what's in here hasn't been discussed in the group. It's stuff where there was a ML post and it got into the draft. glazou: Yes. It's sometimes more of an idea sink. That's why the list from fantasai has almost a dozen features to drop. fantasai: The list in the draft are ones that have been discussed in the WG. tantek: The right criteria for TR is if it's better than the last. I find it hard to believe that publishing this wouldn't be better than having a draft that's 2 years old. However I sympathize with fantasai's concerns about not having reviewed as a co-editor. Can you consider what's the minimum level of review you need to publish? I understand wanting to be thorough, but I think we need to update. fantasai: If I review I'm going to be thorough. The changes that need review are detailed. tantek: Okay, fair. <dbaron> I'd want section 3.2 either removed or rewritten if we're going to publish on TR. <TabAtkins> dbaron: The thread on 3.2 died off waiting for a response from you, iirc <dbaron> TabAtkins, there's one message from you in the thread, to which I replied CSS 2015 prose and prefixing policy ----------------------------------- <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0261.html glazou: So fantasai and Florian requested review. Florian: It was fantasai and TabAtkins, but I was a part of writing an older draft. I have reviewed the latest and it matches my memory, but I didn't review enough to speak on details so I'd like another week. High level, though, it's good to me. Bert: I like it overall. It's a bit vague in some places, but I'm not sure that can be helped. It mentioned browser instead of UA and I'm wondering if that could be a problem for the features that are only done by UA. Florian: There's a difference between things exposed to the web and things that aren't. So if we define browser as something exposed to the web...we need to clarify, but we need to clarify the difference between exposed to web and not. glazou: A batch processor prints something without a dynamic environment. Florian: It should be a browser. glazou: It's going to be tricky. Florian: That's why I want a week. hober: The blog post write-up I think makes assumptions about how browsers are shipped that aren't necessarily true. hober: I think we shouldn't as a WG impose specific release strategy on browsers. In section B there's a line that says "experimental features ship only in non-release builds" which assumes there's a thing as a non-release build and I don't think we should demand that. TabAtkins: It's an implicit case. hober: Where do you ship experimental features? fantasai: You don't. You're not allowed. Florian: You could tweek the wording to allow a flag. Taking one step back I remember what you said and when trying to word that I remember that the general way to do it didn't match with Apple and it was generally a 'you should do this' rather than a 'you must do this'. hober: I think your suggestion of a run-time flag improves the degrees of freedom that we're giving browsers. What I was trying to say is it's a mistake for the WG to impose a release strategy so allowing a diversity is better. TabAtkins: We want a policy that works well for the web in the future. If it's something like that make a suggestion in the thread and we'll word-smith it. smfr: Historically iOS apple hasn't had experimental releases so we can't ship if we follow these rules. So we wouldn't have shipped transitions, animations, etc. It feels like it's impeding progress. I understand wanting less prefixing, but I don't want to prevent browsers from innovating. <tantek> smfr is making good points <tantek> OTOH we're now stuck with having to support -webkit- prefixes for some properties on mobile because they've taken root in some geos <TabAtkins> Note: transitions/animations/etc, while great, are PRECISELY THE SITUATION WE'RE TRYING TO AVOID because of how crazy annoying and painful they've been to iron out inconsistencies that were baked in due to early shipping. <tantek> TabAtkins it's a tradeoff - no easy answer :( Florian: We considered this specific case. It was good that Safari pushed for innovation, but the standardization wasn't good. That's why in general the prefixing policy says you shouldn't release what hasn't been discussed. It also has 'if you end up doing it, here's how you prefix and here's how others should react'. We realize you will and it's innovative, but will also screw up with standardization. smfr: I think that's why we're okay since it's a should. * fantasai reminds everyone that this text is attempting to reflect http://www.w3.org/blog/CSS/2012/08/30/resolutions-53/ smfr: Another high level question, is any of the text actually normative? Florian: Given that it's shoulds and musts it sounds normative. fantasai: This is the in the boiler plate for every module. In that instance it's most definitely normative. fantasai: We discussed how the snapshots used to be WD because we wanted it to be non-normative. The WG resolved to make it a note. You can conform to a note, but it's not a required. In regards to a note its status isn't REC track. So you can conform, but I don't know what the W3C thinks of that. fantasai: We do need this stuff to be normative. You're non-conforming if you, for example, you parse things you don't support. smfr: That sounds fine. I think that this will appear in every spec means we must agree. gregwhitworth: TabAtkins have you spoken with Chris Wilson and the other people that were working on it so that authors can rely on it working? TabAtkins: We've discussed it, but not beyond 'maybe this is a cool idea'. gregwhitworth: It might be good to loop those people in. Come up with even above the WG so authors can have the flags and can turn them on so real users are supplying real feedback. TabAtkins: It might be good to bring to TAG so they can discuss. fantasai: This is intended to reflect a bunch of resolutions three years ago and a bunch of discussion we had around this. hober: I haven't clicked through to the minutes, but I was surprised to see that we thought this was resolved. My recollection was we didn't resolve anything. It was three years ago so I can be mis-remembering. <fantasai> hober: yeah, you're right, we didn't put final approval on it <fantasai> hober: due to lack of proposed text <tantek> yeah, agreed Florian: We did on some high level concepts but not all the details. Based on the agreed high level ideas I was tasked to write it, I did it with fantasai, passed it on to SimonSapin and we've juggled the hot potato. hober: Okay, that makes sense. It seems risky to resolve without details. I guess if we resolved on a bunch of things without details that could effect how people felt. Florian: There's tension between discussing first and shipping first-discussing later. The rules are drafted in favor of browsers who can discuss before shipping, but they don't ignore that it happens. hober: I like what you just said. I wish this said that. If you can do it, do blah. If you can't, don't. Florian: The intent is the same. It's details in the wording and that's important, so let's take a week or two and decide. fantasai: While we're here, Florian would you like to be an editor. Florian: Sure. glazou: Objections? RESOLVED: add Florian as an editor to the snapshot fantasai: Can we add TabAtkins? glazou: And objections? RESOLVED: add TabAtkins as an editor to the snapshot glazou: We have 8 minutes. Florian: And we've done topic 1. <fantasai> hey, we pre-emptively dropped a bunch of topics already! CSS Break --------- <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0285.html fantasai: I'll summarize. First issue is a concern about break-before 'any' and 'always'. Second is margins. When you have a forced break and you preserve the margins after the break. If you're doing unforced we collapse the margin into the page break so your content is flush with the top. fantasai: Because of how cloning works you might have a clone margin at a forced break and you might end up with it at the top of the page. I wanted to add a rule that drops the cloned margins even if you're at a forced break, because the element requesting the margin isn't the one forcing a break. fantasai: Just wanted to make sure people are okay with that or if anyone has a different opinion on how things work. Florian: Conceptually I understand, but I can't decide without examples to look at. You're probably right, but it's too abstract for me. fantasai: So do cloned margins ever get kept at page breaks at the top of the page or do we always drop them? SteveZ: I think you're moving in the correct direction. I just had trouble understanding the wording you put it as saying that. My concern is a bit like Florian's. I'd like to make sure you're still preserving the behavior on first pages, but not when it's not quite first page. It's not clear to me that it's only the cloning case. fantasai: It's just the clone case. SteveZ: I'm happy with that, but people need to look at the wording. bradk: Could this be solved with collapsing the page margins? fantasai: Sort of. That's sort of what happens. bradk: There are really big margins if you want it off the top of the page. SteveZ: These are fragments, not elements. fantasai: Please continue to think about it and if you're still not sure next week we can talk more. glazou: So let's defer to next week. 2 minutes on the call. glazou: I don't think we have a 2 minute item. user-select: none ----------------- <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jun/0132.html Florian: This is user-select: none and a question of should we have it. I think we should, but a number of people say it can be abused horribly as copy-protection. Given its been raised a couple of times it would be good for the WG to decide. It can be abused, it has valid cases, there are warnings not to misuse it and permission to browsers to work around the abuse. glazou: I'd like a week of review. I want to make absolutely sure it won't harm my software. <tantek> I think the abuse is more likely than the valid use-cases, thus I'm leaning towards drop <tantek> especially since there's already sites working even harder to block users <tantek> the evidence is there that sites would abuse <tantek> let's not make abuse easier Florian: If you disagree with how it behaves we can keep working on it. TabAtkins: We consider it a useful feature. <tantek> if you consider it a useful feature, then perhaps we need specific documentation of such use-cases <Florian> tantek: I have that in the spec already Florian: So if we agree it's useful and we may need to tweek it, but won't drop, I want a WG resolution that I can point to next time someones says it should be dropped. glazou: I consider it a useful feature. SteveZ: abstain glazou: Anyone else? smfr: I think in webkit we have valid use cases. tantek: I have mixed feelings. I sympathize with useful features, but the evidence I have from sites that try to hone the experience more make me think that if we lower the barrier to abusive sites it makes it more likely sites will be abusive. I'm not sure the usefulness outweighs the abuse. TabAtkins: Its been in webkit and blink for years and there isn't much abuse. tantek: Okay. That's a good data point. <Florian> Mozilla has had it as well for years. glazou: tantek, can you live with it's a useful feature and we don't drop it. tantek: Yeah. glazou: Any objections? <tantek> 0 RESOLVED: user-select: none is a useful feature and we won't drop it. glazou: Thank you for today, talk to you next week.
Received on Thursday, 23 July 2015 11:52:12 UTC