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

[CSSWG] Minutes Telecon 2019-08-14 [css-text-decor] [css-images] [css-lists-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 14 Aug 2019 19:06:21 -0400
Message-ID: <CADhPm3smJehuP1bQQBGEjnEEb29BVYvo+r3uZXs-u5iU3QFbhg@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.

2020 F2F Dates

  - Apple will look into dates and locations for the second F2F in
      2020. If anyone has conflicts please add them to the wiki so
      they can be factored into date selection.

Text Decoration

  - RESOLVED: No limit. If past what the UA can render it's clipped
              (Issue #4059: Limits on text-underline-offset to
              preserve semantic meaning)
  - RESOLVED: No change to the current spec, use thickness (Issue
              #4138: Rename `text-decoration-thickness` to

CSS Images

  - Myles will review issue #1984 (Specify fallback behavior when
      replaced or background image content not available) for next
      week's call.
  - RESOLVED: Update note saying this is not for implementation and
              will be dropped (Issue #4164: Should the values of
              image-orientation include the <angle> variants?)
  - After issue #1984 is resolved there will be a call for

CSS Lists

  - It seems like browsers function interoperably in issue #4181
      (Should automatic list-item increment adjust for ol[reversed]?)
      after the initial value is determined so the group was leaning
      toward UA magic to handle this.
  - RESOLVED: Update to match 2.1 and make counter(name, none) invalid
              (Issue #4163: counter(name, none) should be invalid)
  - RESOLVED: Republish Lists 3 with open issue on ol[reversed] and
              reversed counter.


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Aug/0004.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Peter Linss
  Myles Maxfield
  Anton Prowse
  Devin Rousso
  Jen Simmons
  Greg Whitworth

  Christian Biesinger

Scribe: dael

  Rossen: We should get going
  Rossen: We have a pretty full agenda.
  Rossen: As usual, are there any additional agenda items you want to
          consider or any changes to current agenda?

2020 Spring f2f dates

  Rossen: Gentile ping to see where we are with securing space.
          Ideally if we can lock the week down.
  Rossen: Not adding pressure to organizers, I know it's not easy.
          Apple folks, do you have any inclination as to if you're
          able to host? If yes, do you have readiness to commit to a
          week regardless of location?
  <jensimmons> for quick reference:
  smfr: We need a week to get answers. Willing to host, need to see if
        availability for dates group is interested in
  Rossen: When you say dates interested in this is the thing we
          wanted. What are the dates?
  smfr: Thought we had options
  Rossen: Currently only have constraints, but not an actual agreed
          week. That's why we're handing it to you to check if there's
          a better or easier week
  smfr: We can look and come back with options
  Rossen: Let's do that. If you can nudge myles or hober or whoever is
          handling to look at timing we can go from there

  smfr: Any constraints, please add to wiki
  <jensimmons> the week of April 13 doesn’t work for me, and likely
               Rachel Andrew
  Rossen: Definitely. Add constraints now so as Apple looks at
          availability they can take those into account.
  Rossen: smfr and team as soon as you have preliminary plans ping us
          on the private list and we'll make plans. People are trying
          to arrange travel

  smfr: Do we know normal headcount?
  Rossen: Usually 30 +/- 5. Location dependent
  dbaron: I'll put in assuming the meeting spacing I'll put where our
          dates would be from January and TPAC.

  Rossen: We have Spring for Apple and Summer in Kyoto. dbaron if you
          want to add ideal space between we can go from there
  florian: Kyoto is probably not in summer.
  Rossen: I think it was Kyoto/Tokyo/France/NYC so there's
  Rossen: I'm sure folks will get back to us.

  <dbaron> Also, I updated https://wiki.csswg.org/planning with
           "evenly spaced" meeting dates, so if people have conflicts
           in late April or late July, those are particularly
           important to note.

Text Decoration

Limits on text-underline-offset to preserve semantic meaning
  github: https://github.com/w3c/csswg-drafts/issues/4059

  myles: Apple delegation has done internal soul searching and we're
         now comfortable with no limit solution. No clamping
  <astearns> \o/
  <bradk> Yay!
  <florian> yay
  <jensimmons> Excellent!

  Rossen: Is that only thing we wanted to resolve?
  myles: I believe that's the only topic of conversation
  fantasai: There's going to be a limit because UA has limit of what
            it can do. If the spec size is greater then that should
            underline be clipped or clamped?
  fantasai: Let's say limit is 5 pages long. Author expects underline
            on 6th page. Is the underline on the 5th page or not
  myles: Match text shadow which I believe is clipping
  fantasai: Makes sense. If you get greater than a couple pages
            clamping gets you unexpected lines, which might overpaint
            something unexpected
  TabAtkins: I think if it's greater than a few lines it's confusing
             so clipping is fine
  fantasai: Proposal: no limit. If past what UA can render it's clipped
  <florian> +1
  Rossen: Okay.
  Rossen: I'm the biggest non-fan but won't object
  Rossen: Any objections or comments or can we resolve?
  Rossen: Objections?

  RESOLVED: No limit. If past what the UA can render it's clipped

Rename `text-decoration-thickness` to `text-decoration-weight`?
  github: https://github.com/w3c/csswg-drafts/issues/4138

  Rossen: Last week discussion narrowed to 2 choices.
  Rossen: Evenly distributed preference. More people voting thickness.
  <fantasai> largely due to the "no change from impl" principle
  Rossen: Are we ready to resolve on thickness?

  bradk: What are the 2?
  jensimmons: I opened this and didn't intend to re-open thickness vs
              width conversation. My intention was to say is weight a
              good solution. I think it's great and makes sense to
              lots of people. Opposite is that text-decoration-weight
              doesn't match values. Seems like you guys disregarded
  jensimmons: I'd rather keep thickness
  Rossen: Did rule out weight. Slight preference, but wanted majority
          of group to resolve on not change. That way FF can move
          forward and we can close the issue
  jensimmons: Does look from straw poll...Looks to me there was a
              definite preference for thickness, lots that didn't
              care. Some people preferred width.
  fantasai: A number were due to not wanting a change. It wasn't so
            much preference as not change things
  bradk: Width is not under consideration?
  Rossen: Width was last week. We can take a straw poll again.
  Rossen: Higher level discussion. We did rule out weight. Going to
          original issue it was rename thickness to weight and we can
          say no. In the middle of that width was brought up with some
          preference for width. Fine spending a few minutes about
          rename to width. Or just close original issue no change

  Rossen: Anyone want to straw poll?
  <fantasai> curious to poll a) weight b) thickness c) width d) no
             change (= thickness)
  bradk: I'd like width so consistent with other border thicknesses. I
         think it's unnecessary cognitive burden to remember which is
  myles: You're right about the burden. But also burden in calling it
         something unrelated to what it does. Web search to change
         underline the results say thickness. So people are clearly
         using that.
  bradk: Boat has sailed. If we change to thickness we should have
         border-thickness and outline-thickness
  myles: We've got 1 shipping impl and 1 non-shipping
  bradk: I meant borders have thickness not width
  jensimmons: Agree with myles. At the heart some people come at this
              from css prospective and they're looking for internal
              consistency and things should match. On the other hand
              there are folks who are looking at the words for what
              they are and consistency beyond CSS and intuitive for
              learning CSS. And they say it's okay because it makes
              sense in the larger world
  <chris> Agree with myles and jen
  jensimmons: Every time I see width I think it means the length of
              the line not the thickness. I totally understand where
              both prospectives come from. I think we don't share same
              way of looking at things.
  <fantasai> border-width, outline-width, stroke-width
  bradk: To me there's so many terms an author has to learn that
         having 2 terms for same concept is confusing and makes it
         harder to learn. New user that learned thickness of a border
         is border-width or an older user with that ingrained it's
         harder to remember text-decoration is thickness for the same
         concept of how wide the line stroke is.

  Rossen: I don't want to re-do the entire conversation. I want us to
          resolve what is the stroke called. We ruled out weight. I
          see IRC advocating weight. I prefer to keep this to
          thickness vs width
  Rossen: I hear both sides and bradk has a valid case here for width.
  Rossen: Let's take a straw pool
  jensimmons: I'm disappointed that I proposed weight and it was
              considered in a meeting where I wasn't there. Normally
              folks try and make people in the conversation. And now
              we're re-litigating a decision. I'm surprised this
              happened because that's not usual for the group
  Rossen: You had asked us to discuss without you here. We don't
          usually hold off when there's group consensus. Making
          decisions in that regard is fine and according to what we've
          been doing. It's also fine to bring the topic back and say
          you want to re-discuss something.
  <florian> Jen did say we could decide without her. But if we are
            re-litigating, I think her option should be included
  <fantasai> +1 to Florian
  Rossen: We can have a straw poll of thickness vs width. Since you're
          bringing the point back if you want to reintroduce it let's
          add weight for completeness. We'll decide based on straw
          poll. Sound fair?
  florian: Can we use fantasai straw poll?
  <fantasai> suggestion was a) weight b) thickness c) width d) no
             change (= thickness)
  Rossen: Best to use same order as first time.
  Rossen: Nevermind, first didn't have weight

  Rossen: a) weight b) thickness c) width d) no change (= thickness)
  Rossen: Enter choices in IRC
  <myles> BBBBBBBBBB
  <bradk> C) -width
  <bkardell> present+
  <fantasai> c
  <smfr> b
  <astearns> d
  <jensimmons> Prefers A. Would be ok with B.
  <plinss> c
  <chris> b
  <drousso> b
  <stantonm> b
  <TabAtkins> b due to compat, c in my heart
  <fantasai> TabAtkins, that would be d :)
  <TabAtkins> oh so I guess that's D, not B. Then C in my heart.
  <Rossen> b
  <dbaron> b or c
  <rachelandrew> b
  <florian> abstain
  <emilio> b
  <dauwhe> b
  Rossen: Waiting on anyone?
  Rossen: 10 seconds
  <chris> looks like the winner is B
  Rossen: I think it's clear decision is thickness and no change to
          current spec

  Rossen: Resolve on no change to the current spec, thickness

  RESOLVED: No change to the current spec, use thickness

  Rossen: jensimmons anything else FF engineers waiting on?
  jensimmons: Another issue fantasai was writing text on
  Rossen: Anything on the agenda?
  jensimmons: No, thanks
  <jensimmons> there might be clarifications needed about wavy and
               double lines…. https://github.com/w3c/csswg-drafts/issues/4134
               fantasai was tasked with working on the spec.
  <fantasai> jensimmons, for the record, I think what I was actioned
             to write was that the line thickness, amplitude, and
             frequency should scale together (not necessarily strictly
             proportionally, but roughly proportionally), and double
             similar to border-width: double in the same way

