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

[CSSWG] Minutes Telecon 2019-05-01 [color-adjust] [selectors] [css-shapes] [css-text]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 1 May 2019 21:06:04 -0400
Message-ID: <CADhPm3ub+Fdyv26Eb_+SYOXYmp1Rq2JtNOq9T6FTRwJ1wKxpjg@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.
=========================================


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

  - RESOLVED: FPWD for css-color-adjust

Selectors
---------

  - RESOLVED: Generic selector grammar allows stacking pseudo elements
              and classes. Only certain combos will be made valid, by
              default everything is invalid (Issue #3876: Need to
              allow stacked pseudo-element selectors in the grammar)
  - RESOLVED: Close the issue (Issue #3754: What a whitespace
              character is)

CSS Shapes
----------

  - It was proposed to remove the padding-box and content-box values
      from <shape-box> (Issue #3872) since they have extremely low use
      counts and bad behavior with scrollbars.
      - There were some use cases for the values, especially
          content-box, but many of them relied upon interacting with
          properties that haven't been implemented so discussion
          mostly changed from removing completely to changing to Level
          2 so the issues with scrollbars can be fixed.
      - Since these values are already implemented and interoperable
          except for scrollbar interaction, the group decided to open
          a new issue to fix scrollbar behavior and keep the values.
  - RESOLVED: No change on this issue (Issue #3872)

CSS Text
--------

  - RESOLVED: Add this to the spec (Issue #3863: Styling of soft
              hyphens)
  - RESOLVED: Inline boundaries do not effect hyphenation, styled or
              unstyled (Issue #3862: Impact of unstyled inlines on
              hyphenation)
  - Another issue will be opened to discussed if a general note should
      be added about unstyled spans having no effect and, if so, where
      that note should go and what is the exact text we should use.
  - There were contrasting principles about what behavior to align to
      when discussing issue #3440 (When to/not to include preserved
      trailing spaces) and there wasn't enough time to reach consensus
      on the call, so discussion will continue in github

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

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

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Christian Biesinger
  Oriol Brufau
  Elika Etemad
  Dael Jackson
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Cameron McCormack
  Florian Rivoal
  Jen Simmons

Regrets:
  Rachel Andrew
  Daniel Bates
  Tantek Çelik
  Dave Cramer
  Simon Fraser
  Myles Maxfield
  Melanie Richards
  Alan Stearns

Scribe: dael

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

color-adjust Call for FPWD
--------------------------
  <Rossen> https://drafts.csswg.org/css-color-adjust-1/

  Rossen: That is something we had resolution to put in a working draft
  Rossen: It is now assembled as an ED on the drafts repo
  Rossen: It has a shortname of css-color-adjust
  <chris> +1 for FPWD
  Rossen: Call is to go for a FPWD
  <florian> +1 for FPWD
  Rossen: Comments or objections?

  RESOLVED: FPWD for css-color-adjust

  Rossen: We have 4 people currently listed as editors
  Rossen: I'll go ahead and prepare the spec for FPWD

Selectors
=========

Need to allow stacked pseudo-element selectors in the grammar
-------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3876

  Rossen: Is TabAtkins on?
  <@TabAtkins> Will be in a sec
  fantasai: I can take it
  <florian> I did not check that TabAtkins did the grammar correctly
            (I assume he did), but I support the intent.

  fantasai: There were some cases where we had pseudo elements that
            are pseudo elements of pseudo elements. One is the marker
            of a before pseudo if that's set as display:list-item
  fantasai: Selectors grammar only allows one pseudo element in the
            grammar. We'll have to relax to allow this. Proposal is do
            it same as pseudo classes applied to pseudo elements. It's
            generically allow, but disallowed except for certain
            allow-listed combinations
  fantasai: The generic grammar needs to allow for the stacking.
            Proposal here is to do that for pseudo elements so one can
            allow another to stack after
  amelia: Really a need to make the allow-list or defined at
          individual level? It could be a valid that doesn't match
          anything. Example is invalid that doesn't match non-form
          elements anyway and wouldn't when on a before or after.
  fantasai: Reason to do is because at some point in future might
            allow some combos, but not sure which will become
            reasonable. Better to make them invalid now and only the
            ones that make sense now are valid. When another combo is
            reasonable in the future we can say it's now valid and
            means something.
  fantasai: Don't want a selector that's valid now but matches nothing
            but 5 years from now it starts matching a bunch of stuff
  Rossen: Sounds reasonable

  Rossen: Other points?
  <dbaron> sounds reasonable to me too, though I'm not sure I could
           extract all that from the issue
  Rossen: +1 to dbaron comment. Thanks for making it clear fantasai
  Rossen: Objections to accepting the issue?
  fantasai: Proposal: Generic selector grammar allows stacking pseudo
            elements and classes. Only certain combos will be made
            valid, by default everything is invalid
  Rossen: Objections?

  RESOLVED: Generic selector grammar allows stacking pseudo elements
            and classes. Only certain combos will be made valid, by
            default everything is invalid

CSS Shapes
==========

Remove padding-box, content-box values from <shape-box>
-------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3872

  iank: As I was redoing parts of shapes impl for our layout engine I
        noticed something that bugged me. I put in use counters.
        Padding-box and content-box as values on shape outside is
        weird. If you have scrollable content inside it won't respect
        scrollbars. Not a strong use case for these values
  iank: Use counter was basically 0.
  iank: Given all this, to simplify can we remove?
  Rossen: Move to L2 or at all?
  iank: Just remove it. I don't know there are strong use cases for
        these values. Be interested if there are.

  amelia: Mentioned a few use cases in a comment earlier today. It's
          matching up shapes with either actual content image of an
          element. shape-outside can be defined using an image and you
          use it to match actual content image and you need them to
          align to correct layout box
  amelia: Also aligning...shape-outside shapes with clip-path shapes
          functions. One issue there is Chrome and possibly WK don't
          support shape boxes on clip-path and default is border-box
          so if people are using a combo they're almost automatically
          using border box. That might effect use counter more than
          anything else.
  amelia: Other is matching with background images that can be aligned
          to many other boxes. Definitely use cases, but need to deal
          with...there's inside boxes and outside boxes when talking
          about scroll and that doesn't seem thought of in the spec
  amelia: Something needs to change in the spec. I don't think
          deleting is best because then have to deal with that that
          set of boxes is used in a lot of graphic properties. Also
          clip-path and shape-inside in the future.
  amelia: Getting rid of it all together will probably cause problems
          with consistency to other properties
  iank: Doesn't sound like...we haven't shipped padding box for clip
        path
  amelia: no
  iank: My primary issue is no one has thought about scrollable boxes.
        It's also weird for engine caching, this reaches inside
        internals of the box.

  fantasai: I think for dealing with scrollable boxes you would want
            to, for clip-path as well, only thing that would make
            sense is inset it by border edge by amount of border and
            padding width. Can't draw it around scrollable area
  amelia: That's one option. Makes perfect sense. Figure out what
          padding box would be working from existing box.
  amelia: Other option is for scrolling boxes only you make at used
          value time these values get re-written but still allow
          content-box and border-box to work on non-scrollers. I like
          fantasai's suggestion better
  fantasai: As we switch to incorporate padding into scrollable [gives
            example]
  iank: Other thing to keep in mind for boxes with scrollers you've
        got to account for where scrollbars are with is a potential
        world of pain

  iank: I don't care where we fall on this issue. 9 months ago I found
        this weird, hence use counters
  fantasai: If we hadn't impl it would make sense to drop. Since they
            are impl I'm ambivalent
  iank: Impl but no usage. I can drop based on that.
  amelia: Willing to accept this. Going back to Rossen question is
          make them invalid for now and defer to L2 where people can
          look more carefully about how should impl. If we've got
          something not impl consistently and we don't agree how and
          it's not used a lot we should take it out. I don't want to
          resolve to never support

  jensimmons: Do we know if we have interop and complete impl or a
              lack of interop and confusion what it should be
  iank: Based on amount of WPT there's good interop. Good between
        Blink and WK because of heritage. Good with FF based on WPT.
  amelia: On the things you want to remove?
  iank: Yes. There's well tested I believe. I can check. But that said
        they have 0 usage
  amelia: But if we've got clear interop why is issue to get rid of
          it? You don't like behavior standardize on?
  iank: Yeah. Behavior is weird for scrollers
  amelia: Wrapping around area overflowing the box? I don't have any
          pictures...
  iank: Make simple impl, apply to scroller and that's what you get.

  Rossen: Going back to original motivation to add them was
          completeness and symmetry with other properties. That's what
          motivated us to add them in
  Rossen: Given there's no uptake on the values and a reason to remove
          from a given impl. In terms of being safe to unship it
          sounds okay. Technical PoV sounds like we can unship with no
          negative effect on content.
  Rossen: Question is are we completely uninterested or are we saying
          we don't know enough but might have reasons to work on it
          and we push to L2
  Rossen: Where on this spectrum are we? Push to L2 and worry later?
          Or no use cases and let's move on.
  fantasai: amelia's point that some things it would work with aren't
            shipped yet means we won't know potential usage accurately
            until those are widespread
  Rossen: Push to L2
  fantasai: If we have interop and spec and impl there's no reason to
            move to L2 because it would pass REC. If we didn't have
            impl it would make sense to drop
  Rossen: Sounds like one impl will unship so we won't reach rec
          without having another impl
  florian: Don't we have 3?
  Rossen: 2 only
  amelia: WK and Chromium aren't independent is the issue?
  iank: Correct
  amelia: Agree playing with the demo what's happening is not good
          behavior. If we leave as a valid value we'd want to spec and
          define better behavior. Considering status of spec I don't
          think that can really happen in timelines we want.
  Rossen: Yeah
  florian: Suggestion is push to L2 with an issue saying there is
           interop but we want to change?
  Rossen: If it is unshipped from blink there's no interop
  amelia: FF and Chrome aren't identical. Both bad, but not interop

  Rossen: Let's see if we can resolve. Objections to move these
          properties out of L1 and into L2 and add a note about the
          interop problem?
  dbaron: What does that imply impl should do?
  florian: rediscuss how it should work before usage and then fix it
  Rossen: In short term blink is looking into removing their impl. In
          long term spend more time thinking about how should work in
          conjunction with scrolling, overflow, etc.
  amelia: One thing, if we change definition there will be
          dependencies beyond this one property.
  amelia: Just practical for whoever does edits
  amelia: We've got a shape-box type that's equal to set of keywords.
          Used in more than this one property
  Rossen: Right

  jensimmons: For me...I'm not hearing that a browser needs to unship
              this in order to get through re-engineering of platform.
              Not hearing a compelling reason to remove. As a person
              that's taught about this property adjusting the
              shape-box property is the last thing people think about
              or learn. Switching from border-box to margin-box makes
              sense, but makes me nervous to unship.
  jensimmons: That people aren't using it doesn't convince me because
              I think people have not dug into it. I haven't thought
              of use cases, but makes me nervous
  TabAtkins: Shouldn't fall pray to status quo fallacy. Since no one
             has come up with reasonable reason to have it in, it's
             weakly supported at best
  dbaron: Sounds like reason to remove isn't that it's complicated,
          but it's not useful.
  dbaron: Could argue using it on a thing with scrollbars is a bad
          idea. Then it's not that bad that it has weird results.
          Clipping a scrollbar is probably not what you wanted.
          Question is are there use cases for non-scrollbar
  amelia: That's what I brought up. There are use cases. Simplest
          solution from spec is add a warning that using content-box
          or padding-box on an element with scrollbars has undefined
          behavior. It's a warning to authors you'll get weird stuff.
          In non-scrollbar case we've got clear interop. But for the
          intersection of properties adding a warning behavior is
          undefined might be quick
  TabAtkins: Officially undefined is something we try not to use. All
             it means is we hope to revisit once web compat has frozen.

  TabAtkins: No one has brought up use cases and I can't think of when
             I'd want text outside to flow into a box past a border
  fantasai: We see this frequently with first letter shapes. You can
            have a light color bg and want text to flow over and wrap
            shape of letter. This kind of design does happen
  jensimmons: And a lot of ability to overlap with negative margin.
              You can't do that here.
  fantasai: I don't see use case for padding-box, but for content-box
            you have that
  iank: In the wild when people want that they reach for insets to
        modify
  fantasai: If you want to take an image, cut into a circle. You don't
            want to have to do an inset of your border and padding
            when you can just say make the circle that covers the
            content box. Less repeating yourself, less complications.
            That's what these keywords are for. If want to cut image
            to a circle, then want text wrap in a circle
  TabAtkins: And also have the image have a border and have text
             overlap that border?
  fantasai: Might not be a circle so yeah. I think it's not the common
            case, but I don't think it's totally crazy
  jensimmons: Interesting question to ask now. If we asked a year ago
              when there's one impl and the question at the time is
              this is complicated. But we just shipped it all and
              we've got interop except the corner case of scrollbars,
              why remove it now? Only reason I'm hearing is it would
              make things feel better for those reading the code so
              you don't have to drag around extra code. I get that as
              an engineer, but not compelling to change a spec
  TabAtkins: Trying to ignore scrollbar doesn't work, we still need
             interop. People will have to add code to handle it. It's
             not a matter of leave it alone, someone will have to pay
             additional cost to get it right. Then there's the non-0
             maintenance for a feature we're not going to use and
             doesn't have a realistic use case

  fantasai: We've spent a lot of time talking about removing a feature
            that's mostly interop. I'm inclined to leave things along
            with no change
  <dbaron> +1 to spending time on other things
  Rossen: Also a valid option
  Rossen: iank would you be okay no change for now?
  iank: Fine. No work for me now, this is for someone down the line
        with scrollers.
  Rossen: Objections to no change on this issue?
  amelia: Can we leave an issue about scrollbar case?
  Rossen: We can

  RESOLVED: no change on this issue

CSS Text
========

Styling of soft hyphens
-----------------------
  github: https://github.com/w3c/csswg-drafts/issues/3863

  florian: Trying to write tests around this. Spec wasn't clear how
           the soft hyphens are styled. Does a span change the color
           of the hyphen? Spec is silent. Impl are interop where if
           line isn't breaking you style span as an empty span. When
           line does hyphenate it behaves as if span was around
           actual hyphenation character. Makes sense, has interop,
           like to spec
  fantasai: Happy to add as clarification. I'm pretty sure that
            codepoint represents visible glyph. Can't lookup unicode
            right now
  florian: I think it says you may want to tailor to language. There's
           some level of smart to what you insert. Not clear it falls
           out. but if we clarify this is what we want doesn't matter
           to me

  Rossen: Other opinions?
  TabAtkins: Agree completely
  Rossen: Objections?

  RESOLVED: Add this to the spec

Impact of unstyled inlines on hyphenation
-----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3862

  florian: While playing with tests I noticed inconsistency in Chrome
           behavior. If you put unstyled spans on parts of the word,
           it causes Chrome to suppress hyphen. Have a general
           principle unstyled spans don't do anything, but call it out
           where it matters.
  florian: I don't think it's good a span around part of a word
           changes what the word is. We have similar notes for text
           transforms what a span doesn't change

  iank: Test case?
  florian: Yes
  iank: Put one in IRC?
  <florian> https://github.com/web-platform-tests/wpt/pull/16428
  florian: Yes ^
  florian: All test cases in the PR are about that. I don't remember
           which version does what, but the superset of Chrome breaks
           some cases

  fantasai: Agree we should spec. Might also be worth putting that
            unstyled spans do not effect any stuff in CSS Text into
            this spec.
  florian: Good too
  heycam: What's the definition of style here?
  fantasai: Any span that's inline, not inline block, even if styled
            has no effect. Principle of unstyled spans if you have 0
            properties on a span and just put it in almost no where in
            CSS does that cause a difference in rendering. One
            exception is text-combine due to impl difficulties.
  fantasai: General principle and then once styles on span it depends
            on the properties. It can no longer be a blanket rule
  fantasai: CSS text it can be a styled span should not effect line
            breaking

  Rossen: Hearing general consensus
  Rossen: Objections?
  fantasai: Prop: Inline boundaries do not effect hyphenation, styled
            or unstyled
  fantasai: Second is do we want to note general principle about
            unstyled in this spec or another or just a principle we
            don't define. Mostly it's a note for spec authors to write
            so unstyled span has no effect on styling
  florian: In a display spec?
  Rossen: Not sure
  florian: It's where we define inline. There we say and if it's not
           otherwise styled and no exception it has no effect.
  fantasai: Good to put that for inline and blocks too
  florian: fantasai I think this is good to nail down. Specific
           wording maybe need more thoughts so open a new issue?
  fantasai: Let's get a new issue for generic one and close this for
            styled and unstyled spans
  Rossen: Objections to Inline boundaries do not effect hyphenation,
          styled or unstyled?

  RESOLVED: Inline boundaries do not effect hyphenation, styled or
            unstyled

  Rossen: Please open an additional issue

Selectors (continued)
======================

What a whitespace character is
------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3754

  florian: Filed against text, but it's a selectors issue. But I'm not
           editor. I think we can close though. Old definition of
           common blank is it contains only whitespace. We no longer
           rely on whitespace so I think this is a non-issue.
  TabAtkins: Yeah, close
  Rossen: Other opinions?
  Rossen: Objections to close the issue

  RESOLVED: Close the issue

CSS Text (continued)
====================

When to/not to include preserved trailing spaces
------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3440

  florian: Before concluded whitespaces at the end of a line for
           whitespace pre-wrap force hang. But spaces before forced
           break wouldn't hang.
  florian: Based on issue fantasai proposed in order to make them
           count to max content, but definition of hanging doesn't say
           if they count or not.
  florian: Then again spaces before a forced break also shouldn't
           count to min content
  florian: If you look at interop browsers don't treat spaces before a
           forced break differently
  florian: I think we should say they hang regardless of forced or
           soft wrap, but say they count toward max-content size.
  florian: Also clarify if hanging punctuation counts or not. Implied
           maybe, but hanging on intrinsic size isn't explicit

  fantasai: [reads spec]
  <fantasai> https://www.w3.org/TR/css-text-3/#hang
  florian: Doesn't say for intrinsic. For min talked explicitly, but
           for max it's fuzzy. In punctuation case...it's saying a
           bunch of things and you can figure out what they probably
           mean but it doesn't say it explicitly. Especially given
           tests aren't clear there's interop so clarifying is good
  florian: I proposed we clarify toward don't count regardless of it's
           min or max. Space we don't count for min and do for max. I
           think that matches rough interop
  fantasai: If we include it in max content size but then subsequently
            align to the right the max content no longer fits the
            content. This is why we want to be consistent if it's
            counter for alignment max content and justification. Need
            same answer or otherwise weird
  florian: Also quite weird with non-intrinsic size. You've got
           whitespace at the end of lots of lines. All except last
           align to the right. That's also weird.
  fantasai: Yeeah. But in other cases you're wrapping. Whitespace at
            wrap you expect to disappear. Whitespace before a break
            you didn't have to put it there.
  fantasai: If behavior makes more or less sense depends on if content
            is wrapping or not. Nice if right/left/center align is
            consistent and encased in max-content
  fantasai: No great answer here. Having max-content and align have
            different answers on a single line doesn't make sense
  florian: If koji's test is still accurate everyone includes spaces
           for max and most but not all include for right align.
           Webkit and blink don't include for justification so they do
           that differently then alignment
  florian: Last time around we resolved to align with WK and Blink for
           justification and apply that to right align so never
           include the spaces.
  florian: It's weird anyway. I have tests to match previous, I just
           think it's weird.

  Rossen: We're overtime
  Rossen: I don't feel we're ready to resolve.
  florian: I think we forced last time and that's part of problem
  Rossen: Table discussion back to github. For those interested,
          continue there and we'll resume next week
  florian: Please look, what we have is well defined, but I'm not sure
           it's good.

  Rossen: Let's wrap up today. Thank you everyone, next week back to
          west coast US time. Thank you for calling in.
Received on Thursday, 2 May 2019 01:06:56 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:10 UTC