[CSSWG] Minutes San Francisco F2F 2019-02-26 Part IV: Transforms, CSS UI [css-transforms] [css-ui]

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Transforms
----------

  - Discussed interaction of overflow and flattening; no clear
      conclusions yet.
  - mattwoodrow will put together an explainer for how Gecko handles
      3D rendering context penetration.
  - Inclined to have backface-visibility apply to all elements in 3D
      context
  - smfr will clean up the document of issues
        https://docs.google.com/document/d/1FIQW9qVPbZxn0pifFOXWWK0-7fXrjlSeYeZN7wHmIHo/edit#heading=h.zcumbwxv8iww
        Archived at
https://lists.w3.org/Archives/Public/www-archive/2019Mar/att-0001/01-part
      and new proposals and put them into github. At the same time
      he'll clean up the current github issues list.
  - Group will schedule a special telecon to go over these transforms
      issues before the next F2F
  - RESOLVED: Move Dean and Tess to former editor, add Matt as current.

CSS UI
------

  - RESOLVED: Auto computes to auto, but the used value does what it
              currently says auto computes to (Issue #3344)
  - Discussed how user-select: contain is assigned to editable
      elements: one option was to assume it at computed-value or
      used-value time; the other to assign it via UA styles, in which
      case it can be overridden.
  - RESOLVED: Close this issue as addressed, then publish a new WD
              once pending edits for this spec are done. (Issue #3024:
              Unprefix 'appearance' and/or make the spec
              web-compatible)

  - Discussion on issue #2846 (Consider requiring that descendants do
      not contribute to outline) led to a wider conversation about
      styling outlines.
      - There was concern about dynamically and unintentionally
          different behavior between when an element is in focus
          and when it's not, which is what Chrome does.
      - The property needs to be able to balance good functionality
          with letting authors maintain good design.
      - One idea was having 'outline-style: auto' do more complex
          shapes, while keeping other outline styles close to the
          border box
      - Microsoft recently did user testing on this topic and will
          turn their report into github issues once it's complete.
      - On the original topic about descendants more testing needs to
          occur because Firefox recently made some changes so there
          may be more or less compat then previously recorded.
      - gregwhitworth will file issues brought up in this discussion
          and the study

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

Agenda: https://wiki.csswg.org/planning/sf-2019

Scribe: AmeliaBR

++++++++++++
  This is the breakout focused on 3D Transforms
  The rest of the group's minutes are captured afterwards
++++++++++++

Transforms
==========

  <smfr> https://docs.google.com/document/d/1FIQW9qVPbZxn0pifFOXWWK0-7fXrjlSeYeZN7wHmIHo/edit#heading=h.zcumbwxv8iww
  [ Archived at
https://lists.w3.org/Archives/Public/www-archive/2019Mar/att-0001/01-part
]
  smfr: This is the 12-page explainer we're reviewing. (link above)
  smfr: Do we need basic explainer, or can we jump into the issues?
  (consensus: jump in)

Overflow a grouping property
----------------------------

  smfr: Issue 1, overflow as a grouping property
  smfr: Spec currently says that overflow causes a flattening, which
        limits many things like parallax effects.
  smfr: It's related to causing containing block. Transform style
        flows through dom tree. Maybe it would be better to flow
        through the containing block layout tree, so then a transform
        wouldn't need to force containing.
  <smfr> https://codepen.io/smfr/pen/ZPYjZq
  chrishtr: That doesn't sound right. Overflow:hidden should clip all
            descendants that can be contained within it, so the two go
            together. Transforms may not be same as abs pos, but it
            acts similar for painting.
  chrishtr: Compare A and B in Simon's example (Codepen link above)
  smfr: Top one, overflow isn't clipping B; bottom one it is
  chrishtr: Isn't that because of the position: absolute?
  smfr: Oh, that might break my demo...
  smfr: So, unless we want to change the behavior of transform things,
        we need to change something.

  chrishtr: But the issue is that if overflow is grouping, that
            implies flattening, which implies a stacking context, but
            overflow doesn't create a stacking context.
  smfr: But unless you do flattening, I don't think you can clip. The
        elements are into 3D space.
  AmeliaBR: Could you possibly partially flatten sections after
            dividing elements by stacking layer? It's a bit of a mess,
            but there's no sane way to mix 3D z-ordering and z-index.
  mattwoodrow: Also, as I comment there, how do you decide what is the
               scrolling region without first flattening?
  mattwoodrow: It's particularly problematic with `preserve-3d`, since
               the used style still gets forced to flat.
  chrishtr: So we'd need to make overflow: hidden/scroll part of the
            transform-style, in that it is always the end boundary. It
            changes to flat *and* forces a stacking context.
  TabAtkins: So only in that combination, would it all happen.
  mattwoodrow: It's still pretty confusing in the `transform-style`
               three-value syntax
  chrishtr: So, what does `auto` mean?
  Amelia: Flatten under various conditions, e.g. stacking context or
          overflow hidden, but pass through 3D context if it is not
          complicated. `preserve-3d` says pass through even if the
          current element has transforms, which would usually trigger
          flattening.
  chrishtr: So, can we do what Matt said?
  dbaron: We're discussing what triggers flattening
  chrishtr: We can assume every element for now, then focus on
            developer ergonomics

  [ some minutes missed due to connection issue ]

