- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 4 Dec 2019 21:19:30 -0500
- 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.
=========================================
Resize-Observer
---------------
- RESOLVED: Publish FPWD of resize-observer
Colors 5
--------
- RESOLVED: Add Adam Argyle as an editor for Colors L5
Media Queries 5
---------------
- RESOLVED: Add the video prefix MQ and define how used in bi-plane
and non-bi-plane environments (Issue #4471: Dealing with
bi-plane (video/graphics) when reporting values)
- The parts of this issue related to CSSOM will be broken into a
separate github issue.
- After the previous resolution is added, a request will be made to
take Media Queries L5 to FPWD.
CSS Fonts
---------
- RESOLVED: Serif, sanserif, and monospace must match, all other
generics should match if appropriate. (Issue #4442:
Don't require browsers to always match every generic
font family to a concrete font family)
CSS Lists
---------
- RESOLVED: Take Mats' 3 part proposal leaving actual value of UA
stylesheet in the air as a separate issue to be
determined later (Issue #4448: How should spaces be
treated in markers?)
1) Add white-space as a property that applies to ::marker
2) Add ::marker { white-space:pre } to the UA sheet
3) Mention that an outside ::marker box has its display value
blockified. (This makes it clear that if an author overrides
white-space with say white-space:normal then any trailing
space in an outside marker's text is expected to be truncated
as it normally would at the line end in a block.)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Dec/0007.html
Present:
Rossen Atanassov
Amelia Bellamy-Royds
Oriol Brufau
Elika Etemad
Chris Harrelson
Dael Jackson
Brian Kardell
Chris Lilley
Myles Maxfield
Florian Rivoal
Alan Stearns
Greg Whitworth
Regrets:
Tab Atkins
David Baron
Christian Biesinger
Daniel Holbert
Peter Linss
Ravikiran Ramachandra
Manuel Rego Casasnovas
François Remy
Christopher Schmitt
Scribe: dael
astearns: We've got enough to start
astearns: Does anyone have extra things for the agenda? I saw FPWD
for resize-observer
January F2F
===========
bkardell: Wanted to ask about January F2F
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 appreciate
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 always happy to talk about logging browser bugs and
creating tests
astearns: Please start a thread, people can volunteer, and then we
can coordinate time and topics
Resize-Observer
===============
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
astearns: Concerns about publishing FPWD of Resize-Observer?
astearns: Objections?
* bkardell anti-objects... I fully support this :)
<fantasai> +1 to publishing specs for things we're shipping :/
should publish earlier!
RESOLVED: Publish FPWD of resize-observer
<gregwhitworth> YAY!!
astearns: Thanks smfr for pointing out we hadn't gotten to it.
January 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.
Colors 5
========
Add Adam Argyle to Colors 5
---------------------------
* bkardell yays again! happy to hear that
RESOLVED: Add Adam Argyle as an editor for Colors L5
Media Queries 5
===============
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 was 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.
gregwhitworth: AmeliaBR, chris, and TabAtkins said video-[property]
made sense.
gregwhitworth: Why we need this is TV manufacturers 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.
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 just 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
gregwhitworth: 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 standardized term
florian: I mean something that does not depend on layout
gregwhitworth: My expectation would be no. I don't think 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 assuming 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 derive 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 piece of content has non-standard parts what's
rational for standardizing this MQ
gregwhitworth: This would be like standardizing 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 what video is capable of rendering. I
want the truth for each. I don't want to 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
<bkardell> what constitutes a 'tv' here?
<bkardell> seems like a weird term of distinction?
AmeliaBR: That's important consideration. MQs are saying when you
render video what are features going to be. Sensible use
case is on source elements in a video element that you're
using to pick correct source.
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 because TV isn't upgraded often content providers
want to provide correct content
AmeliaBR: bkardell asked in IRC 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.
chris: I don't see a down side. For most cases this is a bunch of
aliases
<fantasai> +1
astearns: Proposal: add the video prefix MQ and define how used in
bi-plane and non-bi-plane environments
gregwhitworth: sgtm
astearns: Objections?
RESOLVED: 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 summarizing 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.
AmeliaBR: 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
Media Queries publication
-------------------------
AmeliaBR: Who is doing edits?
gregwhitworth: I can take a stab at it
fantasai: MQ 5 right?
fantasai: We need a FPWD of MQ 5 at some point
<fantasai> https://drafts.csswg.org/mediaqueries-5/#contents
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 MQs. The potential amount of
changes in 5 people are experimenting with so FP would be
good
chris: Patent review is 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
<fantasai> Technically, the reference draft for patent review is the
latest WD published within 90 days after FPWD, fwiw.
CSS Fonts
=========
Don't require browsers to always match every generic font family to a
concrete font family
---------------------------------------------------------------------
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 because they have to be
mapped.
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
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
guarantee 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
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
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 to lose that
myles: I could move the must sentence 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.
* fantasai had same interpretation as chris
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 my mental
model of CSS1
AmeliaBR: Important is to update author guidance to 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 composite but allow users to change mappings for
languages so not sure how it falls back
myles: Proposal: Move the normative sentence 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
florian: I support this
* fantasai thinks if a cursive font exists on the system, it should
get mapped also
<AmeliaBR> https://github.com/w3c/csswg-drafts/issues/4442#issuecomment-547627749
astearns: Concerns?
astearns: 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 just 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't
do one
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 influence 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 a Mincho font in the
fallback you get the layout but with the wrong font metrics.
florian: That's not nice
myles: It's a separate topic
florian: Agree but we were getting there
AmeliaBR: It's worth a second issue specifically 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 one if my concern is
not there
astearns: Objections 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.
[ https://github.com/w3c/csswg-drafts/issues/4442#issuecomment-547627749
]
RESOLVED: 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
astearns: 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 discretion 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
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
oriol: Proposal in GH was a solution with 3 parts. 1) Say the
whitespace property applies to marker elements. 2) by default
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 line break 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
fantasai: Alternative is to define a new value pre-spaces that
preserves spaces but not line breaks. That would solve
problem of introducing preserved line breaks
fantasai: 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 line breaks 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 as !important so author
can't override until we figure out how outside markers are
aligned
astearns: Wondering if it makes sense to put on line breaks and use
pre and if you put a line break 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 line break 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
doesn'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
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 marker
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
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
<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)
<fantasai> AmeliaBR, text-space-collapse was a longhand of
white-space
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 line breaks until we
get to point of specifying 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't 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 undefined for inline. If behaves as everything else,
but is it inherits or from UA stylesheet?
AmeliaBR: Would like a decision on that because seems not as
dependent 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
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
AmeliaBR: Problem with outside markers is the whitespace property if
you insert a line break 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
line breaks 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 think we can do inline alone
fantasai: Trailing space is preserved. It needs to be value that
does not collapse
astearns: Can we resolve on whitespace applies to markers, there's a
UA stylesheet rule about blockified markers, and leave 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)
<fantasai> I was thinking pre-space or pre-spaces :)
astearns: Objections to: Take Mats 3 part proposal leaving value of
UA stylesheet in the air as a separate issue
RESOLVED: Take Mats' 3 part proposal leaving actual value of UA
stylesheet in the air as a separate issue to be determined
later
astearns: Thanks everybody and we'll talk next week
Received on Thursday, 5 December 2019 02:20:02 UTC