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

[CSSWG] Minutes Telecon 2019-06-26 [css-syntax-3] [css-multicol] [css-text-decor] [css-text] [fill-stroke] [filter-effects] [css-color] [css-backgrounds-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 26 Jun 2019 19:26:41 -0400
Message-ID: <CADhPm3trk2epH0V1vOpB-4RsObJg6nq4hna-Xr-Tae+0tKjM5w@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 Syntax 3
------------

  - There is a resolution to republish already, all that's left to do
      is update the DoC before sending the request

CSS Multicol
------------

  - The proposal to have column-fill behave more similar in paginated
      and continuous contexts (Issue #4036) ran into conflicting
      compat concerns where one solution would break pdf viewer to
      print and the other would break webpage to print scenarios.
  - On the call the group agreed that the way to solve both compat
      concerns is to rollback the resolution in Issue #3224 (Improve
      column-fill and make it backward-compatible). Not everyone
      involved in the discussion of both 3224 and 4036 were on the
      call so discussion will continue on GitHub.

Text Decoration
---------------

  - RESOLVED: Update the spec so positive offsets are outward from the
              text (Issue #4021: text-decoration level 4 clarification
              on text-underline-offset positive/negative lengths)
  - myles mentioned that in Safari's implementation of
      text-underline-offset there was a clamp so that the underline
      didn't go so high that it looked like a strikethrough. The group
      was interested in getting this, and possibly not letting to get
      too low, into spec text. Issue #4059 was filed to further refine
      this proposal.

CSS Text
--------

  - There's still not clear winner to decide Issue #3987 (Clarify
      whether soft breaks exist at boundaries of an inline element
      with `word-break:break-all`). fantasai will reach out to the
      i18n working group to see if they have input.

