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

[CSSWG] Minutes Telecon 2019-02-20 [css-pseudo-4] [css-text] [css-sizing] [css-grid]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 20 Feb 2019 19:22:10 -0500
Message-ID: <CADhPm3v9kMZkF1yxEz=RmdCzRKLKKQWTpaE0ZRR-TFkON9HEVg@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.

Pseudo Elements 4

  - RESOLVED: Publish new WD of Pseudo L4
  - The group discussed Issue #3605 (Specify better handling of text
      shadows for ::selection) but could not resolve if text shadows
      should be painted during ::selection.
      - The argument for painting was that the author has already
          indicated that they want the text shadow. However, the
          argument against is that when styling the ::selection the
          author would not be thinking about text shadow that's only
          set in one place.
      - Discussion will continue at the F2F.

CSS Text & CSS Sizing

  - RESOLVED: Trailing spaces should be counted for max-content but
              not min-content (Issue #3440)
  - RESOLVED: When preserved trailing spaces hang they do it using
              allow-end rather than force-end (Issue #3440)

CSS Grid

  - RESOLVED: Include space in empty explicit grid tracks in the
              scrollable overflow area (Issue #3638)
  - While discussing issue #3638 the group also discovered that there
      may be a chance to have Grid align closer to author expectations
      around including padding in scrollable area. A separate issue
      will be filed to cover that topic.


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Feb/0008.html

  Rachel Andrew
  David Baron
  Amelia Bellamy-Royds
  Oriol Brufau
  Dave Cramer
  Benjamin De Cock
  Elika Etemad
  Javier Fernandez
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Nigel Megitt
  Michael Miller
  Anton Prowse
  Manuel Rego Casasnovas
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Greg Whitworth
  Eric Willigers

  Tab Atkins
  Jen Simmons
  Lea Verou

Scribe: dael

  astearns: I think we have enough people to start. Does anyone have
            extra things to add to the agenda besides a new WD of
            Pseudo 4?
  fantasai: Couple of grid issues if we have time.
  astearns: Things that were just agenda+ last night?
  fantasai: Yeah
  * rego has this issue from a while ago:
         but probably it'd be enough if someone takes a look to it out
         of the call and provide some feedback there

Pseudo 4

Publish new WD of Pseudo L4

  <florian> +1
  astearns: fantasai I assume this is just reg WD?
  fantasai: Yes. Folded in large number of changes including cascade
            changes. 2 issues open for F2F discussion are marked in
            the draft. Should publish new to get it up to date. Major
            issues left are around first-line and first-letter.
  astearns: Objections?

  RESOLVED: Publish new WD of Pseudo L4

CSS Text & CSS Sizing

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

  fantasai: This was discussion with koji and xidorn with how trailing
            spaces handled for intrinsic sizing and alignment. xidorn
            suggested we consider them when counting for max content.
            For min content because trailing spaces don't create
            overflow or cause wrapping we shouldn't count them. So
            longest word, not longest word+space controls content
  fantasai: Other suggestion was to define spaces hang according to
            allow-end rules. allow-end if it fits in the line it's not
            hanging. When you do right alignment it won't go outside.
            If it doesn't fit we allow it to fit on the line and in
            that case it's hanging

  myles: Changing things about expansion opportunities is something
         the web depends on. Do we have compat?
  florian: We don't have compat
  myles: Meaning browsers do different things?
  florian: Yes. Safari does force-end and others do allow-end for
  myles: I don't think we have any philosophical desire so as long as
         no web compat problem we're willing to change

  florian: fantasai your last comment in the issue- can you clarify?
           I'm not sure where that's coming from
  fantasai: xidorn confirmed my first comment and not second. I think
            I was trying to figure out...That question is about
            handling spaces after a forced break different than soft
            break or if they're the same
  fantasai: I think just treating the same is the plan unless someone
            thinks different
  florian: I would think treat the same
  fantasai: Obviously they're kind of different when doing max-content
            because there is no soft break

  florian: For rest of the question I think in terms of taking into
           account for max-content and not min-content I initially
           thought we would ignore in both. If you think in terms of
           punctuation this proposal makes more sense. Including in
           max-content is right idea. For alignment I could go either
  fantasai: That's what I was thinking. Spaces then text then spaces.
            If we say hang in general and you wrap halfway through the
            text you'd see the beginning spaces but not the end. If
            you right align we end up hanging them
  fantasai: Gonna depend on how they happen to fit. I think proposed
            behavior is fine
  florian: Makes sense. Good argument

  astearns: nigel had a point but he's having difficulty being heard
  fantasai: If nigel is asking about issue #1997 that's about if
            inline elements interrupt whitespace trimming. Whitespace
            is trimmed when collapsible, but this is when it's not
            collapsible so it's not really related
  astearns: nigel can you indicate on IRC if that makes sense?
  <nigel> okay, I was just referencing that other issue because it
          seemed relevant
  <nigel> and space allocation at the ends of lines is a big deal for
          e.g. captions.

  florian: I am in support of proposal. Tests need to be updated but I
           will do so

  astearns: Trailing spaces should be counted for max-content but not
  astearns: Objections?

  RESOLVED: Trailing spaces should be counted for max-content but not

  <dbaron> this is all just *preserved* trailing spaces, right?
  <florian> dbaron, yes
  astearns: What is next thing to resolve?
  fantasai: When spaces hang they hand using allow-end behavior rather
            than force-end
  astearns: dbaron has a question on previous and that is correct as
            far as I understand
  fantasai: Yes.
  astearns: Next is when preserved trailing spaces hang they do it
            using allow-end rather than force-end

  RESOLVED: When preserved trailing spaces hang they do it using
            allow-end rather than force-end

  fantasai: Think that's all on this issue

CSS Grid

Empty grid tracks should contribute to scrollable overflow
  github: https://github.com/w3c/csswg-drafts/issues/3638

  astearns: Had some discussion, sounded to me like we were breaking
            toward including explicit tracks in scrollable area of
            grid container
  fantasai: I agree with that
  * florian is happy. That was one of the things in css-text where we
            had interop problems, that I wasn't quite sure how we'd

  astearns: Mats had a couple responses at end of thread that sounded
            like he's not objecting but not happy
  fantasai: Wondering if that's because implementations track info
            about tracks temporarily but don't store. Then managing
            overflow requires tracking additional information somehow.
            But I think authors really do expect those tracks to be in
            scrollable overflow so we should do that
  astearns: Other opinions?

  lajava: I also have doubts about implementing this in Chrome. I
          commented some of my issues with this approach. Because the
          example about grid tracks contributing to intrinsic size I
          don't think is the same as contributing to overflow area as
          Mats pointed out in last comment
  florian: You mean technically they're different so no technical
           reason to handle the same?
  lajava: Conceptual PoV. I don't think it's technically difficult but
          the argument for doing it is tracks contribute to intrinsic
          size. But in this case grid container has a specific size so
          shouldn't consider tracks as content by themselves. Why the
          overflow area is bigger then specific size if there is no
  florian: I think logic is the author explicitly asked for that size.
Even if not putting anything in it putting a size indicates they
expect that large. The intrinsic size is one way to see that the size
they ask is what they get. If they don't observe it as that size it
breaks that assumption. Yeah there's no content but grid is often to
use whitespace as an active part of the design
  astearns: If you have a grid container that has explicit grid
tracks, is auto sized, and not scrolling you'll see trailing white
space before next bit of content. If you then constrain height and
make it scrollable that whitespace disappears. That seems surprising
to me
  lajava: I'm not sure. I think if there are items in the second row
          even that first is empty I think we use the bottom position
          of first item to define scrollable area. In a way the
          whitespaces in the first row are not lost. You mean the
          trailing ones? Yeah, I see
  lajava: As Mats said there are other ways to achieve that
  fantasai: But there's the question of what do authors expect. They
            expect the rows to be considered as space that's there.
            That they're not scrollable is confusing to them and not
            what expected. If creating a grid and want random empty
            spots, if they happen to be in one row that row shouldn't
            collapse away. If they said there is a 100px column it
            should be there. It might be there from implementation
            side but end result of the page is you can't tell it's

  florian: Thought of something else. Invisible things causing
           scrollbars to appear tends to be a thing authors hate.
           Given this isn't part of box model this is harder to find.
           I think with FF grid dev tools you could figure out what's
           going on but not other browsers
  fantasai: I think if you give explicit track sizes you should be
            able to figure out it's causing the scroll. We also have
            padding and it should be considered in scrollable and we
            get a lot of bugs on why it's not. Initial behavior for
            overflow is you trigger only as necessary to show content.
            There are a lot of general expectations that there will be
  fantasai: Authors are unhappy when don't include padding in
            scrollable overflow. We're limited by web compat there,
            but we're not here. I don't think authors will be they put
            10 tracks of 100px and why is my scrollable overflow not
            500px because only half are full.
  florian: I'm back to agreeing
  astearns: Your point is fair that this is a new thing that causes
            space to be added. This isn't in pre-grid dev tools, but
            that's a dev tool issue

  plinss: General principle: If you change the overflow behavior it
          should not effect it's size
  astearns: And size before changed overflow is what we're trying to
            arrive at where empty tracks contribute to scrollable

  iank: What is use case authors want to have additional tracks?
  astearns: Preserving layout intent. It had the whitespace before
            scrollable so should contribute once it is
  florian: And what fantasai said about breathing space between
           content and edge
  iank: So what padding was previous
  AmeliaBR: Or saving space for content that will be added
  astearns: Good point. Not changing the size as you add things to
            explicit grid is pretty useful
  iank: Really good point AmeliaBR

  <rego> the padding is also lost as oriol explained
  <rego> it'll be nice to be consistent on that case in the future too

  astearns: I think we are converging on including explicit grid track
            sizing to the scrollable area of a grid container
  astearns: Anyone on the call that has an argument against or would
            object to resolving?
  lajava: I think rego has a point with padding not being consistent.
          I think oriol mentioned that in issue
  oriol: Problem with padding is there is no interop. In FF it does
         not add space but in Chromium the space is always added in
         block axis and sometimes in inline. So there is no interop. I
         think this is a similar case and would prefer consistent
  fantasai: We'd like consistent but we're constrained on compat.
            There are issues on overflow spec and the goal is to
            include the padding.
  <fantasai> See issues in https://drafts.csswg.org/css-overflow-3/#scrollable
  astearns: If oriol says there is no interop there may be more
            possibility to get behavior we want
  fantasai: The amount to which chrome includes padding we're trying
            to do that. You can see those issues on overflow spec. but
            in inline axis it's pretty random. Separate discussion

  daniel: I'm testing chrome 74 and it seems to behave same as FF
  lajava: Yes because we just fixed the bug
  lajava: Because there is nothing in the spec that suggests we should
          use grid tracks to contribute to overflow area. If we want
          this to be new we should propose new text
  fantasai: Yes, this is not a clarification
  astearns: That is a slight concern. There is a bug Chrome canary
            responded to. I'm not sure if that's interop or if person
            that wrote the chrome bug wanted space to collapse.
  fantasai: Don't know, but guessing spec compliance.
  astearns: My guess as well
  florian: If I'm looking at the right thing, chrome bug is from Mats
  lajava: Yeah, original bug was to FF but Mats argued they followed
          spec and he filed bug against Chrome. We decided to follow
  astearns: Thanks for the quick response on that
  lajava: Means we need to agree with Mats this is behavior we will
  astearns: Certainly. If we resolve we need to get Mats to agree to
            change behavior to spec. Unfortunate he's not on call, but
            I don't see in his issue comments reasons to not resolve
            the way we intend

  florian: Clarification point or extra argument. Given that Chrome in
           some cases includes padding if we have empty tracks and
           padding it seems it will be confusing to including padding
           and not empty tracks
  astearns: Interop on including padding?
  <fantasai> https://drafts.csswg.org/css-align-3/#overflow-scroll-position
  florian: No but we're trying to including it at least as much as we
           can. And when alignment is not the default we always do. So
           when we have some cases where include the padding not
           including empty track seems weird. Or am I confused?
  fantasai: I think we should try and include padding in grid if we
            can. If we can include empty tracks we should because it's
            used for many more cases then padding
  florian: Yes, but given padding is outside not including the inside
           is confusing
  fantasai: Tackle in separate issue but I think you're right we
            should adjust grid and flexbox to do thing authors want
            to do

  astearns: Objections to including space in empty explicit grid
            tracks in the scrollable overflow area?
  <florian> +1

  RESOLVED: Include space in empty explicit grid tracks in the
            scrollable overflow area

  astearns: Hopefully implementations can follow. We'll get feedback
            as we go.
  astearns: Do we have issues for including padding in scrollable
  florian: We do
  fantasai: Might want a separate one on grid
  astearns: Is that overflow spec or grid?
  fantasai: mmm...I think grid. I'll file
  <AmeliaBR> Lots of open issues:

Pseudo 4

Specify better handling of text shadows for ::selection
  github: https://github.com/w3c/csswg-drafts/issues/3605

  astearns: I see daniel commented. Did you get to read spec daniel?
  daniel: I haven't
  fantasai: When we highlight text the problem is if you have a shadow
            behind. In general I would expect highlight to obscure
            shadow. In tests I've seen highlighting lets you see text
            badly styled.
  daniel: Sounds like you don't expect picture I posted?
  fantasai: The color of text and background of highlights are defined
            by selection. If we keep color of text from selection but
            take shadow from author we might not get enough contrast
            between text and shadow behind.
  fantasai: Whereas if we obscure the text shadow then you can ensure
            there is enough contrast because you have chosen both text
            and background color
  AmeliaBR: A little confused about drawing over text shadow. It's not
            like text decoration where it's continuous from parent.
            Text shadow is inheriting. It's not about drawing over,
            it's we're drawing within selection and that's part of
            character style

  chris: Sounds like 2 models for this. One if it's above or below and
         another is painting without shadow.
  fantasai: That's fair. Maybe way to deal is UA default sheet should
            have text-shadow:none and that turns it off in selection

  daniel: I like effect in picture. That would be example of if
          someone wanted to do word processing that's what I'd expect
          as a user. Any way we can let a webdev get that?
  fantasai: If we go with AmeliaBR model author could set
  AmeliaBR: But what if you want it preserved in selection. Maybe in
            the default selection styles could include turning off
            text shadow. But if user sets selection styles we
            shouldn't unset an inherited style
  <chris> +1 to what Amelia said. Set a good default but give authors
  fantasai: I think in cases users won't think through it. If
            selection color was navy blue and white...
  AmeliaBR: If author has set custom selection and not considered
            contrast that's author error
  fantasai: They didn't think about the text shadow that's incompat. I
            think text shadow should be an explicit opt in
  AmeliaBR: As an author I would not want browser to mess things up so
            I have to explicitly say text-shadow:inherit on my
  fantasai: I don't think text-shadow:inherit would work because
            inherit from parent selection

  chris: Better to let author do what they want. Fine to have a
         default, but argument for not having contrast is same for
         setting foreground and background color. You can't legislate
         against bad design.
  fantasai: I think it's a question of where styles come from and do
            authors except them to combine. You as author should set
            background and foreground readable and text shadow in
            conjunction with that. Seems unlikely you'll style a space
            and have headers with white text on black shadow and
            somewhere else in stylesheet you have hot pink as
            selection color with black text
  fantasai: Then in that section you have black text on a black shadow
            with a hot pink background. It's hard to read. You were
            thinking about making sure you had enough contrast, but
            where you set text shadow it takes effect
  AmeliaBR: I want to point out one of the things I use text shadow
            for is to create contrast. If I've intentionally added
            something to create contrast and you wipe it for selection
            that could be counterintuitive. Unless I have easy way to
            say inherit that it's confusing
  fantasai: But that is cause of creating context, but when have
            selection you have different background and text color and
            shadow will no longer give you contrast. It should be
            exactly wrong color

  daniel: Seems to alternate between 2 audiences. One is web dev and
          stylesheet and other is person on computer who has own
          stylesheet. I think there's 2 answers. If this is for the
          website it's the website author's problem. I can see your
          argument makes sense for a human who has their own stylesheet
  fantasai: I'm worried about author picks good colors in all cases
            but when you use selection color with the shadow that was
            for the heading you end up with a combo of the same color
            because selection wasn't thinking about heading having
  daniel: I think that's their responsibility to think through. They
          can do selection pseudo with good properties.

  daniel: solution: if you take the selection, paint the background
          and then blend shadow when you paint so that it preserves
          contrast. Not exactly what author wants but we're
          correcting. Could be crazy solution
  fantasai: If author wants text shadow to show through selection you
            can set that
  daniel: I think that's the wrong audience. What does user expect and
          I think they would expect shadow to stay
  fantasai: I didn't expect it to stay
  daniel: Native OS gets you that result

  gregwhitworth: We are doing a lot of user studies in similar
                 scenario. We had to come to same conclusion that
                 ultimately that's what selection pseudo is for and
                 author needs to think through. We have to give
                 capability for authors to override so they can still
                 do stupid things. I don't know what to standardize
                 but would instead leave it to UAs. This comes down to
                 user preference and in our studies people wanted it
                 all ways and authors too.
  gregwhitworth: Don't know how to standardize and take that all in in
                 a meaningful way
  <chris> authoring advice is a good way forward
  astearns: Maybe we change from what should happen in the spec to an
            authoring note telling authors they should consider this
            but not put normative requirements on UA
  florian: Seems like a lot of work for authors. Every time you have
           selection you should turn off text shadow before you think
           about it so you get right contrast. Default is you have to
           cancel the shadow and please think about it
  astearns: Not sure default is you should cancel the shadow
  florian: If you set selection you set foreground and background
           color. If shadow comes from where ever it could be whatever
           color and you don't know contrast is good
  florian: So by default you need to suppress it
  fantasai: No one is going to think to reset shadow when setting
            selection. You're not using shadows everywhere. I think we
            should be biased toward good contrast
  daniel: Could adjust visibility of color. webkit does this for
          regular foreground text. That's one way

  fantasai: Let's talk about this later, we're not going to resolve
  astearns: Not much time in the call and not hearing consensus. Let's
            close for now and come back.

  <gregwhitworth> fantasai: maybe we can discuss this at the F2F as a
                  breakout session?
  <fantasai> gregwhitworth, added it to the F2F agenda
  <gregwhitworth> fantasai: thanks

  astearns: In IRC rego pointed out a possible agenda item
  <astearns> https://github.com/w3c/csswg-drafts/issues/3416
  astearns: Probably need to cover at F2F so please take a look. Also
            a couple of grid items fantasai mentioned but please look
            so we can get to them at F2F.
  astearns: Anything else?
  astearns: That's it then. For everyone traveling next week, safe
            travels. See you then.
Received on Thursday, 21 February 2019 00:23:21 UTC

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