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

[CSSWG] Minutes Telecon 2019-07-03 [css-color-4] [css-lists] [css-content] [geometry] [writing-modes]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 4 Jul 2019 06:21:20 -0400
Message-ID: <CADhPm3u4CpVeQv0JYMQs4tOXgM_+Muo2OZqKa0NgFjHwLx0xOA@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.
=========================================


CSS Color 4
-----------

  - There was some confusion on what properties are included in the
      resolution for issue #3804 (Resolved: add the original list of
      colors from TabAtkins and fantasai as well as Field, FieldText
      and ActiveText). melanierichards will draft a PR for chris to
      review and add to the spec.
  - RESOLVED: Take what we're calling image-p3 in our spec and rename
              it to display-p3 (Issue #4056)

CSS Lists
---------

  - RESOLVED: Leave undefined for now and add a note explaining why
              [it's undefined] (Issue #4004: Should option/optgroup be
              able to set counters?)

CSS Content
-----------

  - RESOLVED: Add an 'auto' value (Issue #4074: Initial value of
              quotes should be auto)
  - The group was interested in discussing a more exact definition of
      the new 'auto' value to try and get an interoperable value that
      roundtrips.

Geometry
--------

  - RESOLVED: Add back in the overflow for DOMMatrix readonly to the
              DOMMatric constructor (FXTF Issue #346)

Writing Modes
-------------

  - Issue #4026 (Need to define the list of calculations that require
      a definite inline space) needs to be reviewed before the spec
      can continue its path toward REC.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jul/0000.html

Present:
  Rossen Atanassov
  David Baron
  Amelia Bellamy-Royds
  Oriol Brufau
  Tantek Çelik
  Elika Etemad
  Dael Jackson
  Dean Jackson
  Chris Lilley
  Cameron McCormack
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Lea Verou

Regrets:
  Rachel Andrew
  Tab Atkins
  Christian Biesinger
  Manuel Rego Casasnovas
  Christopher Schmitt
  Dirk Schulze
  Greg Whitworth

Scribe: dael

CSS Color 4
===========

Resolution Clarification for Issue #3804
----------------------------------------

  astearns: Let's get started
  <Rossen> I have one small topic - it is about this resolution here
           (https://github.com/w3c/csswg-drafts/issues/3804) Did we
           resolve to undeprecate ALL previously deprecated system
           colors or only the set required for High Contrast + the new
           ones required by Apple (smfr)
  astearns: Rossen mentioned an extra topic in IRC about high contrast
            and dark mode colors
  astearns: Does anyone know the answer to his IRC question?
  * fantasai can't see the question, has too much lag
  <Rossen> Yes, I just wanted a clarification to our resolution
  <Rossen> This resolution here
(https://github.com/w3c/csswg-drafts/issues/3804)
           Did we resolve to undeprecate ALL previously deprecated
           system colors or only the set required for High Contrast +
           the new ones required by Apple (smfr)
  astearns: Since no one has an answer on the phone I'll ask him to
            add a comment
  <astearns> Rossen: can you add a comment to that thread asking the
             question?
  fantasai: What was the question?
  fantasai: Ah.
  fantasai: Only resolve to undeprecate the ones listed in the issue,
            not all
  <Rossen> OK, thank you Elika. We will undeprecate the ones for High
           Contrast + the ones from smfr
  <fantasai> Rossen, not exactly -- we're going with the ones listed
             in the resolution

  astearns: Anyone else have extra items for the agenda?
  fantasai: If chris is here I have publication questions
  astearns: I don't see him in webex or IRC
  <fantasai> https://github.com/w3c/transitions/issues/142

CSS Text
========

Clarify whether soft breaks exist at boundaries of an inline element
    with `word-break:break-all`
--------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3897

  astearns: From last week. Sounded like we wanted to make progress on
            GH, but not sure if that happened.
  astearns: Is there anything we can do on the call or does it need
            time+comments?
  [silence]
  astearns: We'll come back to this

CSS Multicol
============

column-fill should behave more similarly in paginated and continuous
    contexts
--------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4036#issuecomment-506507437

  astearns: I think there was progress. Something we can resolve on
            here?
  dbaron: I wrote down my interpretation. What we need is Blink and WK
          impl feedback
  astearns: Any WK feedback on this issue?

  astearns: You suggested revert but that requires Blink and WK to
            agree
  tantek: Looks like smfr joined IRC at least.
  astearns: Are you on call smfr ?
  <smfr> no but myles and dino should be
  myles: I'm on, but nothing to say
  myles: No comment
  astearns: I'll remove agenda+ tag until we get feedback
  <smfr> I would have to digest this before commenting
  fantasai: Does that mean only waiting on WK?
  astearns: Both would be good.
  fantasai: Probably want to ask Morton.
  astearns: Fair
  astearns: I'll add a comment mentioning a few people to see if I can
            shake anything out in GH discussion

Publishing questions
====================

  astearns: I see chris is on IRC. Are you on call as well?
  fantasai: Can you [chris] get display published? Other question was
            about edits to css color L4 related to forced colors mode
  fantasai: There was confusion about that so might be good to get
            that edited in

  chris: Thing with display is there were duplicate IDs
  fantasai: I believe they're fixed
  chris: Cool
  fantasai: If not, ping me I will fix

  chris: astearns did we add renaming image back to display?
  astearns: On the agenda

  astearns: Other question about color L4 edits?
  chris: There's an open issues, is there a PR?
  fantasai: I can do edits if you want
  melanierichards: I can help submit a PR for this
  chris: That would help, sure. Thanks.
  dino: There's no GH for this?
  <fantasai> https://github.com/w3c/csswg-drafts/issues/3804
  fantasai: This is the one Rossen brought up.
  astearns: Issue #3804
  astearns: I haven't reviewed, is there a resolution
  fantasai: Yes.
  astearns: Only colors in issue itself
  fantasai: In the resolution, yeah
  astearns: We'll wait on a PR

CSS Lists
=========

Should option/optgroup be able to set counters?
-----------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4004#issuecomment-506906199

  astearns: We left it at fantasai and TabAtkins suggesting we punt on
            replaced elements for now
  <TabAtkins> Yes
  fantasai: Dug into issue a little. Seems like figuring out what's
            going on for form controls is a mess. To get spec to
            reflect reality we figured fine for spec to leave it
            undefined.
  fantasai: Want to check with WG if really want to dig into the issue
  heycam: I think need to do at some point, but okay undefining it for
          now. At some point need to consider alternate presentations
          of certain elements like select and what it means to allow
          UAs to have CSS based and nonCSS based presentations.
  heycam: Make sure counters and anything else makes sense in presence
          of presenting these in different ways

  astearns: Given we have 1.5 impl that reset counters and option/
            optgroup are the most list-like would it make sense to
            define those and leave reset?
  fantasai: Could. Want to move to a world with more styling rather
            than less. Makes sense elements with some visual
            representation can handle counters. No reason they can't
            manipulate counters. I don't feel strongly this is
            important to solve right now. Happy to leave undefined and
            let implementations merge toward more things being
            countable
  AmeliaBR: Specific behavior for option/optgroup the inconsistencies
            with counters are related to other styling
            inconsistencies. Getting a proper model for explaining how
            option/optgroup and selects in general work for display
            trees would be useful. Special rules for counters without
            whole model might make more complicated
  heycam: Counters are special because can effect things without.
          Separate from general stylability in that way. Seems we
          could solve counter issue independent in terms of should be
          observable outside the select so counters increment
  heycam: Am I right that if counters increment inside you can see it
          outside?
  fantasai: Yeah
  astearns: In some browsers it has effect, in others it does not
  heycam: Agree with fantasai might not be super important. Does seem
          like a discussion we can have about if it's acceptable to
          make UAs that don't have CSS based and therefore boxes
          should do something else to inc. counters
  fantasai: I think cases where this shows up is test cases. I can
            image using counters within select box but not referencing
            them outside. Given not sure how this impacts impl
            architecture. I'm leaning to undefined and let them
            converge. I don't think we should spend effort getting
            impl to align. If there's a use case later we can add it.
            That's why I advocate leave undefined. What impl doing is
            probably fine for now

  astearns: What if we resolve to undefine at this level and add a
            note we're doing this because no interop and don't have a
            use case guiding to the right direction
  fantasai: More no use case to spend engineering effort to align.
            Right direction for authors is honors counters. That's
            what they would expect and it's reasonable. Don't think it
            matters in this strange case
  astearns: Just having a note why we're leaving undefined.
  fantasai: I can have a note that there's no interop and we don't
            think it's important to get interop so we're leaving it
            undefined

  astearns: Any further arguments to not leave undefined?
  tantek: Can we live with this being a compat issue where we have to
          become compat with whatever Chrome does?
  astearns: Are you aware of any Gecko bugs currently?
  tantek: I don't. I believe that us leaving undefined in the long
          term means it'll end up being a compat issue with Chrome. If
          we can live with what Chrome does eventually spec may have
          to specify that behavior.
  AmeliaBR: Given it's lack of feature in dominant browser I don't
            know if that argument is that strong. I don't think people
            will rely on counters not working in optgroups. There
            might be a zombie CSS issue if it ever works but that's
            not major web compat argument.
  tantek: Okay

  astearns: Proposal is leave undefined for now and add a note
            explaining why
  astearns: Objections?

  RESOLVED: Leave undefined for now and add a note explaining why

CSS Color
=========

Predefined colorspaces (renaming image-p3 to display-p3)
--------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4056#issuecomment-505993145

  <chris> I looked into the edit history, there were a number of
          changes from dci-p3 to where we are now. Rik was the main
          contributor; there was discussion on the commits. See for
          example
https://github.com/w3c/csswg-drafts/pull/557/commits/644c4c49b86d97bb59bf74e533bdfbe339f3d176
  chris: Looked at this. When originally put in spec confusion between
         dci-p3 and what Apple used. I originally called it dci-p3 and
         that was wrong for many reasons
  chris: Thought we had a resolution, but can't find it. Went through
         edit history and it went through name changes. I'm happy
         changing to to what everyone knows it as
  dino: My memory is not great. At some point I posted the profile for
        it given the idea it can be linked form the spec. I'm in favor
        of display-p3. Also willing to add another named to dci-p3 but
        I don't think there's a need
  chris: I don't think there is. dci-p3 has strange greenish white and
         designed for use in digital cinema. Not appropriate for web
  dino: That's the main driver for Apple creating what we call
        display-p3
  tantek: You said because it's designed for dark environments it's
          not appropriate for web
  dino: Pitch black rooms
  tantek: People do use the web in dark rooms
  dino: This is just the convenience method. You can get the same
        result using display-p3. It just happens to have been
        calibrated for different env.
  tantek: Is that calibration not useful when looking at web in the
          dark?
  dino: If you're writing to be used in something like a cinema sure
  astearns: That's an argument to add dci-p3, but this is about what
            do we call the thing that we know is not dci-p3 and we
            want to support it

  AmeliaBR: Adding separate profile can defer until demand. There is
            demand to match the thing Apple does. If the definition is
            match Apple then we should match the name unless there's
            trademark reasons
  dino: Nothing Apple specific about this other than we gave it a
        name. That's why I posted the file. There's nothing secret or
        protected about this
  chris: Given that I would like to call for resolution
  astearns: I could not find reason why we changed from display-p3 to
            image-p3. There's some discussion about how web isn't only
            for displayed, but not terribly compelling.
  astearns: Proposal: Take what we're calling image-p3 in our spec and
            rename it to display-p3
  astearns: Objections?

  RESOLVED: Take what we're calling image-p3 in our spec and rename it
            to display-p3

  dino: Anything we can do in CSS to stop people from using their
        phone in a cinema? ^_^
  astearns: Happy to follow the incubation process

CSS Content
===========

Initial value of quotes should be auto
--------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4074

  heycam: Commenter is happy with deciding or not on call
  AmeliaBR: Request is a new value auto to be clear. This is language
            sensitive default
  dbaron: I think that's the idea
  dbaron: Idea is that WK and Blink use an initial value that is not
          something they can serialize that triggers language
          dependent marks. Would like to do in Gecko, but want to be
          able to serialize and roundtrip
  AmeliaBR: I think this is something authors would want to use. Might
            not need to set explicitly if it's sensible default.
  heycam: Can use initial to get this unserializable value

  astearns: Is reason because no one wanted to impl auto in past?
            Reason why we did not do this previously?
  dbaron: I don't know. I do know it used to be the spec acted as
          though you would write all language dependent values in CSS
          in UA stylesheet. Some have non-speedy selectors and it's
          better to impl in not-CSS and more direct data from CLDR
  AmeliaBR: In spec have a 'depends on UA initial value'. Not great
            because means no interop. Sounds like in some UA depends
            on more than a single value. Having an auto value and the
            UAs that have a simple initial value auto can resolve to
            the initial value

  florian: Auto and initial value for language reasons is reasonable.
           Are you considering specifying what the behavior is or is
           it meant to be impl dependent?
  AmeliaBR: Good question. Should we define auto needs to be sensible
            language based
  dbaron: Could be more precise depending on interop situation. Worth
          follow-up investigation. Worth coming up with more specific,
          but no one has that written down right now
  florian: If we define what it is eventually I support auto value
  myles: Having the initial value be auto is a good idea. Should do it

  astearns: Having rough consensus for auto value that is for now impl
            dependent but it serializes well
  <fantasai> https://html.spec.whatwg.org/multipage/rendering.html#quotes
  fantasai: HTML spec, I believe this is out of CLDR. Has a definition
            for quotes. Seems to be all we're asking for is an auto
            value with this behavior built into it. So UA stylesheet
            just says auto and have this behavior. So we have a
            definition. Might want to update the definition but not
            defining from scratch
  AmeliaBR: Sounds good. Simplify UA stylesheet. Integrate into CSS.
  fantasai: None of these selectors are HTML specific
  AmeliaBR: But for default HTML @namespace.
  fantasai: We can drop the @namespace
  AmeliaBR: Either way making it defined in CSS rather than HTML means
            defined for all CSS applications
  myles: Should allow for other browsers to change CLDR rules.
         Shouldn't say must adhere to exactly what CLDR says
  florian: Do you have specific ways you want to differ from CLDR or
           just fundamental principle?
  myles: I'm sure we have tweaking. Lots of designers and language
         experts that have many different opinions in our company.
         Don't have specific example off the top of my head

  astearns: Aside from question of defining exact behavior of auto,
            does anyone object to adding an auto value?

  RESOLVED: Add an 'auto' value

  astearns: I'm open to figuring out if we can define this. Would be
            good to have specific proposal, not just pointing to
            another spec ans saying copy. If someone wants to define
            auto more closely good to open a new issue with a
            proposal. Sound okay for everybody?
  heycam: Yeah

Geometry
========

DOMMatrix constructor is a performance and code portability footgun
-------------------------------------------------------------------
  github: https://github.com/w3c/fxtf-drafts/issues/346

  astearns: krit sent regrets. TabAtkins said makes sense.
  chris: [missed] said he didn't need to be in discussion and happy
         with what we agreed
  astearns: Proposal was [reads]. I don't entirely understand it.
  AmeliaBR: I don't entirely understand it either. Right now the
            constructor allows either a string or an iterate-able
            object. In certain environments if you pass another matrix
            object as a parameter it gets serialized to a string and
            reparsed and act like it works. In others it won't happens
            and it throws. Concern this is bad
  AmeliaBR: Not sure why sometimes serialized and not others
  AmeliaBR: Request is support another constructor overload that you
            can construct any matrix by copying values of another
            matrix object
  heycam: Don't understand why it is worker throws exception
  dbaron: I suspect some serialization or parsing code not exposed to
          workers.
  <dbaron> yeah, the stringifier is Window-only
  AmeliaBR: If behavior in a window is it serializes and parse back
            again it doesn't sound efficient. Direct cloning is more
            efficient
  dbaron: Difference is because stringifier is DOM only.

  dbaron: There's consensus in issue. Asking WG to declare that
  astearns: I don't see anyone saying it's a bad idea to revert the
            change
  dbaron: And it's part of a change being reverted, not the entire
  heycam: I also don't understand underlying motivation of removing
          overloads in general

  astearns: Proposal: Add back in the overflow for DOMMatrix readonly
            to the DOMMatric constructor
  astearns: Objections?
  AmeliaBR: Question- do we have multiple implementor consensus?
  astearns: I see Blink and Gecko in comments
  AmeliaBR: Probably okay unless someone from WK objects

  RESOLVED: Add back in the overflow for DOMMatrix readonly to the
            DOMMatric constructor

Writing Modes
=============

  astearns: 2 weeks ago talked about pushing Writing Modes forward.
  astearns: florian you were going to file and issue on Gecko?
  florian: I have not, but dbaron raised an issue about part of spec
           in question. Someone who is not me, probably fantasai or
           koji, should look. Filing an issue while considering
           changing the spec is not best time.
  <fantasai> I think the issue was asking for clarification
  <fantasai> Not a change particularly
  florian: I have not given up on pushing writing modes forward. For
           people that understand writing modes, looking at dbaron's
           issue is a good idea
  <dbaron> https://github.com/w3c/csswg-drafts/issues/4026
  florian: That's the one; dbaron just posted

  florian: fantasai, koji, and others if you can look it would be good
  astearns: Thanks. I will ask again next week for what progress we've
            made. If the issue has baring on test results we can get
            that sorted.

  astearns: Anyone have anything else to do in last 7 minutes?
  astearns: We're done. Thanks everybody and talk to you next week!
Received on Thursday, 4 July 2019 10:22:25 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 4 July 2019 10:22:26 UTC