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

[CSSWG] Minutes Telecon 2018-06-13 [css-grid-2] [filter-effects-1] [css-contain] [css-shapes]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 13 Jun 2018 19:56:19 -0500
Message-ID: <CADhPm3tPVHSjCcZ9BYVYHOfnR_Miynznin-1KnK3uizo1W0xBw@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 Grid 2
----------

  - RESOLVED: publish a new Working Draft of Grid Level 2

Filter Effects
--------------

  - RESOLVED: If there is an explicit author-specified background,
              that layer that has gotten propagated on top of the
              canvas, filter does effect that. (FXTF Issue #282)

CSS Contain
-----------

 - RESOLVED: Size containment doesn't apply to tables (Issue #2746)

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

  - There were two proposals for how to handle the author desire to
      allow shape-outside to apply to initial letter, the initial
      commit from dauwhe and a proposal from astearns. Both seemed
      like they would work, so discussion will continue on GitHub as
      to which is preferred (Issue #885).

===== FULL MEETING MINUTES =======

Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jun/0016.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Amelia Bellamy-Royds
  Garrett Berg
  Dave Cramer
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Tony Graham
  Chris Harrelson
  Chris Lilley
  Peter Linss
  Anton Prowse
  Liam Quin
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Lea Verou
  Eric Willigers

Regrets:
  Tab Atkins
  Dael Jackson
  Vlad Levantovsky
  Michael Miller
  Dirk Schulze

Scribe: melanierichards

CSS Grid 2
==========

  <fantasai> https://github.com/w3c/csswg-drafts/issues/2564
  <fantasai> https://github.com/w3c/csswg-drafts/issues/2592

  fantasai: Requesting review on #2564, for #2592 can publish keeping
            this issue open.
  <chris> fantasai, Grid 1 is a CR. This is a transition request, not
          a publication request
  <chris> for updated CR
  <fantasai> chris, grid 2 is WD
  <chris> oh this is for grid 2, okay sorry
  Rossen: would prefer to have this as an open issue.

  Rossen: any objections to publishing as WD?
  [no objections]

  RESOLVED: publish a new Working Draft of Grid Level 2

Filter Effects
==============

Effect of filter on document element
------------------------------------
  github: https://github.com/w3c/fxtf-drafts/issues/282

  smfr: Question is whether this effects the root background color, by
        which I mean HTML body element. The way the spec currently
        stands it's possible to create unreadable text [paraphrased].
        Wonder if it's possible to allow the canvas's background color
        to be effected by filter()
  smfr: Summarized in issue, but what happens if you apply filter() to
        html element?
  smfr: Informal poll on twitter, authors didn't expect currently
        defined behavior, expecting inverted background
  <smfr> https://twitter.com/LeaVerou/status/1001859421469855744
  florian: Not sure about how the question was phrased, didn't seem to
           be clearly about the html element and various interactions
  <leaverou> (poll phrasing was exactly the same as smfr's
  <florian> the poll phrasing asked if people expected the invert
            filter "to make the default white background black" it did
            not ask if people expected that it would "make the default
            transparent background that is over a while background
            black"

  Rossen: One of the points being made is, when you do apply a filter
          that happens to apply to the default canvas background
          color, this is something that we have not specified. We are
          keeping this UA dependent. We might want to have the window
          or the canvas of the UA itself to be not necessarily want
          particular color. We may have special filters applied to it.
          In the more recent version of Windows, that's one of the
          defining principles. I'm not particularly excited in losing
          this ability in saying no, the background color would have
          to be a specced color, black or white.
  smfr: I don't think this is saying that. In webkit we have the
        ability to make the canvas transparent and have other things
        shine through. You would be apply to transparent pixels and
        the filter would be applied in the correct way. If there was a
        color, the filter would apply to that color
  Chris: what if the filters make the pixels transparent?
  Chris: I think we shouldn't allow a webview to become transparent
  [general consensus]
  smfr: When you're rendering with a filter, you essentially take a
        snapshot of the page, render the filter, and apply the
        snapshot.

  Florian: It seems simpler to say that the filter on the background
           effects the background color of the HTML element, and not
           the background behind it, which is white
  <chris> no, background on html is black (and background on root is
          transparent) see https://drafts.csswg.org/css-color/#sample
  Florian: From the twitter poll it seems to be referring to the white
           background behind transparent background

  AmeliaBR: Part of the problem is authors don't have a detailed
            understanding of how the background layers work in the spec
  chrisl: They don't understand the root behind html, those sort of
          details
  florian: Most people don't understand those, but can still ask the
           question: what do you expect? instead of suggesting an
           answer
  * chrisl needs a couple of good examples in the spec, and a diagram
           showing root, html, and body layers
  AmeliaBR: Regardless of exact poll details, I think we can accept
            this is a confusing topic and needs to be clearly defined
            and explained. There are a couple layers of it. By the
            fact that it hasn't come up, if you apply filter to html
            that would apply to a background image on the element, is
            everyone in agreement with that?
  [general consent] So long as there's another color behind that
  AmeliaBR: We have the canvas default color, behind that we have the
            background image or color set on the root element, or set
            on the body and propagated up to the root. The question is
            what if that layer has not been set and it defaults to
            transparent
  smfr: What you proposed is actually a behavior change in Chrome and
        FF
  AmeliaBR: That is a change but I think we agree it's logical. Next
            question: if there is no root bg on the element, then we
            still have the default canvas background, which is a
            separate layer. Used as separate in blend modes, where
            blend modes never affect that default canvas layer. I'm ok
            with saying that that default canvas layer is independent
            from filters, but need to communicate clearly to authors.
  AmeliaBR: If we let that never be effected by filters, we need to
            deal with if the filter makes that ??? layer partially
            transparent.

  chrishtr: 3 layers: root background, canvas layer, root element
            which may be different?
  AmeliaBR: The root element never has a background of its own, it's
            always propagated to the canvas.
  chrishtr: I think we can always have two layers
  Rossen: What we are getting at, if we have this model of 2 bg colors
          on the canvas, one which is modifiable by whatever comes
          from the root, and one which is not which is the very bottom
          background layer, UA defined, but it's blend-able with
          whatever's on top of it. The only way this could work is if
          the intermediate one is transparent. If body or html
          propagates to transparent, transparent is transparent. So
          you see whatever is on the bottom layer (the UA background
          canvas color)
  Rossen: We have one bottom layer which is non reachable by any CSS
          constructs, regardless of whether or not we are propagating.
          We have the intermediate layer that allows you to blend what
          you need to blend; author defined background color
          propagates to here. Is this the model we're trying to get to?
  smfr: Propagated color not necessarily opaque, rgba
  Rossen: But still not effecting the bottom layer. Don't want to
          punch a hole through webview by specifying transparent root
          bg color

  Florian: If the filter is applied to the transparent canvas, we
           would still see the white background behind it, right?
  Rossen: If we need to have an initial color on say html that gets
          propagated to background root element, that is different
          from transparent, we can discuss this
  Florian: Would be ok with default being white
  AmeliaBR: In spec we could have a warning that if you apply filter
            to the html element, then also need an opaque background
            for it to work correctly
  AmeliaBR: Think it can be handled with note to authors to apply
            background color to root element
  <florian> +1 to AmeliaBR

  smfr: What about applying filter to root elements for accessibility
        reasons? (UA etc) might be different from the author of the
        page
  smfr: We have some interest in this from dark themes on Mac
  fantasai: Could set white as default in that case, and user would've
            had to set root bg color explicitly to transparent

  Bo Campbell: Would like to look into this a little more from
               accessibility, can you help me understand that use case
               better?
  smfr: Someone with accessibility issues might want to avoid bright
        colors and apply a saturation filter to all the web pages they
        look at. Or they want to turn down brightness (don't want to
        see stark white background)
  Florian: In the user style sheet, they could set it to white, and
           only if author set to transparent would it break

  smfr: An option to allow filters to apply to default page bg would
        be to propagate the color from the bottom UA-controlled layer
        to the intermediate layer
  Rossen: The blending layer!
  chrishtr: smfr's proposal seems reasonable
  AmeliaBR: That proposal to always make the root background opaque,
            may mess with how blend modes currently work
  smfr: Will have to think carefully about blend modes w/ new
        conceptual model

  Rossen: Proposal is an intermediate layer where background from
          UA-controlled layer is propagated by default. All of the bg
          color propagation from HTML also propagates up to that
          intermediary layer. Can we try to adopt that model and
          resolve? otherwise take back to GH
  Rossen: Objections to adopting this model?
  Florian: Whether it gets the UA layer background color or not, I
           think that's what we have to think about more
  AmeliaBR: Quick test, looks like blend modes never effect the canvas
            layer even if explicitly set on root element. Still need
            careful consideration
  Florian: Open question is whether or not we propagate from the
           background layer or not
  AmeliaBR: If there is an explicit author-specified background, that
            layer that has gotten propagated on top of the canvas,
            filter does effect that. need a resolution on that
  Rossen: Objections to resolution in Amelia's comments?

  RESOLVED: if there is an explicit author-specified background, that
            layer that has gotten propagated on top of the canvas,
            filter does effect that.

CSS Contain
===========

Size contain shouldn't apply to tables
--------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/2746

  florian: We've already said that size containment doesn't apply to
           table parts, haven't said anything about tables. The way
           containment works, tables would end up smaller than their
           contents
  Florian: In the inline axis of tables we don't have a good
           definition or interop. In block axis seems to do nothing.
           In inline axis, in some browsers the borders go diagonal
  Florian: Think we should skip this here
  fantasai: I can imagine someone wanting to size constrain a table
            and put a scroller on it

  Florian: Proposal is to add tables to the list of things size
           containment doesn't apply to
  Rossen: Sounds reasonable
  Rossen: Objections? opinions?
  [none]

  RESOLVED: size containment doesn't apply to tables

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

Allow shape-outside to apply to initial letter
----------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/885

  fantasai: [explained two open questions in issue]
  fantasai: This is for initial letter in inline 3 spec. Should be
            able to handle combo of initial letter and shape-outside,
            we have to define that
  <AmeliaBR> +1 to allowing shape-outside: glyph or self anywhere, not
             just on initial-letter
  <chrisl> +1 to fantasai
  Rossen: One of the reasons we didn't want to add any geometric
          abstractions for shapes in level 1 is much higher
          implementation complexity. ??

  astearns: My solution is to enable you to use all the initial wrap
            values, either with the margin box or the shape outside.
            We'd get the ink wrapping behavior once we add it for
            shape outside
  astearns: See my updated comment in issue
  astearns: [reads out comment:
https://github.com/w3c/csswg-drafts/issues/885#issuecomment-397001523
]
  astearns: There is a problem in that you wouldn't get the full ink
            behavior until we define that for shape outside. That does
            make the parallel between letter wrapping and floating
            wrapping more solid.
  fantasai: Means that the first value cannot work on the shape
            specified on shape outside, Florian suggesting we make
            that work. Either the shape outside is controlling what we
            wrap the rest of the line to, or what we wrap that first
            line to
  astearns: Trying to match the rest of the word to the initial
            letter. If I've got a letter and want to wrap most of it
            around a circle, still want the rest of the word to move
            to match typographically
  fantasai: Could imagine someone would want to do that, but also see
            someone being like "This shape is replacing the glyph
            shape", wrap to that
  astearns: In my proposal, first line would definitely use ink bounds
            in every case. would get that, even with margin box
  fantasai: For an initial letter, the shape that we're wrapping to is
            the first letter shape, unless shape outside says
            "actually I want you to wrap to this other shape". we use
            glyph shape if shape outside is none, otherwise use
            provided shape
  florian: Both proposals seem valid and useful in different cases
  Rossen: Let's discuss further on Github and revisit next week
Received on Thursday, 14 June 2018 00:57:16 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 14 June 2018 00:57:17 UTC