Fill-Stroke, Filter Effects & Color 4
-------------------------------------

  - RESOLVED: No change to spec [opacity can take a percent] (Issue
              #3342: percentage opacity)

Backgrounds & Borders 3
-----------------------

  - RESOLVED: No change to spec [computed value includes missing
              autos] (Issue #2574: Computed value of background-size
              includes missing autos)
  - There needs to be a note in a centralized location clarifying that
      computed value is not the same as specified values and detailing
      the different purpose and usage.

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

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

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Oriol Brufau
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Dael Jackson
  Brian Kardell
  Peter Linss
  Nigel Megitt
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Greg Whitworth
  Eric Willigers
  Fuqiao Xue

Regrets:
  Christian Biesinger
  Alan Stearns

Scribe: dael

CSS Syntax 3: Should we update the CR, or is there anything else we
    should do before the update?
-------------------------------------------------------------------

  Rossen: There was a ping for updated CR
  Rossen: Looking through GH and issues doesn't seem to be open ones.
          Anything holding us back from republish?
  TabAtkins: No and I think we have a resolution I haven't gotten to it
  fantasai: We have DoC and changes section and tests you wanted to
            write?
  TabAtkins: Have tests. Haven't written DOC but it's in github and
             tagged correctly so it'll be copy/paste. Changes is up to
             date
  Rossen: Sounds like there's staff willing to help if things are ready
  Rossen: Since we have a resolution no need for a new one. Just a
          nudge to you TabAtkins

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

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

  Rossen: Opened by dbaron. Is he on?
  [silence]
  Rossen: Can anyone take or should we wait?
  florian: I can
  florian: There is currently a difference between what happens to
           columns in fragmented and non-fragmented context and
           there's no constraint on height
  florian: dbaron proposed to align fragmented context to
           non-fragmented
  florian: My reason why not is that the behavior specified in
           fragmented context is the one pdf and print formatters
           implemented interoperably. multicol in fragmented documents
           is used a lot.
  florian: If there wasn't a compat concern we could align but in
           print we do have a dependency. I don't think they'll change
           and I don't want to fork language. Based on that I suggest
           don't
  dbaron: Important difference is in browsers people care about print
          being similar to on screen. If we leave this we end up with-
          for multicols that happen to be in fragmented context and
          don't fragment or for the last fragmented of a multicol in
          fragmented context- you get different balancing then on
          screen. Problematic. Mostly for when you print and it's not
          fragmented and balancing on paper is different.
  <fantasai> So basically we have two different, conflicting compat
             constraints. :/

  <AmeliaBR> Is “make browsers match print behavior” (for the last
             fragment OR for no fragments) still an option?
  Rossen: dbaron to visualize I'm assuming talking about multicol that
          has auto balance and in the continuous space you have plenty
          of height so no balance
  dbaron: Yeah
  Rossen: In print when we reach the last fragmented where the column
          would otherwise fragmented to one per page we're not
          balancing per fragmented we'll have 1 column per fragment
  dbaron: Not sure what you mean. Confused me with last bit
  Rossen: When we go to print and we have fragment now they have a
          constrained height which triggers balancing
  Rossen: Or did I mis-read?
  Rossen: What is different between continuous medium and fragmented
  <florian> this table has the summary:
https://github.com/w3c/csswg-drafts/issues/4036#issuecomment-503648397
  florian: 2 tables in GH, 2nd is correct. Unconstrained fragmented
           with auto the columns don't balance.
  florian: Would switch to balance columns when column fill is auto in
           an unconstrained context. Can't have unbalanced column on
           last page
  Rossen: Balancing on last page in my case, it's only on last page
          with current proposal?
  florian: All pages including last.
  florian: Currently it's all except last (I think)
  <fantasai> I think the mistake in multicol was that continuous media
             balances in cases where print does not, but I guess
             that's not fixable...
  dbaron: With column-fill:auto and unconstrained height you do not
          balance on any page in fragmented context. In continuous you
          balance
  florian: Okay. I missed a step. I think print formatters balance on
           every page but the last.
  Rossen: That's...interesting. Almost opposite of proposal
  florian: Proposal assumes spec says on non-last pages don't balance.
           That's not what print impl do. They don't balance on last
           page but do on others. Let me check spec

  Rossen: Reason I looked at table as misleading you said for auto
          balancing unconstrained if you're in fragmented and not last
          you won't balance. If you're in fragmented context and last
          you will balance. Continuous you always balance. Right
          dbaron?
  dbaron: In continuous you don't balance with auto and constrained.
  Rossen: Unconstrained case. When you're in fragmented context but
          not last fragmented you don't balance
  florian: That's dbaron's table but spec says when value is auto you
           fill sequentially
  dbaron: Let me open spec. I think there's words. Not in value
          definition.
  Rossen: Sounds like in this case we print 4 pages with one column
          and on last page we have 3 col and that's weird. We either
          always or never balance. Half and half is weird.

  dbaron: I think the previous resolution was also somewhat odd.
          Reverting previous resolution gets us consistent state
  Rossen: [missed]
  florian: Which dbaron ?
  Rossen: 3224?
  dbaron: Yes
  <Rossen> https://github.com/w3c/csswg-drafts/issues/3224
  Rossen: This one ^
  [everyone reads]

  dbaron: Regarding florian's question on auto, I agree it's not clear
          for unbalanaced. Clear for balance they are not. Balance
          says [reads]
  florian: What that means is not single column is filled, all filled.
           But if you honor force break they have different heights.
           Means you fill sequentially
  dbaron: That's what I mean by not balanced in my table
  florian: Except for last fragmented where not balance means fill
           first column and stop
  dbaron: With auto height?
  florian: Yes
  dbaron: Messy with auto height where have to define auto height calc
          which can vary
  florian: There's two behaviors for the no. Fill multiple and no
           balance or fill a single column
  dbaron: At a high level you might see those, but it's a result of
          what auto-height calculation does
  florian: What we'd lose with your proposal is ability on last page
           to only fill first column. Or do you not lose that?
  florian: If you have multi page and last has only enough to fill 2/3
           of one column printers have 1 column and your proposal
           there is 3
  dbaron: Correct. Changed for continuous already in previous
          resolution.

  dbaron: There are cases where mutlicol is relatively small. You may
          well print and it fits on one page
  dbaron: So if you're in this case where previous resolution effects
          and it fits on one page previous resolution only applies
          before you print. After you print we do completely the
          opposite. That's a major inconsistency
  florian: True. Two problems. browser printing vs printing and pdf
           printing vs printing
  florian: What will save us if you called for auto it's okay and
           [missed]
  dbaron: Reality of printing in browsers users care about results
          even if authors didn't

  fantasai: I think florian says we've got two conflicting compat
            constraints
  dbaron: Three
  fantasai: Ones I'm aware of is printing through pdf formatter and
            printing through a browser should have same result. Other
            is printing through a browser should have same result as
            looking at page without printing.
  dbaron: 2 web compat. One is PDF. Other is what led to 3224 which is
          Chromium and Webkit did one thing and Gecko the other.
  fantasai: So that's a 3rd
  fantasai: What florian pointed out is because auto is not initial
            it's possible 3rd between Chromium and others is not
            incompat and we can revert
  florian: That's possible. What I was saying is because balance is
           initial most browsers will be on balance and when you print
           it gets you the same thing. Don't change balance. For auto
           behavior changes only if you haven't constrained. If you
           constrained auto and balance do the same. If they do both
           or neither we're safe.
  dbaron: People leave things in code that didn't work
  florian: True. I agree revert previous if we can. That's only sane
           way. Would require WK and Chromium to change

  Rossen: Opinions from WebKit or Chromium impl?
  [silence]
  dbaron: I think we could cycle back. I don't know if Morten is on
          but he seems to know about Chromium limitation. There was
          new information an hour before the call
  florian: Sorry, just finished compat testing
  dbaron: There's a new proposal, should let it cycle on the issue and
          come back.
  fantasai: Anyone else on the call with a concern or are we proposing
            what florian and dbaron say?
  Rossen: Proposal is revert resolution on issue #3224. With that we
          leave discussion open for a week. When others can catch up
          we can re-open the issue and try to resolve.
  florian: sgtm

Text Decoration
===============

text-decoration level 4 clarification on text-underline-offset
    positive/negative lengths
--------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4021

  dbaron: The commenter is a Mozilla intern implementing
  Rossen: Can you represent?
  <myles> I can take it
  <myles> if I can get my mic working
  dbaron: Maybe emilio

  fantasai: There's a text-underline-offset property that takes a
            length to adjust underline position. Positive is inward
            and negative is out. Negative goes down on an underline.
            Safari impl opposite.
  fantasai: Does something different.
  fantasai: Property is positive values move outwards. Down for
            horizontal text
  fantasai: Seems fine to me. I don't understand what Safari is doing
  dbaron: Sounds like which direction things move it.
  dbaron: Apparently Safari treats negative as 0
  fantasai: Okay
  fantasai: I don't have a strong opinion. I'm fine if positive moves
            outward

  AmeliaBR: As someone with no experience I'd expect positive and
            negative to map up/down consistent between under and
            overline. Or I'd expect positive to be father from text.
            Large values meaning closer to text for over and under
            seems weird
  <florian> agree with AmeliaBR

  myles: Couple things. First I want to say when I implemented this
         was an oversight not trying to thwart spec. We have a clamp
         because worried about content spec underline and do offset
         that looks like strikethrough but a browser without it looks
         like underline and that changes meaning. We did it can't be
         closer than baseline.
  myles: Wanted to do other direction too but never got around to impl
         that
  myles: As far as positive and negative directions I believe they're
         just flipped. That's and oversight, I'm sorry. Happy to
         switch. But the person opened the issue said match Safari. I
         don't have a preference here
  <fantasai> myles, given Amelia's logic, I think it might have been a
             good thing you misinterpreted the spec :)

  jensimmons: On question on if positive moves away from text rather
              than closer with margin and padding there's a cowpath in
              author minds where if there's a border and you add
              positive it moves away and negative is closer.
  jensimmons: Instinct is Safari way makes more sense to author minds
  fantasai: proposal: Change the spec. I think there has been good
            arguments.
  fantasai: Arguments against changing to match Safari?

  Rossen: None against. Is what myles desc for clamping in spec? That
          is good behavior to me and maybe to spec. That values can't
          go beyond baseline in negative direction? Maybe something
          like baseline+ascent in positive?
  Rossen: Prevents underlines being used as strikethrough
  fantasai: Separate issue so let's address separately. Good point,
            let's close this.
  <AmeliaBR> Agree these are separate issues. But +1 for a second
             resolution to support clamping the used values to avoid
             under/overline looking like strikethrough
  <myles> Rossen: Should I open that issue or do you want to

  fantasai: Proposal is update the spec so positive offsets are
            outward from the text
  Rossen: sgtm
  Rossen: Objections?

  RESOLVED: Update the spec so positive offsets are outward from the
            text

  <jensimmons> Thanks myles for "doing it backwards" so this would
               come up and we could make it better!
  fantasai: Thanks to myles for making a mistake, we have a better spec

  fantasai: Second, I understand logic for having clamping. Happy to
            add spec text, but need to think about reasonable limits.
            ascent on upper is too high.
  Rossen: Yep. Let's open as separate issue and figure out limits
  myles: You want me to open?
  Rossen: Please
  Rossen: Anything else on this?

  jensimmons: Preventing using it as a strikethrough: I'd love to see
              clear interop and clear spec. That's exactly what
              authors will try and do and if they're able in one and
              get annoyed if they can't in another. I vote interop on
              that whatever it is.
  myles: I'm interested in this. You think there should be interop in
         all browser try and prevent or don't? Or in specific algo for
         limits?
  jensimmons: Need to think more about what different limits might be.
              If it's minor and technical I think doesn't matter. If
              you can have a cool background for some text with
              underline in one browser or not another that's a problem.
  Rossen: I think there's consensus we want interop. Let's take this
          conversation to the new issue and let's get to something
          that can be implemented by all
  fantasai: Want to point out jensimmons comments made me think it's
            worth noting underline is under text not on top. Won't be
            same as strike through.
  Rossen: If same color it will be
  fantasai: Could be reasons you want a thick underline that you
            shift up.
  Rossen: This is why we need a new issue. This is not a 4 minute
          discussion

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

  fantasai: I don't know if we can resolve today. Issue is when you
            have a span of text with word-break:break-all on it and
            it's in a set of characters that would not break
  fantasai: Clear that able to break between characters, but what
            should happen at edges like first letter and previous
            letter. Jonathan Kew posted an example. Browsers are
            inconsistent
  fantasai: Spec says when breaking between 2 characters you look at
            breaking property on nearest common ancestor. Jonathan
            argues how word-break is defined it reclassifies
            characters so that definition doesn't apply. Have behavior
            fall from re-classification
  fantasai: break-all is Latin as CJK, keep-all is treat CJK as Latin
  fantasai: There's also some related properties. line-break which
            decides what rules in effect. If we do character based we
            have asymmetric effects. Another thing is that one of the
            fundamental line breaking is white-space and that uses
            nears common ancestor def.
  fantasai: Overview of considerations. This needs people to think
            about it and try to figure out best cases. There were use
            cases in favor of current spec. Nothing in favor of
            proposal. Use cases are particularly welcome

  Rossen: Thanks fantasai for summary. Issue has been kicked around
          for some time now. How to make it more actionable?

  dbaron: To what extent do you feel like compat is an issue vs this
          is that impl haven't done well yet and you want to push
          toward impl of spec?
  fantasai: I don't think there is a web compat issue. It's making
            sure impl of spec want to move forward in same direction
  florian: I think it's in between. At first approx it doesn't seem
           impl follow spec, but they don't follow alternative or each
           other either. What they're closer to is difficult to say.
           You could make arguments either way. We should make
           everyone agree. I prefer the spec, but the alternative a
           'b' in the last comment on the issue is sane but I like it
           less. Don't like 'c'
  <fantasai> Summary of the state of the issue -
