W3C home > Mailing lists > Public > www-style@w3.org > December 2019

[CSSWG] Minutes Telecon 2019-12-04 [resize-observer] [css-colors-5] [media-queries-5] [css-fonts] [css-lists]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 4 Dec 2019 21:19:30 -0500
Message-ID: <CADhPm3vjafzXt5=gFp67YPueNjmh=pMRXN3zJ9Zg_+V=AsiasA@mail.gmail.com>
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.


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


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Dec/0007.html

  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

  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


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
  <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
  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
  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
  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
  chris: I don't see a down side. For most cases this is a bunch of
  <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
  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
  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
  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
  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
  myles: They interact. You found the corner case where it is
  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
  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
  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
  <fantasai> AmeliaBR, text-space-collapse was a longhand of

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

  astearns: Thanks everybody and we'll talk next week
Received on Thursday, 5 December 2019 02:20:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:14 UTC