- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 Nov 2014 15:33:25 -0500
- To: www-style@w3.org
New WD for CSS Transforms -------------------------- - Everyone should review Transforms in order to be able to vote on publishing a new WD next week. Fixed position creating a new stacking context ---------------------------------------------- - Microsoft is going to test out the changes. - If it works well, it will be brought back to the group and likely written into the spec. Extend :matches() to pseudo-elements ------------------------------------- - RESOLVED: extend :matches() to pseudo-elements Specificity of :matches() inside :not() --------------------------------------- - RESOLVED: The specificity of a :matches() inside a :not() is the specificity of the most specific :has-focus ---------- - RESOLVED: reuse the hook from :active on :focus - RESOLVED: define a new :focus-within that matches on the same things as :focus, plus parents, including if there are Shadow DOMs Applying pseudo classes to the label based on labeled content ------------------------------------------------------------- - RESOLVED: both :hover and :active should propagate from the labeled control to the label, in addition to the other direction. CSS3-UI issues -------------- - For text-overflow, the conversation about handling items where, due to other properties, the text can't overflow ended up being too complex for the time on the telecon and will go back to the mailing list. - RESOLVED: Drop the text that says: "The resize property applies to elements whose computed overflow value is something other than visible. If overflow is different in a particular axis (i.e. overflow-x vs. overflow-y), then this property applies to the dimension(s) which do not have the value visible." - For outline offset, everyone agreed that there needed to be constraints on how far in the negative direction values can go, but there were several different options as to how the should be written. Options included: - Setting 0 as the minimum. - Set a floor as soon as any two lines of the shape touch each other. - Changing the outline of the shape itself and making it shrink. - Florian will try and write up a clear and relatively simple proposal for the mailing list. ===== FULL MINUTES BELOW ====== Present: Rossen Atanassov Tab Atkins David Baron Bert Bos Angelo Cano Adenilson Cavalcanti Tantek Çelik Dave Cramer Alex Critchfield Elika Etemad Daniel Glazman Koji Ishii Dael Jackson Brad Kemper Peter Linss Matt Rakow Florian Rivoal Andrey Rybka Simon Sapin Dirk Schulze Alan Stearns Greg Whitworth Steve Zilles Regrets: Simon Fraser Mike Miller Simon Pieters Keshav Puttaswamy Scribe: dael glazou: Let's get started. glazou: I saw a few additions from Florian. glazou: Let me get them on my screen. Since we have tantek and Florian we can do them. Are there other extra beyond what Florian sent? New WD for CSS Transforms -------------------------- TabAtkins: I'm all for it. Florian: Sure. <dbaron> +1 <tantek> +1 <andreyr> +1 krit: Are the objections since we discussed transform styles at the last F2F. We still have issues in the spec. It shouldn't be a huge issue, but people may want to wait. I'd like a new WD to reflect the changes we have. MaRakow: I'm still concerned about the implications of some changes, but I haven't gotten a chance to look at it fantasai: Do you want to review and publish next week? MaRakow: I'd prefer that. glazou: So any comments besides MaRakow's? Action: everyone review for next week Fixed position creating a new stacking context ---------------------------------------------- <glazou> http://lists.w3.org/Archives/Public/www-style/2014Nov/0384.html gregwhitworth: You can see the link in the agenda. 2 years ago Rossen and I talked and we were going to make the change and see if we got egregious issues. We're going to go ahead and make the switch so our enterprise customers will say if there's problems. It would be good to get a resolution. Florian: You want a resolution first? Rossen: We'll flight the solution...It would be good to discuss and see what the area is where we want to be. We don't want to go back and forth between stacking context and not. It's hard to gage what blink and webkit intend to do. TabAtkins: I haven't been able to talk to the implementor, but I suspect we want to have it. I think maybe Jacob Rossi... one of our implementors said it makes it easier. I have to check the thread. glazou: smfr sent a message just recently saying webkit has no plan to change in the foreseeable future. <dbaron> I'd be hesitant to agree firmly to change the spec before you've done the experiment, but I'm fine with you doing the experiment and seeing how it goes, with the idea that we'll change the spec if it goes well. gregwhitworth: I think us flighting will help the discussion. Webkit and blink might not get bugs but we may. We'll flight it and we can come back, I want to get the discussion going. It would be good to look back once we get it tested and get a full solution. gregwhitworth: Does gecko have opinions? dbaron: I just wrote in IRC. I'm hesitant to agree to change the spec pre-experiment, but I think you should do the experiment and we'll change if it works. We'll want to know if it's a compatible improvement to do it. gregwhitworth: Sounds good. glazou: Anything else on this? Is it done? tantek: gregwhitworth, you're talking about changing the spec so the first example is a blue sq? gregwhitworth: Yep. It would create a stacking context essentially. glazou: Can we move on? group: Yes. glazou: I suggest we do item 3 before moving on to CSS3 UI Extend :matches() to pseudo-elements ------------------------------------- glazou: This created a long discussion because someone from webkit already implemented. Before we discuss the mobile, I'd like to understand why we would do it. TabAtkins: The use case is like that of :matches, but without the :matches pseudo it's hard to do. So like without this spec'ed in style sheets I can use :matches, but I have to repeat it for the before and after. fantasai: I think it's effectively a syntactic sugar. You can write the selectors longhand to be equivalent in such a way that it should work exactly the same. There's not a reason not to make it accept a pseudo-element, but we have to be careful to make sure the syntactic constraints are there for the shorthand as well as longhand. fantasai: TabAtkins, you were having trouble spec'ing it. It shouldn't be hard, we can do that together. glazou: Any other opinions? Everyone okay with extending? TabAtkins: Or having the functionality in some form. dbaron: I'd want to catch up and see the proposal, but it sounds reasonable. glazou: Okay then. <SimonSapin> +1 with what fantasai said, keep the same constraints as when written the long form RESOLVED: extend :matches() to pseudo-elements glazou: We have two other things on selectors. <tantek> let's keep going with selectors Florian: 2 of the things I have are selectors related Specificity of :matches() inside :not() --------------------------------------- <glazou> http://lists.w3.org/Archives/Public/www-style/2014Oct/0530.html glazou: So Benjamin asked about this on the list and he has a weird explanation. The two definitions collide and it's hard to understand what to do. TabAtkins: The definition of :matches() talks about which selector matches. If you nest inside a :not() he's arguing that none of them match so you can't get any specificity. And wrapping two nots does something really weird with specificity. TabAtkins: So he says when this happens, pretend it's the most specific one. dbaron: This sounds right to me. <tantek> this sounds like a good spec clarification fantasai: Also me. It's making :matches() behave like the longhand which is how it should be. <SimonSapin> +1 for most specific TabAtkins: Using :matches() like the e-mail doesn't add anything. For continuity, even if you nest inside the large selector inside a :not() we should act similarly. RESOLVED: The specificity of a :matches() inside a :not() is the specificity of the most specific glazou: Can one of the editors reply on the list? TabAtkins: Yes. glazou: There's the last last on the agenda, that's Florian's. We can go as you wish for the rest of the time. <dbaron> where's Florian's long list of stuff? :has-focus ---------- <Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0271.html Florian: The :hover and :active pseudo classes match on more than themselves, they also attach to other elements and pierce shadow DOM. The :focus pseudo doesn't do this and we probably can't change that for backwards compat reasons. Florian: It would be useful to do, though, so I suggested a new :has-focus pseudo class which would propagate through ancestors. <fantasai> I think we also don't want to change that, since you want to know exactly what's in focus Florian: There's fairly obvious use cases. If you have a form and want to highlight it you can't do it without JS right now. Same thing if you want to go through a shadow-DOM. Since we can't change :focus, I suggest introducing this. fantasai: I think we don't want to change :focus. Florian: We can't, but we want something that does the same with the extension. fantasai: I think there's reasons why you'd want to go up the ancestors and reasons why you wouldn't. I think it's a good idea to add this because it handles a lot of use cases. Florian: Also some people suggested we didn't need it because it was handled by :has, but it doesn't pierce shadow barriers unless you specifically make it do so. TabAtkins: Agreed. fantasai: I think :has-focus, I'm not sure about the label propagation, I'd prefer that via :focus, but if this is an ancestor for a focus element it matches. Florian: Opening the possibility for the host language to match is appropriate, but if it should do the same is a slightly different conversation. Opening the possibility is appropriate and we can leave :focus as is since it's got a long history of backwards compat. tantek: I have a concern about confusion from web developers. You learn about :has and :focus but :has-focus doesn't do what you think it would from the pieces. Having it named like that would be confusing. Florian: I'm happy to bikeshed. It's been called :focus-within and other options. I'm not attached to the name. fantasai: I think I agree with tantek. It should function like :has(:focus) if it has :has-focus as a name. fantasai: I think that it's okay for it to also pierce shadows, I don't think it's okay for the host language to customize :has except through customizing :focus Florian: I'm a bit confused. Are you saying it should be unfocused directly? fantasai: If the host language wants to change, it changes through :focus and can't change :has-focus except that it is defined in terms of :focus. It's a general principal I'd want, but the name makes it more important. tantek: You want to minimize the number of interface points between specs. If you use how the host language uses :focus, that's the hook for the host language. Florian: So if the host language can modify :focus, that's great. If not I'd like to introduce it on the new thing, no matter the name. It currently does on :active, not on :focus. :focus just matches the focus thing. Florian: That's why I'm trying to introduce this on the expanded focus. tantek: I'd rather allow a hook on :focus that's reused instead of saying you can hook into :has-focus. Florian: If we can I'd prefer that too. fantasai: Is this the label thing? I think there's no backwards compatibility issue, just implementation issues. tantek: Can we re-use the hook on :active? Florian: We can try and say it's the same hook as :active if there's no backwards compat issues. If we can do that that's best. Florian: Should we try and resolve on that? So we resolve that we use the hook on :active for :focus and we create a new element that is like :focus but pierces shadows tantek: If you're looking for a name to use, :focus-within works. Florian: Especially if we're using the hook on :focus. tantek: And we can bikeshed on that name later. <Florian> RESOLVED: reuse the hook from :active on :focus <Florian> RESOLVED: define a new :focus-within that matches on the same things as :focus, plus parents, including if there are Shadow DOMs Florian: Alright. <tantek> Sounds reasonable glazou: No objections on those two resolutions? glazou: Adopted! Let's move on. Applying pseudo classes to the label based on labeled content ------------------------------------------------------------- Florian: The other topic is related to this. Currently the hook on :active and the definition of :hover both propagate from the label to the labeled control, but not backward. If the control is active the pseudo won't match on the label. I think it's better to go both ways. Florian: I raised that on whatwg and there were few answers. The answers was that the current direction is 1-1, but the other direction was 1-to-many. gregwhitworth: We ran internal tests and we've never had issues regarding this. Their math works, but in the real world you won't hit this problem. I ran something with 5,000 <div>s inside a label and it was only milliseconds of difference, so I don't think it's a problem. Florian: In general, it makes sense to go in both directions. Now that the hooks are separate we might want to decide separately. glazou: Other thoughts? <tantek> Curious what dbaron thinks about this. <dbaron> I don't particularly care. <tantek> Then I'm willing to go with consensus as well. <tantek> No strong bias. fantasai: I think having it go in both directions make sense. TabAtkins: I agree as well. Florian: So we should go back to the whatwg and say the CSS group agrees it should work both ways. <Florian> RESOLVED: both :hover and :active should propagate from the labeled control to the label, in addition to the other direction. glazou: no objections? [silence] Action: Florian to ping the whatwg on the above resolution <trackbot> Created ACTION-662 Florian: So to CSS3-UI or finish the agenda? glazou: We finished the regular agenda. CSS3-UI issues -------------- Florian: We'll do these one at a time and see how far we get. <Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0425.html Florian: This is the first comment, it was half of a change was done. Did you forget the other half or decide not to do it? tantek: Likely accidental. I was trying to be conservative with the edits, but that was probably unintended. tantek: So this was line box. I'm reading. Florian: So, basically, do we overflow onto the float? tantek: The suggestion is reasonable. I can make the change. I guess I just didn't make the edit. Florian: I have no opinion- just trying to guess why you didn't do it. Browsers are interoperable along the current spec. The question would be to implementors, would you make the change if we spec it? Florian: It seems reasonable, but we're interoperable in another way currently. Florian: If you have text-overflow ellipsis and we're overflowing onto the float, does the text overlap or do we apply the ellipsis? Florian: Currently the spec says you overwrite. Everyone does it according to text. tantek: I think Gecko would change to have the better behavior. There's aspects that are interoperable, but things like handling scrolling aren't. So do we look at this as a forward looking change, or is it a compat issue? Florian: If browsers will change I'm happy. Rossen: With this edge case, and it's very edge, from a usability point of view, let's say you apply the ellipsis, but if your text is colliding, how would you scroll that? I'm assuming in that test case you can't scroll, so why would you hide? tantek: So that you don't overlap and have it look ugly. Rossen: How can you get to that case? Do you have a test case that shows it? I just can't picture how the text would overlap with the float. Unless this is a bug, the float for the text should be one over the other. Florian: I have a test case, hang on. <TabAtkins> https://bug944200.bugzilla.mozilla.org/attachment.cgi?id=8340052 <Florian> https://bug944200.bugzilla.mozilla.org/attachment.cgi?id=8339998 tantek: I think the test case from TabAtkins is the right one. Florian: Yes. We're talking about the third line. Rossen: The one that you just pasted? Florian: The third line in TabAtkins's linked example. tantek: In this case the third line, what happening is the text is overriding...normally text would wrap around the float. It's only overlapping because the white-space no wrap. Rossen: Yes, I see. I missed that part. Florian: So what we're currently seeing is correct by the spec. We're proposing a change tantek: Rather than drop the visible requirement, there's something else causing the overflow. That's why we should consider the case. Or the line box has a whitespace that doesn't allow wrapping, we're basically talking about conditions where the text can't overflow. Florian: I think that's already addressed by the spec. I think so. tantek: I didn't think it was but okay. tantek: This seems deeper than we thought it would be. It sounds like the spec change to make this requires more iterations. Florian: Take it back to the list? tantek: Does that seem reasonable? The whitespace no wrap relationship should be well understood. Florian: That is, but the float bit needs to be looked at. Back to the list. Next one? tantek: Sorry, I thought that would be easy. <Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0445.html Florian: Still on overflowing. This is issue 37. We have it spec'ed that the resize applies to non-visible overflow and if that's the case in only one direction it applies in only one direction. But you can't have that in only one direction because everyone is interoperable that if you have overflow in one direction visibility is set to auto. Rossen: Anything other than that behavior would be a nightmare to implement. Florian: I'm suggesting we remove that bit of text since it's trying to hook into something that doesn't happen. If we have visible in only one direction we have it become auto, so visible set in only one direction doesn't happen. fantasai: It's a case that doesn't happen. tantek: So we need to say something else. Florian: So I proposed a note that says it's not possible, but if later that becomes possible we'll need to define the behavior. tantek: So we apply both directions? Florian: Yes. Currently the spec pretends there's another possibility. tantek: I agree with TabAtkins that we drop it with no note. fantasai: We have a case that's slightly different where there's regions where you paginate in one direction and scroll in the other. That's a case to think about. Florian: For regions the fragment isn't on the overflow property. Even if you're fragmenting you only have one direction. There's no need for something special. For the overflow fragments, the spec isn't stable and we don't know what will happen. Rossen: I agree. Regions, the only extra constraint is how much content you have, not what happens with content layout. I don't think we can get in situations where one direction overflow is visible and the other one it's not. Rossen: So dropping this? Florian: That's my recommendation and add a note if someone is concerned Rossen: I'm up for it. glazou: Everyone agrees? RESOLVED: Drop the text that says: "The resize property applies to elements whose computed overflow value is something other than visible. If overflow is different in a particular axis (i.e. overflow-x vs. overflow-y), then this property applies to the dimension(s) which do not have the value visible." <SimonSapin> Florian, http://www.w3.org/Style/CSS/Tracker/actions/662 lacks some context <Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0449.html Florian: The spec doesn't put any constraints on the outline offset, so you can put it -9000 which isn't interoperable. There's been discussion, but no conclusion. There's no reason to forbid small negatives, it's only a problem when the outline smashes into itself. Florian: The option C in the e-mail isn't great. Another is when it slams into itself, but you preserve 1 pixel, or preserve the entire thickness which is my favorite. tantek: What do implementors do? Florian: They disagree. In Chrome it disappears, in Firefox if you have 1 pixel outline and a large negative offset it has a large black area. So a 10 pixel high box and a -9000 offset, you get a 1000 pixel black thing. It's not interoperable Rossen: The outline offset to me...the reasonable behavior to expect is if you consider the content box and border box you use padding to offset them and that lets you move the border box from the content. We don't allow negative padding, I don't see a reason that outline offset shouldn't be considered the same way. Once you distance outline box from padding box, I don't think why you'd want to constrain inside. Florian: So allow no negative values? Rossen: Yes. Rossen: If you draw parallels between how padding is used, it's an offset for border box, so outline-offset is the same thing. We don't allow negative padding. tantek: It's because the use cases for drawing an outline are different than a border. I appreciate simplifying the model, this was deliberately allowed. fantasai: I think we should say the area constrained by the outline is floored at 0 so you can't have overlap no matter the shape. If it's an hourglass it might turn into a 0 width square. Florian: But if you start non-rectangular and shrink, I would block as soon as two sides hit each other. <BradK> +1 on stopping the offsets once two edges touch each other * fantasai happy for UA to have higher limits * fantasai e.g. letter-spacing has UA-defined limit on negative values dbaron: I'm a little worried that you're getting into defining a complex algorithm for an obscure case. Florian: I'm trying to define and make it not disappear because it's useful for :focus. Rossen: tantek, can you explain the major use case you're trying to achieve? tantek: There's UIs that have a glow where you want to overlap. I believe that's why it was introduced. I share the concern about trying to over specify an algorithm. We might be able to say use the metrics of the border box and you can't go negative beyond what would 0 out the border box? tantek: You can go negative into the border box, but you can't completely eliminate it. Rossen: So you want the inner border box edge? tantek: It has dimensions and overall width. You divide that by 2 and that's a clamp. fantasai: Maybe define as not changing the outline set, but changing the outline of the shape being drawn. Right now you have various border boxes and we can say this shrinks the box you're wrapping around. If you have a non-rectangular shape, the boxes you're wrapping around shrink. Rossen: What do you exactly define as shrink? tantek: I was trying to specify in terms of the border box. <tantek> computed value Florian: To make it more complex, presto does it differently where if you have a way to flow outside the box you can also get it non-rectangular. Something sticks out and you draw outside that non-rectangular. tantek: We have no obvious solution. We need someone to make a simple proposal on the mailing list that isn't too algorithmic but also handles it reasonably. Florian: I can try and do that. So are we looking for perfect interoperability or just keep boxes from disappearing? Rossen: We want interoperability and please consider inline and outline where they overlap. Florian: And we don't have interoperability on outline. fantasai: I want interoperability. We should have to spec so we limit bad things. Rossen: And we want interoperability because without that there's no reason. Florian: Short of defining it, we need to make it so that it works for people trying to do common things. fantasai: Letter-spacing says you can do it but there's UI limits, those just aren't defined. tantek: We need simple limits that don't make it useless. Rossen: And real examples so that we can see what reasonable means. Florian: I'll give it a shot and get back to the list. Rossen, I'll send you an e-mail to help me understand IE behavior. Florian: I have more, but that's next week. glazou: Thank you.
Received on Wednesday, 26 November 2014 20:33:53 UTC