https://github.com/w3c/csswg-drafts/issues/3897#issuecomment-505931859

  Rossen: Give a week or try for progress?
  fantasai: I don't have anything to add. If others have something to
            add or want to think another week is good. Can try to ping
            i18n WG
  florian: Maybe rule C out. Then action impl to look at a and b to
           see if one is harder
  fantasai: Jonathan Kew advocated for c
  florian: Oh, sorry.
  Rossen: fantasai can you ping i18n group?
  Rossen: Is b leading? No c? A is the spec. Seems people mostly
          gravitate to c
  florian: I like spec as-is. Can't advocate alternative is bad. I
           would prefer not to change line-break.
  Rossen: a or c
  florian: I'd object to c. But we don't have a clear winner
  Rossen: We'll ping people to chime in and look next week.

Fill-Stroke, Filter Effects & Color 4
=====================================

percentage opacity
------------------
  github: https://github.com/w3c/csswg-drafts/issues/3342

  ericwilligers: The argument is opacity can be percent or number.
                 Opacity property says same. Not browser impl that.
                 We're proposing to impl but want to ping other
                 browsers to make sure they're okay with it.
  ericwilligers: To allow opacity to accept percent

  AmeliaBR: Has anyone looked and found reason not to? Or has no one
            prioritized?
  myles: We're happy to adopt. Percent opacity is good in every context
  Rossen: Other opinions or objections to resolve in favor of percent?
  ericwilligers: Mozilla?
  emilio: No strong opinion. Reasonable. As long as it doesn't cause a
          conflict
  ericwilligers: Serializes as a number
  AmeliaBR: We don't have anywhere we're using opacity and they're
            ambiguous. In color it's defined by position in param
            list. In all others it's single value. No parsing concern
  ericwilligers: Thanks everyone

  AmeliaBR: It's resolve no change to spec.
  Rossen: Prop: No change to spec

  RESOLVED: No change to spec

