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

[CSSWG] Minutes Paris F2F 2017-08-02 Part III: Flexbox, Selectors, focus-ring [css-flexbox] [css-selectors]

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 27 Aug 2017 14:56:44 -0400
Message-ID: <CADhPm3stVGZMO8rASBVjPYY4e0wWQntZKUxUEAYGwTTAgUgKPA@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.
=========================================


Flexbox
-------

  - Discussion of issue #2 devolved into disagreement on how to
      word the note at the bottom of section 5.4.1; a GitHub issue
      was filed to address this.
  - Definitiveness of flex items main size needs input from the UAs'
      flex engineers. Issue: https://github.com/w3c/csswg-drafts/issues/1290
  - RESOLVED: Percentage margins & paddings compute to 0 in
              intrinsic sizing and then resolve during layout.
  - RESOLVED: box-sizing is accounted for in the flex algorithm so
              that the flex ratios reflect the distribution of the
              specified box; add a note in the spec wrt web compat

Selectors
---------

  - fantasai will review the edits to Selectors 4 ED before the
      group resolves to republish as a WD.
  - RESOLVED: Take changes outlined in 3rd comment in the issue
              https://github.com/w3c/csswg-drafts/issues/1240, with
              Tab's amendment re: must not match focus.

focus-ring
----------

  - RESOLVED: focus-ring pseudo matches IFF browser native focus
              ring would be displaying on that element
  - RESOLVED: Feature to add focus-ring to other elements should
              affect whether browser native focus-ring shows up or
              not, and then the :focus-ring pseudo just follows
              from that. (Such a feature would not be specific to
              controlling the :focus-ring pseudo's behavior.)

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

Agenda: https://wiki.csswg.org/planning/paris-2017#topics

Scribe: gregwhitworth

Flexbox
=======

  astearns: there are a whole bunch of issues in the DOC
  <astearns> https://drafts.csswg.org/css-flexbox/issues-cr-20160526

Add property for switching keyboarding order DOM vs flex order
--------------------------------------------------------------
  Topic: https://drafts.csswg.org/css-flexbox/issues-cr-20160526#issue-2

  fantasai: First open issue.
  fantasai: We have had many issues about keyboarding tab index with
            DOM order vs visual order.
  fantasai: There was another thread opened up.
  fantasai: So far, no we're not going to do this with links to the
            discussion
  fantasai: Since it was re-raised we need a working group
            resolution.
  tantek: Was there new info?
  fantasai: No.

  Rossen: I think our last discussion was in an APA WG, I thought we
          resolved to allow either.
  fantasai: We did not resolve that way.
  Rossen: Is this something that they're ok with?
  astearns: No they're not ok with it, they keep re-raising it and
            we keep giving the same answer.

  Florian: It's a bit of a tangent, but in CSS3UI there is spatial
           navigation.
  Florian: Maybe in the next level we can allow people to navigate
           via visual order.
  Florian: If you sync navigation with this it may solve issues in
           grid, flex, etc.
  astearns: That seems like a good way forward.
  fantasai: The problem is their request currently isn't generic,
            it's solely focused on flex when order is used.
  Florian: Maybe we should try to convince people to stop discussing
           visual order, there is only order when things are linear,
           but visually we're in a 2d space, which is not strictly
           ordered.
  astearns: There are many possible orders.

  tantek: I was trying to see if there is new information.
  tantek: a11y issues are very important, some of the wording seems
          "newish"
  tantek: The spec is actually vague here.
  tantek: It doesn't actually say you need to do this type of
          keyboard navigation.
  fantasai: Firefox's behavior doesn't fit into either behavior.
  tantek: The spec doesn't define beyond informal note.
  fantasai: The spec talks about sequential nav order and clarifies
            that it's not talking about spatial navigation order.
  fantasai: It is allowed to have a special navigation, but not just
            for flex order. If it has something that is logical and
            based on the content, then the spec requires to follow
            the DOM order.
  tantek: I'm not getting that from reading her email.
  fantasai: *reads from the spec*
  <fantasai> https://drafts.csswg.org/css-flexbox/#order-accessibility
  tantek: Right, leaves room for interpretation.

  fantasai: Firefox was violating that.
  fantasai: If you have a webpage and you have one version with the
            order property, one without they should traverse it the
            same.
  tantek: It states default, and that's an important word.
  tantek: Please file tests to prove we're wrong.
  astearns: Default is defined elsewhere.
  tantek: It's outside the scope of the spec, you can't test this.
  fantasai: Did you change the default, if not then it shouldn't
            change with order?
  [back and forth argument between tantek and Florian]
  tantek: I think the spec allows what Firefox did which does what
          Leonie likes.
  tantek: We need to resolve it postpone, not reject it.

  <rachelandrew> more here
https://alastairc.ac/2017/06/the-responsive-order-conflict

  Rossen: I found a note, based on our discussion last time
  Rossen: *reads note*
  <astearns> end of https://drafts.csswg.org/css-flexbox/#order-accessibility
  [Note Text:
      User agents, including browsers, accessible technology, and
      extensions, may offer spatial navigation features. This
      section does not preclude respecting the order property when
      determining element ordering in such spatial navigation modes;
      indeed it would need to be considered for such a feature to
      work. But order is not the only (or even the primary) CSS
      property that would need to be considered for such a spatial
      navigation feature. A well-implemented spatial navigation
      feature would need to consider all the layout features of CSS
      that modify spatial relationships.
  ]
  Rossen: This was explicitly added so that if a UA wants to explore
          in this space they can
  Rossen: so in this respect, the note was added for uses such as
          Firefox.
  Rossen: If you're following the order within Flex then that's what
          we added for it to allow.
  fantasai: No it wasn't.
  tantek: That's great it's an informative note.
  fantasai: Authors need to be able to know what happens here, we
            need interop.
  fantasai: We either enforce what's there or change our opinion
            and have all browsers follow.
  tantek: That is a strawman.
  tantek: When we agreed on this informative note, that was a
          consensus to allow for interop differences
  fantasai: Either we require following order or we forbid it. I
            will object to leaving that up to the UA.
  tantek: I only want the last sentence removed as it's conformant
          requirement.

  Florian: I disagree with the way that you're reading the
           conclusion you've reached.
  Florian: We've agreed that sequential navigation works ignoring
           'order', but you may take other things into account.
           Completely separate.
  <fantasai> +1 to Florian, that is exactly what this prose is
             intended to convey
  <rachelandrew> +1 to Florian
  tantek: Taking sequential from spatial is no where in Leonie's
          email.
  fantasai: The prose currently in the spec was added in response to
            a different, earlier set of discussions, not about
            Leonie's email.

  dbaron: I agree with what Florian and fantasai say the spec
          currently says and disagree with tantek about what it
          currently says. But the note is expressing a conformance
          requirement in the third sentence that should either be
          removed or needs to be in normative prose.
  <astearns> +1
  tantek: Drop that last sentence from the note.
  fantasai: I refuse to drop text here.

  fremy: I am 100% sure that we added this for screen readers, so
         that they can innovate by adding additional modes of
         navigation. But not to affect tab navigation.
  Florian: Tab is not spatial navigation.
  <tantek> the whole sequential vs spatial is a in-the-weeds red
           herring
  <tantek> Leonie's email only mentions "visual order" and "keyboard
           order"
  fremy: This allows them to. For tab navigation you can't accept
         that browsers will tab one way and not in another way.
  fremy: Then if the user decides they want another setting then
         they can change it.
  fremy: You have an opt in as a user.
  fremy: As an author I need to be able to ensure that there is
         interop or they'll re-implement order themselves.
  fremy: It has to be the same.
  fremy: I am with fantasai if the spec needs to be clarified.
  fremy: To me it seems that Firefox's behavior does whatever
         it wants and doesn't care what the spec says.
  fantasai: And you keep the tab order, speech order, etc together.
  dbaron: I believe the tab order and the acc tree work off the box
          tree in Gecko
  dbaron: which I consider a bug, and I think is unusual.
  dbaron: I think a11y tree and tab order are consistent.
  fremy: Edge uses the box tree right.
  Rossen: For some cases, yes.
  <dbaron> Actually it seems like our a11y code follows the DOM tree
           now.

  <tantek> PROPOSAL: drop the sentence ending with " is
           non-conforming." from the informative note at the end of
           5.4.1
  astearns: The second sentence in 5.4.1 - is the conformance
            requirement that order does not affect sequential
            navigation.
  astearns: The note says that if you're doing other navigation,
            then you can try other things.
  fantasai: That third sentence is providing an example of where a
            UA would be non conforming by doing spatial navigation
            but only when order property is used.
  <dbaron> I mostly agree with Alan but I think the word sequential
           in "However a UA that uses order in determining
           sequential navigation, but does not otherwise account for
           spatial relationships among elements (as expressed by the
           various layout features of CSS including and not limited
           to flex layout), is non-conforming." is confusing.
  <dbaron> because I think it really means "in determining
           navigation"
  Florian: I think the capability would be allowed, but only if the
           default was following sequential
  fantasai: I wouldn't be ok with that, it would need to take into
            account everything else, flex direction, order, etc
  Florian: I agree it's not as complete as possible. I don't think
           that we should ban people from innovation. Allow them to
           place them under a separate menu.
  astearns: We already have normative text that states how this
            should work.
  astearns: As Florian said that it does allow innovation.
  fantasai: But then you can do sorta sequential kinda special
            navigation. No you can't do that.

  fantasai: The renaming things does not get you out of having to
            follow the spec. If you want to be non-conforming be
            non-conforming
  astearns: Would work to change the text in the note that UAs may
            offer spatial navigation in addition to sequential nav
            features that they must provide?
  Florian: Is there already a requirement for sequential nav at all?
  astearns: I don't know.
  fantasai: Requiring sequential navigation is probably a bit too
            far.
  <tantek> strawmanning is not helpful here
  <tantek> It makes zero sense to make any "conforming" or
           "non-conforming" claims in a NOTE
  <fantasai> it's an example, tantek. If you want I will put a
             yellow box around it instead of a green one
  <tantek> no if it has the text "conforming" or "non-conforming" it
           is no longer just an example, and is misleading
  <fantasai> "These examples are conforming, these examples are
             non-conforming" is perfectly normal use of examples,
             tantek
  <tantek> no fantasai, that statement does not say "example"
           anywhere

  astearns: The main problem is that there is a normative
            requirement in the note. I suggest that we take about 30
            seconds and make it not have conformance states.
  fantasai: But we do mean that you can't be conforming if you do
            that.
  fantasai: That's just renaming things to get out of conformance
            requirements.
  fantasai: No it's not a conformance requirement in the note, it's
            an example.
  fantasai: We do that in other specs.
  <tantek> so simple solution, just drop that sentence from the note
  <fantasai> tantek, alternate solution: add the word example
  <tantek> I think it's really bad spec authoring practice to put
           any use of "conforming" in an informative note. Do any
           other specs do this anywhere?

  astearns: From the discussion I have heard I don't think we have
            consensus to make this conformance requirement.
  Florian: I think we have conformance that we need this as the
           default, but I don't think that we have conformance on
           allowing navigation via other methods.
  Florian: I would say it's not a non-conformant browser if the
           default does what the spec says.
  fantasai: Yes.
  astearns: I think we should keep the sentence in the note and
            remove the conformance language.
  fantasai: What's the purpose of the example then?
  fantasai: It's an example of how to fail at the spec.
  fantasai: It's supposed to illustrate that renaming what is stated
            prior makes you still not conformant.
  astearns: You can provide spatial navigation, but doing that for
            just this one property is not enough.
  fantasai: Exactly, that is exactly what is this trying to
            illustrate.
  Florian: I think I get what you're trying to say, but I'm going to
           try and come up with another way to phrase it.

  astearns: We've spent enough time on this - please open an issue
            so we can point to it.
  tantek: Can we just remove the sentence?
  tantek: Let's at least agree on that.
  fantasai: I am not going to agree to that resolution.
  tantek: You're going to keep the spec hostage with bad language.
  fantasai: Yes, I want something better before removing.
  astearns: It is a valid issue that we have conformance in a note.
  astearns: Next topic please.

  <dbaron> I think what the sentence is trying to say is "However a
           UA that uses order in determining navigation, but does
           not otherwise account for spatial relationships among
           elements (as expressed by the various layout features of
           CSS including and not limited to flex layout), is a
           non-conforming sequential navigation mechanism rather
           than a conforming spatial
  <dbaron> navigation mechanism."... though that does provide
           stronger definitions of "sequential navigation" and
           "spatial navigation" than the normative text does.
  <Rossen> github issue for the a11y note is 1678

  <tantek> FYI I think Leonie's blog post is worth reading on issue
           2: https://tink.uk/flexbox-the-keyboard-navigation-disconnect/

Definitiveness of flex items main size
--------------------------------------

  <fantasai> https://drafts.csswg.org/css-flexbox/issues-cr-20160526#issue-6
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2017Jan/0068.html
  fantasai: This was raised by gsnedders.
  fantasai: I think TabAtkins and I concluded we weren't sure what
            to do with this.
  gsnedders: I don't really care what we do here.
  gsnedders: The change seems to go against what many web devs
             expect it to do.
  astearns: Is there a change that Edge and FF made?
  TabAtkins: I'm not sure about this one either.
  TabAtkins: It's because if you look at the spec, why did you think
             that Chrome's behavior is correct according to the
             current spec
  TabAtkins: Ah, the flex-basis is auto.
  TabAtkins: In general, the container that that depends on it's
             content you can't resolve percentages against them.
  TabAtkins: So it was on purpose the current spec.
  fantasai: We have two browsers doing this.
  gsnedders: This is a common web dev problem.
  gsnedders: It accounts for about 50% of dups in the flexbugs repo.

  dbaron: Maybe there should be a GitHub issue on this and we can
          have the flex engineers weigh in.
  TabAtkins: Can you open an issue and then have UAs discuss it
             offline.
  Rossen: I'm looking at it right now.
  fremy: Can you take a look at issue 1290?
  <fremy> tabatkins can you review
https://github.com/w3c/csswg-drafts/issues/1290

Percentages in intrinsic sizing
-------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/347

  TabAtkins: We normally set percentage margins to 0.
  TabAtkins: Edge/Chrome does this when flex asks for intrinsic
             sizing.
  TabAtkins: Firefox backcomputes this information to resolve the
             percentage.
  TabAtkins: That implementation in general is scary and weird, I'd
             prefer to avoid it.
  TabAtkins: If Firefox plans to keep this would they please spec
             it, or discuss what to do?

  Rossen: Didn't we discuss this in Seattle?
  fantasai: That was about width.

  dbaron: We're trying to figure out the contribution of the
          intrinsic of its parent.
  dbaron: We consider it's intrinsic size and it's margin, border,
          padding.
  dbaron: Your source of width, might be the width property,
          *explains the rest of the math*.
  <TabAtkins> (sum of lengths)/(1 - sum of %s) = container width
  <TabAtkins> Rather, = width you resolve %s against on that element
  <dbaron> https://dbaron.org/css/intrinsic/#outer-intrinsic
  iank: In your intrinsic sizes, it computes its content size
  iank: ignoring padding, margin, border
  iank: then the parent takes the content size and looks at the
        border, margin, padding and looks at the percentage as well
        and takes into account all percentages of its children.
  dbaron: No, it only takes one at a time.
  Rossen: Which is where it falls apart.
  TabAtkins: Tables don't have to worry about lines, that's why they
             can do them.

  dbaron: What did we resolve in Seattle?
  dbaron: I thought we resolved to not do it since it doesn't take
          siblings into account for intrinsic sizing.
  Rossen: That's what I recall, I'm reviewing the minutes now.
  astearns: Does that resolution go against what gecko currently
            does?
  dbaron: That means some things may not fit, but we're not perfect
          so... meh

  astearns: Does anyone have any other issue?
  <fremy> https://github.com/w3c/csswg-drafts/issues/509 is still
          open
  <fremy> "Percentage resolution for margins"
  <fremy> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-277119468
  <fremy> "myles RESOLVED: "Percentages contribute intrinsic size
          and they resolve after layout""

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2017Feb/0088.html
  <astearns> other issue was https://github.com/w3c/csswg-drafts/issues/1051 ?
  Rossen: We resolved that percentages will behave as auto.
  astearns: Sounds like some additional archiving needs to happen?
  Rossen: Oh hold on.
  <Rossen> https://lists.w3.org/Archives/Public/www-style/2017Feb/0061.html
  Rossen: This was the related discussion about grid & percentages.
  TabAtkins: What happens if the percentages go higher than 100%?
  dbaron: We cap it.
  TabAtkins: There's a bit of a discontinuity there.
  dbaron: Right.
  dbaron: We cap at 100% so that we don't go to infinity/
  Rossen: After we did all of the issues in Seattle we had consensus
          to go with that go to 0 but they still resolve.
  <Rossen> https://lists.w3.org/Archives/Public/www-style/2017Feb/0061.html
  <dbaron> TabAtkins,
https://searchfox.org/mozilla-central/rev/bbc1c59e460a27b20929b56489e2e55438de81fa/layout/base/nsLayoutUtils.h#1455-1470
  Rossen: The resolution doesn't make much sense, but if you follow
          the discussion, there is a 0 intrinsic size.
  Rossen: After the straw poll that's what we resolved for.
  TabAtkins: Yeah this was for widths.
  Proposed resolution: percentage margins compute to 0 in intrinsic
                       sizing and then resolve during layout

  RESOLVED: percentage margins & paddings compute to 0 in intrinsic
            sizing and then resolve during layout

Absolute flex ratio
-------------------
  github: https://github.com/w3c/csswg-drafts/issues/316

  <fantasai> https://drafts.csswg.org/css-flexbox/issues-cr-20160526#issue-15
  TabAtkins: One of the original things with flex, was relative &
             absolute flexing
  TabAtkins: Absolute flex allowed you to setup a ratio of flexing.
             That works great as long as your margin/border/padding
             are 0
  TabAtkins: It's impossible to do this because flexing always
             increases the content box size
  TabAtkins: The total size of the elements end up not matching the
             ratio *gave an example*
  TabAtkins: Change the ratio to take box sizing into account
  fantasai: They are actually, they take it into account--but not
            correctly
  fantasai: We use the margin box, so your starting point will be
            bigger than 0
  fantasai: So we have to take margin/border/padding into account
            as min-size rather than a flex-basis minimum.

  Florian: Is this web compatible?
  Florian: And box-sizing doesn't have 'margin-box'
  TabAtkins: Border is the important one here
  TabAtkins: We think this is web compatible, the ratios are
             probably still close enough that they're not noticing
             differences right now
  fantasai: They set box-sizing on *
  TabAtkins: If it turns out that this is not web compatible we can
             come up with a different solution
  TabAtkins: But we'd like to try and use that first rather than
             introduce new things
  TabAtkins: We wanted working group approval
  fantasai: I think a lot of these sites are slightly off and will
            probably be slightly improved.
  Rossen: Do we have interop?
  TabAtkins: We do
  TabAtkins: But it would be a better improvement, hopefully

  dbaron: Who's going to make the change first? We have a record of
          making changes that are possibly risky and then nobody
          willing to be the first implementer.
  dbaron: I think I'd like someone to be the first implementation as
          we are normally hesitant
  Florian proposes the browser with dominant market share
  TabAtkins: Guaranteed not to affect how boxes wrap or are
             arranged, just slight difference in how they are sized.

  astearns: Those with web compat concerns, any objections?
  TabAtkins: I'm pretty confident that I can volunteer Christian to
             try it.
  astearns: Any objections?...
  Rossen: Well - yes
  Rossen: I would like to believe it, but I'd hate to have you start
          flooding this and then they fix it and they do, and then
          we change our mind later on then.
  fantasai: I'm pretty confident this is the right thing to do for
            the web.
  Rossen: I have no problem with anyone trying it.
  fantasai: I think we need the spec to change for anyone to do it.
  Florian: Put a note in there to provide feedback on it.
  TabAtkins: We've done that before, implementations please test is
             it and send it back.
  Rossen: With a note would be better.
  PROPOSED RESOLUTION: Include box-sizing in flex sizing with a note

  RESOLVED: box-sizing is accounted for in the flex algorithm so
            that the flex ratios reflect the distribution of the
            specified box, add a note in the spec wrt web compat

  <topic: break>

Selectors
=========
  Scribe: tantek

Selectors 4 Publication
----------------------

  <astearns> https://lists.w3.org/Archives/Public/www-style/2017Jul/0022.html
  dbaron: One of the reasons is that there was a section of text
          added in the editor's draft that I disagreed with and
          didn't have a chance to review it.
  TabAtkins: I think we should update this four year old WD
             regardless.
  fantasai: I'm co-editor of the spec and I don't know what's in the
            ED, so I'd like to review it first.
  * fantasai hasn't been involved in most of the changes Tab checked
             in over the last 4 years, since had to drop some things

  ACTION fantasai: review current state of Selectors 4 and determine
         what if anything is blocking publishing a new WD
  <trackbot> Created ACTION-854

  dbaron: I put a note in about ... but I think it might be wrong
  TabAtkins: I'm happy to review the algorithm, dealing with issues
             as they come. I don't think they should block anything.

  dbaron: One other note, does bikeshed have a way to find specs
          that reference the term that I just removed?
  TabAtkins: Not yet.
  TabAtkins: I'd like to expose it
  TabAtkins: and give you a way to track it.
  TabAtkins: It's imminently possible, just haven't done the actual
             work.
  dbaron: I removed "evaluate a selector" and suggested replacement
          is ".... selector against a tree"
  dbaron: I put a suggestion in the changes section in a fragment,
          but that might not stay around
  dbaron: these are API hooks for other specs to reference.

  astearns: Anything else on Selectors 4?

propagation of the :focus pseudo
--------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1240

  Florian: We've discussed this a couple of times already.
  Florian: We defined how :active works deferred to HTML, we did
           also for :focus but incorrectly deferred to HTML
  Florian: so our spec makes no sense.
  Florian: Easiest fix, leave :active as is, point :focus at the
           right thing
  Florian: or we could define what :focus does.
  Florian: 3rd aspect, open issue on *how* it should work.
  Florian: Without being specific about hover and active but not
           focus propagate from a labeled form control to the form
           control but not back.
  Florian: At some point we defined that all three should propagate
           both directions.
  Florian: If we defer to them there, it overturns our previous
           resolution.
  Florian: If we define it here, we may be able keep current
           resolution.
  Florian: IE used to propagate both directions, but Edge does not.
  Rossen: We might've done something for interop.
  Florian: I tested this a few months ago
  <astearns> testcase from previous discussion?
data:text/html;charset=utf-8;base64,PCFET0NUWVBFIGh0bWw+DQogIDxzdHlsZT4NCiAgICA6Zm9jdXMgeyBiYWNrZ3JvdW5kOiBvcmFuZ2U7fQ0KICA8L3N0eWxlPg0KICA8bGFiZWwgZm9yPXlvPkZvbzwvbGFiZWw+DQogIDxpbnB1dCBpZD15bz4=

  Florian: Do we just defer to whichever group manages HTML these
           days? or do we takeover? How much do we takeover?
  TabAtkins: I think it is still a host language thing, I don't
             think we should take over.
  TabAtkins: Should be easy enough to get WHATWG to fix that.
  Florian: Whether or not active and focus prop. to their ancestors
           is ... ?

  Florian: So in the github issue I proposed a phrasing.
  Florian: Open issue to get them to fix it.
  Florian: Shall we do that or shall we takeover more?
  TabAtkins: I disagree with your proposal.
  TabAtkins: Would prefer to defer to host language for parent
             element too.
  TabAtkins: Regarding prop. upward.
  Florian: ok I can fix that.
  TabAtkins: Otherwise it seems pretty good.
  Florian: Is that a resolution? accept Florian's changes with Tab's
           fix?

  Florian: Separately we may want to continue to debate whether not
           they propagate to label/form control?
  Florian: Regarding whether we should make a statement to the
           WHATWG on this
  astearns: Tab's change is to ... ?
  astearns: Is this in a draft?
  Florian: Just in the issue, I can turn it into a pull request.
  astearns: Proposed resolution is to take changes outlined in 3rd
            comment in the issue, with Tab's amendment re: must not
            match focus.
  astearns: Any objections to taking Florian's change?

  RESOLVED: Take changes outlined in 3rd comment in the issue
            https://github.com/w3c/csswg-drafts/issues/1240, with
            Tab's amendment re: must not match focus.

  Florian: Shall also discuss next issue? we have also resolved on
           not what the HTML spec says.
  astearns: I'm unclear whether a group resolution would help.
  astearns: They have our input already.
  Florian: Kinda. Last time two people objected. one was bz with a
           well reasoned argument. and the other was ryosuke who
           said we don't need this because we have the :has selector
           - which we don't have, so that objection is invalid
  Florian: but bz objection is still valid.
  astearns: Can you update the issue that we made this change and
            are still waiting?
  Florian: A major part of the pushback from WHATWG is that for
           hover in particular this is expensive because hover
           events can fire a lot around the page.
  Florian: Some people say just active, and some say ... ?
  Florian: or the other thing with IDref (?) like selector?
  Florian: Shall I write something?
  Florian: Or does WG not care?
  tantek: I think we can't follow.

  ACTION Florian follow-up on the issue
  <trackbot> Created ACTION-855

  Florian: Static vs dynamic profile?
  Florian: Important to change the name.
  Florian: Everyone misunderstands static vs dynamic - as in this
           means JS or not
  TabAtkins: I agree - too much confusion - I want to change the
             names also.
  Florian: This is related because it sounded like Apple engineers
           were confused.

focus-ring
==========

  astearns: Next topic is focus ring
  <astearns> https://wicg.github.io/focus-ring/spec/focusring.html
  TabAtkins: We agreed to take on focus-ring selector.
  TabAtkins: There is a WICG version.
  TabAtkins: Open questions on what it should do precisely-
  TabAtkins: big one is elements that don't normally have user
             interaction
  TabAtkins: should the pseudo only match elements that browsers
             normally make UI interactive? or other elements also?
  TabAtkins: I think focus-ring should only match browser native
             focus-ring.
  TabAtkins: One of the big problems is that custom elements want to
             mimic native UI now
  TabAtkins: that needs a different feature.
  TabAtkins: There is never a case when you want to style an element
             with a :focus-ring pseudo but not show a native focus
             ring when you're styles don't load.
  <fremy> +1

  Florian: Question about state of drafts. It's in selectors4 and in
           wicg?
  nainar: Shall we just keep it in selectors4?
  TabAtkins: Selectors spec is more recent.
  TabAtkins: Ignore anything from the old one.
  Florian: Can we mark the old one as obsolete?
  <Florian> obsolete isn't the right word, but you get my point
  TabAtkins: We should tombstone the spec document - the wicg
             document so it just points over to selectors.
  TabAtkins: We want to make sure that the spec properly points to
             the current thing.

  TabAtkins: that was #1 and #3
  TabAtkins: if nobody objects, I would like to say focus-ring only
             applies IFF native focus-ring shows up. and if it needs
             to be fixed more widely, then new things need to be
             added to HTML or CSS to make the focus-ring show up
  TabAtkins: 1 focus-ring pseudo matches IFF browser native focus
             ring would be displaying on that element
  fremy: question ... ?
  fremy: As long as it's not affected by 'outline:none' styles

  RESOLVED: focus-ring pseudo matches IFF browser native focus ring
            would be displaying on that element

  TabAtkins: 2 if we do decide to have focus-ring match more types
             of elements than we have now, then we need new ways to
             control browser native focus ring.
  TabAtkins: Whether it lives in CSS or HTML I don't have a strong
             opinion about.
  TabAtkins: Point being it should affect whether browser native
             focus-ring shows up or not, and then the :focus-ring
             pseudo just follows from that
  <fantasai> +1 to what Tab said
  astearns: Doesn't sound like a resolution.

  astearns: RESOLVED what tab said
  RESOLVED: Feature to add focus-ring to other elements should
            affect whether browser native focus-ring shows up or
            not, and then the :focus-ring pseudo just follows
            from that. (Such a feature would not be specific to
            controlling the :focus-ring pseudo's behavior.)

  TabAtkins: Final issue is ... not relevant - older issue, since
             resolved.
  nainar: Everyone should just get their implementations correct.
  Florian: UI 3 is fairly vague about outlines so browsers have a
           broad range of possibilities.
  <nainar> For context this is some research we did into
           outline-style:auto -
https://docs.google.com/document/d/116RHq9KF31NAQtYb5gN4PjulOJC8IwxcGUaWJeIZ-1o/edit
  Florian: Auto is whatever you get automatically from the browser.
  TabAtkins: Yes you're allowed to default it to just be solid.
  Florian: Somehow FF has a native looking outline when you do
           initial, but solid for auto.
  Florian: So how do you get that.
  TabAtkins: That's a UI issue
  TabAtkins: we are done with :focus-ring topics then

  <nainar> Github issue for matching focus-ring:
https://github.com/WICG/focus-ring/issues/33
Received on Sunday, 27 August 2017 18:57:41 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 27 August 2017 18:57:41 UTC