CSS Images

Specify fallback behavior when replaced or background image content
    not available
  github: https://github.com/w3c/csswg-drafts/issues/1984

  <TabAtkins> https://github.com/w3c/csswg-drafts/commit/3f884b87c54b38afd7742fb8e123a7d27ddd3ac4
  TabAtkins: When we spoke last time waiting on Apple; myles wanted to
             review. fantasai committed text [above] for replaced
             image. Want to ensure spec did not rule out leaving image
             in place while waiting for new image
  TabAtkins: If Apple wants to review that's fine but want to do
  myles: Can I give myself an end of week deadline?
  TabAtkins: Next call is fine.
  Rossen: Next week's call is fine. TabAtkins anything else on this?
  TabAtkins: It's good
  <fantasai> myles, end of week would be great in case you have things
             we should try to fix before the call :)

Should the values of image-orientation include the <angle> variants?
  github: https://github.com/w3c/csswg-drafts/issues/4164

  smfr: WK is working on image-orientation. there's one with angles
        and one without. Any other browsers interested in angle
  fantasai: Because we made from-image default orientation I don't
            think strong use case for none. If not having web compat
            problems is this a necessary property? Still need
            definition because css print profile. If defaulting to
            EXIF do we need property at all?
  <dbaron> I didn't think the <angle> values were useful...
  TabAtkins: I don't recall affirmative use cases for none
  myles: Easier to add CSS to fix a busted image then to rotate
  fantasai: True. Ideally information should be in image or html. If
            photo is sideways it's data is wrong
  fantasai: If you turn off CSS or in reader mode you want it to be
            upright. If image is wrong you should fundamentally fix
            and not patch with CSS

  emilio: Gecko impl the angle values and unshipped when spec
          deprecated it. I don't think it's a lot of work to
          re-implement them
  <emilio> https://groups.google.com/d/msg/mozilla.dev.platform/A1aaENcsR6k/fPB1AvyaCAAJ
  dbaron: I also don't think that useful and a weird use of angles
  myles: Under specified because don't say which orientation rotated
  <fantasai> rotated from the orientation before applying EXIF
  TabAtkins: Question on myles' comment. Use case was something where
             image pixel are correct and EXIF is busted? Or more broad?
  myles: Yes. Comment not about angle value, but presence of property
  TabAtkins: With regards to angles unspecifying implication was
             rotation from none...says 0deg corresponds to none.
             Implies you rotate from that. I don't think
             underspecified, but can be tweaked. Hopefully don't need
             to be implemented. They're there because print renderers
             have them.
  <myles> TabAtkins: where does it say that 0 means none?
  <myles> i don't see it
  <TabAtkins> myles, hm, I was sure there was something written there
              about that. Guess I remembered wrong.

  smfr: fantasai suggested removing property. But if Mozilla has been
        shipping with from-image removing is tricky. emilio do you
        have info on how long shipped?
  emilio: I don't think we have use counters. Could add. Been shipping
          for a long time if I recall. I'll find a link
  <emilio> smfr: https://bugzilla.mozilla.org/show_bug.cgi?id=825771,
           landed in ff 26
  dbaron: If we're going to try and change the default I would suspect
          that any of the things using it are doing so to set
          from-image not none
  fantasai: +1
  fantasai: Unless using it to set a value other than from-image
            there's not a change if we remove property. Already
            resolved to change initial to from-image so might not need
  smfr: Possible to get photos with bad EXIF information. If you take
        a picture straight down you get an angle. I can imagine trying
        to fix that. It does fail with things that strip css
  fantasai: My inclination is impl that support this try and switch to
            from-image as default. Impl that don't change to from or
            EXIF. If that works we try and remove property. If it
            doesn't we keep
  <dbaron> What fantasai just said sounds like a good plan to me.

  plinss: If building photo editing software might want to show image
          naturally as it is and then manually rotate
  TabAtkins: Editing you're parsing photo into a canvas?
  plinss: Maybe. Could parse EXIF data yourself, but there is utility
          to keeping. Agree from-image and none are only properties
          with from-image as default
  Rossen: unshipping of Mozilla behavior and resolve on that behavior
  Rossen: Which way are we leaning?
  TabAtkins: Fine with dropping if impl are okay on supposition we can
             make switch to from-image
  plinss: Compat risk when I was writing code for this you don't know
          if browser will rotate and can't tell. Anyone with code that
          cares about this is already screwed so wouldn't worry about
  plinss: Would be nice if you can tell browser rotated but don't know
          how to tell in css
  fantasai: Query size of box if it's not square and get aspect ratio.
            Can tell you a bit
  <TabAtkins> plus, as established, the number of images with
              non-Top-Left orientations is < .0001% of all images on
              the web.
  plinss: But then have to parse image and then you might as well
          parse EXIF data
  Rossen: Leaning toward dropping image-orientation

  fantasai: Proposal: update note in draft to indicate we might drop
            the entire property for browsers and keep a definition
            with the <angle> values for historical reasons and say
            it's optional. Then remove. Or information this is in css
            print by not rec for impl
  Rossen: Proposed resolution: Update note saying this is not for
          implementation and will be dropped
  Rossen: Objections?

  RESOLVED: Update note saying this is not for implementation and will
            be dropped


  Rossen: If we've got 1984 still open we'll push republish until next

