23:56:58 RRSAgent has joined #css 23:56:58 logging to https://www.w3.org/2019/12/04-css-irc 23:57:00 RRSAgent, make logs public 23:57:00 Zakim has joined #css 23:57:02 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 23:57:02 Date: 04 December 2019 23:58:42 present+ 23:58:47 ScribeNick: dael 23:59:19 present+ 00:00:17 present+ 00:00:29 astearns: Thanks everyone that called in on time. We'll see how many others we can get on before we start 00:01:05 smfr has joined #css 00:01:10 present+ 00:01:24 mostly regrets; i'm at tc39 meetings today 00:02:21 astearns: We'll wait until 5 after to decide on quorum unless we get a flood of people 00:02:30 Rossen_ has joined #css 00:02:31 present+ 00:02:41 bkardell_ has joined #css 00:03:12 chris has joined #css 00:03:17 present+ 00:04:06 ving has joined #css 00:04:15 astearns: We've got enough to start 00:04:28 present+ 00:04:31 astearns: Does anyone have extra thigns for the agenda? I saw FPWD for resize-observer 00:04:39 bkardell_: Wanted to ask about January F2F 00:04:40 present+ 00:05:13 bkardell_: We're doing a developer meetup at that time and looking to see if anybody would be willing to do a presentation. rachelandrew has already agreed, but we'd appriciate anyone else 00:05:19 florian: Format or duration? 00:05:29 bkardell_: We're pretty open. I believe we said max 20 minutes 00:05:37 chcunningham has joined #css 00:05:56 Rossen_: If we don't have a thread on this on the private list perhaps we should start one to concentrate and have people sign up. Did you send something earlier? 00:06:18 bkardell_: Nope, this is the beginning of it. We reached out to a couple of people directly and rachelandrew said yes, now we're putting it here 00:06:30 astearns: I'm alway happy to talk about logging browser bugs and creating tests 00:06:45 astearns: Please start a thread, people can volunteer, and then we can coordinate time and topics 00:06:55 Topic: FPWD for Resize Observer 00:07:15 astearns: A few months ago there was a moment where TabAtkins said he would ask and then we didn't get to it 00:07:27 astearns: Concerns about publishing FPWD of Resize-Observer? 00:07:32 astearns: Objections? 00:07:42 +1 to publishing specs for things we're shipping :/ should publish earlier! 00:07:47 RESOLVED: Publish FPWD of resize-observer 00:07:58 astearns: Thanks smfr for pointing out we hadn't gotten to it. 00:08:39 Topic: F2f 00:08:41 Rossen_: Wanted to emphasize to please mark on wiki if you're attending or regrets for next F2F. It really helps organizers. 00:08:41 RSVP here! https://wiki.csswg.org/planning/galicia-2020 00:08:51 Rossen_: Helps with rooms, food, etc. 00:09:08 Topic: Add Adam Argile to Colors 5 00:09:21 RESOLVED: Add Adam as an editor for Colors L5 00:09:32 Topic: [cssom-1][mediaqueries-5][css-color] Dealing with bi-plane (video/graphics) when reporting values 00:09:41 github: https://github.com/w3c/csswg-drafts/issues/4471#issuecomment-555743057 00:10:18 gregwhitworth: Overview: the media WG looking into adding to capabilities API. Wanted to determine what in an output can support. WE came up with 3 options that are in the issue. 00:11:12 gregwhitworth: AmeliaBR chris and TabAtkins said video-[property] made sense. Why we need this is TV manufactuors have 2 graphics plans. Where movie is shown gets different high support but menus might get lower capability and they don't plan to change that. 00:12:08 s/graphics plans/graphics planes/ 00:12:14 gregwhitworth: They want to tell the truth and if we only have one plane they have to lie. chris went over it in the beginning where we could jsut tell them to lie, but ultimately what WG came to is video-[property list] that works in CSS media queries so we can use in JS or CSS and see if UA supports them 00:12:27 gregwhitworth: Does anyone disagree with the resolution in media WG 00:13:05 chris: Clarification; TVs have 4k for video and lower. I didn't want TVs to say this is how TVs work and we don't care about PCs. But would they return the same if there's one? 00:13:15 gregwhitworth: Yes, we'd answer same statement if there's one plane. 00:13:24 chris: Then yes, I think this is the best possible and I support 00:13:37 florian: For video playing we're talking about if it's full screen and not window mode? 00:13:53 gregwhitworth: Yes. We've been vague on what we mean because it's not a standarized term 00:14:02 florian: I mean something that does not depend on layout 00:14:18 gregwhitworth: My expectation would be no. I don't htink they're doing web layout. THey're different roles. 00:14:30 florian: As long as it's a full thing then sure 00:14:42 chris: I think it would work. Hardware would do a mask 00:14:54 florian: Sure, that works. It's a MQ and shouldn't depend on layout 00:15:34 AmeliaBR: I do think it's true that some environments use the separate plane for embedded videos, but it's at the level where they're rendering video data and converting to screen pixels. What MQ would match is assming full screen 00:15:59 gregwhitworth: Right, wouldn't be layout of plane but dimension of the plane. It would be saying TV supports 4k and returns true with width and height 00:16:14 myles: How does web content say I want this element to go in this plane 00:16:26 myles has joined #css 00:16:30 gregwhitworth: You don't. WebDev doesn't get to derrive which element it goes on 00:16:50 AmeliaBR: Part of definitions would be if rendering agent isn't using separate plane then these values would match regular MQ 00:16:52 gregwhitworth: Correct 00:17:09 myles: If every peice of content has non-standard parts what's rational for standarizing this MQ 00:17:26 gregwhitworth: This would be like standarizing GPU chipsets. It's their version of hardware 00:17:36 myles: Why standardize? Why not have own custom thing to annotate 00:18:29 gregwhitworth: They're rendering web content. That was an option is pretend this doesn't exist. We keep only 1 query and force TVs to lie. But we had content providers say we want to know wha video is capable of rendering. I want the truth for each. I don't want ot send 4k images on lower resolution 00:18:33 florian: Don't want UA sniff 00:18:51 gregwhitworth: Yes, that's part of why 3 options. And it's not technically TV only but that's the angle 00:18:58 chris: I want this to work same for non-TVs 00:19:27 AmeliaBR: That's important consideration. MQs are saying when you render video what are features going to be. Sensible use case is on source lements in a video element that you're using to pick correct source. 00:19:30 what constitutes a 'tv' here? 00:19:45 seems like a weird term of distinction? 00:20:06 AmeliaBR: How the browser decides what type of rendering environment it's going to use for video isn't important. Only thing that matters is UAs are using different rendering for video then for rest of content so existing MQs aren't sufficient. 00:20:08 gregwhitworth: Yep 00:20:45 AmeliaBR: If in future we have situation where this division isn't good enough and some other content wants super high level then that can be a discussion at the time. Reality of environments we have now is high resolution is for video 00:21:24 gregwhitworth: My expectation also is that over time things will converge so 4k is available in both. Not reality now and b/c TV isn't upgraded often content providers want to provide correct content 00:21:57 AmeliaBR: bkardell_ asks what's a TV here and we don't have to define that. We're defining the video resolution regardless of if it's a TV or a high powered laptop with a separate video card 00:22:20 chris: Important point is we don't care but the answer is clear. Many times it will be the same but there are cases where it's not. 00:22:36 chris: I don't see a down side. For most cases this is a bunc hof alaises 00:22:56 astearns: Prop: add the video prefix MQ and define how used in bi-plane and non-bi-plane environments 00:23:02 bkardell_: sgtm 00:23:04 astearns: Obj? 00:23:14 RESOLVED: Add the video prefix MQ and define how used in bi-plane and non-bi-plane environments 00:23:23 s/bkardell_/gregwhitworth 00:23:28 chris: I think we should open a new issue on the OM thing 00:23:52 astearns: I was about to bring that up. I think we should have a new issue for the OM part so summerizing that separately will be easier. 00:23:59 chris: Anything I need to do for color 4? 00:24:10 gregwhitworth: No, that was me ensuring chris got on the thread 00:24:20 lol 00:24:30 fantasai: For the OM part is there stuff that's parallel with the media queries or is there some additional thinking? 00:24:39 AmeliaBR: Not exactly parallel. 00:24:52 AmeliaBR: Last comment in issue is one of the Media folks saying they want to discuss on best API 00:25:02 astearns: Let's open a new issue, hash it out, and bring to group 00:25:04 present+ 00:25:08 AmeliaBR: Who is doing edits? 00:25:14 gregwhitworth: I can take a stab at it 00:25:19 fantasai: MQ 4 right? 00:25:31 fantasai: We need a FPWD of MQ 5 at some point 00:25:36 s/MQ 4/MQ 5/ 00:25:49 https://drafts.csswg.org/mediaqueries-5/#contents 00:25:51 Topic: Media Queries publication 00:25:54 astearns: What's in it? 00:25:59 florian: Reduced motion 00:26:02 Rossen_: [missed] 00:26:11 chris: If that's in why not resolve? 00:26:17 AmeliaBR: I thought we had 00:26:21 Rossen_: We had resolution 00:26:31 fantasai: I don't think so. I think we were waiting 00:26:46 astearns: Why don't we wait on edits for video MQs and if we don't have a resolution we'll get it then 00:27:01 florian: Things we discussed could be L5, but similar things are in 4. 00:27:05 fantasai: It goes in 5. 4 is done. 00:27:11 MQ4 is CR already 00:27:42 s/[missed]/the preferences queries/ 00:27:42 Rossen_: Shouldn't hold L5 FPWD on these MQs. The potential amount of changes in 5 people are experimenting with so FP would be good 00:28:11 chris: Patent at FPWD and CR and given this is consumer electronics there's a chance of a patent. Throw these in and then do FPWD 00:28:17 Rossen_: Okay, let's keep going 00:28:22 astearns: Happy to do it next week 00:28:31 Topic: [css-fonts] Don't require browsers to always match every generic font family to a concrete font family 00:28:32 Technically, the reference draft for patent review is the latest WD published within 90 days after FPWD, fwiw. 00:28:44 github: https://github.com/w3c/csswg-drafts/issues/4442#issuecomment-553707851 00:29:37 myles: Was doing edits for new system font families. I couldn't make them regular generic font families b/c they have to be mapped. 00:30:01 myles: Was thinking and reason spec says have to have mapping is it's supposed to help authors where they can says font-family: fantasy and you get something in every browser 00:30:57 myles: THat's cool except there's 2 problems. 1 for any new font-family old browsers won't have mapping. 2 is there's no guar. that font supports your characters. So author can't set and forget because if use an unsupported character where it doesn't look right anyway 00:31:24 myles: That there's this statement I don't think it helps anyone and makes spec more complicated where some are generic and some are standard and I wish I could join them 00:32:04 fantasai: One distinction is a system might not have sanserif that's UI and wanted to be okay that this doesn't exist. But any sanserif on the system should have a mapping for sanserif. I don't want ot lose that 00:32:25 myles: I could move the must sentince into specific generic font-families. sanserif family must have mapping 00:32:40 chris: can we do it for the 3 real ones and not require fantasy and cursive? 00:32:44 myles: Don't see why not 00:32:54 heycam: Mapping but not requirement on character coverage? 00:33:00 myles: Correct. THat's current state 00:33:25 florian: In discussion chris and I had different understanding. When you write make it clear which version is right. 00:33:35 chris: Agree and I think I'm wrong and we should make it clear 00:33:42 myles: Yeah and I'll make examples 00:33:55 florian: I used to interpret like chris and I don't think it's right 00:34:06 chris: And mine doesn't have benefit it's mapping from CSS1 00:34:28 AmeliaBR: Important is to update author guidance ot match reality. Some UAs generic fonts won't have full coverage and will fall back to next in stack. 00:34:39 myles: Anyone from FF that says it's true? 00:34:46 chris: Jonathan Q was on the thread 00:34:57 s/Q/Kew/ 00:34:59 s/Q/Kew/ 00:35:01 AmeliaBR: They do composit but allow authors to change mappings for languages so not sure how it falls back 00:35:07 fantasai: And you can just change it 00:35:10 s/authors/users/ 00:35:23 s/fantasai: And you can just change it// 00:35:31 myles: Prop: Move the normative sentince about font-families mapping to a font into the serif, sanserif, and monospace items. 00:35:42 florian: And add a note that the font might not cover everything 00:35:46 florian: I support this 00:35:49 https://github.com/w3c/csswg-drafts/issues/4442#issuecomment-547627749 00:35:52 astearns: Concerns? 00:36:01 astearns: fantasai thinks cursive should be in the list 00:36:10 fantasai: If there's not one on the system it's okay not to map 00:36:25 AmeliaBR: Cursive is such a mess you get different results in different browsers 00:36:40 myles: I think if we jsut say all these should map to something if such a font exists covers it 00:37:08 +1 to Amelia's definition 00:37:15 AmeliaBR: I think that's fair for entire list include system-ui. If a font exists that matches definitions UA should map to the keyword. If you don't have a sensible mapping don'ts do oone 00:37:33 astearns: serif, sanserif, and monospace must match, all others should match if appropriate 00:37:39 chris: myles you'll edit? 00:37:41 myles: Yeah 00:38:00 heycam: Must match and not distinction; does that imfluence first matching? 00:38:10 myles: They interact. You found the corner case where it is observable 00:38:32 AmeliaBR: Also effects cases where this is a match but no character 00:38:38 astearns: Then you get line height with the font 00:39:24 florian: I think the concern I have which can be separate is that though not unique to generic fonts if you say use serif to mean [missed] and then manually provide one in the fallback you get the layout but with the wrong font metrics. 00:39:29 florian: That's not nice 00:39:35 myles: It's a separate topic 00:39:40 florian: Agree but we were getting there 00:39:51 AmeliaBR: It's worth a second issue specfically on font metrics 00:39:52 s/[missed]/Mincho/ 00:39:55 florian: Will open one 00:40:04 chris: There are issues on similar things 00:40:13 florian: I'll look at existing and make a new if it's not there 00:40:34 astearns: Obj to serif, sanserif, and monospace must match, all other generics should match if appropriate 00:41:05 AmeliaBR: Earlier in chat I linked to my comment in issue that breaks down other places in spec with coordinating edits. I think those are editorial, though. 00:41:20 RESOLVED: serif, sanserif, and monospace must match, all other generics should match if appropriate. 00:41:32 astearns: AmeliaBR it would be great if you can review once myles does edits 00:41:44 astearns: Should we discussed first available height issue? 00:41:50 florian: I'll make github first 00:41:56 s/similar things/similar things, like nastaliq and fangsong 00:42:18 heycam: Also which generic in the list determines fallback at the end. Should I make it a separate issue? It's if there should be wording to say which influences. 00:42:39 AmeliaBR: Tendency was leave to UA discression but if you want normative we want a separate discussion 00:42:47 astearns: Let's make that a separate issue 00:43:00 Topic: [css-lists] How should spaces be treated in markers? 00:43:09 github: https://github.com/w3c/csswg-drafts/issues/4448#issuecomment-552605582 00:44:15 oriol: When have sequence of whitespaces it's controlled by whitespace property. Doesn't apply to marker] elements. Can't say it's inherited. Markers have outside position. one of the effects is it blockifies. If you have a block where spaces at end would collapse they are instead completely removed 00:44:42 oriol: All native content styles use suffix that end with a space and if the markers have an outside position and then space disappears it's bad 00:45:58 oriol: Proposal in GH was a solution with 3 parts. 1) Say the whitespace property applies to marker elements. 2) by defaults in UA-origin markers should be assigned whitespace as pre to preserve spaces, but let authors pick another value. 3) make it explicit this outside position blockifies the marker so if some author changes whitespace value to normal they shouldn't get surprised if space disappears when they have an outside marker 00:46:03 astearns: Makes sense to me 00:46:52 fantasai: Questions. First it's well understood what would happen with a preserved linebreak with an inside marker. One with an outside marker is not defined. We would need to figure out how alignment works with markers and define what that means when you have multi-line text. Have a concern about that 00:47:25 fantasai: Alternative is to define a new value pre-spaces that preseves spaces but not linebreaks. That would solve problem of introducing preserved linebreaks 00:47:42 fantasai: Other option is we have to define what it is with an outside marker. 00:48:06 s/what it is with/how to handle multiple lines of text in/ 00:48:19 AmeliaBR: To follow up on collapsing value that preserves spaces but converts linebreaks sounds like SVG legacy value possibly. There's a value on the spec for SVG legacy stuff 00:48:32 fantasai: Vaguely remember it, but don't remember SVG behavior 00:48:41 heycam: I think it drops new lines and preserves spaces 00:49:16 fantasai: Maybe solution is to make sure that ends up in CSS text spec and assign it to ::marker and !important so author can't override until we figure out how outside markers are aligned 00:49:20 aja has joined #css 00:49:37 astearns: Wondering if makes sense to put on linebreaks and use pre and if you put a linebreak in a marker something weird will happen 00:50:07 fantasai: Eventually markers will be stylable in a variety of ways. Why not now is we don't have a layout model. We want to go there. Not a good idea to have browsers do different things 00:50:38 astearns: Not saying linebreak is different in each browser. Once you put a line break in and it's preserved something will happen and we have to spec this in the layout model anyway 00:51:21 fantasai: If we go with permitting we don't have a magic that makes them go away. We'd have a whitespace value that makes it go away and make the rule UA level !important so author doens't override. THat's one way to handle it which gives you consistent model 00:51:37 astearns: I thought it was part of this solution's design that authors would have way of changing UA stylesheet value 00:52:00 for reference, here's the SVG spec about this: https://svgwg.org/svg2-draft/text.html#LegacyXMLSpace ; looks like the last plan was to map it to a separate `text-space-collapse` property (https://drafts.csswg.org/css-text-4/#white-space-collapsing) 00:52:08 oriol: Mats wants authors to be able to customize. Not that strong with that, though I wouldn't mind. He was strongly in favor of letting authors customize it 00:52:42 heycam: Alternative might be change definitions of counter styles to not allow a space. THat would only work if we don't have authors using custom counter styles with spaces 00:52:51 fantasai: Can't be that many since it's a very new feature 00:52:55 s/not allow a space/use a non-breaking space/ 00:53:20 AmeliaBR: Compat issue is if you want markers spec with market pseudo element and content property to behave similar to how markers spec with list style properties behave. That's the compat issue 00:53:28 heycam: Not just counters, but normal content property 00:53:29 AmeliaBR, text-space-collapse was a longhand of white-space 00:54:01 oriol: Can define contents of marker by setting list-style-type to a string or in marker element you set content property to random string which can contain spaces or line breaks 00:55:02 astearns: Since our layout model for markers is likely to need to deal with these I'm inclined to go with Mats solution as-is and not worry what happens with linebreaks until we get to point os spec marker layout 00:55:28 fantasai: Concern there is we will get whatever behavior falls out of current impl which may not be interop. If it is interop it might not be what we want. 00:55:52 astearns: As far as I understand we don' have line breaks in marker strings now unless author adds it. If there is a problem it's fairly constrained. 00:56:03 florian: Want to make sure we don't need to add new values of whitespace 00:56:14 fantasai: Looks like SVG one satisfies the constraint 00:57:01 AmeliaBR: If we're officially define as undefined we should be limited. Everyone agrees when marker is inline position so part of normal block flow that line breaking and whitespace handling behaves the same. Undefined bit is with outside markers because exact box model of that isn't defined 00:57:13 Karen has joined #css 00:57:22 florian: Partly underfines for inline. If behaves as everything else, but is it inherits or from UA stylesheet? 00:57:37 AmeliaBR: WOuld like a decision on that b/c seems not as dependant on markers 00:57:55 florian: If there is a value on UA stylesheet it applies to inline and not. If it's inherit we have an answer 00:58:20 florian: We might still want to define a tweak if you're in the special layout but I hope not. Not sure how we define inline and not outside 00:59:08 AmeliaBR: Problem with outside markers is the whitespace property if you insert a linebreak not sure how would effect alignment of marker position. THat's the undefined part until we spec how markers are aligned. THe do you preserve linebreaks or not sounds like something we could decide on 00:59:29 florian: If we can resolve on whitespace property being inherit that's fine. But I don't htink we can do inline alone 00:59:47 fantasai: Trailing spce is preserved. IT needs to be value that does tno collapse 01:00:15 astearns: Can we resolve on whitespace applies to markers, there's a UA stylesheet rule about blockified markers, and levae the value in the air for now 01:00:32 fantasai: I'm okay resolving it's pre for now. Of the values we have available it's the only one that preserves spaces 01:00:38 florian: pre-wrap or break-spaces 01:00:43 (-moz-pre-space is the internal value name we have for SVG xml:space="preserve" text) 01:01:02 astearns: Obj: Take Mats 3 part proposal leaving value of UA stylesheet in the air as a separate issue 01:01:09 I was thinking pre-space or pre-spaces :) 01:01:24 RESOLVED: Take Mats 3 part proposal leaving actual value of UA stylesheet in the air as a separate issue to be determined later 01:01:26 Topic: end 01:01:36 astearns: Thanks everybody and we'll talk next week 01:01:47 florian: newlines get dropped 01:02:27 AmeliaBR, https://drafts.csswg.org/css-text-4/#white-space-collapsing 01:02:49 oh cool, didn't realise it got a standard name 01:03:07 heycam, we tried at one point :) 01:03:16 heycame, that's fairly unstable stuff in css-text-4, though 01:03:27 heycam, maybe I should open an issue against css-text-3 to add pre-spaces 01:03:29 it might be I'm misremembering that newlines are dropped. and maybe they're transformed into spaces instead. would have to test 01:03:40 SVG spec says they turn into spaces 01:03:43 ok 01:03:44 which is imho rather less useful... 01:03:53 it's weird, agreed 01:04:09 is it weird? 01:04:16 (to convert the new lines into spaces) 01:04:17 It's useful if you're writing out a heading and breaking lines to fit in your code editor. 01:04:32 given the current resolution for the ::marker issue, I don't think we need to pull this value up to css-text-3 01:04:53 (if you're writing in a language that uses spaces or newlines as word separators, that is) 01:05:58 it should probably follow the line break transformation rules ideally :) 01:06:29 trackbot, end meeting 01:06:29 Zakim, list attendees 01:06:29 As of this point the attendees have been dael, florian, oriol, AmeliaBR, Rossen_, fantasai, bkardell_, gregwhitworth, ving, chrishtr 01:06:37 RRSAgent, please draft minutes 01:06:37 I have made the request to generate https://www.w3.org/2019/12/04-css-minutes.html trackbot 01:06:38 RRSAgent, bye 01:06:38 I see no action items