3D Rendering Context Penetration
---------------------------------
  Scribe: TabAtkins

  <smfr> https://webkit.org/blog-files/3d-transforms/morphing-cubes.html
  smfr: So you're saying that when "cube" is rendering into its
        ancestor, you flatten. In WK we flatten when rendering the
        children.
  smfr: But that results in the same rendering at the end.
  AmeliaBR: Would the behavior differ if there was a second cube?
  smfr: WK will depth-sort these all together in that case.
  dbaron: Are you sure you're reading this correctly?
  dbaron: Two sibling cubes both with preserve-3d
  mattwoordrow: Right, their *parent* doesn't have preserve-3d, so the
                cubes themselves establish 3d rendering contexts.

  TabAtkins: So is *anyone's* current behavior actually described in a
             spec?
  smfr: No. Current WK behavior is the result of someone bolting CG 3d
        support into the web, and me trying to write up a model into a
        spec.
  mattwoodrow: Right. I think there's a lot of confusion here. I think
               Firefox's behavior is simple to understand, and it
               mostly works for web content.
  TabAtkins: So Firefox does what the spec originally was written to
             say - the highest element with preserve-3d establishes a
             3d scene; descendants have to say preserve-3d to stay in
             that scene
  chrishtr: Simon, sounds like Gecko's model is something we might be
            able to adopt, assuming compat works?
  smfr: It's different from the conceptual model we had before...
  smfr: If we ignore the property values right now, but describe
        things in terms of establishing 3d and participating in 3d, do
        we still have a clear model of clipping and 3d contexts?

  chrishtr: So what about the following model:
  chrishtr: Adjacent things with preserve-3d are in the same 3d scene.
            preserve-3d always establishes a stacking context, so you
            can't mix z-ordering and 3d transforming.
  chrishtr: Any of the grouping properties in the ED spec, when
            combined with a specified style of preserve-3d, will cause
            a used value of flat.
  chrishtr: After the flattening, apply the property's effect
            (clipping, etc)
  smfr: Sounds like ED + this explainer?
  AmeliaBR: Sounds like would be most helpful to have this written
            down by people.

  Rossen: Going back to adjacent preserve-3d elements... What about
          when they're intertwined with non-preserve-3d elements?
  smfr: So if we have a non-3d sibling between the cubes, the non-3d
        renders into the 2d plane of the parent...
  AmeliaBR: Under Gecko's model, is it useful to have perspective on
            non preserve-3d elements?
  TabAtkins: No, it won't do anything.
  mattwoodrow: We might have a different model here too - perspective
               on an element with a 3d transform by itself, will cause
               the perspective to happen
  dbaron: If you think about the process as doing leaves-up,
          perspective is the only things that happens *after*
          scrolling but *before* scroller-caused flattening.
  smfr: So part of the reason I went from ED to WD format is I
        couldn't get ED format to have a consistent model.
  smfr: But maybe it does require putting preserve-3d on all
        ancestors, tho I fear the webcompat implications of that.
  TabAtkins: Apparently it works for Firefox.
  AmeliaBR: Spamming preserve-3d across the tree until it works is a
            common authoring style in my experience.

  mattwoodrow: I can put together an explainer for Gecko in the next
               week or two.
  smfr: One of the differences in our behavior is if you have an
        element with a simple 3d transform, does it start intersecting
        with the plane it's in? Safari does that, maybe unexpected.
  TabAtkins: Yeah, unexpected to me without preserve-3d; I thought it
             would transform and flatten when painting into the parent.
  AmeliaBR: Focus on logical model first, then what properties and
            what value to control that.
  smfr: Reftest strategy: clippath to only show a chunk of the
        interior, or exterior, so you avoid anti-aliasing on edges

