/irc-logs / w3c / #css / 2015-02-25 / end

Options:

# Session Start: Wed Feb 25 00:00:00 2015
# Session Ident: #css
# [00:30] * leaverou is now known as leaverou_away
# [00:31] * leaverou_away is now known as leaverou
# [00:52] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [01:06] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [01:08] * Joins: dauwhe (~dauwhe@public.cloak)
# [01:11] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [01:11] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [01:17] <plinss> TabAtkins: hopefully that’s not a naive split on comma, because there are values like: FontFace/FontFace(family, source, descriptors)
# [01:17] <TabAtkins> plinss: Correct, it's not. ^_^
# [01:17] <TabAtkins> It's a proper parse that pays attention to parens.
# [01:18] <TabAtkins> https://github.com/tabatkins/bikeshed/blob/master/bikeshed/ReferenceManager.py#L583
# [01:22] <plinss> (you do realize that code won’t deal with nested parens…)
# [01:22] <TabAtkins> Nested parens don't happen yet, so shrug.
# [01:22] <TabAtkins> It's a for value.
# [01:23] <TabAtkins> But yeah, I could do better.
# [01:23] <TabAtkins> Not even totally sure why I wrote it this way, it seems really complicated.
# [01:23] <plinss> yeah, for what you have a regex could have done it
# [01:24] <TabAtkins> All right, nuts to this, I'll rewrite.
# [01:24] <plinss> fwiw, shepherd just stores the entire value of the for attribute in the db, the api handler parses it
# [01:24] <TabAtkins> ANYWAY, you know what to do. ^_^
# [01:24] <TabAtkins> Ah, kk.
# [01:24] <plinss> so this leaves me with both space and comma separated values in the db…
# [01:25] <plinss> so I’ll have to make the parser (which knows the bikeshed version) normalize for the db
# [01:25] <TabAtkins> Kinda sorta. Like I said, I've already changed a bunch of the space-separated (and a bunch of them were comma-separated anyway, and were being treated incorrectly).
# [01:25] <TabAtkins> If you just switch to comma-separation, I can manually go through and figure out where that goes wrong.
# [01:25] <plinss> yeah, but some of them are on /TR so won’t get updated for a while
# [01:25] <TabAtkins> (I'll just look at everything with a space that's not inside of parens, and see if it meant to be multiple for values instead.
# [01:26] <TabAtkins> That just means we have to publish again!
# [01:26] <plinss> that too
# [01:26] <TabAtkins> That's not even a problem. ^_^
# [01:27] <plinss> since the API returns an array, I want it to return the right thing, so I’ll handle the space vs comma normalization on my end
# [01:27] * Quits: dauwhe_ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [01:32] <TabAtkins> Okay. It's okay to return duplicates in the for array if you want.
# [01:32] * TabAtkins is curious how you'll dedup.
# [01:32] <TabAtkins> Rather, how you'll normalize.
# [01:32] <TabAtkins> I guess you can infer that "dfn" types with spaces probably intend to be a single term, but anything else with spaces intends to be space-separated. (Assuming no commas in either situation.)
# [01:35] <plinss> Actually I was just goint to look at the bikeshed version meta tag, anything 1.0.0 or better will split on commas, everything else split on spaces
# [01:35] <plinss> (ignoring spaces and commas inside parens)
# [01:38] <TabAtkins> Oh duh, yeah, that'll work.
# [01:38] <TabAtkins> Yay for versioning!
# [01:45] <plinss> TabAtkins: fwiw, here’s a regex that will split on commas except within parens: re.split(r',(?![^()]*\))', text)
# [01:46] <TabAtkins> danke
# [01:46] <plinss> bitte
# [01:48] <TabAtkins> Just pushed it, so hopefully you're right. ^_^ It looks good, though - pretty clever.
# [01:51] * Joins: dauwhe (~dauwhe@public.cloak)
# [01:51] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [02:02] * leaverou is now known as leaverou_away
# [02:14] <plinss> TabAtkins: if you want to strip whitespace and filter empty values, use: return [value.strip() for value in re.split(r',(?![^()]*\))', forValues) if value.strip()]
# [02:14] <TabAtkins> Ah, duh. Yeah, I definitely need to.
# [02:15] <TabAtkins> Sorry, alternating between watching youtube, writing a spec, and drinking, so my coding is a little off at the moment.
# [02:16] <plinss> friends don’t let friends code loaded
# [02:17] <TabAtkins> plinss: Do we have the auto-building thing set up for Houdini?
# [02:17] <plinss> yes
# [02:17] <TabAtkins> Oh, duh, of course we do.
# [02:17] <TabAtkins> k, gonna add a gitignore to the repo and kill all the .htmls.
# [02:18] <plinss> thought I already did that
# [02:18] <TabAtkins> Ah, you did.
# [02:18] <TabAtkins> Okay, then I just need to delete a bunch of .htmls.
# [02:18] <TabAtkins> Or I guess they're all building cleanly.
# [02:19] <TabAtkins> And that's why I'm not getting any emails.
# [02:19] <plinss> shepherd is currently re-parsing all the specs to update the db, so generation is pending that...
# [02:19] <plinss> (almost done)
# [02:19] <TabAtkins> ah, k
# [02:28] * heycam is now known as heycam|away
# [02:31] <TabAtkins> zcorpan: Your CSSOM conversion to Bikeshed left almost all of your autolinks as <span> or <code>, which means they aren't autolinking at all. You also kept most of your linking texts in the silly concept-foo form, when that should just be the ID. I'm fixing for you.
# [03:34] * Quits: dwim (~dwim@public.cloak) ("Leaving.")
# [03:37] * Joins: dwim (~dwim@public.cloak)
# [03:48] * heycam|away is now known as heycam
# [03:51] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [04:12] * leaverou_away is now known as leaverou
# [04:46] * Quits: tantek (~tantek@public.cloak) (tantek)
# [04:48] * Joins: adenilson (~anonymous@public.cloak)
# [04:53] * Joins: jdaggett (~jdaggett@public.cloak)
# [05:02] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [05:04] * Joins: tantek (~tantek@public.cloak)
# [05:09] * Quits: tantek (~tantek@public.cloak) (tantek)
# [06:16] * heycam is now known as heycam|away
# [06:38] * heycam|away is now known as heycam
# [07:03] * Joins: tantek (~tantek@public.cloak)
# [07:40] * heycam is now known as heycam|away
# [07:48] * Quits: tantek (~tantek@public.cloak) (tantek)
# [07:51] * Joins: zcorpan (~zcorpan@public.cloak)
# [09:06] * Joins: svillar (~sergio@public.cloak)
# [09:18] * Quits: svillar (~sergio@public.cloak) (Ping timeout: 180 seconds)
# [09:41] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [09:53] * Joins: antonp (~Thunderbird@public.cloak)
# [09:55] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [09:59] * Joins: antonp (~Thunderbird@public.cloak)
# [10:01] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [10:02] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [10:12] * Joins: antonp (~Thunderbird@public.cloak)
# [10:14] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [10:26] * Joins: antonp (~Thunderbird@public.cloak)
# [10:28] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [10:36] * Joins: svillar (~sergio@public.cloak)
# [10:37] * Joins: glazou (~glazou@public.cloak)
# [10:39] * Quits: svillar (~sergio@public.cloak) ("Ex-Chat")
# [10:41] * Joins: svillar (~sergio@public.cloak)
# [10:53] * Joins: lajava (~javi@public.cloak)
# [10:56] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [11:06] * Joins: antonp (~Thunderbird@public.cloak)
# [12:01] * Quits: Bert (bbos@public.cloak) (Client closed connection)
# [12:10] * Joins: Bert (bbos@public.cloak)
# [12:12] * Joins: jdaggett (~jdaggett@public.cloak)
# [12:29] * Joins: zcorpan (~zcorpan@public.cloak)
# [13:15] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [13:24] * Quits: svillar (~sergio@public.cloak) (Ping timeout: 180 seconds)
# [13:50] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [14:07] * Joins: plh (plehegar@public.cloak)
# [14:16] * Joins: zcorpan (~zcorpan@public.cloak)
# [14:19] * Joins: svillar (~sergio@public.cloak)
# [16:08] * plh is now known as plh-roof
# [17:19] * Joins: Florian (~Florian@public.cloak)
# [17:31] * Joins: Zakim (zakim@public.cloak)
# [17:31] <glazou> Zakim, this will be Style
# [17:31] <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 32 minutes
# [17:32] * Joins: RRSAgent (rrsagent@public.cloak)
# [17:32] <RRSAgent> logging to http://www.w3.org/2015/02/25-css-irc
# [17:32] <glazou> RRSAgent, make logs public
# [17:32] <RRSAgent> I have made the request, glazou
# [17:33] * glazou changes 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 )'
# [17:42] <Florian> There are lots of things that are very nice about Japan. 2am telecons is not one of them
# [17:42] * Joins: bkardell_ (~uid10373@public.cloak)
# [17:44] <glazou> Florian: oh come on, don’t start complaining like all french people ;-)
# [17:44] <glazou> hey bkardell_ you were the first one this morning for the bday wishes, even before the family eh !
# [17:44] <glazou> thx :-D
# [17:44] <bkardell_> :)
# [17:48] <Florian> glazou: but I am French, why should I not complain? Also, happy birthday.
# [17:49] <glazou> :-) thx!
# [17:53] <Ms2ger> Happy birthday, or so I hear :)
# [17:55] * Joins: tantek (~tantek@public.cloak)
# [17:55] <glazou> thanks Ms2ger !
# [17:56] <bkardell_> I have a conflict today, so regrets for not being able to call in... will try to follow on IRC
# [17:56] <glazou> ok
# [17:58] <tantek> good morning
# [17:58] <glazou> hi tantek
# [17:58] <Florian> Hi Tantek
# [17:59] <tantek> hello glazou Florian
# [17:59] <Zakim> Style_CSS FP()12:00PM has now started
# [17:59] <Zakim> +??P26
# [17:59] <tantek> good news css3ui TR draft published
# [17:59] <SimonSapin> Zakim, ??P26 is me
# [17:59] <Zakim> +SimonSapin; got it
# [17:59] <Zakim> +??P28
# [17:59] <glazou> Zakim, ??P28 is me
# [17:59] <Zakim> +glazou; got it
# [17:59] <tantek> so I hope to get all the pending edits in in the next couple of weeks or so
# [18:00] <tantek> and then I want to do another WD with all of those, since that seems to be what the current publishing process allows for
# [18:00] <Zakim> + +1.479.764.aaaa
# [18:00] * Joins: dael (~dael@public.cloak)
# [18:00] <Florian> Zakim, I am aaaa
# [18:00] <Zakim> +Florian; got it
# [18:00] <Zakim> +plinss
# [18:01] <Zakim> +dael
# [18:01] * Joins: antenna (~antenna@public.cloak)
# [18:02] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [18:02] <Zakim> +[Microsoft]
# [18:02] <Rossen> zakim, microsoft has me
# [18:02] <Zakim> +Rossen; got it
# [18:02] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [18:03] * Joins: adenilson (~anonymous@public.cloak)
# [18:03] <Zakim> +dauwhe
# [18:03] * Joins: AH_Miller (~mike@public.cloak)
# [18:03] <Zakim> +??P38
# [18:03] <adenilson> Zakim, ?P38 is me.
# [18:03] <Zakim> sorry, adenilson, I do not recognize a party named '?P38'
# [18:03] <Zakim> +[Microsoft.a]
# [18:03] * Joins: alex_antennahouse (~458c94ae@public.cloak)
# [18:03] * Joins: smfr (~smfr@public.cloak)
# [18:03] <adenilson> Zakim, ??P38 is me.
# [18:03] <Zakim> +adenilson; got it
# [18:04] <gregwhitworth> Zakim, Microsoft.a is me
# [18:04] <Zakim> +gregwhitworth; got it
# [18:04] <Zakim> +[IPcaller]
# [18:04] * Joins: andreyr (~andreyr@public.cloak)
# [18:04] <Zakim> +[IPcaller.a]
# [18:04] <Zakim> +fantasai
# [18:04] <tgraham> Zakim, IPCaller is me
# [18:04] <Zakim> +tgraham; got it
# [18:05] <Zakim> + +1.631.398.aabb
# [18:05] <alex_antennahouse> I think im IPcaller.a
# [18:05] <Zakim> +MikeMiller
# [18:05] <dael> ScribeNick: dael
# [18:05] <dael> zakim, IPCaller.a is alex_antennahouse
# [18:05] <Zakim> +alex_antennahouse; got it
# [18:06] * dael fantasai, did you get the e-mails with minutes from the F2F? I know my e-mails sometimes end up in your spam folder ^-^
# [18:06] <Zakim> +??P11
# [18:06] * Joins: bcampbell (~chatzilla@public.cloak)
# [18:06] <kwkbtr> Zakim, ??P11 is me
# [18:06] <Zakim> +kwkbtr; got it
# [18:06] <Zakim> +smfr
# [18:07] * Joins: sanja (~sanja@public.cloak)
# [18:07] <Zakim> +[IPcaller]
# [18:07] <bcampbell> IPCaller is me
# [18:07] <dael> Zakim, IPCaller is bcampbell
# [18:07] <Zakim> +bcampbell; got it
# [18:08] <dael> plinss: Let's get started. Anything to add to the agenda?
# [18:08] <dael> ??: I have something remove.
# [18:08] * smfr changes topic to 'https://lists.w3.org/Archives/Public/www-style/2015Feb/0494.html'
# [18:08] <Zakim> + +43.134.001.00aacc
# [18:08] <dael> ??: Transform-style 3d issue has been resolved by now.
# [18:08] <dael> plinss: Okay.
# [18:08] <fantasai> s/now/email/
# [18:08] <smfr> s/??/smfr/
# [18:08] * Joins: BradK (~bradk@public.cloak)
# [18:08] * dauwhe +1
# [18:08] <dael> plinss: To start, happy birthday glazou
# [18:08] <dael> Topic: WebVTT review.
# [18:09] <dael> plinss: There's been discussion on e-mail, but do we have group concensus feedback to send? Do folks need time to review?
# [18:09] <Zakim> +BradK
# [18:09] <Zakim> + +1.860.479.aadd
# [18:09] <Zakim> + +1.281.305.aaee
# [18:09] <TabAtkins> Zakim, aaee is me
# [18:09] <Zakim> +TabAtkins; got it
# [18:09] <dael> 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.
# [18:09] <sanja> +43.134.001.00aacc is me
# [18:09] <dael> Topic: abspos change compat risk
# [18:10] * Bert a few minutes late. Will dial-in soon.
# [18:10] <sanja> Zakim, aacc is me
# [18:10] <Zakim> +sanja; got it
# [18:10] <Zakim> +hober
# [18:10] <dael> 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.
# [18:10] <dael> 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.
# [18:10] <Zakim> +Jerome
# [18:11] <dael> 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.
# [18:11] * Bert zakim, jerome is me
# [18:11] * Zakim +Bert; got it
# [18:11] <dael> 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.
# [18:11] <dael> fantasai: If websites want this behaiour we need to dig into these cases.
# [18:11] <dael> Rossen: I don't believe this is what people want, it's what people have. They're using what they have.
# [18:12] <dael> 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.
# [18:12] * TabAtkins Man, who keeps pressing phone buttons?
# [18:13] <dael> 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
# [18:13] <dael> Rossen: Does that make sense?
# [18:13] <dael> 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.
# [18:13] <Zakim> +??P12
# [18:13] <tantek> zakim, ??p12 is me
# [18:13] <Zakim> +tantek; got it
# [18:14] <dael> 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.
# [18:14] <dael> fantasai: Okay.
# [18:14] <dael> fantasai: What can we put to tell impl they need to change?
# [18:14] <dael> gregwhitworth: Is TabAtkins on the call?
# [18:14] <dael> TabAtkins: Yes.
# [18:14] <dael> gregwhitworth: What do you think?
# [18:14] <fantasai> s/What can we put to tell impl they need to change?/need to hear from other implementers/
# [18:14] <dael> TabAtkins: I haven't had the change to check with my team.
# [18:14] <dael> gregwhitworth: Why don't we circle back. dbaron isn't on.
# [18:15] <dael> fantasai: While we're on flexbox, TabAtkins did you sort out the margins?
# [18:15] <dael> TabAtkins: I couldn't figure out where so it was yesterday. Let me see if anyone commented.
# [18:15] <dael> fantasai: That holds up pub.
# [18:15] <dael> TabAtkins: No responce yet. I'll let you know when I do.
# [18:15] <dael> fantasai: We'll have to come back next week.
# [18:15] <dael> TabAtkins: Yes.
# [18:15] <dael> Topic: CSS3 UI
# [18:15] <Zakim> +??P0
# [18:15] <dael> Florian: We just got a WD out
# [18:16] <dael> Florian: Also I sent a mail about issue 69 which was the long standing one about box sizing.
# [18:16] <Zakim> +deirdrelee
# [18:16] <dael> 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.
# [18:16] <dael> Florian: I erred on more explicit.
# [18:17] <Florian> https://lists.w3.org/Archives/Public/www-style/2015Feb/0357.html
# [18:17] <dael> Florian: Things to discuss, issue 79
# [18:17] <dael> 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.
# [18:17] <dael> tantek: That's desktop only.
# [18:18] <dael> 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
# [18:18] <Zakim> -adenilson
# [18:19] <dael> 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.
# [18:19] <dael> 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.
# [18:19] <dael> Florian: Okay.
# [18:19] <dael> tantek: That's the history. Maybe we should have a note that mentions that. This isn't the first time it was mentioned.
# [18:20] <Zakim> +??P3
# [18:20] <dael> 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
# [18:20] <dael> tantek: That makes sense.
# [18:20] <adenilson> Zakim, ??P3 is me.
# [18:20] <Zakim> +adenilson; got it
# [18:20] <dael> Florian: Do you have examples of current non-desktop browser?
# [18:21] <dael> 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
# [18:21] <dael> 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?
# [18:22] <dael> 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.
# [18:22] <dael> 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.
# [18:23] <dael> 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.
# [18:23] <dael> Florian: I have no direct knowledge, but that sounds reasonable. I think it would be better.
# [18:23] <dael> tantek: Since it's normative in 2.1 it needs to be normative here.
# [18:24] <dael> tantek: Two use cases are setop boxes and web VR
# [18:24] <dael> Florian: Anyone else have something to add?
# [18:24] <dael> 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.
# [18:24] <dael> plinss: Other opinions?
# [18:25] <dael> 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
# [18:25] <dael> Florian: If we have more time, I'd like to do issue 78.
# [18:25] <Florian> https://lists.w3.org/Archives/Public/www-style/2015Feb/0344.html
# [18:25] * glazou sorry for bg noise
# [18:25] <dael> Florian: This is about the directional focus prop
# [18:26] <dael> 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.
# [18:26] * Rossen is now known as Rossen_away
# [18:26] <dael> 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.
# [18:26] * leaverou glazou Happy birthday!!
# [18:26] <dael> Florian: That was fantasai disputing this. I think the current intent is what you say.
# [18:26] <dael> Florian: The spec is currently implicit but ambig.
# [18:26] * glazou thanks leaverou
# [18:27] * tantek happy birthday glazou too!
# [18:27] * glazou thx tantek !
# [18:27] * Rossen_away is now known as Rossen
# [18:27] <dael> Florian: We should make the intenet explicit and that a selector should match, but we should consider that it makes things unfocusable and focusable.
# [18:27] <dael> 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.
# [18:28] <dael> tantek: I want the group to approve or tell us to do more.
# [18:28] <dael> Florian: Both behaviours are useful and I'm not strongly minded about which. Which one should be the default I'm not sure.
# [18:28] <dael> tantek: I'd rather a smart default instead of a switch unless there's a usecase that both are useful.
# [18:29] <dael> 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.
# [18:29] <dael> tantek: We haven't heard a lot so far.
# [18:30] <dael> 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
# [18:30] <dael> TabAtkins: In particular some things are only focusable when other things are the active focus.
# [18:30] <fantasai> s/without HTML/without reflecting this in the HTML/
# [18:30] <bcampbell> thanks for mentioning the a11y implications, would like to investigate further and help there.
# [18:31] <dael> 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.
# [18:31] <dael> tantek: IN that case, content across impl is unlikely
# [18:32] <dael> 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.
# [18:32] <dael> plinss: What does it mean to focus on something unfocusable? If it can't take imput what's the value?
# [18:32] <dael> TabAtkins: You can always do tabindex=url
# [18:32] <dael> tantek: That's already in the platform.
# [18:32] <dael> plinss: Seems like a bug. Should we perpetuate.
# [18:32] <gregwhitworth> IE: with tabindex-1 allows both active and focus to work
# [18:33] <gregwhitworth> without, :active only works
# [18:33] <dael> 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
# [18:33] <dael> 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.
# [18:34] <dael> fantasai: That's what we need to push to CR>
# [18:34] <dael> Florian: Sounds fair.
# [18:34] <fantasai> s/need/can/
# [18:34] <dael> tantek: I'm happy to have an informal note that saying we think it should work this way and we need to test.
# [18:34] <dael> 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.
# [18:35] <dael> 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.
# [18:35] <dael> 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.
# [18:35] <dael> tantek: If there's feedback before CR we'll take it and if it's after we'll take it.
# [18:36] <dael> fantasai: I think you should ping HTML, a11y and maybe TAG for more feedback since it's a where's the boundry issue.
# [18:36] <dael> plinss: I'd especially like to hear from a11y.
# [18:36] <dael> 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
# [18:36] <Florian> 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)
# [18:37] <Zakim> -kwkbtr
# [18:37] <bcampbell> I am unable to cut in on the phone but can volunteer to bring this to a greater group for accessibility.
# [18:37] <dael> 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.
# [18:37] <Zakim> +??P7
# [18:37] <dael> tantek: I think TabAtkins disagreed with the game example, such as getting focus and then getting event.
# [18:37] <kwkbtr> Zakim, ??P7 is me
# [18:37] <Zakim> +kwkbtr; got it
# [18:37] <dael> tantek: It might not be a bug.
# [18:37] <fantasai> s/focusability/nature of focusability/
# [18:37] <fantasai> s/can it be/without it being/
# [18:38] <dael> Florian: Which is why I'm inclined to say both is reasonable and switch to one in the future.
# [18:38] <fantasai> fantasai: Tab's example could be done with HTML
# [18:38] <Florian> s/switch to one/we should have a swtich for it/
# [18:38] <dael> 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?
# [18:38] <dael> plinss: Obj?
# [18:39] <dael> fantasai: And also actively solicit input. Don't jsut put it in the spec and expect feedback.
# [18:39] <dael> tantek: That's reasonable.
# [18:39] <dael> RESOLVED: Tighten the language of the behavior and include an informative note about the behaviors we're considering and welcome/actively solicit input
# [18:40] <fantasai> plinss++
# [18:40] <dael> 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.
# [18:40] * smfr has to drop off, sorry
# [18:41] <Zakim> -smfr
# [18:41] <dael> 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.
# [18:41] <dael> Florian: The switch you suggest is what I have in mind, so I agree.
# [18:41] <dael> plinss: I think this is something for 4 since 3 is heading to CR.
# [18:41] <dael> Florian: I think we're okay with CSS3. There's another, but it can go in e-mail.
# [18:41] <dael> tantek: Is that clip?
# [18:41] <dael> Florian: Yes.
# [18:42] <dael> tantek: It does seem editorial. So yeah, that should be it.
# [18:42] <dael> Topic: Allowing @import to be conditional on @supports queries
# [18:43] <dael> 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
# [18:43] * fantasai TabAtkins link?
# [18:43] <dael> 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.
# [18:43] * fantasai finds it
# [18:43] <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jan/0292.html
# [18:44] <dael> 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.
# [18:44] <dael> TabAtkins: So I propose to extend the @import grammar so it can support any grammar.
# [18:44] <dael> TabAtkins: Also tighten up the lang in CSSOM as to where in the cascade we load conditionally imported style sheets
# [18:44] <Bert> q+ to ask if *not* loading the style sheet is a security/privacy risk.
# [18:44] * Zakim sees Bert on the speaker queue
# [18:44] <dael> TabAtkins: Any comments? Otherwise I'd like a resolution
# [18:45] <gregwhitworth> yes please!!!
# [18:45] <dael> fantasai: Seems like a good idea.
# [18:45] <dael> fantasai: It seems necessary and reasonable syntax. Add to cascade 4?
# [18:45] <dael> TabAtkins: Yes, I'm fine with 4. This isn't urgent, it's useful.
# [18:45] <plinss> ack bert
# [18:45] <Zakim> Bert, you wanted to ask if *not* loading the style sheet is a security/privacy risk.
# [18:45] * Zakim sees no one on the speaker queue
# [18:46] <dael> 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?
# [18:46] <dael> TabAtkins: No more than you do with scripts
# [18:46] <fantasai> 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.
# [18:46] <dael> 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.
# [18:47] <dael> plinss: It is part of the fingerprinting surface, but it's already exposed through other means.
# [18:47] <fantasai> TabAtkins, Cascade 3 is in CR, pretty stable. Think it's fair to bikeshed 3, then fork off 4 to add this.
# [18:47] <fantasai> (Would definitely bikeshed 3 first, so 3 is bikeshedded onto /TR)
# [18:47] * leaverou is now known as leaverou_away
# [18:47] <dael> 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.
# [18:48] <dael> TabAtkins: If you have script, you can evaluate MQ whenever you want so exposing more doesn't hurt.
# [18:48] <dael> fantasai: I'm thinking we should bikeshed cascade 3 and work up level 4 so we can maybe add this and also introduce default
# [18:48] <dael> TabAtkins: We do need to add default
# [18:48] <dael> plinss: Anyone object to adding @supports?
# [18:48] * Florian sound distorting made it sound here like Bert said "Netscape recently fixed...." which was somewhat surprising :)
# [18:49] <dael> RESOLVED: Add @supports to Cascade Level 4
# [18:49] <dael> TabAtkins: Can we get a resolution for level 4 ED?
# [18:49] <dael> fantasai: If you bikeshed 3 first and then fork it.
# [18:49] * Florian s/distorting/distortion/
# [18:49] <dael> TabAtkins: Yeah.
# [18:49] <dael> RESOLVED: Create an ED for Cascade Level 4
# [18:49] <dael> fantasai: Do people want to resoolve on default now?
# [18:49] <tantek> 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.
# [18:49] <dael> TabAtkins: I'd rather do that on the list.
# [18:49] <dael> fantasai: Okay.
# [18:49] <dael> plinss: Anything else?
# [18:50] <dael> Topic: Logical border radius properties
# [18:50] <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jan/0313.html
# [18:50] <dael> TabAtkins: Was that fantasai or was that from cameron?
# [18:50] <dael> plinss: Cameron brought it up.
# [18:50] <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jan/0327.html
# [18:50] <Zakim> -adenilson
# [18:50] <dael> plinss: Anyone want to talk on it?
# [18:50] <dael> Rossen: What about?
# [18:50] <dael> fantasai: Naming conventions. border-block-start-order-????? is really wrong.
# [18:51] <dael> fantasai: There was a convention to do block first. We would jsut want to resolve on that.
# [18:51] <dael> TabAtkins: Sounds good to me.
# [18:51] <dael> fantasai: I posted the proposal in IRC
# [18:51] <TabAtkins> s/order-?????/inline-start-corner/
# [18:51] <TabAtkins> s/-corner/-radius/
# [18:52] <dael> plinss: Okay. Any thoughts about adding this?
# [18:52] <dael> Rossen: Sounds reasonable.
# [18:52] <Zakim> +??P3
# [18:52] <dael> 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.
# [18:52] <adenilson> Zakim, ??P3 is me.
# [18:52] <Zakim> +adenilson; got it
# [18:52] <dael> Rossen: fantasai and I have quite a bit of work on that spec. This is good input and makes sense.
# [18:52] <dael> fantasai: This would be the pattern for things that reference corners
# [18:52] <dael> plinss: Okay. Want a resolution?
# [18:53] * Quits: svillar (~sergio@public.cloak) ("Ex-Chat")
# [18:53] <dael> fantasai: Properties referencing corners dropt he axis mentions and go into the block access first, for example border-start-end-radius
# [18:53] * Joins: svillar (~sergio@public.cloak)
# [18:53] <dael> plinss: Obj?
# [18:53] * tantek so many border-* properties
# [18:53] <TabAtkins> s/access/axis/
# [18:53] <dael> RESOLVED: Properties referencing corners drop the axis mentions and go into the block access first, for example border-start-end-radius
# [18:54] <dael> Rossen: Is fantasai auto-sizing of ruby not on the agenda anymore?
# [18:54] <dael> plinss: I think we did it at the F2F
# [18:54] <dael> plinss: Anything else?
# [18:54] <dael> fantasai: I have DoC for flexbox and a couple more issues were raised. Upcoming will be dealing with that, but it's mostly done
# [18:54] <dael> plinss: That's a future call?
# [18:54] <dael> fantasai: Yeah. Prob next week.
# [18:55] <Zakim> -hober
# [18:55] <Zakim> -TabAtkins
# [18:55] <Zakim> -gregwhitworth
# [18:55] <alex_antennahouse> bye
# [18:55] <Zakim> - +1.860.479.aadd
# [18:55] <Zakim> -BradK
# [18:55] <Zakim> -dauwhe
# [18:55] <Zakim> -adenilson
# [18:55] <Zakim> -[Microsoft]
# [18:55] <Zakim> -tgraham
# [18:55] <Zakim> -glazou
# [18:55] <Zakim> -fantasai
# [18:55] <Zakim> -alex_antennahouse
# [18:55] <Zakim> -Florian
# [18:55] <dael> plinss: Alright, everyone gets 10 minutes.
# [18:55] <Zakim> -kwkbtr
# [18:55] <Zakim> -bcampbell
# [18:55] <Zakim> -deirdrelee
# [18:55] <Zakim> -tantek
# [18:55] <Zakim> -plinss
# [18:55] <Zakim> -sanja
# [18:55] * Quits: AH_Miller (~mike@public.cloak) ("")
# [18:55] <Zakim> -SimonSapin
# [18:55] <Zakim> -Bert
# [18:55] <Zakim> -dael
# [18:55] <Zakim> -??P0
# [18:55] * Quits: alex_antennahouse (~458c94ae@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [18:55] <Zakim> -MikeMiller
# [18:55] * Quits: kwkbtr (~kwkbtr@public.cloak) ("")
# [18:55] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [18:56] * Quits: dael (~dael@public.cloak) ("Page closed")
# [18:56] <sanja> Zakim, who is on the phone?
# [18:56] <Zakim> On the phone I see +1.631.398.aabb
# [18:56] <Zakim> - +1.631.398.aabb
# [18:56] <Zakim> Style_CSS FP()12:00PM has ended
# [18:56] <Zakim> Attendees were SimonSapin, glazou, +1.479.764.aaaa, Florian, plinss, dael, Rossen, dauwhe, [Microsoft], adenilson, gregwhitworth, fantasai, tgraham, +1.631.398.aabb, MikeMiller,
# [18:56] <Zakim> ... alex_antennahouse, kwkbtr, smfr, bcampbell, +43.134.001.00aacc, BradK, +1.860.479.aadd, +1.281.305.aaee, TabAtkins, sanja, hober, Bert, tantek, deirdrelee
# [18:56] * Parts: glazou (~glazou@public.cloak) (glazou)
# [18:56] * plh-roof is now known as plh
# [18:57] * Quits: sanja (~sanja@public.cloak) ("")
# [18:57] * Quits: antenna (~antenna@public.cloak) ("Leaving")
# [18:58] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [19:00] * Quits: smfr (~smfr@public.cloak) (smfr)
# [19:00] <tantek> hello bcampbell you had a question about nav-* props and a11y?
# [19:00] * Quits: svillar (~sergio@public.cloak) (Ping timeout: 180 seconds)
# [19:01] <bcampbell> 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.
# [19:02] <bcampbell> 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?
# [19:02] <bcampbell> as opposed to simply jumping from the original focussable items
# [19:03] <TabAtkins> 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.
# [19:03] <bcampbell> when I try the jsbin example, the paragraph does not get focus as it says it might.
# [19:04] <tantek> bcampbell - try it with a div or span destination
# [19:04] <TabAtkins> bcampbell: Note that desktop browsers dont' generally implement nav-*.
# [19:04] <TabAtkins> Or do they?
# [19:04] <tantek> and that
# [19:04] <TabAtkins> Anyway, some TV browsers do.
# [19:04] <bcampbell> Okay, but I can understand the issue without that working.
# [19:04] <tantek> 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
# [19:04] <Florian> 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.
# [19:04] <tantek> e.g. nav-right from one <a href> to another <a href>
# [19:05] <tantek> which is the common case
# [19:05] <tantek> so if you're testing a particular browser/implementation, start with that
# [19:05] <tantek> the point is that as spec'd (and will be tightened), nav-* properties can make any element focusable as the destination of directional navigation
# [19:06] <tantek> that has TWO impacts
# [19:06] <tantek> 1. that element is in :focus
# [19:06] <tantek> 2. that element receives events as focused elements do
# [19:06] <tantek> TabAtkins pointed that out
# [19:06] <Florian> TabAtkins: Presto Opera implements nav-* on desktop. Webkit needs a command line argument to activate it, but does implement spatial navigation on desktop
# [19:06] <tantek> and the "obvious" use-case for that is games
# [19:06] <TabAtkins> Florian: Ah, thanks.
# [19:06] <tantek> which are typically an a11y challenge in general
# [19:06] * leaverou_away is now known as leaverou
# [19:06] <Florian> TabAtkins: Blink same as webkit, as the predates the fork
# [19:06] <tantek> so if we can figure out how to make things better here for a11y, we can *try* to improve the situation with games
# [19:06] <TabAtkins> Or, for example, SVG graphs.
# [19:07] <TabAtkins> spatial navigation across graph links.
# [19:07] <tantek> Florian - do you have a URL documenting how to activate WebKit directional navigation?
# [19:07] <tantek> I'd like to link to those in the spec or at least wiki
# [19:07] <tantek> both for a11y folks to try out
# [19:07] <tantek> and for other implementers to play with while they themselves are implementing
# [19:07] <tantek> e.g. FirefoxOS is looking at directional nav now
# [19:08] <bcampbell> 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?
# [19:08] <tantek> because of the growing number of different devices using it
# [19:08] <tantek> or working on using it, e.g. TVs or those USB sticks that plug into tvs
# [19:08] <bcampbell> yes, a working demo would be really great
# [19:08] <tantek> bcampbell: yes I'm going to add a working example to the spec
# [19:08] <tantek> as I have with other features
# [19:08] <tantek> e.g. box-sizing, cursor, text-overflow
# [19:09] <tantek> bcampbell: I don't know what you mean by within the frame
# [19:09] <Florian> tantek: no url. Just entries in my bash history.
# [19:09] <bcampbell> I was trying to use the draft language :)
# [19:09] <TabAtkins> LIke, they're not tab-focusable (unless you use the tabindex attribute, or we reintroduce the dropped nav-index property).
# [19:09] <bcampbell> right
# [19:10] <tantek> Florian - maybe you could write up something brief on the CSSWG wiki?
# [19:10] <tantek> or a blog post
# [19:10] <Florian> actually, it looks like I was wrong, this seems to be a blink only feature, not a webkit one
# [19:11] <Florian> open /Applications/Google\ Chrome.app --args --enable-spatial-navigation
# [19:11] <bcampbell> 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.
# [19:11] <Florian> tantek: which wiki page do you want this in?
# [19:11] <TabAtkins> bcampbell: OH, you misunderstand the feature entirely!
# [19:11] <bcampbell> oh geez, figures
# [19:11] <TabAtkins> nav-down contains an ID of the element that'll be navigated to when you press down from the source element.
# [19:11] <bcampbell> so I have it upside-down in my head
# [19:12] <bcampbell> when you say "press down" you mean literally the down arrow (when talking keyboard).
# [19:12] <TabAtkins> Yeah (or equivalent button on your input device).
# [19:12] <bcampbell> ok, right
# [19:13] <bcampbell> ok, this is coming together now thanks
# [19:13] <bcampbell> and thus the question of widgets
# [19:13] <TabAtkins> So I have #a { nav-down: #b; }, then if #a is focused, I can press Down to move the focus to #b.
# [19:13] <bcampbell> that use arrows
# [19:14] <tantek> Florian - probably a new one?
# [19:14] <tantek> let me check
# [19:15] <bcampbell> 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
# [19:15] <tantek> bcampbell: correct!
# [19:15] <tantek> except I would say not in the *sequential or linear nav order* rather than *tab*
# [19:15] <tantek> the *tab key* is just one way to do sequential or linear nav
# [19:16] <bcampbell> yes
# [19:16] <bcampbell> gotcha
# [19:16] <tantek> tab / ctrl-tab to go backwards
# [19:17] <Florian> 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.
# [19:17] <tantek> Florian - not true about no one finding it
# [19:17] <tantek> that's what links are for :)
# [19:18] <tantek> and ++ to a self-hosted blog!
# [19:18] <bcampbell> Ultimately this is for jumping around to elements non-sequentially
# [19:18] <tantek> even if you just put up static HTML pages for now at stable permalinks
# [19:18] <tantek> bcampbell: rather than "non-sequentially" - the point is, *directionally*
# [19:18] <tantek> I prefer a positive framing
# [19:18] <bcampbell> ok
# [19:18] <tantek> rather than a "this is not x" framing
# [19:18] <bcampbell> sure
# [19:18] <bcampbell> sorry
# [19:18] <bcampbell> cup is half full, that works for me
# [19:18] <TabAtkins> There is a sequence, it's just not linear. ^_^
# [19:19] <tantek> that ^^^
# [19:19] <tantek> it's a 2D sequence
# [19:19] <tantek> we may introduce a 3D sequence in the future :)
# [19:19] <tantek> per webVR
# [19:19] <bcampbell> 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.
# [19:19] <bcampbell> yes, quantum sequencing
# [19:20] * Rossen is now known as Rossen_away
# [19:20] <tantek> bcampbell: most UIs on TVs are 2D
# [19:20] <tantek> think of DVD UIs for example
# [19:20] <bcampbell> right
# [19:20] <tantek> where you have a bunch of "hot" areas scattered around some graphic image, or moving background
# [19:20] <bcampbell> and right now, generally, you can only arrow in the sequence of the tab order?
# [19:20] <tantek> and you need a way to say, when you press the ">" button, it should go from focusing hot area A to hot area B
# [19:20] <bcampbell> ok
# [19:20] <tantek> on a DVD there is no tab order for example
# [19:21] <tantek> there is ONLY directional nav
# [19:21] <tantek> that's the experience we're talking about
# [19:21] <bcampbell> makes sense
# [19:21] <tantek> except instead of a DVD UI, imagine it's built in HTML
# [19:21] <tantek> + CSS of course
# [19:21] <tantek> but it could look exactly the same
# [19:21] <tantek> I started mocking one up years ago
# [19:21] <tantek> hmm maybe I should put it in the spec
# [19:22] <bcampbell> I'm working on a11y implications in my head, but it would also probably be a general usability issue when talking about keyboards.
# [19:23] <tantek> here: http://tantek.com/CSS/Examples/matrixdvdmenu.html
# [19:24] <TabAtkins> tantek: Most DVD menus would just be a bunch of abspos images, of course. ^_^
# [19:24] * tantek is impressed with TabAtkins's knowledge of "most DVD menus" ;)
# [19:25] <TabAtkins> I've seen a lot of DVDs!
# [19:25] <TabAtkins> They're all pretty consistent.
# [19:25] <TabAtkins> In other words, they could all be described with SVG.
# [19:26] <bcampbell> ignorant question: where is the crossover with tv interfaces and html/css?
# [19:26] <bcampbell> Is DirectTv's interface in html?
# [19:27] <bcampbell> or is this just an example for tv "on a browser" - or am I just lost and need more coffee?
# [19:29] <tantek> TabAtkins: I know, let's just use SVG as the UI platform :P ;)
# [19:29] <tantek> bcampbell: set top boxes from Microsoft (e.g. WebTV) since 2000s all have UI in HTML+CSS+JS
# [19:30] <tantek> I personally worked on that 2000-2004.
# [19:30] <tantek> and they've continued to the present day
# [19:30] <bcampbell> Excellent. I was unaware what platform they have been on.
# [19:31] <tantek> WebTV was the pioneer here
# [19:31] <tantek> but they did most of it with custom HTML
# [19:31] <tantek> 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
# [19:31] <tantek> some of the first set top boxes to do so (if not the first)
# [19:31] <TabAtkins> I know there are more these days, but not sure of specifics. Generally, though, embedding WebKit as your UI layer is pretty common.
# [19:31] <shepazu> Opera was used as the embedded UI (and browser) on many set-top boxes, with HTML+CSS+JS+SVG as the UI
# [19:32] <tantek> there were also other industry-vertical specific attempts like DVB-HTML
# [19:33] <shepazu> 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
# [19:33] <shepazu> I think (?) that faded off in 2008-2010, but I'm not sure
# [19:33] <shepazu> BitFlash and Ikivo were big players in that space
# [19:33] <shepazu> Opera too
# [19:36] <tantek> 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."
# [19:37] <bcampbell> So, is directional navigation for this use case specifically?
# [19:38] <bcampbell> 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.
# [19:38] <shepazu> Joost, an IPTV company, used SVG exclusively as it UI for the first iterations https://en.wikipedia.org/wiki/Joost
# [19:39] <tantek> bcampbell: yes
# [19:39] <shepazu> I think Joost might have moved to Silverlight later on
# [19:39] <tantek> in fact it started in WebTV as proprietary extensions to HTML
# [19:40] <tantek> 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
# [19:40] <tantek> hence the nav-* directional properties proposed in CSS3-UI back when I was working on set top boxes
# [19:42] <bcampbell> 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.
# [19:45] <tantek> bcampbell: it is *definitely* a design problem
# [19:45] <tantek> that's why we included it in the CSS
# [19:45] <tantek> specifically *directional* 2D navigation is heavily tied to the layout of the elements
# [19:45] <tantek> thus it makes sense to specify them in the same place, ergo style sheet
# [19:46] <tantek> more important than an abstract notion of "separate behavior and presentation"
# [19:47] <bcampbell> 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.
# [19:47] <bcampbell> yeah, wow.
# [19:50] <bcampbell> 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.
# [19:52] <tantek> bcampbell: with current display devices, only 2D or 2.5D really makes sense
# [19:52] <tantek> maybe with some overlap
# [19:52] <tantek> and hence sometimes the focus outline of something *in the back* showing up *on top* of stuff *in front*
# [19:52] <tantek> but once we get to VR screens, all bets are off
# [19:53] <tantek> designers are coming up with new ways to make webVR more usable than just an extension of the 2D/2.5D experience
# [19:53] <tantek> thus we don't actually know yet what they'll settle on
# [19:53] <tantek> they're still experimenting with UX!
# [19:53] <bcampbell> ha
# [19:53] <bcampbell> that's my thing
# [19:54] <bcampbell> used to be
# [19:55] <tantek> UX or VR?
# [19:56] <bcampbell> Interaction - UX
# [19:56] <bcampbell> HCI
# [19:56] <bcampbell> I jumped into accessibility about a year ago
# [19:58] <bcampbell> 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 :)
# [19:59] <bcampbell> 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.
# [20:04] * Joins: adenilson (~anonymous@public.cloak)
# [20:10] * leaverou is now known as leaverou_away
# [20:11] <tantek> bcampbell: that's a very logical progression. makes a lot of empathetic sense :)
# [20:11] <tantek> I really appreciate you getting and bringing a11y perspective to our UI work. It's super important.
# [20:12] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [20:12] * Joins: zcorpan (~zcorpan@public.cloak)
# [20:12] <bcampbell> 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.
# [20:15] <bcampbell> Really hoping to be at f2f in NY, too.
# [20:15] <tantek> 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.
# [20:16] <tantek> Hope to see you in NY also.
# [20:18] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [20:27] * Joins: adenilson (~anonymous@public.cloak)
# [20:35] * Quits: RRSAgent (rrsagent@public.cloak) (Ping timeout: 180 seconds)
# [20:37] * Quits: BradK (~bradk@public.cloak) ("Buh bye")
# [20:42] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [20:46] * Quits: andreyr (~andreyr@public.cloak) ("Page closed")
# [20:47] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [20:47] * Joins: adenilson (~anonymous@public.cloak)
# [21:05] * leaverou_away is now known as leaverou
# [21:11] * Zakim excuses himself; his presence no longer seems to be needed
# [21:11] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [21:12] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [21:12] * Joins: Florian (~Florian@public.cloak)
# [21:15] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [21:17] * Joins: Florian (~Florian@public.cloak)
# [21:21] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [21:29] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [21:58] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:58] * Quits: bcampbell (~chatzilla@public.cloak) ("ChatZilla 0.9.91.1 [Firefox 31.4.0/20150105205548]")
# [22:11] * Joins: elijah_ (~elijah@public.cloak)
# [22:11] * Quits: elijah_ (~elijah@public.cloak) ("Page closed")
# [22:11] * Joins: elijah (~sid21431@public.cloak)
# [22:11] <elijah> help
# [22:12] <elijah> help?
# [22:12] <elijah> channellist?
# [22:15] * Rossen_away is now known as Rossen
# [22:25] * Rossen is now known as Rossen_away
# [22:26] <tantek> elijah what channel are you looking for?
# [22:29] * Joins: Florian (~Florian@public.cloak)
# [22:36] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [22:42] * heycam|away is now known as heycam
# [22:51] <elijah> tantek: was just trying to lurk on some more channels
# [22:51] <elijah> tantek: I found a small list on the web so that is good to start; #css, #html-wg, #html, #webapps
# [22:52] <tantek> that's a decent start yes
# [22:52] <elijah> tantek: if you have any others that have activity from time to time that would be appreciated
# [22:54] <tantek> elijah are you interested in social web related topics?
# [22:56] <elijah> tantek: sure
# [22:57] <tantek> feel free to lurk in #social also then
# [22:57] <elijah> tantek: thanks!
# [22:58] <tantek> np!
# [23:11] * Quits: tantek (~tantek@public.cloak) (tantek)
# [23:12] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [23:16] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [23:26] * Quits: bkardell_ (~uid10373@public.cloak) ("Connection closed for inactivity")
# [23:43] * leaverou is now known as leaverou_away
# [23:47] * Joins: Florian (~Florian@public.cloak)
# [23:47] * Joins: adenilson (~anonymous@public.cloak)
# [23:54] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# Session Close: Thu Feb 26 00:00:00 2015

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn