16:28:31 RRSAgent has joined #css 16:28:31 logging to http://www.w3.org/2015/02/25-css-irc 16:28:36 RRSAgent, make logs public 16:29:33 glazou has changed the topic to: See also #fx for minutes - logs: http://krijnhoetmer.nl/irc-logs/css - Agenda confcall 20150225 https://lists.w3.org/Archives/Public/www-style/2015Feb/0494.html (JS only logs: https://log.csswg.org/irc.w3.org/css/today ) 16:38:07 There are lots of things that are very nice about Japan. 2am telecons is not one of them 16:39:15 bkardell_ has joined #css 16:40:30 Florian: oh come on, don’t start complaining like all french people ;-) 16:41:10 hey bkardell_ you were the first one this morning for the bday wishes, even before the family eh ! 16:41:13 thx :-D 16:41:18 :) 16:45:10 glazou: but I am French, why should I not complain? Also, happy birthday. 16:46:21 :-) thx! 16:49:55 Happy birthday, or so I hear :) 16:52:14 tantek has joined #css 16:52:19 thanks Ms2ger ! 16:53:02 I have a conflict today, so regrets for not being able to call in... will try to follow on IRC 16:53:10 ok 16:54:46 good morning 16:55:02 hi tantek 16:55:24 Hi Tantek 16:55:42 hello glazou Florian 16:55:44 Style_CSS FP()12:00PM has now started 16:55:51 +??P26 16:55:57 good news css3ui TR draft published 16:55:58 Zakim, ??P26 is me 16:55:58 +SimonSapin; got it 16:56:00 +??P28 16:56:11 Zakim, ??P28 is me 16:56:11 +glazou; got it 16:56:13 so I hope to get all the pending edits in in the next couple of weeks or so 16:56:43 and then I want to do another WD with all of those, since that seems to be what the current publishing process allows for 16:56:48 + +1.479.764.aaaa 16:56:52 dael has joined #css 16:56:56 Zakim, I am aaaa 16:56:56 +Florian; got it 16:56:59 +plinss 16:57:40 +dael 16:58:01 antenna has joined #css 16:58:51 kwkbtr has joined #css 16:58:55 +[Microsoft] 16:59:04 zakim, microsoft has me 16:59:04 +Rossen; got it 16:59:22 gregwhitworth has joined #css 16:59:30 adenilson has joined #css 16:59:32 +dauwhe 16:59:54 AH_Miller has joined #CSS 17:00:02 +??P38 17:00:12 Zakim, ?P38 is me. 17:00:12 sorry, adenilson, I do not recognize a party named '?P38' 17:00:13 +[Microsoft.a] 17:00:15 alex_antennahouse has joined #css 17:00:16 smfr has joined #css 17:00:25 Zakim, ??P38 is me. 17:00:26 +adenilson; got it 17:00:27 Zakim, Microsoft.a is me 17:00:27 +gregwhitworth; got it 17:00:59 +[IPcaller] 17:01:06 andreyr has joined #css 17:01:09 +[IPcaller.a] 17:01:10 +fantasai 17:01:16 Zakim, IPCaller is me 17:01:16 +tgraham; got it 17:01:28 + +1.631.398.aabb 17:01:33 I think im IPcaller.a 17:01:35 +MikeMiller 17:01:36 ScribeNick: dael 17:02:00 zakim, IPCaller.a is alex_antennahouse 17:02:00 +alex_antennahouse; got it 17:03:08 +??P11 17:03:12 bcampbell has joined #css 17:03:15 Zakim, ??P11 is me 17:03:15 +kwkbtr; got it 17:03:22 +smfr 17:03:28 sanja has joined #css 17:03:38 +[IPcaller] 17:03:45 IPCaller is me 17:04:01 Zakim, IPCaller is bcampbell 17:04:01 +bcampbell; got it 17:04:38 plinss: Let's get started. Anything to add to the agenda? 17:04:50 ??: I have something remove. 17:04:56 smfr has changed the topic to: https://lists.w3.org/Archives/Public/www-style/2015Feb/0494.html 17:04:58 + +43.134.001.00aacc 17:05:02 ??: Transform-style 3d issue has been resolved by now. 17:05:05 plinss: Okay. 17:05:07 s/now/email/ 17:05:10 s/??/smfr/ 17:05:14 BradK has joined #CSS 17:05:15 plinss: To start, happy birthday glazou 17:05:22 Topic: WebVTT review. 17:05:41 plinss: There's been discussion on e-mail, but do we have group concensus feedback to send? Do folks need time to review? 17:05:46 +BradK 17:05:50 + +1.860.479.aadd 17:05:53 + +1.281.305.aaee 17:05:58 Zakim, aaee is me 17:05:58 +TabAtkins; got it 17:06:07 plinss: I'll take that as a no. So everyone should review and send comments on the e-mail. We'll gather feedback as a group reply. 17:06:11 +43.134.001.00aacc is me 17:06:16 Topic: abspos change compat risk 17:06:34 Zakim, aacc is me 17:06:34 +sanja; got it 17:06:43 +hober 17:06:49 gregwhitworth: We made the abspos change where it goes like 0,0 for flex items. Google docs has an issue. I posted the flipboard issue. I've got two bugs open against those. 17:07:07 gregwhitworth: I don't know what we do because I understand why we have the change. I guess I wanted to maket he group aware of it. 17:07:24 +Jerome 17:07:27 fantasai: I thought the change was there to simplify what's going on. If the old behavior is what's useful we might want to go with that. 17:08:00 fantasai: I think we ran into issues with complexity where you have aplaceholder that has to follow layout and can't affect order and there's an invisable thing adding space so we took it out of flow. 17:08:13 fantasai: If websites want this behaiour we need to dig into these cases. 17:08:25 Rossen: I don't believe this is what people want, it's what people have. They're using what they have. 17:09:01 Rossen: When we were discussing inSophia, we agreed the simplified algo gets us quicker to better interop. The abspos inline algo will be tricky, though everyone had a impl of it. 17:09:43 Rossen: I think what gregwhitworth is bringing is relivant and if we stick tot he current algo which I personally prefer, then the q is are the other impl going to follow soon. If they do this will basically dictate when content will change 17:09:50 Rossen: Does that make sense? 17:10:12 gregwhitworth: That's similar to what I was going to say. It's not that they were asking for a specfic use case, they just happened to fall into it. 17:10:15 +??P12 17:10:20 zakim, ??p12 is me 17:10:20 +tantek; got it 17:10:37 gregwhitworth: It's an unfortunate thing. The sooner all other browsers change the devs will see it. I thinkw e should keep it because we're moving to better layout. 17:10:39 fantasai: Okay. 17:10:51 fantasai: What can we put to tell impl they need to change? 17:11:00 gregwhitworth: Is TabAtkins on the call? 17:11:02 TabAtkins: Yes. 17:11:05 gregwhitworth: What do you think? 17:11:13 s/What can we put to tell impl they need to change?/need to hear from other implementers/ 17:11:15 TabAtkins: I haven't had the change to check with my team. 17:11:25 gregwhitworth: Why don't we circle back. dbaron isn't on. 17:11:36 fantasai: While we're on flexbox, TabAtkins did you sort out the margins? 17:11:52 TabAtkins: I couldn't figure out where so it was yesterday. Let me see if anyone commented. 17:11:57 fantasai: That holds up pub. 17:12:05 TabAtkins: No responce yet. I'll let you know when I do. 17:12:10 fantasai: We'll have to come back next week. 17:12:12 TabAtkins: Yes. 17:12:18 Topic: CSS3 UI 17:12:23 +??P0 17:12:26 Florian: We just got a WD out 17:12:42 Florian: Also I sent a mail about issue 69 which was the long standing one about box sizing. 17:12:44 +deirdrelee 17:13:12 Florian: I went through CSS 2.1 and figured out where everything should be and wrote the patch and put into CSS3 UI where it goes. WE don't need to discuss, but I appriciate review. 17:13:17 Florian: I erred on more explicit. 17:13:27 https://lists.w3.org/Archives/Public/www-style/2015Feb/0357.html 17:13:34 Florian: Things to discuss, issue 79 17:14:03 Florian: CSS3 UI doens't define outline overlap. CSS2.1 does, but it gives 2 options. Does anybody remember why we have 2? All the browsers seem to do the same thing. 17:14:07 tantek: That's desktop only. 17:14:48 tantek: A lot of the loosness in outline has been based on experience on platforms where outline is essential for indicating user focus and that's not common on desktop. It's common on TV or other devices with directional nav like a remote 17:15:18 -adenilson 17:15:32 tantek: The rendering of the outline was left looser in CSS3 UI because platofrms needed it for better UI. This is where 2.1 specified too much precision. On some platforms we choose a better UI instead of strictly what CSS2.1 said. 17:16:00 tantek: That's the experience from like early 2000 to now on nondesktop. It's important to keep that in and it's easy to forget since it's non-desktop specific. 17:16:02 Florian: Okay. 17:16:19 tantek: That's the history. Maybe we should have a note that mentions that. This isn't the first time it was mentioned. 17:16:46 +??P3 17:16:47 Florian: I'd go even futher since CSS UI doesn't replace. If we have a note saying we don't define it's only in 2.1 If you want looser it should be normative 17:16:50 tantek: That makes sense. 17:16:55 Zakim, ??P3 is me. 17:16:55 +adenilson; got it 17:17:03 Florian: Do you have examples of current non-desktop browser? 17:17:44 tantek: Last I checked every set top box was violating it because it's more important to have the line visable to the user. It's not the easiest to set up, but I don't see why browsers would regress their UI 17:18:11 Florian: I was just trying to figure out why one is looser than the other with no clear resolution. But do these TV UIs do the same and we can spec that? 17:18:42 tantek: They did similar as of 10 years ago, but I don't have modern set top devices to check today. My presumption is they stayed similar, but I can't gaur. I wouldn't want to spec their behaviour. 17:19:13 tantek: The other things is there's a lot of experimentations with Web VR and we're going to want hooks into CSS. Outline and focus behave even more differently in 3D. I don't see this convergine. 17:19:55 tantek: Seeing the spectrum of implementation will broden. We can add some normative text to make it explicit that the stacking of focus outline is left to the impl to provide better user experience. 17:20:10 Florian: I have no direct knowledge, but that sounds reasonable. I think it would be better. 17:20:20 tantek: Since it's normative in 2.1 it needs to be normative here. 17:20:41 tantek: Two use cases are setop boxes and web VR 17:20:48 Florian: Anyone else have something to add? 17:21:17 tantek: I would welcome input from anyone working on a non-desktop platform, especially if you have experience with outline rendering. More expereince gives us more data. 17:21:21 plinss: Other opinions? 17:21:33 RESOLVED: add some normative text to make it explicit that the stacking of focus outline is left to the impl to provide better user experience 17:21:49 Florian: If we have more time, I'd like to do issue 78. 17:21:49 https://lists.w3.org/Archives/Public/www-style/2015Feb/0344.html 17:21:58 Florian: This is about the directional focus prop 17:22:27 Florian: The way it's written you can make something focus-able that wasn't before. It's not implicit, but it's intended that the focus connector will match. I think explicit wouldn't hurt. 17:22:55 tantek: Last time we discussed I thought we couldn't resolve on if you did a nav up, should it make the element focusable. Someone was arguing it should nav to the first focusable thing. 17:23:10 Florian: That was fantasai disputing this. I think the current intent is what you say. 17:23:20 Florian: The spec is currently implicit but ambig. 17:23:49 Florian: We should make the intenet explicit and that a selector should match, but we should consider that it makes things unfocusable and focusable. 17:24:24 tantek: I agree with your conclusion, but I wasnted to bring it up since it wasn't consensus. I want to be upfront witht he group that those are the idea on the table. Even if Florian and I agree, the group should know about the debate. 17:24:37 tantek: I want the group to approve or tell us to do more. 17:24:57 Florian: Both behaviours are useful and I'm not strongly minded about which. Which one should be the default I'm not sure. 17:25:13 tantek: I'd rather a smart default instead of a switch unless there's a usecase that both are useful. 17:25:48 tantek: From that prospective, consider this a call for examples or experience from anyone using directional focus prop, especially if you're using them for otherwise unnav-able properties. 17:25:55 tantek: We haven't heard a lot so far. 17:26:44 fantasai: Two other things. Existing impl may have content so we might not have a choice. Second is this interacts with HTML and a11y in widgets so those people might have feedback. Making something focusable without HTML, is that a thing we want in the web platform 17:27:03 TabAtkins: In particular some things are only focusable when other things are the active focus. 17:27:07 s/without HTML/without reflecting this in the HTML/ 17:27:09 thanks for mentioning the a11y implications, would like to investigate further and help there. 17:27:34 tantek: fantasai insight is correct thatwe might not have a choice if impl have converged here. If impl are different, then we can reaccess and understand why impl are different. 17:27:44 tantek: IN that case, content across impl is unlikely 17:28:28 Florian: In terms of current impl I think they do agree in terms of making unfocusable things focusable, but I don't know what depends on that. There's nuance. If yo're doing through the keyboard it works, bt not else. 17:28:42 plinss: What does it mean to focus on something unfocusable? If it can't take imput what's the value? 17:28:55 TabAtkins: You can always do tabindex=url 17:29:01 tantek: That's already in the platform. 17:29:10 plinss: Seems like a bug. Should we perpetuate. 17:29:21 IE: with tabindex-1 allows both active and focus to work 17:29:45 without, :active only works 17:29:50 tantek: I think we'll find out through testing. I wouldn't block CR on this issue. Write a doc saying this is what we think, test, and see how it falls out. If the tests show impl converge the other way we don't have a choice 17:30:19 fantasai: I think we should clearly document the issue and narrow the scope. WE're considering these ways, this is how we'll decide, here's the background data, now it's down to testing and impl. 17:30:27 fantasai: That's what we need to push to CR> 17:30:30 Florian: Sounds fair. 17:30:37 s/need/can/ 17:30:52 tantek: I'm happy to have an informal note that saying we think it should work this way and we need to test. 17:31:24 tantek: Normatively we should pick one so we can test and have an informative note that says we think this is right and we think this is what's being done, bt testing will reveal if that's true. 17:31:43 tantek: I think we have an idea of what we want to do and we can have in the spec this is how you do this with informative. 17:32:08 Florian: I do think this is the right way, but I think fantasai has a good point. I'm happy with the current, I'm okay with it, I'm not sure I prefer. 17:32:21 tantek: If there's feedback before CR we'll take it and if it's after we'll take it. 17:32:40 fantasai: I think you should ping HTML, a11y and maybe TAG for more feedback since it's a where's the boundry issue. 17:32:52 plinss: I'd especially like to hear from a11y. 17:33:10 TabAtkins: If you're doing a game UI or something, this is very useful. It shouldn't limit focus to things you can type into 17:33:22 clarifying my point above: I am ok with the current behavior, but I am not sure I prefer it over fantasai's suggestion, so I would definitely welcome author feedback (and feedback form HTML and accessibility) 17:33:28 -kwkbtr 17:33:33 I am unable to cut in on the phone but can volunteer to bring this to a greater group for accessibility. 17:33:49 fantasai: The issue isn't about focusability, the interesting question here is can CSS be a mech for this and can it be reflected any way in the DOM. If it's purely CSS that effects if this can be focused. 17:33:58 +??P7 17:34:04 tantek: I think TabAtkins disagreed with the game example, such as getting focus and then getting event. 17:34:05 Zakim, ??P7 is me 17:34:05 +kwkbtr; got it 17:34:08 tantek: It might not be a bug. 17:34:10 s/focusability/nature of focusability/ 17:34:21 s/can it be/without it being/ 17:34:34 Florian: Which is why I'm inclined to say both is reasonable and switch to one in the future. 17:34:47 fantasai: Tab's example could be done with HTML 17:34:58 s/switch to one/we should have a swtich for it/ 17:35:03 tantek: I agree we shouldn't do a switch now. Tighten the language of the behavior and include an informative note about the behaviors we're considering and welcome input? 17:35:06 plinss: Obj? 17:35:32 fantasai: And also actively solicit input. Don't jsut put it in the spec and expect feedback. 17:35:35 tantek: That's reasonable. 17:35:50 RESOLVED: Tighten the language of the behavior and include an informative note about the behaviors we're considering and welcome/actively solicit input 17:36:42 plinss++ 17:36:48 plinss: I accept that focusablitiy may be something you want only in CSS, but I don't like these features that are sideeffects of other features. I'd like us to create specific prop that say we're taking control of this. You can always have tha behavior actually set. I don't like magical properties that are side effects. 17:37:30 -smfr 17:37:39 tantek: I think I had a prop in an earlier CSS3 UI and it was dropped for lack of interest or obj. What we're dealing with is we have directional nav supported. This seemed the best result. In general I agree with your philosophy. WE can try and introduc in 4. 17:37:52 Florian: The switch you suggest is what I have in mind, so I agree. 17:38:03 plinss: I think this is something for 4 since 3 is heading to CR. 17:38:19 Florian: I think we're okay with CSS3. There's another, but it can go in e-mail. 17:38:23 tantek: Is that clip? 17:38:25 Florian: Yes. 17:38:36 tantek: It does seem editorial. So yeah, that should be it. 17:38:52 Topic: Allowing @import to be conditional on @supports queries 17:39:31 TabAtkins: We have multi conditional rules, but the number of places that invoke media quesries explicitly only involke @media, so you can't import a stylesheet that has new features. Right now you have to include everything inline 17:40:01 TabAtkins: So my prop is extending the grammar to support the other conditional rules. You can do a straight meda query or you do a supports funtion. 17:40:08 https://lists.w3.org/Archives/Public/www-style/2015Jan/0292.html 17:40:33 TabAtkins: Boris pointed out that in order for this to be useful we'd have to be stricter in spec that says you don't load @imports speculatively. You only load if it matches. 17:40:55 TabAtkins: So I propose to extend the @import grammar so it can support any grammar. 17:41:15 TabAtkins: Also tighten up the lang in CSSOM as to where in the cascade we load conditionally imported style sheets 17:41:16 q+ to ask if *not* loading the style sheet is a security/privacy risk. 17:41:26 TabAtkins: Any comments? Otherwise I'd like a resolution 17:41:31 yes please!!! 17:41:35 fantasai: Seems like a good idea. 17:41:53 fantasai: It seems necessary and reasonable syntax. Add to cascade 4? 17:42:03 TabAtkins: Yes, I'm fine with 4. This isn't urgent, it's useful. 17:42:21 ack bert 17:42:21 Bert, you wanted to ask if *not* loading the style sheet is a security/privacy risk. 17:42:51 Bert: I think it's a cool idea. I was wondering you said don't load the stylesheets because you're risking whatever. I think more and more loading unconditionally because privacy concerns. Do you not expose anything about your browser by not loading? 17:42:56 TabAtkins: No more than you do with scripts 17:43:07 TabAtkins, I think either Cascade 4 or Conditional 4 would make sense. Cascade lets you mess around with @import handling rules a little more directly. 17:43:26 TabAtkins: Even without script you can use the standard put the BG image with a URL pointing to something on your server trick. There's no additional privacy concerns. 17:43:46 plinss: It is part of the fingerprinting surface, but it's already exposed through other means. 17:43:50 TabAtkins, Cascade 3 is in CR, pretty stable. Think it's fair to bikeshed 3, then fork off 4 to add this. 17:44:10 (Would definitely bikeshed 3 first, so 3 is bikeshedded onto /TR) 17:44:13 Bert: BG images aren't conditional anymore. Webkit recently fixed BG of scrollbars because they were exposed. OKay. I jsut wanted to think about those. 17:44:29 TabAtkins: If you have script, you can evaluate MQ whenever you want so exposing more doesn't hurt. 17:44:57 fantasai: I'm thinking we should bikeshed cascade 3 and work up level 4 so we can maybe add this and also introduce default 17:45:02 TabAtkins: We do need to add default 17:45:14 plinss: Anyone object to adding @supports? 17:45:27 RESOLVED: Add @supports to Cascade Level 4 17:45:37 TabAtkins: Can we get a resolution for level 4 ED? 17:45:46 fantasai: If you bikeshed 3 first and then fork it. 17:45:48 TabAtkins: Yeah. 17:46:01 RESOLVED: Create an ED for Cascade Level 4 17:46:10 fantasai: Do people want to resoolve on default now? 17:46:13 Note: resolutions for CSS3-UI issues 78 and 79 captured https://wiki.csswg.org/spec/css3-ui#issue-78 and https://wiki.csswg.org/spec/css3-ui#issue-79 as discussed earlier in the telcon. Thanks for everyone's input. 17:46:16 TabAtkins: I'd rather do that on the list. 17:46:21 fantasai: Okay. 17:46:25 plinss: Anything else? 17:46:35 Topic: Logical border radius properties 17:46:45 https://lists.w3.org/Archives/Public/www-style/2015Jan/0313.html 17:46:50 TabAtkins: Was that fantasai or was that from cameron? 17:46:56 plinss: Cameron brought it up. 17:46:59 https://lists.w3.org/Archives/Public/www-style/2015Jan/0327.html 17:47:01 -adenilson 17:47:04 plinss: Anyone want to talk on it? 17:47:07 Rossen: What about? 17:47:24 fantasai: Naming conventions. border-block-start-order-????? is really wrong. 17:47:45 fantasai: There was a convention to do block first. We would jsut want to resolve on that. 17:47:49 TabAtkins: Sounds good to me. 17:48:08 fantasai: I posted the proposal in IRC 17:48:09 s/order-?????/inline-start-corner/ 17:48:21 s/-corner/-radius/ 17:48:29 plinss: Okay. Any thoughts about adding this? 17:48:34 Rossen: Sounds reasonable. 17:48:54 +??P3 17:48:55 TabAtkins: As part of the logical prop it would logicalizing most things. It would be let's use this pattern for things that are extra long. 17:49:02 Zakim, ??P3 is me. 17:49:02 +adenilson; got it 17:49:08 Rossen: fantasai and I have quite a bit of work on that spec. This is good input and makes sense. 17:49:18 fantasai: This would be the pattern for things that reference corners 17:49:27 plinss: Okay. Want a resolution? 17:50:02 fantasai: Properties referencing corners dropt he axis mentions and go into the block access first, for example border-start-end-radius 17:50:05 svillar has joined #css 17:50:05 plinss: Obj? 17:50:16 s/access/axis/ 17:50:20 RESOLVED: Properties referencing corners drop the axis mentions and go into the block access first, for example border-start-end-radius 17:50:34 Rossen: Is fantasai auto-sizing of ruby not on the agenda anymore? 17:50:41 plinss: I think we did it at the F2F 17:50:55 plinss: Anything else? 17:51:13 fantasai: I have DoC for flexbox and a couple more issues were raised. Upcoming will be dealing with that, but it's mostly done 17:51:20 plinss: That's a future call? 17:51:25 fantasai: Yeah. Prob next week. 17:51:34 -hober 17:51:35 -TabAtkins 17:51:37 -gregwhitworth 17:51:38 bye 17:51:38 - +1.860.479.aadd 17:51:38 -BradK 17:51:39 -dauwhe 17:51:40 -adenilson 17:51:41 -[Microsoft] 17:51:41 -tgraham 17:51:41 -glazou 17:51:42 -fantasai 17:51:42 -alex_antennahouse 17:51:42 -Florian 17:51:42 plinss: Alright, everyone gets 10 minutes. 17:51:43 -kwkbtr 17:51:43 -bcampbell 17:51:44 -deirdrelee 17:51:45 -tantek 17:51:46 -plinss 17:51:48 -sanja 17:51:49 -SimonSapin 17:51:49 -Bert 17:51:51 -dael 17:51:51 -??P0 17:51:56 -MikeMiller 17:52:46 Zakim, who is on the phone? 17:52:46 On the phone I see +1.631.398.aabb 17:52:50 - +1.631.398.aabb 17:52:51 Style_CSS FP()12:00PM has ended 17:52:51 Attendees were SimonSapin, glazou, +1.479.764.aaaa, Florian, plinss, dael, Rossen, dauwhe, [Microsoft], adenilson, gregwhitworth, fantasai, tgraham, +1.631.398.aabb, MikeMiller, 17:52:51 ... alex_antennahouse, kwkbtr, smfr, bcampbell, +43.134.001.00aacc, BradK, +1.860.479.aadd, +1.281.305.aaee, TabAtkins, sanja, hober, Bert, tantek, deirdrelee 17:53:00 glazou has left #css 17:57:05 hello bcampbell you had a question about nav-* props and a11y? 17:57:43 hello tantek, yes. I am looking at the spec, just trying to understand the issue better so I can discuss with a11y experts on my side to better inform you. 17:58:29 As I understand it, the issue is whether to give items focus when stating a focus direction that were not going to get focus originally in the DOM? 17:58:58 as opposed to simply jumping from the original focussable items 18:00:06 bcampbell: Right, 'nav-up' explicitly points to a target element that should receive focus when you do an "upwards" spatial navigation from the (focused) source element. 18:00:09 when I try the jsbin example, the paragraph does not get focus as it says it might. 18:00:34 bcampbell - try it with a div or span destination 18:00:35 bcampbell: Note that desktop browsers dont' generally implement nav-*. 18:00:40 Or do they? 18:00:41 and that 18:00:55 Anyway, some TV browsers do. 18:01:12 Okay, but I can understand the issue without that working. 18:01:13 bcampbell: for any such test you need an "atomic" test first on the page that shows whether the property is supported *at all* in the browser you're using 18:01:21 bcampbell: yes. The currently implied behavior is to make the target of nav-* focusable if it wasn't before. A alternative would be to follow dom order, starting with children, order until you find a focusable element and focus that instead. 18:01:27 e.g. nav-right from one to another 18:01:31 which is the common case 18:01:48 so if you're testing a particular browser/implementation, start with that 18:02:11 the point is that as spec'd (and will be tightened), nav-* properties can make any element focusable as the destination of directional navigation 18:02:38 that has TWO impacts 18:02:38 1. that element is in :focus 18:02:38 2. that element receives events as focused elements do 18:02:43 TabAtkins pointed that out 18:02:46 TabAtkins: Presto Opera implements nav-* on desktop. Webkit needs a command line argument to activate it, but does implement spatial navigation on desktop 18:02:52 and the "obvious" use-case for that is games 18:02:58 Florian: Ah, thanks. 18:03:05 which are typically an a11y challenge in general 18:03:17 TabAtkins: Blink same as webkit, as the predates the fork 18:03:19 so if we can figure out how to make things better here for a11y, we can *try* to improve the situation with games 18:03:19 Or, for example, SVG graphs. 18:03:34 spatial navigation across graph links. 18:03:39 Florian - do you have a URL documenting how to activate WebKit directional navigation? 18:03:56 I'd like to link to those in the spec or at least wiki 18:04:05 both for a11y folks to try out 18:04:13 and for other implementers to play with while they themselves are implementing 18:04:23 e.g. FirefoxOS is looking at directional nav now 18:04:32 Would all the elements receive focus automatically or would you need to tag them as such? I'm assuming here that it would be automtic within the frame that all elements receive focus? 18:04:32 because of the growing number of different devices using it 18:04:47 or working on using it, e.g. TVs or those USB sticks that plug into tvs 18:04:56 yes, a working demo would be really great 18:05:07 bcampbell: yes I'm going to add a working example to the spec 18:05:13 as I have with other features 18:05:20 e.g. box-sizing, cursor, text-overflow 18:05:43 bcampbell: I don't know what you mean by within the frame 18:05:54 tantek: no url. Just entries in my bash history. 18:06:15 I was trying to use the draft language :) 18:06:17 LIke, they're not tab-focusable (unless you use the tabindex attribute, or we reintroduce the dropped nav-index property). 18:06:26 right 18:06:47 Florian - maybe you could write up something brief on the CSSWG wiki? 18:07:03 or a blog post 18:07:25 actually, it looks like I was wrong, this seems to be a blink only feature, not a webkit one 18:07:35 open /Applications/Google\ Chrome.app --args --enable-spatial-navigation 18:07:39 Sorry, yes, it's a bit muddy to me now. For instance, if you put a nav-down on a button mid-way down a page, does everything after come into focus, just the next focusable element, or all things after the button. 18:07:50 tantek: which wiki page do you want this in? 18:07:55 bcampbell: OH, you misunderstand the feature entirely! 18:08:03 oh geez, figures 18:08:11 nav-down contains an ID of the element that'll be navigated to when you press down from the source element. 18:08:26 so I have it upside-down in my head 18:09:04 when you say "press down" you mean literally the down arrow (when talking keyboard). 18:09:15 Yeah (or equivalent button on your input device). 18:09:20 ok, right 18:09:37 ok, this is coming together now thanks 18:09:55 and thus the question of widgets 18:09:56 So I have #a { nav-down: #b; }, then if #a is focused, I can press Down to move the focus to #b. 18:09:57 that use arrows 18:11:14 Florian - probably a new one? 18:11:17 let me check 18:11:30 so they are not in the tab order, they are in a nav order, such as being in a nav-tree for a keyboard user 18:11:43 bcampbell: correct! 18:12:00 except I would say not in the *sequential or linear nav order* rather than *tab* 18:12:12 the *tab key* is just one way to do sequential or linear nav 18:12:29 yes 18:12:32 gotcha 18:12:38 tab / ctrl-tab to go backwards 18:13:40 A new one means no-one will find it, and then it isn't terribly useful. If there is a good place for info like this, I'll put it there. Otherwise, maybe this is the excuse I needed to get a (self hosted) blog :) The last one (a while ago) died when the host gave up on hosting. 18:14:23 Florian - not true about no one finding it 18:14:27 that's what links are for :) 18:14:37 and ++ to a self-hosted blog! 18:14:41 Ultimately this is for jumping around to elements non-sequentially 18:14:46 even if you just put up static HTML pages for now at stable permalinks 18:15:04 bcampbell: rather than "non-sequentially" - the point is, *directionally* 18:15:08 I prefer a positive framing 18:15:12 ok 18:15:13 rather than a "this is not x" framing 18:15:14 sure 18:15:15 sorry 18:15:23 cup is half full, that works for me 18:15:23 There is a sequence, it's just not linear. ^_^ 18:15:31 that ^^^ 18:15:35 it's a 2D sequence 18:15:46 we may introduce a 3D sequence in the future :) 18:15:50 per webVR 18:16:01 I have to look at it the reverse, but what I really like to hear is what you just said, the purposes in a positive way so I can make valid arguments. 18:16:11 yes, quantum sequencing 18:16:35 bcampbell: most UIs on TVs are 2D 18:16:43 think of DVD UIs for example 18:16:51 right 18:16:53 where you have a bunch of "hot" areas scattered around some graphic image, or moving background 18:17:02 and right now, generally, you can only arrow in the sequence of the tab order? 18:17:13 and you need a way to say, when you press the ">" button, it should go from focusing hot area A to hot area B 18:17:22 ok 18:17:25 on a DVD there is no tab order for example 18:17:30 there is ONLY directional nav 18:17:36 that's the experience we're talking about 18:17:42 makes sense 18:17:43 except instead of a DVD UI, imagine it's built in HTML 18:17:46 + CSS of course 18:17:54 but it could look exactly the same 18:18:00 I started mocking one up years ago 18:18:07 hmm maybe I should put it in the spec 18:19:22 I'm working on a11y implications in my head, but it would also probably be a general usability issue when talking about keyboards. 18:19:43 here: http://tantek.com/CSS/Examples/matrixdvdmenu.html 18:20:57 tantek: Most DVD menus would just be a bunch of abspos images, of course. ^_^ 18:21:30 I've seen a lot of DVDs! 18:21:47 They're all pretty consistent. 18:22:07 In other words, they could all be described with SVG. 18:22:38 ignorant question: where is the crossover with tv interfaces and html/css? 18:23:24 Is DirectTv's interface in html? 18:23:51 or is this just an example for tv "on a browser" - or am I just lost and need more coffee? 18:25:49 TabAtkins: I know, let's just use SVG as the UI platform :P ;) 18:26:21 bcampbell: set top boxes from Microsoft (e.g. WebTV) since 2000s all have UI in HTML+CSS+JS 18:26:28 I personally worked on that 2000-2004. 18:26:35 and they've continued to the present day 18:27:02 Excellent. I was unaware what platform they have been on. 18:27:29 WebTV was the pioneer here 18:27:34 but they did most of it with custom HTML 18:27:56 the MSTV platform stuff was what I worked on, which used the Tasman rendering engine, and we built our UIs with proper (X)HTML+CSS+JS 18:28:10 some of the first set top boxes to do so (if not the first) 18:28:22 I know there are more these days, but not sure of specifics. Generally, though, embedding WebKit as your UI layer is pretty common. 18:28:27 Opera was used as the embedded UI (and browser) on many set-top boxes, with HTML+CSS+JS+SVG as the UI 18:28:28 there were also other industry-vertical specific attempts like DVB-HTML 18:29:30 around 2003-2007, there were many set-top boxes using embedded SVG UAs as the UI, with the UI typically being SVG-Tiny 1.1 or 1.2 18:30:02 I think (?) that faded off in 2008-2010, but I'm not sure 18:30:25 BitFlash and Ikivo were big players in that space 18:30:25 Opera too 18:33:08 bcampbell: here's further documentation: https://en.wikipedia.org/wiki/Tasman_%28layout_engine%29#Version_history specifically note "The Tasman engine is now used in the Microsoft TV Mediaroom Edition." 18:34:15 So, is directional navigation for this use case specifically? 18:35:07 and thank you, I find this very interesting and could get lost now for hours if it weren't for several more meetings I must not miss. 18:35:26 Joost, an IPTV company, used SVG exclusively as it UI for the first iterations https://en.wikipedia.org/wiki/Joost 18:35:48 bcampbell: yes 18:35:58 I think Joost might have moved to Silverlight later on 18:36:00 in fact it started in WebTV as proprietary extensions to HTML 18:36:46 but when we were looking at follow-on platform updates, e.g. for the UltimateTV and MSTV product lines, I worked actively on opening those features up, in proposals 18:37:08 hence the nav-* directional properties proposed in CSS3-UI back when I was working on set top boxes 18:39:14 I would think a creative designer could also figure out ways to leverage this in web apps/pages... the problem being the usual: devs hacking to save time, using things like this to fix the order rather than doing good code. 18:41:37 bcampbell: it is *definitely* a design problem 18:41:41 that's why we included it in the CSS 18:41:55 specifically *directional* 2D navigation is heavily tied to the layout of the elements 18:42:04 thus it makes sense to specify them in the same place, ergo style sheet 18:42:38 more important than an abstract notion of "separate behavior and presentation" 18:43:58 I think I see what you mean when you say 2D vs 3D ... you can have a widget literally on top of others, with layering... you could either tab to the next widget, or arrow to something somewhere else on the screen. 18:44:22 yeah, wow. 18:47:20 It would be interesting to see an example of directional nav surrounding other sequential nav with some widget there which uses the arrow keys, also. 18:48:50 bcampbell: with current display devices, only 2D or 2.5D really makes sense 18:48:56 maybe with some overlap 18:49:11 and hence sometimes the focus outline of something *in the back* showing up *on top* of stuff *in front* 18:49:23 but once we get to VR screens, all bets are off 18:49:37 designers are coming up with new ways to make webVR more usable than just an extension of the 2D/2.5D experience 18:49:44 thus we don't actually know yet what they'll settle on 18:49:51 they're still experimenting with UX! 18:50:12 ha 18:50:24 that's my thing 18:50:29 used to be 18:51:51 UX or VR? 18:52:42 Interaction - UX 18:52:43 HCI 18:53:24 I jumped into accessibility about a year ago 18:54:59 the usual story, web dev for many years, specialized in ux, then more into HCI (MS), consulted and now trying to use it all to help people with disabilities :) 18:56:16 thank you so much for clarifying this for me. I have to drop for another meeting, but would like to stay in this loop and can bring this to the a11y experts here, too, for help. 19:00:53 adenilson has joined #css 19:07:52 bcampbell: that's a very logical progression. makes a lot of empathetic sense :) 19:08:18 I really appreciate you getting and bringing a11y perspective to our UI work. It's super important. 19:08:35 zcorpan has joined #css 19:09:01 Thank you. It might sound funny but I'm honored to be involved and always hoping to have more time to be more involved than I am now. 19:11:33 Really hoping to be at f2f in NY, too. 19:12:05 I'm also happy we've got more people interested and participating in UI related discussions in CSS. For a while it seemed like no one else cared. 19:12:42 Hope to see you in NY also. 19:24:01 adenilson has joined #css