backface-visiblity
------------------

  smfr: Simple case, element is flipped over. With
        backface-visibility: off, the element disappears.
  smfr: If there's an element inside of it with the
        backface-visibility, does it stop rendering?

  dbaron: Is the outer flattened?
  dbaron: Speaking directly from ideas, if the outer element flattens,
          the child's backface-visibility won't matter when you flip
          the parent.
  mattwoodrow: Almost. Actual implementation is that
               backface-visibility creates a pseudo-stacking context
  mattwoodrow: [missed explanation ;_;]
  mattwoodrow: Spec says the property applies to the element and not
               its descendants
  mattwoodrow: Case: 3d rendering root with 2 children
  mattwoodrow: Back face is flipped around, so it's 3d and a stacking
               context. Front face doesn't have anything, so it's not
               a stacking context.
  mattwoodrow: So when you flip around the parent, the "front" face
               doesn't have its backfaces hidden.
  mattwoodrow: It looks like WK doesn't flatten positioned descendants
               of a backface-visibility:no element.
  mattwoodrow: I would prefer to say backface-visibility:hidden
               creates a stacking context.
  mattwoodrow: I don't think some children popping out and not getting
               hidden is a desirable thing.

  smfr: backface-visibility is a cargocult property pages sometimes do
        to trigger compositing
  smfr: Another option is to say only works if it has a transform, or
        participates in a 3d rendering context.
  mattwoodrow: Harder to explain.
  smfr: When we see backface-visibility:hidden we do a compositing
        thing. We look at preserve-3d on the stacking context.
  smfr: So it's really if it's doing 3d rendering. It does nothing if
        it's not participating in 3d.
  smfr: I'd prefer backface-visibility triggering *new* side effects,
        but I'd be willing to have it causing less side effects.

  mattwoodrow: Will a stacking context break things?
  smfr: Right now we only do it when it's in 3d.
  mattwoodrow: I think we can specify that.

  smfr: I think the spec is also wrong... talking about computing the
        matrix relative to the nearest 3d rendering context.
  smfr: People really want it relative to the view/window
  AmeliaBR: If there's flattening somewhere it's relative to that,
            otherwise it'll be relative to the view, basically.

  AmeliaBR: Can we take this explainer and turn it into GH issues so
            people can comment?
  smfr: We could. Not sure this is a great distillation of the issues.
  smfr: We should definitely clean up existing issues, and make sure
        any new issues from this are raised.
  AmeliaBR: I'm thinking of some people that do experimentation with
            3d and know the bugs...
  smfr: We should get them into the WG.
  smfr: I'll sign up to clean up the GH issues.
  AmeliaBR: Let me know when you do and I'll set Ana Tudor on it.

  Rossen: So what about backface-visibility issue?
  smfr: We decided we wanted backface-visibility to apply to things in
        a 3d rendering context.

Mixing stacking contexts and 3D transforms
------------------------------------------

  smfr: Something in the explainer... [draws]
  smfr: Mixing stacking context and 3d transforms.
        <div stacking>
          <div 3d />
          <div stacking>
            <div 3d />
            <div 3d />
          </div>
        </div>
  smfr: So all the 3d divs have different z transforms.
  dbaron: Isn't isolate a grouping property? It would flatten, so the
          latter two don't z-sort with the first.

  dbaron: Also, after writing up happens, maybe useful to schedule a
          special telcon, maybe longer than an hour, to go thru all
          this before the next f2f
  Rossen: Agree.

  [discussion about editing]

  RESOLVED: Move Dean and Tess to former editor, add Matt as current.

+++++++++++++++++++++++++++++++++++++
  This is the regular group's minutes
+++++++++++++++++++++++++++++++++++++

CSS UI
======
  Scribe: myles

