- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 26 Feb 2019 23:01:53 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Outline around descendants`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Outline around descendants<br> <fantasai> ScribeNick: fantasai<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/2846<br> <fantasai> heycam: A little whiel ago I bourgh tup the fact that in Gecko we include a lot of descendant boxes when rendering outlines<br> <fantasai> heycam: and we do get some compat issues from that<br> <fantasai> heycam: because essentially in Blink and WebKit, and I didn' trecently test Edge, outline only is derived from the position and size of that element's principle box<br> <fantasai> s/principle/principal/<br> <fantasai> heycam: Different things happen<br> <fantasai> heycam: but the important difference is that no descendants contribute to the outline position or size<br> <fantasai> heycam: Definition fo outline in the spec is deliberately vauge so that UAs can do something fancy<br> <fremy> q+<br> <fantasai> heycam: but there is a suggestion that descendants should contribute to the outline<br> <fantasai> heycam: but I'm suggesting that we switch the suggestion to say that they should not<br> <fantasai> iank_: ...<br> <fantasai> iank_: The tl;dr is that there's the outline proeprty which renders one way, and e agree that it shouldn't include descendants<br> <fantasai> iank_: but then there's the focus outline, when an element is focusable and you focus it<br> <fantasai> iank_: You might want to handle that a different way<br> <fremy> q- since I was basically gonna bring up the focus outline side of things<br> <fremy> 1-<br> <fremy> q-<br> <fantasai> 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<br> <fantasai> florian: You can do whatever you want<br> <fantasai> florian: Intent is that browsers implement focus outline with that<br> <fantasai> florian: What UAs actually do, may be it's different<br> <fantasai> emilio: outline-style: auto not only changes shape of outline, but also uses the system focus outline style<br> <fantasai> emilio: Firefox does something weird on Linux, because bugs, but that's it<br> <fantasai> emilio: it should otherwise match the OS<br> <fantasai> emilio: Not just about channging shape but also style<br> <fantasai> gregwhitworth: was curious about removing descendants from outline<br> <fantasai> gregwhitworth: I don't want removing descendants from focus to be the default<br> <fantasai> iank_: I think we agree<br> <fantasai> iank_: the behavior that I think we want is for the outline property, it doesn't include descendants<br> <fantasai> iank_: but for focus outline it does<br> <fantasai> florian: Define focus outline<br> <fantasai> gregwhitworth: Rob Dotson and Alice Boxhall were thinking that it shouldn't follow descendants<br> <fantasai> gregwhitworth: but currently it does<br> <fantasai> iank_: Why for focus outline, by default, should it enclose descendants?<br> <astearns> s/Dotson/Dobson/<br> <fantasai> gregwhitworth: Because the scenarios where it's a problem, I can find just as many where not enclosing is also a problem<br> <fantasai> gregwhitworth: Many cases where Chrome's rendering looks weird e.g. in FB on Chrome<br> <fantasai> gregwhitworth: Other cases it looks weird<br> <fantasai> gregwhitworth: e.g. wrapping around weird pseudo-elements<br> <fantasai> 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)<br> <fantasai> gregwhitworth: That's happening because looping in descendants<br> <fantasai> iank_: You could have an alternate implementation that's just a bounding rect<br> <fantasai> gregwhitworth: I'd be more OK with that<br> <fantasai> gregwhitworth: Saying that these few sites, we no longer care about descendants, seems odd<br> <fantasai> iank_: We need to check with Alice and Rob, but there disn't seem to be a use case for non-rectangular focus outline<br> <fantasai> iank_: thinking about simplifying and just doing the bounding box<br> <fantasai> iank_: Then the question is in that state, what's the best calculation?<br> <astearns> q?<br> <fantasai> fremy: Reason why important for focus outline to include descendants, e.g. if you have inline links and a position absolute element<br> <fantasai> fremy: If you don't include abspos element, you aren't able to actually show the focus ring around the link<br> <fantasai> fremy: I'm curious if you can do it with one single rectangle<br> <fantasai> 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<br> <fantasai> heycam: ...<br> <florian> q+<br> <bkardell_> can someone repeat what iank just said?<br> <fantasai> iank_: Splitting the discussion slightly, sounds like everyone would be fine if the non-auto outline style ...<br> <fantasai> iank_: sounds like we'd be fine with it not including descendants and just being the border box<br> <Rossen> [high contrast slides link] https://lists.w3.org/Archives/Public/www-archive/2019Feb/0000.html<br> <fantasai> florian: Want to clarify definitions<br> <fantasai> florian: The definition of focus outline that is in the issue that you refer to<br> <fantasai> florian: includes some cases of the proeprty-based outline<br> <fantasai> florian: In the issue now there is the definition of focus outline being either:<br> <fantasai> florian: a) the outline painted whichever way while the element is in focus or<br> <fantasai> florian: b) when the outline-style is auto<br> <fantasai> atotic: That's how it's implemented in Chrome atm<br> <astearns> ack florian<br> <fantasai> florian: Alternate definition is "only outline when element is in focus"<br> <fantasai> Another definition woudl be only when it's non-auto...<br> <emilio> q+<br> <fantasai> gregwhitworth: You need to be focussed and outline<br> <xfq> ack fantasai<br> <emilio> fantasai: so this definition is a little weird, let's say I set an outline: solid purple on a link<br> <emilio> fantasai: and the behaviour will change depending on whether we focus the link<br> <emilio> iank_: this is what we currently implement today<br> <emilio> fantasai: we need a definition that doesn't do that<br> <fantasai> 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 unfocus<br> <bkardell_> it is still a problem<br> <bkardell_> q+<br> <emilio> jensimmons: outline: 0 no longer appears on CSS resets anymore<br> <emilio> jensimmons: nor frameworks. Of course some people still do that but...<br> <florian> q+<br> <fantasai> jensimmons: Word has gotten out, don't do that. Of course ppl still do it, but it's getting better<br> <xfq> ack emilio<br> <fantasai> emilio: I'm a bit confused. Firefox used to conditionally include both in-flow and out-of-flow descendants for all kinds of outlines<br> <tantek> for the record, that was fixed in Eric Meyer's CSS Reset back in 2011: https://meyerweb.com/eric/tools/css/reset/<br> <fantasai> emilio: Then xidorn changed to only include in-flow elements<br> <fantasai> heycam: I think only for abspos<br> <fantasai> emilio: As far as I understand, one of the use cases we want to bring back...<br> <fantasai> emilio: Does Blink include auto flows in their descendant stuff?<br> <fantasai> s/auto flows/overflow/<br> <fantasai> s/overflow/out-of-flow/<br> <fantasai> atotic: It depends. Only if the outline is around the containing block<br> <fantasai> emilio: Ancestor containing block?<br> <fantasai> atotic: *emphatic shrug*<br> <fantasai> emilio: I agree thwith fantasai that having two different behaviors depending on whether focused or not is very weird.<br> <fantasai> emilio: Maybe take greg's advice to give authros control<br> <fantasai> atotic: Our behavior is OK because we don't do bounding box, if boxes are disjoint then they each get outlined<br> <fantasai> atotic: Now that merging boxes, less tolerable<br> <fantasai> florian: Two kinds of merging boxes<br> <fantasai> florian: One is when boxes are not next to each other, have a box around each<br> <fantasai> florian: Other is when they touch each other have either a non-rectangular outline that wraps both<br> <fantasai> florian: or boundign box<br> <gregwhitworth> I'm not seeing Chrome wrap this abspos in focus: https://jsbin.com/muyemusofo/1/edit?html,css,output<br> <fantasai> florian: E.g. For Presto, if two fragments being outlined are not adjacent, you get two outlines<br> <fantasai> florian: but if they are adjacent, you get one non-rectangular outline around the whole shape<br> <fantasai> florian: There are nuances within this<br> <fantasai> emilio: I think we should come up with a consistent plan<br> <florian> q?<br> <xfq> ack b<br> <iank_> q+<br> <fantasai> 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-ring<br> <fantasai> bkardell_: Will help when :focus-visible is implemented everywhere. Also :focus-visible-within<br> <fantasai> bkardell_: I've seen a lot of ppl make comments about confusion around outline<br> <fantasai> bkardell_: Maybe we should really have two properties<br> <fantasai> fantasai: or a switch between behaviors<br> <fremy> q?<br> <fantasai> bkardell_: Using same thign for two purposes seems quite strange<br> <fantasai> bkardell_: We tell ppl don't use border, use outline for focus rectangles<br> <fantasai> bkardell_: So we could use borders<br> <fantasai> bkardell_: Maybe have a thing that's about focus rectangle<br> <fremy> +1 to what fantasai just said (minuted below)<br> <fantasai> 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)<br> <fantasai> fantasai: and other outline-style values give a more normalized outline shape, appropriate for extra "border" looking things<br> <xfq> ack fl<br> <astearns> q+ bkardell_<br> <fantasai> florian: We have half of this. When outline-style is auto, it's reasoanble to assume this is being used for focus. I don't think ppl use it for decorative styles<br> <fantasai> florian: Other half is less clear. It's often used decoratively, but not strictly<br> <gregwhitworth> q+<br> <fantasai> florian: We can spec the auto style to be just the right thing for outline styles<br> <fantasai> florian: Maybe time will help<br> <fantasai> florian: When we get around finalizing spec and implementation, once we have multipel borders or gradients within borders, maybe ppl will use those instead of outliens<br> <gregwhitworth> inline desc are wrapped https://output.jsbin.com/gimiwigije/1<br> <fantasai> florian: but we don't have that yet. And might take awhile for ppl to move over<br> <fremy> q?<br> <emilio> q+<br> <xfq> ack iank<br> <fantasai> iank_: The otehr thing is for accessibility sue case, we don't ahve the right people in the room, so it will be a lot of tiem with our a11y experts to not break a11y in this space<br> <fantasai> fremy: I work on that, btw<br> <fantasai> gregwhitworth: melanierichards is also here<br> <xfq> ack bk<br> <fantasai> bkardell_: It feels like we're not really serving the best use cases that we could<br> <fantasai> 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 thigns that are both beautiful and accessible<br> <fantasai> bkardell_: it's pretty hard<br> <fantasai> 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<br> <tantek> Are there specific examples of such "really beautiful design" where this is a challenge?<br> <fantasai> bkardell_: A lot of OSes have developed what I assume is glowy outlines<br> <fantasai> 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<br> <fantasai> bkardell_: so when he was working on that, we came up with a hack to make multi-colored pseudo-border outlines that don't affet layout<br> <fantasai> bkardell_: we could serve taht better and more appealing, then more likely ppl make accessibile things<br> <fantasai> bkardell_: as Alice says, I assume devs want to do the right thing, just if we make it harder they're less likely to<br> <xfq> ack greg<br> <fantasai> gregwhitworth: I 100% agree with bkardell_<br> <fantasai> gregwhitworth: We are currently finishg up a study with 160 users on focus testing, for this reason<br> <fantasai> gregwhitworth: because we belive the one in Chromium is not sufficent<br> <fantasai> gregwhitworth: One issue is wht bkardell_ brought up<br> <fantasai> gregwhitworth: we also looked into prototyping always-visible outlines<br> <fantasai> gregwhitworth: to provide sufficient contrast<br> <fantasai> gregwhitworth: I saw emeyers' scenario of always wanting to ensure high contrast<br> <fantasai> gregwhitworth: What's interesting is that Mozilla has a property that they propsed eyars ago to effectively provide an inversion color as a color keyword<br> <fantasai> gregwhitworth: so you can use a keywrod where youc an't sue the inversion value<br> <fantasai> gregwhitworth: It's just that it looks realy gross when you want a great design<br> <fantasai> gregwhitworth: two things taht came up out of that testing<br> <fantasai> gregwhitworth: one, doing a good focus rect in browser sucks<br> <fantasai> gregwhitworth: doesn't follow border radius is problematic<br> <fantasai> gregwhitworth: I had to hack with border outline and drop-shadow to get the right effect<br> <fantasai> gregwhitworth: I think we should tease out the pieces of following the rect<br> <bkardell_> tantek does greg's expanding answer your question?<br> <fantasai> gregwhitworth: also want to have gradient<br> <fantasai> gregwhitworth: Similar to ...<br> <fantasai> gregwhitworth: In addition, emilio's proposal of whether or not you want to include descendants or not<br> <fantasai> gregwhitworth: will share more publicly once we have the report<br> <fantasai> emilio: what he said.<br> <xfq> q?<br> <emilio> q-<br> <xfq> ack emilio<br> <fantasai> heycam: It think most important thing given distinction between focus outlines and decorative outlines<br> <fantasai> heycam: We should write down which particular descendants get included, because that's the particular difference betwen FF and other browsers that's an issue for us<br> <fantasai> heycam: At the moment, we include all in-flow descendants<br> <fantasai> gregwhitworth: I have interop on all 3 browsers in Windows<br> <fantasai> [discussion about testing]<br> <fantasai> heycam: I only tested normal outlines, and definitely saw differences<br> <fantasai> emilio: Also Firefox only changed recently, might want to test Nightly<br> <fantasai> astearns: Sounds like we won't resovle anything right now, but we need to figure out interop<br> <fantasai> astearns: First thing to figure out as we go through these issues in addition<br> <fantasai> heycam: So next step is wait for this report?<br> <fantasai> ACTION: gregwhitworth open issues against outline on all the aforementioned issues<br> <trackbot> Created ACTION-877 - Open issues against outline on all the aforementioned issues [on Greg Whitworth - due 2019-03-05].<br> <fantasai> astearns: Let's keep this issue on descendants and open more issues for the rest<br> <fantasai> astearns: OK that's it for this topic!<br> <fantasai> BREAK TIME<br> <fantasai> <br type=tea><br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2846#issuecomment-467651032 using your GitHub account
Received on Tuesday, 26 February 2019 23:01:55 UTC