16:58:21 RRSAgent has joined #css 16:58:21 logging to https://www.w3.org/2018/11/21-css-irc 16:58:23 RRSAgent, make logs public 16:58:23 Zakim has joined #css 16:58:25 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:58:25 Date: 21 November 2018 16:58:34 present+ Florian 16:58:45 present+ 16:58:47 ericwilligers has joined #css 16:58:52 present+ 16:58:56 scribenick: dael 16:59:01 šŸŽ+ 16:59:06 present+ 16:59:12 present+ : 16:59:17 present+ Javier Fernandez 16:59:21 present+ 16:59:22 present+ 16:59:26 present+ 17:00:00 present+ 17:00:17 tmichel has joined #css 17:00:20 Rossen: We'll get going in a couple of minutes to give people running late a bit of time. 9:02PT is the start 17:00:41 present+ 17:01:32 present+ 17:01:33 tantek has joined #css 17:02:18 Rossen: It's 9:02. Let's get going 17:02:25 present+ 17:02:30 Rossen: I wanted to see if there are any additions or changes to the agenda 17:02:38 present+ 17:03:05 florian: We have issue #3024 on the agenda. Used to be agenda+ for F2F, was changed to regular. Not sure if it's ready since the discussion at TPAC. 17:03:31 Rossen: How can we make progress? 17:03:32 florian: Is zcorpan on? 17:03:32 florian: If not we should not discuss 17:03:36 astearns: I believe he's on vacation until next year 17:03:42 zcorpan is away tillā€¦ what astearns said 17:03:55 Rossen: I'll push to end of agenda. Can you take an action item to ping him and see if we can get progress? 17:04:09 florian: I think it's mostly you should harass me to respond to his proposal 17:04:34 Topic: Publish WD for Transforms 17:04:43 Rossen: We have a CR resolution, but we don't have a current WD. 17:04:57 RESOLVED: Publish WD for Transforms 17:05:09 Topic: Should 'break-before' / 'break-after' have an 'always' value? 17:05:18 github: https://github.com/w3c/csswg-drafts/issues/3318 17:05:23 chris_ has joined #css 17:05:26 Present+ 17:05:29 present+ 17:05:36 bradk has joined #css 17:05:51 Topic: Status of the exclusions spec 17:06:00 github: https://github.com/w3c/csswg-drafts/issues/3308 17:06:07 myles has joined #css 17:06:20 Canā€™t hear 17:06:33 rachelandrew: This keeps coming up. Every now and again I get a grid question that's actually exlcusions 17:06:39 rachelandrew: This issue is quite compelling 17:07:07 [audio issues] 17:07:08 present+ 17:07:14 present+ myles 17:07:27 I can tell sheā€™s speaking, but sounds like in a different room 17:08:06 rachelandrew: This is something that keeps coming up. The issues I opened this with, floating thing sin a grid, I see people keep asking for. 17:08:16 rachelandrew: I wanted to package this up and see where we are. 17:08:32 present+ 17:08:37 No idea what Rachel is saying, but Iā€™ll follow the minutes 17:09:08 Rossen: For exclusions the current version, you've captured the impl status. We've had some since IE10, carried through to Edge. Current spec as is defines how an exclusion area works, what is effected, how propitiate through descendents. How geometry side works. 17:09:29 q+ 17:09:43 Rossen: Lots of push back in past b/c most people thought this also defines exclusions as working on abspos only. Not true. Not dependent on any specific layout scheme 17:09:48 present+ 17:09:53 present+ 17:10:07 q? 17:10:07 Rossen: As such spec has been held at no progress for those issues. I'd be happy to engage with anyone interested in progress and see if can get more traction. 17:10:17 ack florian 17:11:10 some of my previous concerns about exclusions are at https://lists.w3.org/Archives/Public/www-style/2012Jul/0683.html and the thread above https://twitter.com/fantasai/status/1024736667494535168 17:11:23 florian: There was push back on that, but also on a variant where they could work on some modes that didn't do collision avoidance. That you could exclude without collision avoidance was a problem. I was given an action to try and define collision avoidance by default, but it's very hard and not sure that's the way forward. Other option is to make property have no effect or just let it be possible 17:11:51 florian: Maybe still persue if you turn it on with something that doesn't have collision avoidance you get it. Need someone to define that. It's possible, but massive. 17:11:56 Rossen: That's my memory as well. 17:12:03 Rossen: I think dbaron posted related threads 17:12:21 Rossen: They had to do with some concerns about cyclic dependencies 17:12:31 I think this is going to keep coming up, I'd be happy to help work on it, but I think we need something to solve these use cases 17:12:37 Rossen: I don't recall any such issues when I impl exclusions, but can't speak for other engines. 17:12:44 now we have grid we'll see more of them 17:13:02 Rossen: Most of concerns were related to paged media and not as much visual. This is when most issues would occur 17:13:03 s/to make property have no effect/to make property have no effect on things such as abspos that don't include collision avoidance built-in/ 17:13:38 Rossen: This is where we are. Summary captures everything we've discussed. Be happy to try and make progress and have exclusions move forward because they are awesome. 17:13:50 Rossen: For those interested let me know and we can try and make something actionable 17:13:55 Rossen: rachelandrew are you interested? 17:13:59 rachelandrew: Yes, definitely 17:14:07 alex_antennahouse has joined #css 17:14:14 present+ alex_antennahouse 17:14:25 Rossen: What if we table the discussion until we bring back use cases and see how they fit in current model. 17:14:28 rachelandrew: sgtm 17:14:34 +1 to dbaron's concerns listed above 17:14:40 Topic: Should 'break-before' / 'break-after' have an 'always' value? 17:14:51 github: https://github.com/w3c/csswg-drafts/issues/3318 17:15:42 fantasai: As emilio and I looked into these aliases we noticed IE impl 'always' which is not in spec. IN earlier revisions there was 'always' but not clear. WE considered breakt hrough all fragementation context or in closest one. 17:15:55 fantasai: IE treats as alias to page and only works in paged mode 17:16:15 fantasai: Options: We can define that break-before:always doesn't exist but it looks like usage is high 17:16:23 fantasai: We define it to exist has 3 options 17:17:06 fantasai: Alias of Page, Trigger break at inner most fragmentation context, or Trigger to break through all available fragmentation contexts 17:17:12 fantasai: Those are our options 17:17:50 fantasai: My preference is if we have this we should break at inner most fragmentation context. That way author working on content can ask for a break at the next thing. That seems most useful when trying to simulate pages. 17:17:51 Innermost seems the most sane to me. 17:18:44 fantasai: Most compat is define as page break. I'm not sure we need that level of compate b/c main difference is if inside a multi-col. In IE you will not trigger any break in a multi-col unless you're printing. So if you're using break in multi-col you'll get really inconsistant results depending on mode. 17:19:00 florian: that would be great thanks 17:19:21 florian: I think last time we talked we agreed main use case was inner most, but also a use case for outermost. We removed b/c needed to name both consistantly. I think we had any/all, but not sure. 17:19:31 fantasai: Now we have 'always' which needs to be defined in some way 17:19:57 florian: Always and all and always and any that always pairs best. I think we should get both, but if we have both which name is obvious 17:20:12 always|all 17:20:12 fantasai: I think inner most is most useful, but interested in hearing from rachelandrew and dauwhe 17:20:31 dauwhe: In ebook people fake pagination with multi-col all the time. Inner sounds like would make sense for us 17:21:06 florian: If you're not nesting it doesn't make difference where you punch through. If you are nesting I think you'll need both. Like, you're at a chapter break and want to break all context. Or smaller break. 17:21:21 fantasai: bradk suggests 'always' and 'all' 17:21:28 florian: I think that's okay 17:21:30 always and all sounds good to me 17:21:37 florian: If we're stuck with always it's reasonable 17:21:48 fantasai: Rossen would you be willing to change in Edge? 17:22:38 Rossen: Potentially. Use cases I've heard are compelling and make sense. From impl PoV it's not super hard. more juggling to re-order breaks in the right priority and break as much as needed based on current stack of breaks. 17:22:53 s/difference where you/difference whether you/ 17:22:57 Rossen: Break through all or just current is similar to things we're doing. 17:23:23 Rossen: Having heavy hammers of those two, it'll be fine. I don't think from impl PoV this is a huge concern as long as it fits the bill and addresses enough use cases. 17:23:52 fantasai: I think having 'always' makes it easy for authors. They don't have to think about context, they just want a break. If you want a page break, you can say that specificially. 17:23:57 Rossen: Wouldn't disagree. 17:24:41 Rossen: In principle my model for breaking and fragmentation has been ideally one you can declare your own levels and then have your own defined break for that level. It could be a page, a column, and article, and you should expect that's how it happens 17:24:56 Rossen: Since we're static defining the levels something to punch through is needed. 17:25:14 Rossen: You'll always have cases where they say punch through everything except this one. Hoping to not have to discuss that. 17:25:42 florian: Might need that with region or region-like things. But it's just a maybe. If we do it's not hard, but hopefully unneeded complexity 17:26:00 Rossen: I see last proposal was break-before/after: always | any | first 17:26:02 Rossen: if you have columns inside pages, how do you force a page break without forcing a column break? 17:26:14 fantasai: Always and all, always is nearest 17:26:23 Rossen: All is a superset of always 17:26:35 fantasai: always means you always get the minorest amount of break 17:26:41 Rossen: All implies always everywhere 17:26:44 fantasai: umhum 17:26:47 always break right here, or always break all levels. 17:26:53 Rossen: What do others think? 17:27:13 just making the face at the wordplay 17:27:15 Rossen: myles are you unhappy or borderline happy? 17:27:17 "all implies always everywhere" 17:27:54 Rossen: Objections to adding 'always' and 'all' to break-before/after where always is on the nearest fragmentationer and all breaks across all fragmentaners 17:28:01 RESOLVED: add 'always' and 'all' to break-before/after where always is on the nearest fragmentationer and all breaks across all fragmentaners 17:28:08 Topic: Let :matches() have better error-recovery behavior than normal Selectors 17:28:15 github: https://github.com/w3c/csswg-drafts/issues/3264 17:28:24 Rossen: Is TabAtkins on? 17:28:33 fantasai: I can take it 17:29:11 fantasai: When we have a list of selectors :foo, :bar 17:29:24 fantasai: Browser doesn't rec :foo so the entire style rule is thrown out 17:29:31 fantasai: That's selectors invalidation. 17:30:06 fantasai: Other style of invalidation is media queries-like where you throw out a section. So if you have foo, screen we recognize screen 17:30:31 fantasai: Can't do MQ like because it would break the web for selectors. TabAtkins pointed out we have ability to do it within the new selectors in L4 17:30:50 fantasai: Issue proposes we adopt MQ-like invalidation inside the pseudoclasses that take selectors. 17:31:14 fantasai: :foo || :bar, [known selector] we'd only do the part we recognize. 17:31:51 fantasai: Makes a lot os sense to me together with @supports rule we added. Gives authors much better tools. If they want more granular they can use something else 17:31:55 Rossen: Sounds reasonable. 17:32:00 Rossen: Opinions? 17:32:12 myles: Thoughts from people that teach this? Seems like could be confusing 17:32:16 Rossen: leaverou or rachelandrew ? 17:32:22 Were you suggesting doing different things for :matches() vs. :is() ? 17:32:52 agreed with myles, it could be confusing. would definitely want webdev teacher feedback on this. 17:32:57 fantasai: dbaron this was from before we renamed. Title should be is. Applies to is, not, has, nth-child, and maybe current 17:33:12 dbaron: One worry is some have been around for a while and might have compat issues 17:33:22 fantasai: :not with commas isn't widely supported. 17:33:40 fantasai: Not with a single argument that's invalid makes the whole thing invalid 17:33:53 florian: I think not with a comma is supported in Safari and Viviostyle 17:34:03 fantasai: Not is trickier because it's a negation 17:34:12 leaverou: Trying to decide error recovery or syntax? 17:34:16 fantasai: Error recovery 17:34:53 leaverou: Sounds amazing thing to do. It might be a little confusing, but it's worth it. In talks I only use webkit version and have to mention verbally it's just webkit. As an author I would love it 17:35:04 emilio: Doesn't solve unknown pseudo elements issue, right? 17:35:08 fantasai: No, sep. 17:35:17 emilio: I think that's biggest issue authors want to solve 17:35:23 fantasai: There's a rule for the webkit 17:35:43 emilio: Want to style a video control for webkit and edge it's not stanard. That's the biggest source of duplication 17:35:56 fantasai: This would solve, put it in all one :is 17:36:05 emilio: Syntax allow psuedo elements inside? 17:36:10 Iā€™m still concerned about :not. Can we find out how much authors have :-webkit and commas inside not? 17:36:17 fantasai: This is work for pseudo classes. Elements is next on agenda 17:36:26 I support this 17:36:43 Rossen: bradk point about not and his concern, can we address that now? 17:37:06 Rossen: Concern is the :not and defining how much authors have commas inside a not? 17:37:11 florian: It's safari only 17:37:36 bradk: Safari on iphone is used a lot. :not has been without commas for a while, but it's used in mobile web a lot. That's my suggestion, I'd like actual data 17:38:01 florian: This is hard data to get. Need to find usage that would break the page if it started working in a different way. That's a judgement call 17:38:19 Rossen: Another way to ask is if any Apple folks have an issue with this. If they feel comfortable with compat risk we can resolve 17:38:33 bradk: That solution would be okay 17:38:42 smfr: I don't think we have enough [missed] 17:39:22 smfr: I don't thinkw e have enough information to know. When we impl :not we got compat issues b/c people using it in wrong ways 17:39:35 smfr: No feeling for how common comma use is to know if it's risky 17:39:49 Rossen: Would you be okay with current proposal in the absense of this information? 17:39:51 smfr: I think so 17:40:03 Rossen: Anything else before we try and resolve? 17:40:29 No strong objection 17:40:31 fantasai: Use media query style invalidation inside psuedo classes that accept selector lists 17:40:36 Rossen: Objections to ^? 17:40:46 emilio: Would like behavior for :not clarified 17:40:50 fantasai: Makes sense 17:41:03 RESOLVED: Use media query style invalidation inside pseudo classes that accept selector lists 17:41:15 Rossen: fantasai and TabAtkins will have clarification in spec 17:41:30 Topic: Reconsider removing selector list invalidation 17:41:38 github: https://github.com/w3c/csswg-drafts/issues/3082 17:41:46 fantasai: Closely related issue 17:42:01 fantasai: We were talking about how invalidation is a problem, can't change for compat reasons. 17:42:44 fantasai: Suggestion was have a special rule for unknown pseudo elements to treat as valid, but only for not prefixed ones. Wanted to ask WG if we should look into this 17:43:13 fantasai: If you don't recognize anything in the selector you invalidate the whole thing. Can't change whole rule, but maybe possible to change that rule only for pseudo elements 17:43:33 fantasai: Wanted to ask if anybody has thoughts on if this is something we should look into 17:43:36 Rossen: Opinions? 17:43:54 florian: I think people rely on it not to work as a form of browser sniffing 17:44:10 dbaron: Also one where I would ask who would impl first 17:44:20 Rossen: I'm hearing pushback 17:44:30 emilio: Assume proposal you need to work for unprefixed, right? 17:44:32 fantasai: Yes 17:44:41 s/for unprefixed/only for unprefixed/ 17:44:55 dbaron: sorry, too much noise here today :( 17:44:57 florian: Then it's a question of accidentally relying on it not to work. Possibly less but have no data. 17:45:14 Rossen: I can't figure out if this is something we want to work on or if just table 17:45:27 Rossen: Still hearing more pushback then interest 17:45:35 florian: If we could make it work it would be great. 17:45:52 fantasai: Want to know if we should a, accept b, reject or c, not now, maybe selectors 5 17:45:58 Rossen: Easiest to agree on is C 17:46:00 C 17:46:07 Rossen: Anyone pushing for accept or reject? 17:46:28 Rossen: Objections to kick the can down the road and think about this for Selectors 5? 17:46:34 Kick the can to the table 17:46:37 RESOLVED: kick the can down the road and think about this for Selectors 5 17:46:55 florian: Not satisfactory but until someone volunteers to collect data there's not much we can do. 17:47:01 Rossen: It's reflecting reality, though. 17:47:34 Topic: :defined 17:47:40 github: https://github.com/w3c/csswg-drafts/issues/2258 17:48:24 fantasai: HTML defines :defined pseudo class in its spec, in general we define in selectors and HTML refines. So should :defined be defined in selectors? 17:48:34 fantasai: Matches all elements that had no problem during constructions 17:48:47 Rossen: Any reason why it shouldn't be defined in selectors? 17:49:02 fantasai: Very HTML specific currently. That's the only reason I can think of 17:49:11 Rossen: Not crazy about the name, it's a little too generic 17:49:35 florian: Would fail to match on custom elements not defined properly and any element whose semantics are unknown to browser? 17:49:40 fantasai: Don't know 17:50:00 florian: Reading example that seems to be the case. If using on a not known element it won't match. 17:50:15 florian: Does make it non-HTML specific even if use cases are HTML specific 17:50:20 Karen has joined #css 17:50:24 florian: Seems like we should do this, but also study more 17:50:28 fantasai: It's impl afaict 17:50:36 Rossen: Impl in blink? 17:50:46 fantasai: Not registering as invalid in test case. 17:50:53 emilio: Impl in blink, gecko, and webkit 17:51:10 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ahtml%3Adefined%2C%20foo%3Adefined%20%7B%20border%3A%20solid%20green%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cfoo%3EThis%20is%20a%20test%3C%2Ffoo%3E 17:51:18 are there tests for this? 17:51:37 Rossen: If this has impl in various UA and since it's a selector makes sense as part of selectors unless we're against it in the way it's defined. We should accept it and refine 17:51:41 florian: Sounds good 17:51:53 Rossen: Other comments or Objections to adding :defined to selectors L4? 17:52:03 RESOLVED: Add :defined to selectors L4 17:52:14 Topic: Publication of Selectors 17:52:30 Rossen: Republish WD? 17:52:33 fantasai: Yeah. 17:52:42 fantasai: Thing we jsut resolved on I'll mark as open issue 17:52:45 https://www.w3.org/mid/f9835b3c-1757-e712-b7ba-37a3c9d9ca2b@inkedblade.net 17:52:51 RESOLVED: Publish a new WD of Selectors 4 17:53:18 Karen_ has joined #css 17:53:20 Topic: Draft line-box-contain proposal 17:53:27 github: https://github.com/w3c/csswg-drafts/issues/3199 17:54:04 fantasai: We talked about having a prop that does roughly this. Some control over height of line calc. Been discussed since before my time. dbaron had interesting proposals for how to do it 17:54:20 fantasai: Know we need 3 behaviors: now, quirks mode, and consistant lines people want 17:54:33 fantasai: Drafted rough proposal with behaviors talked about. 17:54:47 https://drafts.csswg.org/css-inline-3/#line-sizing-property 17:54:55 fantasai: Wanted to ask WG if we want to work on this? Add something? I think need to add to inline spec, this is a rough draft. 17:55:11 fantasai: I think we need to add a property that does something smooth with a syntax 17:55:17 fantasai: Vague, but I wanted a start 17:55:56 myles: Been thinking about this for a while and I don't know right approach. Need backwards compat, but mode switches are confusing and multiple ways to solve line-height is extra mantanence and makes web more complicated. Not sure right way to do this 17:55:56 antenna_ has joined #css 17:56:36 florian: Hard time seeing anything but a mode switch here. Not sure we need that many values, I'd rather 2. One does legacy or quirk depending on mode and the better behavior. Others listing leave out until proven 17:56:51 fantasai: The 'better behavior' says [reads] 17:57:23 fantasai: It might be possible to slip that in without breaking too much. Any ledding is too much. It's possible that wont' break anything 17:57:30 q+ dbaron 17:57:57 myles: Not saying mode switch bad. More frustration about where we got to. Also, want to say this is one of the most requested features from people that care about text. Great to solve. We're between a rock and a hard place 17:58:02 s/Any ledding/Any leading/ 17:58:03 dauwhe: I will use it as soon as it exists 17:58:19 q? 17:58:21 s/is too much/would break, but only eliminating positive leading might be possible/ 17:58:23 Rossen: Where do we work on it? 17:58:38 dbaron: A few comments 17:58:42 ack dbaron 17:59:17 dbaron: I think there is an alternative to mode swhich is new syntax to line-height. Mode switch-like, but not as bad in some ways 17:59:44 I seem to only have mic issues with WebEx, need to figure out why as I use this setup for podcasts with no issue. 17:59:58 dbaron: May need >1 new value. bunch of use cases for things like images in a line and in default you want images to change line height, but there are cases where images within a line and do not want a change because images are roughly the size of the text 18:00:22 bgirard has joined #css 18:00:43 fantasai: In terms of new keywords for line-height for ergonomics a mode switch is better. Line-height you're talking about quantity of space, not the mechanism by which you want to measure. It's a separate thought in how you want to do it. 18:01:31 fantasai: You want the good line height calc on the whole page and forget it. Same way as box sizing is done. I used to think it was a mistake, but the way we did box sizing was originally almost always wrong. Webdev would rather set it once on a style sheet. 18:01:58 I actually disagree about box-sizing, since I think it depends whether you care about the inside-size or the outside-size 18:01:58 fantasai: This is similar. You almost never want to switch. You want to set at the top and you don't want to think anymore. If you put it in line-height you have to think every time you change the line height 18:02:10 myles: Would a mode swtich change the way line-height is inherited? 18:02:22 yes it was certainly my intent when I proposed box-sizing that it was a "just fix it so things work like I expect across all the things box related" 18:02:31 s/inherited/inherited or how it applies to only block elements and not inlines/ 18:02:44 fantasai: Various behaviors prop. One that would fix most problems would be to change it so line-height is ignored on all inline elements. They just have a line-height of 1 effectively. 18:03:01 fantasai: Had to modify so if you set line-height <1 we add negative leading so your effect is honored 18:03:38 fantasai: Not that it doesn't apply, just only applies if negative leading. Applies to root and then applied to every line. As long as you're in that space, if the sizing box fits, it doesn't increase height of line or move it 18:03:48 myles: Any precedent for that type of behavior? 18:04:08 myles: I mean changing the behavior of a prop based on another prop. Not sure how I would impl 18:04:24 Rossen: sorry! i didn't realize the time 18:04:41 Rossen: Sorry to interrupt. We're 4 minutes overtime. I want convo to continue, but I want to let everyone else go. We won't resolve, but convo should continue 18:05:02 scribenick: gregwhitworth 18:05:10 oh 18:05:14 lol 18:05:20 myles: I have to go too. 18:05:34 fantasai: Schedule a separate call about this 18:05:36 Rossen: Good idea 18:05:55 Rossen: Focused group would be good. I'll send an email to private list to see if we can get folks 18:05:59 fantasai: I can sent 18:06:15 Rossen: Have a great Thanksgiving for those of you celebrating. Talk to you next week. 18:06:17 Topic: end 18:11:43 aja has joined #css 18:19:27 Tav has joined #css 18:33:21 Tav has joined #css 19:11:23 smfr has joined #css 19:20:17 bgirard_ has joined #css 19:23:42 Tav has joined #css 19:33:57 TBah has joined #css 20:32:16 Zakim has left #css 20:37:49 projector has joined #css 20:38:19 Rossen has joined #css 20:38:49 shans has joined #css 20:39:20 sylvaing has joined #css 20:40:16 dauwhe has joined #css 20:40:20 leaverou has joined #css 20:40:50 plinss has joined #css 20:42:17 Tav has joined #css 20:45:23 Tav has joined #css 20:48:28 Tav has joined #css 20:50:14 Tav has joined #css 21:10:32 florian has joined #css 21:36:31 trackbot, end meeting 21:36:31 Zakim, list attendees 21:36:39 RRSAgent, please draft minutes 21:36:39 I have made the request to generate https://www.w3.org/2018/11/21-css-minutes.html trackbot 21:36:40 RRSAgent, bye 21:36:40 I see no action items