- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 4 Apr 2019 19:07:47 -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.
=========================================
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