- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 7 Jun 2017 21:44:56 -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. ========================================= How does 'inherit' keyword behave in a child of ::first-line? ------------------------------------------------------------- - The proposed spec text from the issue is: "Inheriting properties of inline fragments that are contained in a ::first-line only inherit from the ::first-line if those properties (1) do apply to ::first-line, (2) do inherit by default, and (3) are not custom properties." - Point 1 of the proposal caused some concern as it may not be necessary, but during the call some examples were provided showing that it was important. - RESOLVED: Take the behavior described in the issue and work with it to make sure it works for compat. typed-om editor --------------- - Naina will be added as an editor. "Serializing <an+b>" doesn't match what Firefox or Safari do ------------------------------------------------------------ - RESOLVED: Drop the 1 or -1 on an+b serialization <percentage> shouldn't be able to resolve to <number> in calc() --------------------------------------------------------------- - RESOLVED: Accept proposal (don't allow <percentage> to resolve to <number> in calc()) FPWD as a dependency for [css-contain] -------------------------------------- - RESOLVED: Move the text for integration between contain and overflow to level 4 of overflow Non-positive value should be invalid for 'resolution' feature ------------------------------------------------------------- - RESOLVED: Spec should say resolution used to disallow negative numbers. It makes sense to allow negative with the boolean logic with some examples and that's for all MQ with a numeric value. Propagation of the :focus pseudo -------------------------------- - This topic will be added to the F2F agenda to get further discussion. Any testing before that should be added to both the CSSWG & WHATWG issues. ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jun/0008.html Present: Tab Atkins David Baron Amelia Bellamy-Royds Brian Birtles Tantek Çelik Dave Cramer Alex Critchfield Elika Etemad Dael Jackson Dean Jackson Peter Linss Myles Maxfield Liam Quin Naina Raisinghani François Remy Melanie Richards Florian Rivoal Alan Stearns Shane Stevens Greg Whitworth Regrets: Rachel Andrew Rossen Atanassov Bert Bos Angelo Cano Benjamin De Cock Simon Fraser Daniel Glazman Tony Graham Vlad Levantovsky Chris Lilley Anton Prowse Scribe: dael astearns: Thanks everyone for calling at the different time. astearns: As always, first thing is are there extra items? I got the one from TabAtkins about percentage and calc. astearns: Next topic is usually spec rec, but I've had no time to summarize. Thanks to everyone that updated on group list. I'll get something more up to date next week. How does 'inherit' keyword behave in a child of ::first-line? ------------------------------------------------------------- github topic: https://github.com/w3c/csswg-drafts/issues/1097 fremy: I had been presenting that. We were waiting 2 weeks ago on dbaron's reply. fremy: dbaron basically agreed with the proposal and I think we should probably just resolve on the behavior from the issue. fremy: We were debating on best way to enter this into the spec, it's editorial so it's up to the editor. fremy: We were trying to describe how inherit works when child of first pseudo element. <dbaron> Proposed resolution was: "Inheriting properties of inline fragments that are contained in a ::first-line only inherit from the ::first-line if those properties (1) do apply to ::first-line, (2) do inherit by default, and (3) are not custom properties." fremy: To recap: The element is a child of the ::first-line pseudo and will generate the property and it will inherit by default. fremy: dbaron felt the approach was right if not the best wording. fremy: We can work through the right wording, I guess. astearns: Anyone with more comments or wants more explanation? <tantek> this sounds reasonable, I'm wondering what the interop situ is on this? fantasai: I'm a little confused why we need to check if they apply to ::first-line. dbaron: That's what my comment was about. It wasn't about wording but if that should be more general. Normally in CSS applies to don't effect computed values. But applies to pseudo elements does effect computed has been my understanding. But we don't say that anywhere. dbaron: My comment was that if that is the case we should a) say it and b) remove condition 1 since it becomes redundant. * fantasai thanks dbaron for the clear summary fantasai: It could effect computed value on pseudo element. But having properties inherit differently is really hairy. There are a lot of properties where applies to is more general dbaron: It's possible that we need to separate applies to and if properties apply to pseudo elements. That's more clear cut. TabAtkins: I agree. The rest of applies to are editorial pointers, but that's reasonably mechanically relevant fantasai: There's a lot of properties where we say it applies to everything, but that's because it inherits. We could tighten that, but the majority of applies to aren't tight. Florian: And sometimes it's the opposite case where we state the things it doesn't apply to. It's a fuzzy mess. fantasai: It's not precise enough. If it's going to determine how things inherit we need to be rigorous. I don't think we should make the spec depend on if a properties applies to. It should be if it's inherit or not. dbaron: I think we need it for if it applies to pseudo elements, but the specs aren't great on specifying. In Gecko we list every property that applies to a pseudo in the code. If it's doesn't apply the declarations aren't applied. That's ::first-letter and ::first-line. fantasai: What's that case where we need the distinction? dbaron: display fantasai: It's not inheritable. dbaron: I need to look at examples then. fremy: I don't have a list of, but user-select would be one. Florian: That's not inherited. dbaron: I think the main reason inheritance needed restriction was variables. fremy: Yes, yes. fremy: Variables, in that case, they could apply to any property. But that's condition #3 where we say we don't generate custom properties for ::first-line. There may be others. fantasai: If we're going to have this condition I want an example that is inheritable, not a custom prop, and doesn't apply to ::first-line. If there's no such property we don't need this conditional fremy: Is there a list of properties that inherit? fantasai: Indexes. TabAtkins: That's not tracked across specs. It's on the to do list. astearns: Sounds like we're converging on resolving to take the proposal except possible condition 1 which needs a real world example of why it's needed. fantasai: Yes. I'm happy to resolve on the rest but I don't want this conditional if it's not needed. dbaron: Writing mode and direction are the two properties I've found so far that are problematic. Florian: If you try and change the writing mode on the ::first-line...yeah. Don't do that. astearns: The treatment that is currently in the issue, whither or not we have that first conditional, are writing mode still problematic? dbaron: They're inherited, not custom, but no one interprets them as applying to ::first-line fantasai: That's a good/interesting one. ::first-letter could be in a different writing mode. <dbaron> 'white-space' may also be a problem (with ::first-line and 'pre') astearns: To answer tantek from earlier, it sounds like we don't have interop. Correct? fremy: It's correct, I think. The issue was mostly Chrome allowed a few more properties to inherit and the custom properties weren't blacklisted in FF. astearns: Can we resolve to accept the proposal, possibly excluding condition 1 if there is no compelling example. Florian: I think we found an example. Which leads to applies to not being specific enough to rely. fremy: We can agree on the behavior of this issue. I think we can discuss the other issue separately. We can agree on the behavior and discuss further what applies to means. Florian: I think having or not having part 1 is a difference of behavior. Florian: I'm okay resolving this and filing issues against specs to tighten applies to. fantasai: That won't happen in any reasonable time frame. The exclusion list should be explicit for now and then look for a better way to distribute. Most don't take into consideration ::first-line and ::first-letter and may say "all applies" fremy: Currently in pseudo spec there's a list of properties. <fantasai> https://drafts.csswg.org/css-pseudo/#first-line-styling dbaron: CSS 1 & 2 had a list of what properties apply to ::first-line and ::first-letter, but I think it was a should. dbaron: That may or may not be different to the applies to line. We discussed about moving it, but we never did. Florian: Should we point to pseudo 4? <Florian> pseudo-4 isn't good enough for the list. It has the list of "at least these must apply", it does not have "these do not". <liam> [css 2.1 lists for first-letter, font properties, color property, background properties, 'word-spacing', 'letter-spacing', 'text-decoration', 'text-transform', and 'line-height', and then says, UAs may apply other properties as well. ] <liam> [ https://www.w3.org/TR/CSS2/selector.html#first-line-pseudo just before 5.12.2 first-letter ] <Florian> https://drafts.csswg.org/css-pseudo/#first-line-styling <Florian> https://drafts.csswg.org/css-pseudo/#first-letter-styling fantasai: What we need here is a list of properties that aren't inherited from the pseudo elements and we can come up with a more general approaches, but a good black list is a starting point. astearns: Sounds like we're resolving on the proposal with a blacklist, but further define how to do it later. This is the behavior we want. <dbaron> It could have a list of "these apply", a list of "these do not apply" and a note that if it's on neither list you should contact the spec editor. <fantasai> dbaron: That's a decent approach :) tantek: I think I like the rough approach. I asked about interop because every time we've tried to do this in the past there has been compat issues. If someone wants to try this with simple examples it could illuminate the likelihood of this approach. I'd propose someone writes tests to test their assumptions and show how bad the situation is. tantek: It's a hard problem astearns: Proposed resolution is try and specify this behavior and see how that proposed behavior and interop goes. RESOLVED: Take the behavior described in the issue and work with it to make sure it works for compat. typed-om editor --------------- astearns: I'd like to add naina as an editor of typed OM TabAtkins: I'm fine with that. "Serializing <an+b>" doesn't match what Firefox or Safari do ------------------------------------------------------------ github topic: https://github.com/w3c/csswg-drafts/issues/1504 TabAtkins: If the a value is 1 or -1 you write the digit in serialization. This violates general shortest form rule. FF and Edge agree on not printing the 1 digit. I'd like to change the spec to match that. <fantasai> sgtm astearns: Makes sense to me. Objections? RESOLVED: Drop the 1 or -1 on an+b serialization <percentage> shouldn't be able to resolve to <number> in calc() --------------------------------------------------------------- github topic: https://github.com/w3c/csswg-drafts/issues/1463 TabAtkins: When you use percentage in calc it's allowed...you can use it anywhere the usage would resolve a percentage against another type. TabAtkins: Applies equally, but per spec it applies to numbers. This would apply in opacity, for example. Problem is in typed OM when I'm trying to deal with types of expression how we described in last F2F numbers have an empty type map. TabAtkins: If we don't allow percentage against numbers they're easy to handle. It's always some type and I can later fill in the type. TabAtkins: If it could resolve against a number I lose that ability. A percentage could be a type or none at all and that makes the algorithm harder to describe. Florian: Clarification: opacity you have percentage or number and it's the same or you have line-height where percentage and number aren't combinable. Are there cases where you have percentage and number where they're combinable but not same? fantasai: They're combinable in the sense where number and percentage in line-height ultimately resolve to length. fantasai: We could, in theory, allow that. TabAtkins: There's a reason not to. I'd like to never allow that. There's a reason to disallow that. TabAtkins: It makes the type of number incoherent. It's typeless or has a type. It makes the algorithm to type check math extremely more complicated. <AmeliaBR> For line-height, percentage and number don't inherit the same: percentage gets converted to length before inheritance, number is converted at used-value time. <fantasai> AmeliaBR: Yeah, and in width, <length> and <percentage> have that same difference. <AmeliaBR> PS, for length + number, there are all the SVG properties to deal with, that treat number as equivalent to px <AmeliaBR> (e.g., stroke-width, stroke-dasharray) TabAtkins: Big problem in when you multiply unitless. If a number can represent a length if you multiple 1 x 2px is it a length or a length squared? TabAtkins: There's only two cases where this matters, line-height and tab size. We could just add a unit. For now we're okay. Calc doesn't allow you to treat a number as a length. dbaron: I'm not happy about treating number and percentage the same. Number on line-height needs to be distinct from percentage. TabAtkins: They are. This is where percentage resolves to a number. Opacity is the obvious example. I propose we say a percentage never resolves to a number type. fantasai: Does the percentage value of opacity compute to a number? TabAtkins: I believe it computes to a number. That's what it has to do. Opacity uses 0 to 1 as a percentage. The two are equivalent. <Florian> I'm with Tab here. The alternative seems to mean a lot of complexity for no good reason. fantasai: I think it would be surprising if someone tried to to combine and it didn't work. If you're adding a variable to an inlined you'd have to be very careful. TabAtkins: I agree. That's why we originally wrote percentage can resolve against number. But from a practical standpoint dealing with types it doesn't work. You get an incoherent thing where numbers can sometimes be used as extra values. In the worst case you can never tell what type an expression is if a number shows up. TabAtkins: If I wasn't writing spec text I wouldn't have suggested this. fremy: Edge does not support percentage in opacity. This is the first time I heard you can. I would be fine saying percentage doesn't mix with numbers. <AmeliaBR> percentage for opacity was a relatively recent addition to the spec TabAtkins: No one, even browsers that allow percentages, don't allow them to mix in calc. Everyone is consistent in not allowing this, I want to fix the spec. astearns: By not allowing we're matching impl. TabAtkins: Yeah. dbaron: Some of that is because we don't have a spec for calc() unit algebra. TabAtkins: It's a lack of support not a positive we're doing this on purpose thing. But removing it won't cause problems. astearns: Objections to codifying this limitation? RESOLVED: Accept proposal FPWD as a dependency for [css-contain] -------------------------------------- github topic: https://github.com/w3c/csswg-drafts/issues/1374 Florian: We resolved to take contain to CR, but overflow was not fpwd so it was rejected. Most of the references from contain to overflow go to 3 now that we cleaned it. 4 references are about fragmentation. Given that this is least stable, should we change which spec has that text so we don't depend on overflow 4? fantasai: sgtm astearns: It will get contain through the pipeline more quickly. astearns: Objections to moving the text for integration between contain and overflow to level 4? RESOLVED: Move the text for integration between contain and overflow to level 4 astearns: If there's a process issue we can re-resolve, but let's use the old resolution Non-positive value should be invalid for 'resolution' feature ------------------------------------------------------------- github topic: https://github.com/w3c/csswg-drafts/issues/1454 Florian: We found this issue about resolution, but it's more than that. There are a number of media features that take a range and for which negative value makes no sense. Resolution of -300 dpi makes no sense. Florian: Old MQ it didn't really matter if we declared this as invalid don't parse or value evaluates to false. The difference it makes is in the OM. This has changed a bit in MQ4 because we have unknown values. Florian: If we say it parses and is false there width -300 is false NOT width -300 is true. Florian: I think it would be more useful to parse it and say it evaluates to false. If it doesn't parse we don't know if it is -300 or not. Florian: We have, from the OM PoV we have interop on the opposite. But the boolean logic isn't impl anywhere yet so it's not observable. Florian: I don't feel like breaking the interop is a major issue, but maybe I'm wrong. What do you all think? dino: I think we should do as you said and break the interop. Florian: If they're relying on media resolution -300dpi this will be fine. What this would break is very uncommon. dbaron: Does the effect of the change...is it different on if the browser impl the unknown thing? Florian: Yes. It's part of impl the logic for nested and/or/not. If you don't have that then it's undefined what this does, I guess. dbaron: Maybe the spec should have a note saying that the previous version forbade negative values and that shouldn't be removed until you impl this stuff. Florian: That's fair. astearns: Proposal: have the spec say you should parse negative values if you implement this boolean stuff. Objections? Florian: This is all media features with a range. width, height, aspect ratio, color I suppose. astearns: Spec should say resolution used to disallow negative numbers. It makes sense to allow negative with the boolean logic with some examples and that's for all MQ with a numeric value. dbaron: There should be a note that it's a change from the previous version and we're looking for compat feedback. Florian: Fair. RESOLVED: Spec should say resolution used to disallow negative numbers. It makes sense to allow negative with the boolean logic with some examples and that's for all MQ with a numeric value. <AmeliaBR> [Tangent] A reminder that this and many aspects of CSS parsing would have been easier define if there were CSS Values data types specifically for non-negative or strictly-positive values (https://github.com/w3c/csswg-drafts/issues/355). Propagation of the :focus pseudo -------------------------------- github topic: https://github.com/w3c/csswg-drafts/issues/1240 Florian: When we introduced :focus-within we tried to clarify focus and active. What we attempted was to say active and focus propagate to/from the same time. The spec prose for that isn't very good. I think I authored that, sorry. It also contradicts HTML. Florian: I think we should clarify we do what HTML does. Florian: Secondary, I think we resolved on a preferred behavior which was also in disagreement with HTML. We should either try and convince HTML to change their behavior if we care about this. For now, we should point to their propagation method. astearns: Is their method well tested? Florian: I think it is. I don't think it was fully interop before. IE or Edge didn't used to have it, but there's more interop now. gregwhitworth: I haven't looked recently, but I thought most still propagates in Edge. Florian: I just tried recently and it didn't obviously propagate in the general case. I still think it would be better if it went both ways. There is an open issue on that in WHATWG. I don't say we drop this, but having the contradiction isn't useful. astearns: So there's an open issue on WHATWG. gregwhitworth: Could have sworn I tried to bring that back to CSSWG. It seemed to most of the people in this group felt this want the right behavior. I didn't want people not in the room superseding that. I didn't want to lose that. I can test more throughly. Florian: In spirit I agree, but :focus is fairly complex. It's a bit of a rabbit hole and I don't think we want to take over all of that. If we want some part we need to figure out where to split. Florian: Looks like we won't resolve, but please look at github. <fantasai> testcase: data:text/html;charset=utf-8;base64,PCFET0NUWVBFIGh0bWw+DQogIDxzdHlsZT4NCiAgICA6Zm9jdXMgeyBiYWNrZ3JvdW5kOiBvcmFuZ2U7fQ0KICA8L3N0eWxlPg0KICA8bGFiZWwgZm9yPXlvPkZvbzwvbGFiZWw+DQogIDxpbnB1dCBpZD15bz4= astearns: Can we resolve on removing the contradiction? Or is it better to keep it open so the issue gets more :focus? Florian: I thought it was better, but gregwhitworth argues that we could lose all control. gregwhitworth: I hadn't given it too much thought. Can we talk about this in Paris? Or next WG call with everyone on? Other impl were interested before. <fantasai> +1 to f2f astearns: Seems like bringing this to the F2F is a fair idea. It's not that far. Let's do that. I'll put the F2F tag on it. astearns: Please do add information to both WHATWG issue and ours as you find it. astearns: We're at the hour. I think that's it for the day. Thanks for making it the different time. We'll try this time again the first week in July.
Received on Thursday, 8 June 2017 01:46:02 UTC