Backgrounds and Borders 3
=========================

Computed value of background-size includes missing autos
--------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2574

  emilio: The spec says the computed value includes the missing autos.
          I think we don't need to impl if not relevant. Webkit and
          Blink do that. I think Edge was with FF. There were wpt
          tests depended on them.
  TabAtkins: Agree. Should omit autos when not necessary. Irrelevant
             to issue because that's about computed value.
             Serialization is defined off of computed, but does not
             match computed. The point of computed value is to get a
             well structured value in specs. You serialize in shortest
             value. I agree serialize without autos, but issue is
             invalid.

  emilio: Note to spec saying that?
  AmeliaBR: Good explanation TabAtkins but if multiple implementors
            misinterpret we need to explain it somewhere. Computed
            value has auto for missing values but in serialization
            dropped following shortest serialized.
  TabAtkins: Should add a note in cascade which we link to when
             talking about computed. We should have a specific note
             this is not serialization rules.
  AmeliaBR: Is it something the missing autos should be mentioned in
            computed value line? If that's the as spec value has the
            implied auto for unspec dimension ?
  TabAtkins: That it's not there means it's not there. To talk about a
             value we have to handle the full panoply of things or we
             say computed value has all the possible things. Computed
             values designed to be easy to work with and roughly model
             interior.
  <TabAtkins> clarify it here: https://drafts.csswg.org/css-cascade/#computed
  fantasai: Computed value is not about serialization. We should
            clarify that in a central place, not per property or here
            specifically.
  florian: That the method you call to get the serialization is
           getComputedValue does confuse but what they say is true

  Rossen: For CSS Backgrounds sounds like no change. Can we resolve on
          that? If need to add text to Values or somewhere that's
          great but I'd want us to make progress here.
  TabAtkins: Yes, no change is valid.
  Rossen: Objections to resolving no change?

  RESOLVED: No change to spec

  Rossen: That's the hour.
  Rossen: Thanks for calling in
Received on Wednesday, 26 June 2019 23:27:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 26 June 2019 23:27:37 UTC