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