CSS Lists

Should automatic list-item increment adjust for ol[reversed]?
  github: https://github.com/w3c/csswg-drafts/issues/4181

  TabAtkins: If we can achieve through UA stylesheet or do magic.
             Magic to host language or in css
  TabAtkins: emilio points out [missed]
  [audio problems with Tabatkins' line]
  <TabAtkins> So anyway, Emilio points out that it's literally
              impossible to do the [reversed] behavior via UA
  fantasai: We have normal lists, they're great. We have reversed
            lists where increment is -1. Where you start is a separate
            issue. Each li decrements counter needs to be implement.
            Only magic is that it's incremented by 1 on list item box
  <fantasai> ol[reversed] > li { counter-increment: list-item -1; }
  fantasai: Put in spec you can do on UA stylesheet. Works in general
            easy case. HTML spec includes any box with display of
            list-item in the numbering and excludes non-list-items. If
            you put a div in the li and give that a display: list-item
            it increments. The list relies on the CSS
  fantasai: You can't reflect the current behavior. I can try and
            share a test case
  <TabAtkins> aka the [reversed] behavior is *literally* just "do
              normal list item numbering, then reverse all the numbers"
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Col%20reversed%3E%0A%3Cli%20style%3D%22border%3A%20solid%22%3E%20x%3Cdiv%20style%3D%22display%3A%20list-item%22%3ETest%3C%2Fdiv%3E%0A%3Cli%3E%20y%0A%3Cli%3E%20z%0A%3C%2Fol%3E%0A

  fantasai: 3 things we can do. 1) use UA stylesheet and get impl to
            do something different that doesn't account for display
            value of boxes. 2) have magic and host lang can change
            magic. 3) create css property that says what magic
            increment is
  <fantasai> Behavior of li counting in HTML
  dbaron: I think there are a bunch of edge cases that suggest
          modeling this as a decrement is wrong approach. 2 ways to
          model. Starting value is magic, items decrement, counter
          goes forward. Other is counter counts from end to beginning.
          This is different results at times, like if you change
          counter in the middle
  dbaron: Tend to think modeling this as magic to get the beginning
          and then decrements will get wrong result in a bunch of cases
  TabAtkins: You think counting backwards and interacting with
             counter-set is good?
  dbaron: I'm looking at browser behavior and actual behavior of value
          attribute with reverse is not sensible or interop
  dbaron: Maybe value is already broken and other way is right
  TabAtkins: Something odd in FF. FF and Chrome agree value effects
             following things and not proceeding. Differences in what
             number the very first item starts in. They agree it's
             count forward
  dbaron: Maybe stuck with wrong model
  TabAtkins: Both models have arguments. Fine with either
  fantasai: Did run a test with decrement as -2 and it starts counting
            into negative numbers. Start number was no adjusted to
            account for that
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3Eli%20%7B%20counter-increment%3A%20list-item%20-2%3B%20%7D%3C%2Fstyle%3E%0A%3Col%20reversed%3E%0A%3Cli%20style%3D%22border%3A%20solid%22%3E%20x%3Cdiv%20style%3D%22display%3A%20list-item%22%3ETest%3C%2Fdiv%3E%0A%3Cli%3E%20y%0A%3Cli%3E%20z%0A%3C%2Fol%3E%0A
  <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7121
  <TabAtkins> Dunno why Firefox starts numbering at 7 even tho there
              are only six items.

  Rossen: From the 3 choices at the beginning seems like we're getting
          to none of them?
  TabAtkins: Aside from that my test shows a weird start number,
             browsers seem consistent in how they treat things
  TabAtkins: Figure out value of last item that would increment, use
             that as the first value. Figure out magic value where if
             nothing screws with numbering gets you to 1 and then
             start at that ind do minus 1
  TabAtkins: I'm on side of UA magic so there's interop I don't
             believe css needs to control on it's own.
  dbaron: html editors might be unhappy. html editors seem unhappy
          that css claims their stylesheets are doing wrong thing
  TabAtkins: [missed] reverse engineering at the time and we're saying
             do this with css now. Seeing you got no bugs I think
             we're fine and we can do this
  <Rossen> fwiw current Edge result is [-1, 1, -1, -2]
  fantasai: Still not clear on how reverse is supposed to work.

  fantasai: Would like to get updated draft published because cleaned
            up counters section substantially. We should publish and
            mark reverse lists as an open issue.
  fantasai: Should we publish draft with previous state or should we
            publish with the concept of the magic increment? Should
            leave issue open, but what to publish with
  fantasai: Inclination is publish no change from previous because
            that's clear we have not solved and update later after we
  Rossen: Do you want to discuss next before publish?