The computed value rules of user-select is problematic
------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3344

  emilio: user-select is messy. It’s inherited in some engines, but
          not in others. It has different initial values in some. I
          wanted to make it less insane, but the spec specifies that
          the initial value of the property is different depending on
          the element, which is not great.
  emilio: Depending on whether the element is editable or not, the
          initial value is different. I like when my initial styles
          are all shared.
  emilio: There is an unspecified value, but it computes to something
          at computed value times, was to support user-select:contain,
          IIRC
  emilio: I don’t want the computed value to be different depending on
          which element the style applies to. We should do something
          closer to what Gecko does, which is close to WebKit and
          Blink. The initial value is auto, and once you specify it,
          that inherits down the tree
  emilio: Proposal is to make it non-inherited. Initial value is auto,
          and auto behaves differently depending on which element it
          applies to at used-value time

  florian: I was on an agreement roller coaster
  florian: user-select:contain, only Edge exposes as a value, but all
           browsers have it as a behavior. This is how selection works
           when you’re in an editable element. Selection can’t escape
           that element. All browsers do that. In Edge, that’s
           explained by the user-select:contain
  florian: Now that it’s a value, you can apply that value to other
           things.
  florian: Maybe you want to contain your selection to the body of
           content, so you don’t select UI
  florian: Maybe we need selective inheritance. All values inherit,
           except “contain”
  florian: Propagation would work this way. So the child of contain
           should be something else, but otherwise things inherit
           normally. At computed-value time this would be easier. If
           from an implementor point of view at used-value time is
           simpler, okay
  florian: It’s almost the same thing.
  florian: To support user-select:all, you might have to implement it
           anyway. The user difference is non-existent. Is it simpler
           in other engines?
  emilio: The current spec says “the property is reset in certain
          places, the property is not inherited, all values except
          contain effectively inherit, so you end up needing to change
          all engines to copy-on-write, which WebKit, blink, and Gecko
          do
  florian: It’s not inherited. If the value is auto, look at the
           parent.
  koji: Blink already experienced that once before, but used value is
        easier for us, too
  florian: Okay
  emilio: Using this at computed value time means it breaks style
          system optimizations that assume non-inherited styles
          change, don’t need to restyle children.
  emilio: Also, given the initial value depends on the element it
          applies to, you no longer have a canonical initial value
          representation. Used value is better
  florian: Is it reasonable to assume webkit’s cooperation?

  astearns: proposed resolution: auto computes to auto, but the used
            value does what it currently says auto computes to
  dholbert: This needs to be reflected in the used value, too

  RESOLVED: Auto computes to auto, but the used value does what it
            currently says auto computes to

  florian: There is some more magic here. Currently, on editable
           elements, the computed value is always contain, regardless.
           Should we keep it at computed value time or used?
  emilio: UA rule, so it can be override it.
  florian: We didn’t want it to be overridable
  emilio: Gecko allows it to be overridden. But it’s fine

Unprefix 'appearance' and/or make the spec web-compatible
---------------------------------------------------------
  Scribe: heycam
  github: https://github.com/w3c/csswg-drafts/issues/3024

  florian: I can do a progress report
  florian: zcorpan, fantasai, and I discussed this
  florian: we reached an agreement
  florian: Last time we appeared to have opposing visions
  florian: we no longer do
  florian: We've fixed the high-level mechanics part of the spec based
           on that agreement
  florian: and there remained the details about small exceptions/
           tweaks for web compat on top of that general principle
  florian: The parts that haven't been made should be marked as open
           issues in the spec
  florian: afaik we now have a model that everyone agrees about
  <fantasai> Spec https://drafts.csswg.org/css-ui-4/#appearance-switching

  iank: 2 sentence tldr?
  florian: The appearance property with a gazillion values for
           expressing UA sheet is not what we're going to do
  florian: The model is now based on auto/none, initial value none
  florian: UA sheets do auto on all elements that need special behavior
  florian: due to HTML semantics they'll look right
  florian: That's not sufficient for webcompat
  florian: Maybe 6...12 values that are used by authors
  florian: Most of them can be made to do the same thing as auto
  florian: As we're not interested in e.g. allowing people to turn
           drop down menus into checkboxes
  florian: If you use any of the non-none values on a form control, it
           will be its normal self, with a few special exceptions
  fantasai: There were also a couple of values that will work on other
            elements
  florian: Like button, to buttonize an element
  fantasai: And textfield, to make it look like a text input

  iank: Looks like zcorpan did a good job doing compat analysis based
        on our data
  florian: We're kind of close to the high-level model we had
           previously, but the details that are necessary for web
           compat is mostly coming from zcorpan
  florian: and both sides of that discussion is happy with the other
  fantasai: You, me, fremy, and zcorpan

  astearns: There were a few things remaining that should be spec
            issues?
  florian: There are places in the spec with issue boxes already
  florian: Details needed based on compat info
  fantasai: We should at some point resolve and publish a draft
  fantasai: and continue filling in details
  florian: I need to refresh my memory on the exact status of it all

  fantasai: High level summary is: we have an appearance property,
            initial value is none
  fantasai: it has the values none | auto | button | textfield and a
            bunch of compat keywords that map to auto
  fantasai: UA sheet sets auto on most form controls
  fantasai: then there will be minor tweaks for compat as needed
  astearns: That's in the ED now?
  fantasai: Yes
  astearns: Sounds like we can close this issue as addressed in the
            draft, and publish a draft, and open new issues for
            specific things
  florian: As for publishing, we should do it after I apply the edits
           from the user-select discussions
  florian: I'll add those in then put a WD out
  astearns: So let's resolve now to resolve this issue with what's in
            the draft and with an intent to publish after the edits

  RESOLVED: Close this issue as addressed, then publish a new WD once
            pending edits for this spec are done.

