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

[csswg] Minutes Telecon 2019-06-19 [css-writing-modes] [css-display] [css-grid] [css-color-adjust-1] [css-lists] [css-inline-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 20 Jun 2019 05:20:38 -0400
Message-ID: <CADhPm3uiEKQtJUx7yOE2wRW6t01CofShCDEse-hf4VPos7cOhQ@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.
=========================================


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

  - Coming out of the F2F there is a push to get Writing Modes to REC
      status. Before next week's telecon, there will be follow-up done
      to check into getting Mozilla to conform to a change in the spec.

CSS Display
-----------

  - RESOLVED: Republish Display

CSS Grid
--------

  - RESOLVED: Accept change in
https://github.com/w3c/csswg-drafts/commit/5a43ab7210d08c9a012a7697eb39a382f8133079
              (Issue #3694: How to distribute space using flex ratios
              when the sum is 0?)
  - RESOLVED: Accept change in https://github.com/w3c/csswg-drafts/issues/3693
              ("Maximize Tracks" shouldn't distribute equally for
              flexible tracks)
  - RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/3683
              (Don't expand flexible tracks under a min-content
              constraint)

Color Adjust
------------

  - The group will wait a few more weeks to see if anyone has a
      concrete proposal to handle the concerns in issue #3880 (Combine
      forced-color-adjust and color-adjust properties somehow?). If
      there's no proposal the group will close the issue no change.
  - RESOLVED: Computed value of color-scheme will match its specified
              value (Issue #3848: Disallow repetition of color-scheme
              keywords?)
  - Before deciding if multiple color-scheme <meta> values should take
      the first or the last value (Issue #3846) TabAtkins will
      investigate if other <meta>s do first or last. This will allow
      the group to see if this is something that can be standardized
      so authors don't have to try and remember which <meta>s behave
      which way.

CSS Lists
---------

  - The group generally agreed that option/optgroup should be able to
      set counters (Issue #4004) though there were concerns about how
      it would interact with things like display:none. TabAtkins and
      fantasai will come up with proposed spec text for the group to
      review and debate.

CSS Inline
----------

  - The group would like `text` of `leading-trim` to be interoperable
      (Issue #3978) but there were concerns that browsers aren't using
      the same tables for calculations so interoperability may not be
      possible.
  - At a higher level there is a desire to make new font functions
      handled the same for all browsers and OSs even if older values
      cannot be.
  - The group ran out of time so discussion will continue in the
      GitHub issue


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

Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jun/0002.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  Amelia Bellamy-Royds
  Christian Biesinger
  Benjamin De Cock
  Elika Etemad
  Koji Ishii
  Dael Jackson
  Brad Kemper
  Rune Lillesveen
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Anton Prowse
  Florian Rivoal
  Alan Stearns
  Lea Verou
  Eric Willigers

Regrets:
  David Baron
  Oriol Brufau
  Dave Cramer
  Brian Kardell
  Manuel Rego Casasnovas
  Melanie Richards
  Jen Simmons
  Greg Whitworth

Scribe: dael

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

  astearns: We've got all writing modes folks. At F2F I was told it
            was a week to get writing modes to rec
  florian: It was a full time week of work, not a calendar week. Also
           with some assumptions that need to be verified
  florian: Assumptions are there's one thing that needs to be checked
           for Gecko conformance. Sent an email to dbaron but haven't
           seen if he replied
  astearns: Is there an issue for Gecko?
  florian: dbaron did reply but I haven't read. There are failing
           tests for Gecko, but don't know if there's an issue
  astearns: Let's get back next week call or through github issues.
            Like to make sure there's an issue logged for changes in
            Gecko if that's the case

  fantasai: I should spend time next week digging through impl report.
            5 second look we had failing tests due to broken tests so
            some work will need to go into that. Don't know how much
  astearns: Could I ask you to start that this week?
  fantasai: I'm at AB meeting so no
  astearns: By next week I'll expect to hear from florian about
            Mozilla issue. Then we can decide how much we can get done
            after that. I want to make steady work on this week to week
  florian: Anyone hears this is 40 work hours with no one being paid
           to do it.
  astearns: And that needs to be solved.
  <dbaron> fwiw I filed https://github.com/w3c/csswg-drafts/issues/4026
           in response to Florian's email

  astearns: Anything to add or change in agenda?

CSS Display
===========

Parent box of run-in or non-principal box
  github: https://github.com/w3c/csswg-drafts/issues/3158

  fantasai: Trying to load this. I suspect this issue is just
            verifying something
  astearns: This is where you asked for repub so maybe this should be
            the last.
  fantasai: I think we brought this in F2F when requested publication.
            I think we reviewed
  astearns: And there are changes from a month ago. No changes to spec
            since F2F
  fantasai: I think when we resolved to publish it was including these
            and we forgot to remove agenda+
  astearns: We did resolve to republish a month ago?
  fantasai: Yeah
  astearns: It's just not in this issue.
  astearns: That was display.
  fantasai: Yes, we don't have resolution for grid. Do for display
  astearns: Should we re-resolve to publish display?
  fantasai: I think resolution was in F2F but we can do it again
  astearns: Objections to republish Display?
  astearns: There's a DoC and a diff
  <chris> sounds good to me

  RESOLVED: Republish Display

CSS Grid
========

How to distribute space using flex ratios when the sum is 0?
------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3694

  fantasai: This was we forgot to handle divide by 0 case when
            dividing. Minimal fix to only do that if the sum is >0. If
            sum is 0 we distribute space equally
  <fantasai> https://github.com/w3c/csswg-drafts/commit/5a43ab7210d08c9a012a7697eb39a382f8133079
  fantasai: diff^
  fantasai: Refers to how we split up space for intrinsic track sizes.
            Have to distribute space even though it's flex 0. If there
            are flex ratios we can use we do. If they're all 0 we
            can't divide so we say do equally in that case
  astearns: Any comments?

  astearns: I don't see in diff anything about distributing equally
  fantasai: [reads]
  astearns: Alright so default case is in previous text?
  fantasai: Yes.
  astearns: Objections?

  RESOLVED: Accept change in
https://github.com/w3c/csswg-drafts/commit/5a43ab7210d08c9a012a7697eb39a382f8133079

"Maximize Tracks" shouldn't distribute equally for flexible tracks
------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3693

  fantasai: This was another fix for errors
  fantasai: There was a statement where we made a mistake saying treat
            max sizing same as min sizing. Trying to select a class of
            tracks and didn't use the right words.
  astearns: Okay
  fantasai: Just fixing an error. Happy is people want to look at it
  astearns: Given issue discussion looks correct. oriol said it looks
            good
  fantasai: These were co-edited with oriol so he thinks they're
            correct
  astearns: Comments on this change? Objections?

  RESOLVED: Accept change in https://github.com/w3c/csswg-drafts/issues/3693

Don't expand flexible tracks under a min-content constraint
-----------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3683

  fantasai: Case where spec forgot to consider min content correctly.
            Implementations do logical and don't expand track to take
            up space. Changing spec to match implementations and do
            thing you expect which is size to smaller end when under
            min-content constraint.
  fantasai: If you can shrink something down without overflow then
            min-content constraint should be that amount and not
            bigger. Spec violated concept, implementations did
            correct. Trying to match them up
  astearns: Any comment? I note you asked for TabAtkins or Rossen to
            comment
  fantasai: I'd prefer to get their +1
  TabAtkins: I'll review shortly

  astearns: Resolve or wait on review?
  TabAtkins: I trust fantasai so resolve. If I find a mistake I'll say
             something
  Rossen: On the same page. Proposed doesn't seem crazy, just need to
          look at overall algorithm fit. I'm sure fantasai spent more
          cycles so I trust her
  astearns: Other comments?
  astearns: Objections to this change?

  RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/3683

  astearns: All three of these look like they need tests or need tests
            verified. Have there been any?
  fantasai: None in wpt yet. I'll check with oriol and he might know
            more
  astearns: TabAtkins as you review can you check in tests?
  TabAtkins: Sounds good

  astearns: Once we have tests anything to keep us from updating CR?
  fantasai: Probably tests for other things. I think most that should
            be fixed is but there might be one or two not.
  astearns: I suspect no DoC yet.
  fantasai: Right. Bulk of work is that and changes section
  astearns: Anything else on grid?
  fantasai: I'm going to say no

Color Adjust
============

Combine forced-color-adjust and color-adjust properties somehow?
----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3880

  astearns: Was on F2F, didn't get to it.
  fantasai: I think this would have been better at F2F. I don't know
            if there's anything for call. We need a concrete proposal
            to discuss on a call that handles this issues
  fantasai: If anyone is interested keep track of issue. Someone needs
            to make a proposal before we can move forward

  astearns: Anything else before we punt?
  AmeliaBR: I have a rough proposal in the issue. More I think the
            more I think it's not worth it. I would be comfortable
            resolving no change but we can leave the issue open
            pending a good proposal
  chris: I think they're better separate. dbaron comment is on the
         money there
  astearns: fantasai think we should close no change?
  fantasai: I'd give another couple weeks to see if we can solve
            dbaron concerns and if not we close it.
  astearns: Any other comments?

Disallow repetition of color-scheme keywords?
---------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3848

  TabAtkins: For future extensibility we allowed arbitrary keywords
             and they're ignored. Question is what happens when you
             repeat color-scheme keyword? We don't want to disallow,
             but do we keep it in computed value? Collapse along the
             way?
  TabAtkins: No strong argument either way
  TabAtkins: Originally thought there was an efficiency argument but
             that's not true if trying to preserve unknown. I think
             conclusion is keep the same and don't simplify.
  TabAtkins: Just have computed value = specified value

  astearns: Any comments?
  <futhark> I’m fine with either, it’s just that dropping duplicates
            means having to keep track of them during parsing
  <futhark> Which requires a hash map or something
  astearns: So close no change?
  TabAtkins: I don't recall current state
  TabAtkins: Let me look
  TabAtkins: It would be changing spec
  astearns: That computed is same as specified value
  TabAtkins: Yes
  astearns: Objections to computed value of color-scheme match its
            specified value?

  RESOLVED: Computed value of color-scheme will match its specified
            value

What happens with multiple <meta>s?
-----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3846

  TabAtkins: Meta name = color-scheme lets you set initial
             color-scheme so we can get that value out quick. What
             happens if you use multiple? Two obvious options are take
             the first or take the last valid one. Precedent both ways
  TabAtkins: I propose we take the first so we get the value as
             quickly as possible so don't have to wait for rest of
             page to load before we apply effects
  AmeliaBR: Since whole point of meta is to get it asap it does make
            sense. We have examples in HTML that are consistent
  TabAtkins: theme-value also takes the first so it's consistent
             that way

  fantasai: I would consider multiple to be an error case. If you're
            flipping colors constantly that's your fault. I think it
            benefits authors if we're consistent and agree with smfr
            it should be one rule for all meta tags
  fantasai: Given oldest is viewport that means using last one
  TabAtkins: Using last for viewport gives the bad behavior you
             listed. I think viewport fell out of viewport defined as
             equivalent to a stylesheet
  fantasai: It's an error case. If author wants correct they should
            not put multiple. I think it's fine if broken isn't
            correct. Consistent story for authors is more important
            that it's always last. Arbitrariness is more disruptive
            then having to keep all the things
  TabAtkins: But if we have to take last, we can't render until have
             downloaded enough of HTML. I agree with consistency
             argument. I'd like to be consistent with first and see if
             we can adjust viewport.
  fantasai: If you want to go that route it's fine. I think it's
            important we're consistent. If you want to see first is
            web compat that's good.

  astearns: Sounds like we already have different. I'm concerned about
            hitching consistency to viewport given comment from
            futhark that viewport is last one inserted into doc.
  TabAtkins: Yeah, ours is messed up. We should not rely on viewport
             behavior

  smfr: Before that comment I was reluctant on viewport. Changing
        viewport now does have more web compat concerns. I would love
        all meta tags to have same. Need to figure out dynamically
        inserted nodes
  smfr: UA might not process meta tags until end of head. Just because
        you have multiple doesn't mean you'll see flashes, UA can wait
        until end of head.
  TabAtkins: Certainly can, but end of head could be different packet
             and flush the queue. Definitely different behaviors
             allowed.

  myles: Procedurally meta tag is defined in HTML. If we decide
         something here is there anyone that can make edits to resolve
         this?
  <AmeliaBR> We are currently defining the meta value:
             https://drafts.csswg.org/css-color-adjust-1/#color-scheme-meta
  TabAtkins: Should try and get agreement on consistent behavior and
             get that into general meta authoring guidelines
  astearns: But this needs to be specified elsewhere
  TabAtkins: Yes, actual definition is in HTML. They are deferring to
             us on this since we're defining it
  astearns: I'm assuming that for web compat reasons we're not going
            to be able to change current viewport. Given that would
            anyone object to spec that the color-scheme meta will
            match theme-color and take first one found?
  smfr: What happens with other meta like char-set?
  TabAtkins: I do not know. But those are also more super legacy and
             likely to be weird
  astearns: Would be nice to have answer
  smfr: Agree.

  fantasai: Don't want to resolve without jensimmons or rachelandrew
  astearns: Fair
  fantasai: I believe impact to author is bigger concern then get the
            earliest possible
  TabAtkins: We've got 2 css things that are inconsistent so we'll
             have to change something. Maybe we have a new policy and
             legacy is legacy.
  fantasai: If it's completely inconsistent and we can't align I'm
            fine with a going forward policy. If it's possible to
            align them all we should go that way
  <fantasai> Or even to align most of them
  astearns: TabAtkins can I ask you to do survey of meta tags that
            effect css?
  TabAtkins: Looking at it. It's a consequence of algorithm and not
             stated in spec so I'm chasing it down
  astearns: Let's wait on this issue until we get the survey and
            comments from authoring advocates. Sound good?
  TabAtkins: mmhmm

  <rachelandrew> I'll take a better look at issue 3846 and see if I
                 have any thoughts from the authoring pov.

Multicol
========

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

  rachelandrew: Is dbaron on? He'll be needed
  florian: I think I can represent
  rachelandrew: There was a comment from Morten. Maybe worth waiting
  astearns: Thanks florian but better to move on

CSS Lists
=========

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

  TabAtkins: Technically per CSS they are descendant of replaced so
             don't generate boxes. If continuing the current
             resolution that counters work on box tree there's no box
             to let them set or change counter. However FF and
             previous Edge allow it. Chromium does not
  TabAtkins: There are use cases for this and a chromium issue to fix
             and allow setting of counters.
  TabAtkins: Chrome devs discussing if they should, but no conclusion
  TabAtkins: This may effect related issues like if SVG elements can
             set counters.
  TabAtkins: We need to figure out exact terminology. fantasai's
             proposal is go one level up to also things that are like
             boxes, but not css boxes for layout terms and allow those
             to host counters.
  TabAtkins: I'm fine with that. Proposal is allow optin/optgroup and
             other things that are like boxes outside the css model to
             effect counters
  astearns: sgtm
  AmeliaBR: Makes sense. I'd like a more explicit definition to what
            is and isn't like a box
  TabAtkins: I prefer to define a new term other specs could hook and
             we define what that is for HTML and SVG. Other markup
             languages could say they are that thing even though they
             don't generate css boxes

  astearns: Other comments?
  smfr: Sounds a little confusing for interactions with display:none.
        If you have optgroup that contributes to counters and you
        display:none it does it still contribute?
  TabAtkins: I don't think display:none does anything to optin
  smfr: If you have one of these how do you stop contributing to
        counters
  TabAtkins: You don't set the counter. the display:none wasn't an
             intentional choice, it was legacy
  smfr: Sounds like it will complicate code to determine what
        contributes to counters. May be odd interaction with other
        properties is what I'm saying
  fantasai: I kinda disagree, I would expect display:none to have
            effect on counters. You're processing css properties and
            counters is one of them. I don't have strong opinion
            on this
  <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7018
              apparently 'display' does work on <option> in Chrome...
  TabAtkins: If someone with FF or older Edge can check that link I
             want to see if display has effect in other
  smfr: [missed]
  <futhark> Display:none affected in firefox
  <smfr> webkit shows the ‘bar’ in the testcase
  <futhark> that is, removed from select rendering
  <smfr> filed webkit.org/b/199011

  Rossen: We do not support counters inside of display:none. Only time
          we did something more interesting is if gCS was called
          inside and we'd have something to calculate in the sub tree.
          I think we backed it out because it was fragile
  fantasai: I think proposal is that anything that is a replaced
            element has nothing to do with counters or we have
            something represented in render tree and not display:none
            and they can have counters
  astearns: Either way implementations would need to change because
            we're not interop
  TabAtkins: Yeah
  TabAtkins: And we're buckwild with what styles can effect inside a
             select
  fantasai: If we have an idea we want to do this how about TabAtkins
            and I come up with specific wording that deals with the
            issues brought up here. We can bring it back and think
            about how it effects different impl
  astearns: Objections to that path?

  ACTION TabAtkins and fantasai develop spec text for
         https://github.com/w3c/csswg-drafts/issues/4004
  <trackbot> Created ACTION-881

Counter scopes should be based on box tree, not element tree
------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/674

  TabAtkins: fantasai added the agenda. I'm curious why. There's a
             person asking about implications but don't know what to
             discuss
  fantasai: I don't remember
  astearns: We have a comment with different cases
  TabAtkins: I need to look through his HTML cases to figure out what
             they're trying to favor. I think we have to defer for now
  astearns: My reading is here are the cases that show a difference.
            Not sure they're picking a side

  <fantasai> I think the issue was
https://github.com/w3c/csswg-drafts/issues/674#issuecomment-333541595

CSS Inline
==========

Make `text` of `leading-trim` interoperable?
--------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3978

  astearns: This is F2F leftover
  koji: The leading-trim has text representing text-top and
        text-bottom. text-top and text-bottom isn't browser interop or
        even on same browser across OSs. prop is to define. One
        proposal is to use specific ascender and descender. Another is
        em height. This isn't defined in CSS but algorithm is from
        gecko
  koji: Seems to do a good job for non-tall scripts
  fantasai: I don't think I agree with a platform text value for this
            metric. I think people looking to trim are looking for a
            particular value. Does make sense to have other two,
            ascent, descent and em height. If we want to define an
            existing keyword to do that or add a new I'm less sure
  fantasai: Interesting question of these metrics which do we want

  myles: Like to not parse tables myself. Likely look up the
         functions. not sure if that defeats purpose.
  fantasai: It means you can't read the sTypo metrics?
  myles: Can but takes a lot of code to get the table and figure out
         the values and convert
  koji: If you call core text ascendant and descendant aren't interop
  myles: If there was a interop field we property would just hook that
         field up to core text field which defeats purpose of interop
         field so that's unfortunate

  koji: Clarify, the division of leading trim where authors use
        webfonts so it's the same binary on all platforms and
        browsers. If they use font-top they see different layout
        result. For this property I think having the same result for
        same font value is quite important
  <fantasai> +1 to koji
  astearns: Your last comment is that if for whatever reason web font
            is serving two values typo text won't be interop if
            metrics are different in font files. We're looking for
            interop if same font files is served.
  astearns: I don't know if it's the case that if you have the same
            font file that the different text rendering systems will
            us OS2 table data
  chris: Probably not. Was the case that they all used different tables
  astearns: So even if we do spec that you have to get data out of
            font file we'd still end up with bad interop due to
            different text rendering
  koji: Could be differences of rounding. Most of difference in font
        metrics comes from open type fonts having 3 different metrics
        and each platform uses different of 3. If browsers use same
        metrics should be interop
  astearns: I'm not sure browsers are using same metrics
  koji: Blink we use same metric as one platform uses. Even if same
        web fonts blink uses different metrics depending on platform
  koji: We rely on platform API to read metrics
  <fantasai> And this drives authors crazy

  myles: meta question- if we resolve on this to have interop do you
         expect to apply this to other css properties. Like we'd have
         to implement new type system to get interop or is this one-off
  koji: At least for new things I'd like interoperable ones. Some
        reasons we may need existing ones, legacy reasons or future
        platform behavior. in those cases I'm fine to provide options.
  <fantasai> +1

  astearns: Should we continue later since we're at time?
  myles: Good idea
  astearns: Let's continue in GH and we'll come back
  astearns: Thanks everyone and we'll talk next week
Received on Thursday, 20 June 2019 09:21:47 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 20 June 2019 09:21:47 UTC