Cascading Style Sheets (CSS) Working Group Teleconference -- 04 Dec 2019

<scribe> ScribeNick: dael

astearns: Thanks everyone that called in on time. We'll see how many others we can get on before we start

<TabAtkins> mostly regrets; i'm at tc39 meetings today

astearns: We'll wait until 5 after to decide on quorum unless we get a flood of people
... We've got enough to start
... Does anyone have extra thigns for the agenda? I saw FPWD for resize-observer

bkardell_: Wanted to ask about January F2F
... 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

florian: Format or duration?

bkardell_: We're pretty open. I believe we said max 20 minutes

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?

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

astearns: I'm alway happy to talk about logging browser bugs and creating tests
... Please start a thread, people can volunteer, and then we can coordinate time and topics

FPWD for Resize Observer

astearns: A few months ago there was a moment where TabAtkins said he would ask and then we didn't get to it
... Concerns about publishing FPWD of Resize-Observer?
... Objections?

<fantasai> +1 to publishing specs for things we're shipping :/ should publish earlier!

RESOLUTION: Publish FPWD of resize-observer

astearns: Thanks smfr for pointing out we hadn't gotten to it.

F2f

Rossen_: Wanted to emphasize to please mark on wiki if you're attending or regrets for next F2F. It really helps organizers.

<fantasai> RSVP here! https://wiki.csswg.org/planning/galicia-2020

Rossen_: Helps with rooms, food, etc.

Add Adam Argile to Colors 5

RESOLUTION: Add Adam as an editor for Colors L5

[cssom-1][mediaqueries-5][css-color] Dealing with bi-plane (video/graphics) when reporting values

github: https://github.com/w3c/csswg-drafts/issues/4471#issuecomment-555743057

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.
... AmeliaBR chris and TabAtkins said video-[property] made sense. Why we need this is TV manufactuors have 2 graphics planes. Where movie is shown gets different high support but menus might get lower capability and they don't plan to change that.
... 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
... Does anyone disagree with the resolution in media WG

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?

gregwhitworth: Yes, we'd answer same statement if there's one plane.

chris: Then yes, I think this is the best possible and I support

florian: For video playing we're talking about if it's full screen and not window mode?

gregwhitworth: Yes. We've been vague on what we mean because it's not a standarized term

florian: I mean something that does not depend on layout

gregwhitworth: My expectation would be no. I don't htink they're doing web layout. THey're different roles.

florian: As long as it's a full thing then sure

chris: I think it would work. Hardware would do a mask

florian: Sure, that works. It's a MQ and shouldn't depend on layout

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

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

myles: How does web content say I want this element to go in this plane

gregwhitworth: You don't. WebDev doesn't get to derrive which element it goes on

AmeliaBR: Part of definitions would be if rendering agent isn't using separate plane then these values would match regular MQ

gregwhitworth: Correct

myles: If every peice of content has non-standard parts what's rational for standarizing this MQ

gregwhitworth: This would be like standarizing GPU chipsets. It's their version of hardware

myles: Why standardize? Why not have own custom thing to annotate

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

florian: Don't want UA sniff

gregwhitworth: Yes, that's part of why 3 options. And it's not technically TV only but that's the angle

chris: I want this to work same for non-TVs

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.

<bkardell_> what constitutes a 'tv' here?

<bkardell_> seems like a weird term of distinction?

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.

gregwhitworth: Yep

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

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

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

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.
... I don't see a down side. For most cases this is a bunc hof alaises

astearns: Prop: add the video prefix MQ and define how used in bi-plane and non-bi-plane environments

gregwhitworth: sgtm

astearns: Obj?

RESOLUTION: Add the video prefix MQ and define how used in bi-plane and non-bi-plane environments

chris: I think we should open a new issue on the OM thing

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.

chris: Anything I need to do for color 4?

gregwhitworth: No, that was me ensuring chris got on the thread

<chris> lol

fantasai: For the OM part is there stuff that's parallel with the media queries or is there some additional thinking?

AmeliaBR: Not exactly parallel.
... Last comment in issue is one of the Media folks saying they want to discuss on best API

astearns: Let's open a new issue, hash it out, and bring to group

AmeliaBR: Who is doing edits?

gregwhitworth: I can take a stab at it

fantasai: MQ 5 right?
... We need a FPWD of MQ 5 at some point

<fantasai> https://drafts.csswg.org/mediaqueries-5/#contents

Media Queries publication

astearns: What's in it?

florian: Reduced motion

Rossen_: the preferences queries

chris: If that's in why not resolve?

AmeliaBR: I thought we had

Rossen_: We had resolution

fantasai: I don't think so. I think we were waiting

astearns: Why don't we wait on edits for video MQs and if we don't have a resolution we'll get it then

florian: Things we discussed could be L5, but similar things are in 4.

fantasai: It goes in 5. 4 is done.

<fantasai> MQ4 is CR already

Rossen_: Shouldn't hold L5 FPWD on these MKews. The potential amount of changes in 5 people are experimenting with so FP would be good

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

Rossen_: Okay, let's keep going

astearns: Happy to do it next week

[css-fonts] Don't require browsers to always match every generic font family to a concrete font family

<fantasai> Technically, the reference draft for patent review is the latest WD published within 90 days after FPWD, fwiw.

github: https://github.com/w3c/csswg-drafts/issues/4442#issuecomment-553707851

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.
... 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
... 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
... 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

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

myles: I could move the must sentince into specific generic font-families. sanserif family must have mapping

chris: can we do it for the 3 real ones and not require fantasy and cursive?

myles: Don't see why not

heycam: Mapping but not requirement on character coverage?

myles: Correct. THat's current state

florian: In discussion chris and I had different understanding. When you write make it clear which version is right.