Consider requiring that descendants do not contribute to outline
----------------------------------------------------------------
  Scribe: fantasai
  github: https://github.com/w3c/csswg-drafts/issues/2846

  heycam: A little while ago I brought up the fact that in Gecko we
          include a lot of descendant boxes when rendering outlines
  heycam: and we do get some compat issues from that
  heycam: because essentially in Blink and WebKit, and I didn't
          recently test Edge, outline only is derived from the
          position and size of that element's principal box
  heycam: Different things happen
  heycam: but the important difference is that no descendants
          contribute to the outline position or size
  heycam: Definition of outline in the spec is deliberately vague so
          that UAs can do something fancy, for focus outlines
  heycam: but there is a suggestion that descendants should contribute
          to the outline
  heycam: but I'm suggesting that we switch the suggestion to say that
          they should not
  iank: ...
  iank: The tl;dr is that there's the outline property which renders
        one way, and we agree that it shouldn't include descendants
  iank: but then there's the focus outline, when an element is
        focusable and you focus it
  iank: You might want to handle that a different way

  florian: The spec view of the problem is that there's an
           outline-style called auto, which allows you to be crazier
           in how you do your outline
  florian: You can do whatever you want
  florian: Intent is that browsers implement focus outline with that
  florian: What UAs actually do, maybe it's different
  emilio: outline-style: auto not only changes shape of outline, but
          also uses the system focus outline style
  emilio: Firefox does something weird on Linux, because bugs, but
          that's it
  emilio: it should otherwise match the OS
  emilio: Not just about changing shape but also style

  gregwhitworth: Was curious about removing descendants from outline
  gregwhitworth: I don't want removing descendants from focus to be
                 the default
  iank: I think we agree
  iank: The behavior that I think we want is for the outline property,
        it doesn't include descendants
  iank: but for focus outline it does
  florian: Define focus outline
  gregwhitworth: Rob Dobson and Alice Boxhall were thinking that it
                 shouldn't follow descendants
  gregwhitworth: but currently it does
  iank: Why for focus outline, by default, should it enclose
        descendants?
  gregwhitworth: Because the scenarios where it's a problem, I can
                 find just as many where not enclosing is also a
                 problem
  gregwhitworth: Many cases where Chrome's rendering looks weird e.g.
                 in FB on Chrome
  gregwhitworth: Other cases it looks weird
  gregwhitworth: e.g. wrapping around weird pseudo-elements
  iank: Would it change your opinion if it didn't have the weird
        squiggle and just had a bounding rect (instead of
        non-rectangular shape)
  gregwhitworth: That's happening because looping in descendants
  iank: You could have an alternate implementation that's just a
        bounding rect
  gregwhitworth: I'd be more OK with that
  <florian> that's what presto did
  gregwhitworth: Saying that these few sites, we no longer care about
                 descendants, seems odd

  iank: We need to check with Alice and Rob, but there didn't seem to
        be a use case for non-rectangular focus outline
  iank: Thinking about simplifying and just doing the bounding box
  iank: Then the question is in that state, what's the best
        calculation?
  fremy: Reason why important for focus outline to include
         descendants, e.g. if you have inline links whose contents
         consist of an abspos element
  fremy: If you don't include abspos element, you aren't able to
         actually show the focus ring around the link
  fremy: I'm curious if you can do it with one single rectangle
  fremy: because if the link element is in one part of the page but
         the abspos item that is the clickable target is elsewhere,
         there's a large rectangle around the page... it's not clear
         what's focused
  heycam: ...

  iank: Splitting the discussion slightly, sounds like everyone would
        be fine if the non-auto outline style ...
  iank: Sounds like we'd be fine with it not including descendants and
        just being the border box

  florian: Want to clarify definitions
  florian: The definition of focus outline that is in the issue that
           you refer to
  florian: includes some cases of the property-based outline
  florian: In the issue now there is the definition of focus outline
           being either:
  florian: a) the outline painted whichever way while the element is
           in focus or
  florian: b) when the outline-style is auto
  atotic: That's how it's implemented in Chrome atm
  florian: Alternate definition is "only outline when element is in
           focus"
  <fantasai> Another definition would be only when it's non-auto...
  gregwhitworth: You need to be focused and outline

  fantasai: So this definition is a little weird, let's say I set an
            outline: solid purple on a link
  fantasai: and the behavior will change depending on whether we focus
            the link
  iank: This is what we currently implement today
  fantasai: We need a definition that doesn't do that
  fantasai: Same outline derived from the same style rule shouldn't
            behave differently when I focus the element and then go
            back to behaving different when it's unfocused
  <bkardell> it is still a problem
  jensimmons: outline: 0 no longer appears on CSS resets anymore
  jensimmons: nor frameworks. Of course some people still do that
              but...
  jensimmons: Word has gotten out, don't do that. Of course ppl still
              do it, but it's getting better
  <tantek> for the record, that was fixed in Eric Meyer's CSS Reset
           back in 2011: https://meyerweb.com/eric/tools/css/reset/

  emilio: I'm a bit confused. Firefox used to conditionally include
          both in-flow and out-of-flow descendants for all kinds of
          outlines
  emilio: Then xidorn changed to only include in-flow elements
  heycam: I think only for abspos
  emilio: As far as I understand, one of the use cases we want to
          bring back...
  emilio: Does Blink include overflows in their descendant stuff?
  atotic: It depends. Only if the outline is around the containing
          block
  emilio: Ancestor containing block?
  atotic: *emphatic shrug*
  emilio: I agree with fantasai that having two different behaviors
          depending on whether focused or not is very weird.
  emilio: Maybe take greg's advice to give authors control
  atotic: Our behavior is OK because we don't do bounding box, if
          boxes are disjointed then they each get outlined
  atotic: Now that merging boxes, less tolerable
  <gregwhitworth> I'm not seeing Chrome wrap this abspos in focus:
                  https://jsbin.com/muyemusofo/1/edit?html,css,output
  florian: Two kinds of merging boxes
  florian: One is when boxes are not next to each other, have a box
           around each
  florian: Other is when they touch each other have either a
           non-rectangular outline that wraps both
  florian: or bounding box
  florian: E.g. For Presto, if two fragments being outlined are not
           adjacent, you get two outlines
  florian: but if they are adjacent, you get one non-rectangular
           outline around the whole shape
  florian: There are nuances within this
  emilio: I think we should come up with a consistent plan

  bkardell: I think it is still a pretty significant problem that part
            of the reason historically that developers couldn't tap
            into the right thing to say whether you even should draw
            the outline because didn't have :focus-visible
  bkardell: Will help when :focus-visible is implemented everywhere.
            Also :focus-visible-within
  bkardell: I've seen a lot of ppl make comments about confusion
            around outline
  bkardell: Maybe we should really have two properties
  fantasai: Or a switch between behaviors
  bkardell: Using same thing for two purposes seems quite strange
  bkardell: We tell ppl don't use border, use outline for focus
            rectangles
  bkardell: So we could use borders
  bkardell: Maybe have a thing that's about focus rectangle
  fantasai: I think there was a proposal at some point to have
            'outline-style: auto' be the one intended for focus rings,
            which has the special behaviors of going around
            descendants or being non-rectangular or whatever (up to UA)
  fantasai: and other outline-style values give a more normalized
            outline shape, appropriate for extra "border" looking
            things
  <fremy> +1 to what fantasai just said

  florian: We have half of this. When outline-style is auto, it's
           reasonable to assume this is being used for focus. I don't
           think ppl use it for decorative styles
  florian: Other half is less clear. It's often used decoratively, but
           not strictly
  florian: We can spec the auto style to be just the right thing for
           outline styles
  florian: Maybe time will help
  florian: When we get around finalizing spec and implementation, once
           we have multiple borders or gradients within borders, maybe
           ppl will use those instead of outlines
  florian: but we don't have that yet. And might take awhile for ppl
           to move over

  <gregwhitworth> inline desc are wrapped https://output.jsbin.com/gimiwigije/1

  iank: The other thing is for accessibility use case, we don't have
        the right people in the room, so it will be a lot of time with
        our a11y experts to not break a11y in this space
  fremy: I work on that, btw
  gregwhitworth: melanierichards is also here

  bkardell: It feels like we're not really serving the best use cases
            that we could
  bkardell: Alice and I have talked around about this, just recently
            Eric Meyer was doing some stuff at An Event Apart, talking
            about his frustrations about how to make things that are
            both beautiful and accessible
  bkardell: It's pretty hard
  bkardell: You don't have a lot of control over what outlines can
            look like just with outline, and if you have a really
            beautiful design, you end up having to do a lot of design
            specifically for the outline as well
  <tantek> Are there specific examples of such "really beautiful
           design" where this is a challenge?
  bkardell: A lot of OSes have developed what I assume is glowy
            outlines
  bkardell: An advantage is that there's a light path and a dark path,
            and you'll be able to see at least one of them
  bkardell: so when he was working on that, we came up with a hack to
            make multi-colored pseudo-border outlines that don't
            affect layout
  bkardell: We could serve that better and more appealing, then more
            likely ppl make accessible things
  bkardell: As Alice says, I assume devs want to do the right thing,
            just if we make it harder they're less likely to

  gregwhitworth: I 100% agree with bkardell
  gregwhitworth: We are currently finishing up a study with 160 users
                 on focus testing, for this reason
  gregwhitworth: because we believe the one in Chromium is not
                 sufficient
  gregwhitworth: One issue is what bkardell brought up
  gregwhitworth: We also looked into prototyping always-visible
                 outlines
  gregwhitworth: to provide sufficient contrast
  gregwhitworth: I saw emeyers' scenario of always wanting to ensure
                 high contrast
  gregwhitworth: What's interesting is that Mozilla has a property
                 that they proposed years ago to effectively provide
                 an inversion color as a color keyword
  gregwhitworth: so you can use a keyword where you can't use the
                 inversion value
  gregwhitworth: It's just that it looks really gross when you want a
                 great design
  gregwhitworth: Two things that came up out of that testing
  gregwhitworth: One, doing a good focus rect in browser sucks
  gregwhitworth: doesn't follow border radius is problematic
  gregwhitworth: I had to hack with border outline and drop-shadow to
                 get the right effect
  gregwhitworth: I think we should tease out the pieces of following
                 the rect
  gregwhitworth: Also want to have gradient
  gregwhitworth: Similar to ...
  gregwhitworth: In addition, emilio's proposal of whether or not you
                 want to include descendants or not
  gregwhitworth: will share more publicly once we have the report
  emilio: what he said.
  <bkardell> tantek does greg's expanding answer your question?

  heycam: It think most important thing given distinction between
          focus outlines and decorative outlines
  heycam: We should write down which particular descendants get
          included, because that's the particular difference between
          FF and other browsers that's an issue for us
  heycam: At the moment, we include all in-flow descendants
  gregwhitworth: I have interop on all 3 browsers in Windows
  [discussion about testing]
  heycam: I only tested normal outlines, and definitely saw differences
  emilio: Also Firefox only changed recently, might want to test
          Nightly
  astearns: Sounds like we won't resolve anything right now, but we
            need to figure out interop
  astearns: First thing to figure out as we go through these issues in
            addition
  heycam: So next step is wait for this report?

  ACTION: gregwhitworth open issues against outline on all the
          aforementioned issues

  astearns: Let's keep this issue on descendants and open more issues
            for the rest
  astearns: OK that's it for this topic!

  <br type=tea>

Received on Thursday, 4 April 2019 23:08:45 UTC