counter(name, none) should be invalid
  github: https://github.com/w3c/csswg-drafts/issues/4163

  fantasai: If you say counter(name,counter-style) it represents list
            using that. There is a none value that's value of list
            styletype. Some implementations think that's valid as a
            counter style. CSS 2.1 forbids that. I updated spec to
            match css2.1
  fantasai: If people disagree and think counter(name, none) should be
            valid we can reconsider
  TabAtkins: I wrote that near 10 years ago. Can't comment on
             justification so whatever
  fantasai: Objections to updating spec to match 2.1?
  <TabAtkins> No objection.

  RESOLVED: Update to match 2.1 and make counter(name, none) invalid


  Rossen: Prop: Republish css lists 3 with everything changed and open
          topic on reverse counters and reverse to previous draft state
  <TabAtkins> I want to make sure we're not putting the ol[reversed]
              rule back in the stylesheet.
  <TabAtkins> Because that def doesn't match any implementation
  <TabAtkins> And never will.
  <TabAtkins> Okay so I'm opposed to putting it back in any case.
  fantasai: stylesheet in appendix we should put it back and make it
            clear it's an interpretation. Also okay not mentioning
            reverse at all and removing it
  Rossen: Okay republishing with removing?
  <TabAtkins> Yeah, let's remove all official mention, and just have a
              note that "hey this exists, we'll define how it works
  fantasai: Yes, if removed and not says it's magic
  <fantasai> wfm
  Rossen: Will republsish with issue open
  Rossen: Objections to republish lists 3 with open issue on
          ol[reverse] and reversed counter

  RESOLVED: Republish lists 3 with open issue on ol[reversed] and
            reversed counter
Received on Wednesday, 14 August 2019 23:07:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:15 UTC