chris: Agree and I think I'm wrong and we should make it clear

myles: Yeah and I'll make examples

florian: I used to interpret like chris and I don't think it's right

chris: And mine doesn't have benefit it's mapping from CSS1

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.

myles: Anyone from FF that says it's true?

chris: Jonathan Kew was on the thread

AmeliaBR: They do composit but allow users to change mappings for languages so not sure how it falls back

myles: Prop: Move the normative sentince about font-families mapping to a font into the serif, sanserif, and monospace items.

florian: And add a note that the font might not cover everything
... I support this

<AmeliaBR> https://github.com/w3c/csswg-drafts/issues/4442#issuecomment-547627749

astearns: Concerns?
... fantasai thinks cursive should be in the list

fantasai: If there's not one on the system it's okay not to map

AmeliaBR: Cursive is such a mess you get different results in different browsers

myles: I think if we jsut say all these should map to something if such a font exists covers it

<fantasai> +1 to Amelia's definition

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

astearns: serif, sanserif, and monospace must match, all others should match if appropriate

chris: myles you'll edit?

myles: Yeah

heycam: Must match and not distinction; does that imfluence first matching?

myles: They interact. You found the corner case where it is observable

AmeliaBR: Also effects cases where this is a match but no character

astearns: Then you get line height with the font

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 Mincho and then manually provide one in the fallback you get the layout but with the wrong font metrics.
... That's not nice

myles: It's a separate topic

florian: Agree but we were getting there

AmeliaBR: It's worth a second issue specfically on font metrics

florian: Will open one

chris: There are issues on similar things, like nastaliq and fangsong

florian: I'll look at existing and make a new if it's not there

astearns: Obj to serif, sanserif, and monospace must match, all other generics should match if appropriate

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.

RESOLUTION: serif, sanserif, and monospace must match, all other generics should match if appropriate.

astearns: AmeliaBR it would be great if you can review once myles does edits
... Should we discussed first available height issue?

florian: I'll make github first

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.

AmeliaBR: Tendency was leave to UA discression but if you want normative we want a separate discussion

astearns: Let's make that a separate issue

[css-lists] How should spaces be treated in markers?

github: https://github.com/w3c/csswg-drafts/issues/4448#issuecomment-552605582

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
... 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
... 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

astearns: Makes sense to me

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
... Alternative is to define a new value pre-spaces that preseves spaces but not linebreaks. That would solve problem of introducing preserved linebreaks
... Other option is we have to define how to handle multiple lines of text in an outside marker.

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

fantasai: Vaguely remember it, but don't remember SVG behavior

heycam: I think it drops new lines and preserves spaces

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

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

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

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

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

astearns: I thought it was part of this solution's design that authors would have way of changing UA stylesheet value

<AmeliaBR> 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)

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

heycam: Alternative might be change definitions of counter styles to use a non-breaking space. THat would only work if we don't have authors using custom counter styles with spaces

fantasai: Can't be that many since it's a very new feature

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

heycam: Not just counters, but normal content property

<fantasai> AmeliaBR, text-space-collapse was a longhand of white-space

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

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

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.

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.

florian: Want to make sure we don't need to add new values of whitespace

fantasai: Looks like SVG one satisfies the constraint

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

florian: Partly underfines for inline. If behaves as everything else, but is it inherits or from UA stylesheet?

AmeliaBR: WOuld like a decision on that b/c seems not as dependant on markers

florian: If there is a value on UA stylesheet it applies to inline and not. If it's inherit we have an answer
... 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

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

florian: If we can resolve on whitespace property being inherit that's fine. But I don't htink we can do inline alone

fantasai: Trailing spce is preserved. IT needs to be value that does tno collapse

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

fantasai: I'm okay resolving it's pre for now. Of the values we have available it's the only one that preserves spaces

florian: pre-wrap or break-spaces

<heycam> (-moz-pre-space is the internal value name we have for SVG xml:space="preserve" text)

astearns: Obj: Take Mats 3 part proposal leaving value of UA stylesheet in the air as a separate issue

<fantasai> I was thinking pre-space or pre-spaces :)

RESOLUTION: Take Mats 3 part proposal leaving actual value of UA stylesheet in the air as a separate issue to be determined later

end

astearns: Thanks everybody and we'll talk next week

<heycam> florian: newlines get dropped

<fantasai> AmeliaBR, https://drafts.csswg.org/css-text-4/#white-space-collapsing

<heycam> oh cool, didn't realise it got a standard name

<fantasai> heycam, we tried at one point :)

<fantasai> heycame, that's fairly unstable stuff in css-text-4, though

<fantasai> heycam, maybe I should open an issue against css-text-3 to add pre-spaces

<heycam> it might be I'm misremembering that newlines are dropped. and maybe they're transformed into spaces instead. would have to test

<fantasai> SVG spec says they turn into spaces

<heycam> ok

<fantasai> which is imho rather less useful...

<heycam> it's weird, agreed

<florian> is it weird?

<florian> (to convert the new lines into spaces)

<AmeliaBR> It's useful if you're writing out a heading and breaking lines to fit in your code editor.

<heycam> given the current resolution for the ::marker issue, I don't think we need to pull this value up to css-text-3

<AmeliaBR> (if you're writing in a language that uses spaces or newlines as word separators, that is)

<fantasai> it should probably follow the line break transformation rules ideally :)

<astearns> trackbot, end meeting

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference

04 Dec 2019

Attendees

Contents

FPWD for Resize Observer

F2f

Add Adam Argile to Colors 5

[cssom-1][mediaqueries-5][css-color] Dealing with bi-plane (video/graphics) when reporting values

Media Queries publication

[css-fonts] Don't require browsers to always match every generic font family to a concrete font family

[css-lists] How should spaces be treated in markers?

end

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output