/irc-logs / w3c / #css / 2015-09-30 / end

Options:

# Session Start: Wed Sep 30 00:00:01 2015
# Session Ident: #css
# [00:05] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [00:05] * Quits: joone2 (~joone@public.cloak) (Client closed connection)
# [00:06] * Joins: joone (~joone@public.cloak)
# [00:19] * Joins: jdaggett (~jdaggett@public.cloak)
# [00:28] * Joins: lajava (~javi@public.cloak)
# [00:53] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [00:55] * Joins: dbaron (~dbaron@public.cloak)
# [01:02] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [01:14] * Joins: adenilson_ (~anonymous@public.cloak)
# [01:19] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
# [01:19] * adenilson_ is now known as adenilson
# [01:50] * heycam|away is now known as heycam
# [01:56] * Quits: myles (~Adium@public.cloak) ("Leaving.")
# [02:12] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [02:13] * Joins: Florian (~Florian@public.cloak)
# [02:39] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [02:41] * plinss changes topic to 'drafts.csswg.org mirror at http://csswg.inkedblade.net/drafts/ ; CSS WG confcall 20150930 https://lists.w3.org/Archives/Public/www-style/2015Sep/0300.html'
# [02:54] * Joins: adenilson (~anonymous@public.cloak)
# [02:54] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [03:34] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [04:32] * Joins: jdaggett (~jdaggett@public.cloak)
# [04:56] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [04:57] * Joins: Florian (~Florian@public.cloak)
# [05:02] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [05:15] * Joins: Florian (~Florian@public.cloak)
# [05:22] * heycam is now known as heycam|away
# [05:34] * Joins: dbaron (~dbaron@public.cloak)
# [05:54] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [06:31] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [06:37] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [06:56] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [08:06] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:08] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:39] * Joins: zcorpan (~zcorpan@public.cloak)
# [10:21] * Quits: SimonSapin (~simon@public.cloak) ("Bye")
# [10:22] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [10:23] * Joins: SimonSapin (~simon@public.cloak)
# [10:41] * Joins: lajava (~javi@public.cloak)
# [10:43] * Joins: Florian (~Florian@public.cloak)
# [11:18] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [11:23] * Joins: antonp (~Thunderbird@public.cloak)
# [11:29] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [11:37] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [12:32] * Joins: antonp1 (~Thunderbird@public.cloak)
# [12:34] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [12:39] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [12:39] * antonp1 is now known as antonp
# [12:44] * Joins: antonp1 (~Thunderbird@public.cloak)
# [12:50] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [12:50] * antonp1 is now known as antonp
# [13:08] * Joins: Florian (~Florian@public.cloak)
# [13:09] * Quits: shepazu (schepers@public.cloak) (Ping timeout: 180 seconds)
# [13:28] * Joins: plh (plehegar@public.cloak)
# [13:36] * Joins: lajava (~javi@public.cloak)
# [13:47] * Joins: antonp1 (~Thunderbird@public.cloak)
# [13:51] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [13:51] * antonp1 is now known as antonp
# [13:55] * Joins: antonp1 (~Thunderbird@public.cloak)
# [14:00] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [14:00] * antonp1 is now known as antonp
# [15:09] * Joins: tgraham (~user@public.cloak)
# [15:17] * Joins: zcorpan (~zcorpan@public.cloak)
# [15:30] * Joins: antonp1 (~Thunderbird@public.cloak)
# [15:31] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [15:36] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [15:36] * antonp1 is now known as antonp
# [16:17] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [16:18] * Joins: shepazu (schepers@public.cloak)
# [16:25] * Joins: antonp (~Thunderbird@public.cloak)
# [16:43] * Joins: darktears (~darktears@public.cloak)
# [16:51] * Joins: estellevw (~estellevw@public.cloak)
# [17:15] * Joins: glazou (~glazou@public.cloak)
# [17:16] <glazou> RRSAgent, make logs public
# [17:16] <RRSAgent> I have made the request, glazou
# [17:35] * Joins: dbaron (~dbaron@public.cloak)
# [17:40] * Joins: gregdavis (~udavig4@public.cloak)
# [17:47] * Joins: AH_Miller (~AH_Miller@public.cloak)
# [17:49] * Joins: antenna (~antenna@public.cloak)
# [17:51] * Quits: AH_Miller (~AH_Miller@public.cloak) ("Page closed")
# [17:54] * Joins: zcorpan (~zcorpan@public.cloak)
# [17:57] * Joins: AH_Miller (~AH_Miller@public.cloak)
# [17:57] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [17:57] * Joins: alex_antennahouse (~458c94ae@public.cloak)
# [17:57] <dauwhe> Present+ dauwhe
# [17:57] <glazou> Present+ glazou
# [17:57] <alex_antennahouse> present+ alex_antennahouse
# [17:57] * Joins: dael (~dael@public.cloak)
# [17:57] <dael> present+ dael
# [17:58] <dael> ScribeNick: dael
# [17:58] <glazou> dael: I have a special request
# [17:58] <alex_antennahouse> was that a foghorn?
# [17:58] <dael> glazou: sure, what's up?
# [17:58] <glazou> dael: can you add the URL of the agenda (that is in the topic of this channel) to the top of the minutes every week ?
# [17:58] <dael> glazou: Not a problem!
# [17:59] <glazou> that would help comparing the agenda and the minutes...
# [17:59] <plinss> Present+ plinss
# [17:59] <antenna> present +antenna
# [17:59] <glazou> dael: cool, thanks a lot !
# [18:00] <tgraham> present+ tgraham
# [18:00] * Joins: gregwhitworth (~uid93288@public.cloak)
# [18:00] <gregwhitworth> gregwhitworth present+
# [18:00] * Joins: adenilson (~anonymous@public.cloak)
# [18:00] * Joins: smfr (~smfr@public.cloak)
# [18:01] * Joins: tantek (~tantek@public.cloak)
# [18:01] * Joins: Rossen_ (~Rossen@public.cloak)
# [18:01] <dbaron> Present+ dbaron
# [18:01] <astearns> present+ astearns
# [18:01] * Joins: myles (~Adium@public.cloak)
# [18:01] <smfr> present+ smfr
# [18:01] <adenilson> present+ adenilson
# [18:02] <myles> present+ Myles
# [18:02] * antonp is on IRC only today
# [18:03] <Rossen_> present+ Rossen_
# [18:03] * Joins: vollick (~vollick@public.cloak)
# [18:04] <gregdavis> present+ gregdavis
# [18:04] * Joins: bkardell_ (~uid10373@public.cloak)
# [18:05] <dael> plinss: Let's get started. Anything to add to the agenda?
# [18:05] <Florian> http://www.w3.org/mid/C717D9A5-8A02-4598-935F-EB83E10D5FF0@rivoal.net
# [18:05] <dael> plinss: I'll take that as a no.
# [18:05] <glazou> Chris Lilley sent potential regrets through twitter, his train is 4 hours late…
# [18:05] <dael> Topic: Join Meeting with WEbApps @ TPAC
# [18:05] * Joins: ChrisL (clilley@public.cloak)
# [18:05] <Florian> hello, can you hear me? I tried to talk
# [18:05] * glazou caughs because of topic ;-)
# [18:05] <dael> plinss: This is to discuss ShadowDOM styleing
# [18:05] * dael Florian we can't
# [18:05] * leaverou_away is now known as leaverou
# [18:06] <dael> plinss: They're prop monday or tuesday. Any constraints for time? jdaggett pref. Tuesday afternoon.
# [18:06] <leaverou> present+ leaverou
# [18:06] <dael> Rossen_: Is that a joint meeting discussion?
# [18:06] * tantek is having trouble with iOS9.0.1 update nearly completely breaking wifi on his communicator.
# [18:06] <ChrisL> present+ ChrisL
# [18:06] <dael> plinss: Yes, for ShadowDOM. Any preference or constraints between Monay and Tuesday afternoon?
# [18:06] <zcorpan> present+ zcorpan
# [18:06] <dael> Rossen_: Either works for me.
# [18:06] * TabAtkins will be a few minutes late.
# [18:06] * astearns wonders whether jdaggett wants Tues afternoon because he'll be there or not be there
# [18:06] * bkardell_ is having some w3c password issue - can someone shoot me the webex?
# [18:06] <dael> plinss: Current prop. is Tuesday afternoon from John. Let's go with that.
# [18:06] <dael> Topic: Sydney dates
# [18:06] * tantek seriously I recommend DO NOT upgrade to iOS9.x if you want your wifi to work on your iOS device. So broken.
# [18:07] <fantasai> present+ fantasai
# [18:07] <dael> plinss: I have on my cal. Jan 30, 31 Houdini. Feb 1-3 for us, Feb 4-6 for SVG. Does that agree with everyone else and any reason to change it?
# [18:07] <bkardell_> present+ bkardell_
# [18:07] <vollick> present+ vollick
# [18:07] <Bert> present+
# [18:07] <dael> Rossen_: Is that what's on all the wikis?
# [18:07] <dael> plinss: It's what's on the feed. Let me check the wiki
# [18:08] <Florian> The mail I pasted above is extra agenda items i'd like to get to, but Webex isn't working, as you can seem to hear me. Rebooting
# [18:08] <dael> dbaron: I think it agrees with everything except maybe SVG because they shifted a few days.
# [18:08] * fantasai thinks the mirror doesn't need to be listed in the channel topic atm, at least until she sets up a cron job to update it
# [18:08] <dael> plinss: It agrees with CSS.
# [18:08] * fantasai changes topic to 'CSS WG confcall 20150930 https://lists.w3.org/Archives/Public/www-style/2015Sep/0300.html'
# [18:08] <dael> Rossen_: Then it should be fine. If thats what the wiki says I'm good.
# [18:08] <dael> plinss: Let's consider those dates in stone.
# [18:08] * Quits: Florian (~Florian@public.cloak) ("Leaving...")
# [18:08] <dael> Topic: 'polar-anchor' property
# [18:09] <dael> jihye: I'm from LG Electronics, the editor of Round Display. I wanted to talk about polar-ancor, a new prop related to round display
# [18:09] * fantasai had a dream about polar-anchor. Can't remember the conclusion, though.
# [18:09] <dael> jihye: While discussing it at the F2F in Paris there was a concern about overflowing which in containing block. Using only polar-angle and -distance to position we have to adjust to avoid elements coming out of the containing block
# [18:10] * Joins: Florian (~Florian@public.cloak)
# [18:10] <dael> jihye: To solve this polar-anchor was suggested. It sets the anchor of the element and spec. a position that is a representitive point of the elemnt aligned with the containing block.
# [18:10] <dael> jihye: I refered to BG position prop. It takes value type <position> which is defined there. Any point in the content can be an anchor point.
# [18:10] * tantek seriously I've been waiting 10min for iOS9.0.1 on my iPod 5 touch to "join" my home network. So broken. Maybe Apple stopped testing on iPod Touches?
# [18:11] <dael> jihye: When you can see the polyfill I mentioned in the mailing list there are 12 elements in circular layout.
# [18:11] * dael Florian yes.
# [18:11] <Florian> Agenda+ http://www.w3.org/mid/C717D9A5-8A02-4598-935F-EB83E10D5FF0@rivoal.net
# [18:11] * Zakim notes agendum 2 added
# [18:11] <Florian> Prensent+ Florian
# [18:11] <astearns> http://anawhj.github.io/jRound/demo/polar/anchor.html
# [18:11] <dael> jihye: Please see my message on the mailing list, reference #4. I impl polar-anchor as a polyfill.
# [18:11] <dael> jihye: There are 12 elements in a circular layout.
# [18:12] <dael> jihye: First, 4th, 7th, and 10th are set to top, right, bottom, left.
# [18:12] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [18:12] <dael> jihye: anchor of 2nd and 3rd are right-top
# [18:12] <dael> jihye: Those of 5th and 6th are right-bottom.
# [18:13] <dael> jihye: 8th and 9th are left-bottom, others are left-top. They are set according to the value of polar-angel. Therefore the exact distance value between the center points and the edge of the cont. block become polar-distance value so you don't need to adjust it to avoid overflowing.
# [18:13] <dael> jihye: So I want to ask you is this polar-anchor useful enough to be a new property?
# [18:14] <dael> Florian: Yes, I think it's good. You're e-mail included the auto value and I'm guessing it would mean you wouldn't need to say top-right on 2 and 3, etc. and it would guess based on the angle. I think that would be useful and diff. to specify. Even without that it's useful so I'm in favor.
# [18:14] <dael> jihye: Thank you.
# [18:14] <dbaron> I don't understand how polar-anchor interacts with polar-angle and polar-distance
# [18:14] <dael> jihye: And the name of this property is appropriate?
# [18:15] <dbaron> ah, ok (responding to Florian)
# [18:15] <dael> Florian: I think so. There's a comment on IRC from dbaron saying he doesn't understand. If I do the polar-anchor says which point in the elemnt that you're placing using polar corrdinates is measured from the cente rof the containing block. If you do top-left you're psoitioning the top-left of the element from the center of the contianing block. The default is center-center
# [18:15] <dael> jihye: Yes, default is center-center
# [18:15] <dael> jihye: What was your question?
# [18:16] <dael> Florian: It was dbaron asking how it worked on IRC so I explained.
# [18:16] <astearns> if I understand correctly, if the 7 box is much wider, it's bottom left and right corners would still overflow the circle
# [18:16] <ChrisL> q+
# [18:16] * Zakim sees plh, glazou, ChrisL on the speaker queue
# [18:16] * tantek is going to try powering off and rebooting his communicator.
# [18:16] <dael> jihye: When the anchor point is set within a content box of the element then the represented point of the lement, which point is mapped in the containing block is decided.
# [18:16] <Florian> asteans: I believe so, yes. But presumably not with the auto value (which is not pollified here).
# [18:17] <dael> jihye: Anchor point is center-center then the center point of the content area of the element is mapped to the point of the containing block.
# [18:17] <dael> jihye: When you put the element whose anchor is center-center to the edge of the contianing block some part of the element overflows.
# [18:17] <dael> jihye: Can you understand it?
# [18:17] <dael> Florian: I think that's what astearns was saying on IRC.
# [18:18] <ChrisL> q+ to ask about clipping behavious and to point out that the numbers are irregiularly spaced
# [18:18] * Zakim sees plh, glazou, ChrisL on the speaker queue
# [18:18] * Bert has some trouble with a clock that has "1" at the top :-)
# [18:18] <glazou> Zakim, ack me
# [18:18] <Zakim> I see plh, ChrisL on the speaker queue
# [18:18] <plinss> ack plh
# [18:18] * Zakim sees ChrisL on the speaker queue
# [18:18] * Joins: jihye (~jihye@public.cloak)
# [18:18] <glazou> Zakim, ack plh
# [18:18] <Zakim> I see ChrisL on the speaker queue
# [18:18] <plinss> ack ChrisL
# [18:18] <Zakim> ChrisL, you wanted to ask about clipping behavious and to point out that the numbers are irregiularly spaced
# [18:18] * Zakim sees no one on the speaker queue
# [18:18] <dael> ChrisL: The numbers are irregularly spaced because there isn't a consistant position and I think the reason for that is that the demo is trying to make sure it doesn't go over the edges.
# [18:18] * fantasai chris, you're cutting out
# [18:18] * Joins: bradk (~bradk@public.cloak)
# [18:19] <fantasai> The 'auto' value basically says "position like bg position works"
# [18:19] <glazou> :-D
# [18:19] <dael> ChrisL: In general this prop doens't guar. you won't go out it depends on the shape that uses the alignment point
# [18:19] <ChrisL> It seems that this would need a clipping behaviour
# [18:19] <dbaron> Can't hear Florian either
# [18:19] * fantasai can't hear Florian either
# [18:19] * TabAtkins has arrived
# [18:19] <Florian> :(
# [18:20] * ChrisL has trouble hearing florian
# [18:20] * Joins: MikeJoel (~null@public.cloak)
# [18:20] * ChrisL has stopped
# [18:20] * Bert hears chris as pf... ch... br... plop.
# [18:20] <MikeJoel> wondering where the documentations are on the ftp server. Like CSS documentation?
# [18:20] <dael> Florian: So if I understand this, yes if you're using the explicit position keywords depending on the shape of the element and the container you will have a chance of overflow. The auto should make this magically not overflow. What I'm less sure about s how auto works when the distance is not 100%
# [18:20] * glazou Bert oh that’s better than I, you heard a full « plop » :-)
# [18:20] <dael> jihye: In the polyfill I didn't consider auto.
# [18:21] <dael> plinss: What I'm hearing is people agree it's useful, but there are questions about how auto works and it doesn't seem to completely guar. no overflow so there may be work there. It's a good start.
# [18:21] * ChrisL huh. sorry.
# [18:21] <dael> jihye: Thank you.
# [18:22] <dael> jihye: I'm curious, is value type <position> acceptable for polar-anchor?
# [18:22] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [18:22] <SimonSapin> Present+ SimonSapin
# [18:22] <dael> Florian: I guess so. What I think we should do is resolve to add this, see how you write it, try to resolve the issues around auto, and depending on how well it works maybe we don't need <position>
# [18:22] <dael> jihye: Okay.
# [18:22] <dael> Florian: What do others think?
# [18:22] <TabAtkins> Without a well-behaving (and well-specified) auto value, I'm not convinced <position> is worthwhile.
# [18:23] <dael> dbaron: I feel like <position> is awk when you're at an angle tht's not a multiple of 45deg. If you look at the clock ex. the numbers are a bit uneaven.
# [18:23] <TabAtkins> The trig you need to do to figure out where it should go can just as easily be used to adjust polar-distance with a fixed (center) anchor.
# [18:23] <dael> jihye: Between 1 and 2 and 2 and 3?
# [18:23] <dael> dbaron: Yeah.
# [18:23] <ChrisL> dbaron, I explained why they are uneven earlier. look at the css
# [18:23] <dael> jihye: I will think about that, thank you.
# [18:23] <ChrisL> #item3 {
# [18:23] <ChrisL> position: polar;
# [18:23] <ChrisL> polar-angle: 60deg;
# [18:23] <ChrisL> polar-distance: 100%;
# [18:23] <ChrisL> polar-anchor: right top;
# [18:23] <ChrisL> }
# [18:23] <ChrisL> #item4 {
# [18:23] <ChrisL> position: polar;
# [18:23] <ChrisL> polar-angle: 90deg;
# [18:23] <ChrisL> polar-distance: 100%;
# [18:23] <ChrisL> polar-anchor: right center;
# [18:23] <ChrisL> }
# [18:24] <ChrisL> different alignment points
# [18:24] <dael> dbaron: I wonder...I think having suqare boxes around the numbers seems a bit awk as well so I don't know if that's messing with my view of the example.
# [18:24] * smfr notes that we’ve spent 25 mins on this
# [18:24] <dael> dbaron: The way BG position works is if you say 75% 75% it aligns a point that is 75% 75% in the image to the point that's 75% 75% in the box. I wonder if something more like that would be useful here.
# [18:25] <dael> Florian: Or I think now it's positioning the anchor so when you...I think when you do an angle and a distance it should still work from the center but use the anchor to avoid overflow. That doesn't make sense. What we're tryig to do is adjust how far the element is moved out, not adjust the line of how far it's move. Anchor seems to be doing both.
# [18:25] <dael> Florian: But I still think it's difficult to talk without details. I'm in favor of writing it and working on issues from there.
# [18:25] <dael> plinss: Agreed.
# [18:26] <MikeJoel> is there a better channel to ask in?
# [18:26] <dael> Florian: Should we resolve?
# [18:26] <dael> TabAtkins: I'd rahter see a well spec auto or some fixes to percentages before we resolve. Without that I don't think it's useful.
# [18:26] <dael> plinss: Let's see it added to the ED so we can work on those.
# [18:27] <dael> fantasai: You can add it with those two issues.
# [18:27] <dael> plinss: Yeah.
# [18:27] <dael> RESOLVED: add polar-anchor with issues for spec auto and percentages
# [18:27] <dael> Topic: Reverting 'animation-timing-function' change
# [18:27] <dael> dbaron: I don't know if there's anything to discuss. Everyon on the list agreed. I reverted the one change though there's a bunch more editing I haven't gotten to.
# [18:28] <dael> plinss: Okay.
# [18:28] <dael> Topic: computed values of translate, rotate and scale.
# [18:28] <dael> TabAtkins: I agree with what dbaron said and I'll make the edits.
# [18:28] <dael> plinss: Other opinions?
# [18:28] <dael> Topic: ruby-merge
# [18:29] <dael> plinss: Richard Ishida sent some e-mails on this. Can anyone speak to it?
# [18:29] * dbaron is loading the email links
# [18:29] <dael> Florian: If anyone it would be fantasai.
# [18:30] <dael> fantasai: I sent a message to the list yesterday, I don't know if there's been time to reply. It was suggested there should be a value that triggers jukugo ruby as per JLREQ and that the rest of it should be dropped. I don't have a resonce from Richard.
# [18:30] <dael> plinss: Anyone else or are we okay with letting fantasai and Richard sort this out?
# [18:30] <dael> TabAtkins: Yep.
# [18:30] <dael> Topic: :focus-ring
# [18:31] <dael> TabAtkins: If you rememebr at the last F2F we had a discussion with bkardell_ about input modality. We've been working through the issues to find the simpliest way to solve the use cases.
# [18:31] * dbaron wonders why Tab is so much louder than everybody else
# [18:31] * bkardell_ just greatfully accepts Tab's audible volume :)
# [18:31] <dael> TabAtkins: We're stll working things through, but one thing seems obv. Whenever the author wants to style the focus ring because it doesn't match the website's style. They can use focus styling, but they can't style it only when the browser would have applied focus rings.
# [18:32] <bkardell_> ala https://developer.mozilla.org/en-US/docs/Web/CSS/%3A-moz-focusring
# [18:32] <dael> TabAtkins: The idea is to add a pseudo class that applies only when the browser would apply a focus ring and we say the UA is styled with that pseudo class.
# [18:32] <dael> TabAtkins: We thought that was generally useful. Mozilla already has something that is basically this.
# [18:32] <dael> bkardell_: I shared it in the IRC
# [18:32] <dael> Florian: I agree this is a nicer way to address it, but we should wait for the use case hunt to end.
# [18:33] <bkardell_> ?+
# [18:33] <tantek> present+ tantek
# [18:33] <bkardell_> +?
# [18:33] <tantek> oh yeah focus rings
# [18:33] * bkardell_ never can remember
# [18:33] <bkardell_> q+
# [18:33] * Zakim sees bkardell_ on the speaker queue
# [18:33] <dael> TabAtkins: This seems useful no matter what the other conclusions are. What other functionalities we might need is what we're waiting on. This is independantly useful regardless of how we decidenth on the other pieces of input modality.
# [18:33] <tantek> I'd like to hear from bkardell_
# [18:33] <tantek> rather than speculation
# [18:33] <dael> Florian: Depending on what we find if we see the :focus-ring can solve almost all the use cases we might want to change it to solve all of them.
# [18:34] * smfr button:focusring { display: none; }
# [18:34] <tantek> q?
# [18:34] * Zakim sees bkardell_ on the speaker queue
# [18:34] <tantek> q?
# [18:34] * Zakim sees bkardell_ on the speaker queue
# [18:34] <dael> TabAtkins: That should only happen if we take two years. If we find we need to tweek it it would be in the next few months.
# [18:34] * bradk thinks the name is weird. Should be something like :browser-chosen-focus
# [18:34] * tantek waits for the author-splaining to finish so we can hear from bkardell_
# [18:35] <dael> Rossen: One concern I have is focus ring could be viewed as system specific between different OSs. Different impl may want different ways to handle a11y scenarios which the page author may or may not be handling. With giving authors the ability to style focus-ring they may fight with a11y primitive.
# [18:35] * bradk "ring" is meaningless to indicate that it is a focus that doesn't apply to everything.
# [18:35] <dael> TabAtkins: They have that ability. The focus ring pseudo-class lets them do that. This narrows the meaning of focus so that it doens't happen when a browser doesn't normally trigger a focus ring
# [18:35] <plinss> ack bkardell_
# [18:35] * Zakim sees no one on the speaker queue
# [18:36] <dael> bkardell_: I see a lot on IRC about name bikeshedding. I agree we can bikeshed. I think conceptually Alice and I agree that the crux of the problem as it manifests today is authors have no way to be privvy to the knowledge the browser has. THe focus pseudo class is unfortunate in that your use of it messes with the a11y.
# [18:37] <dael> bkardell_: :focus-ring is internded to just bubble up whatever the browser decides will get the focus ring and allow you to style it better without effecting a11y.
# [18:37] <dael> bkardell_: As to if we need more, this is a useful exercise to drill down and see. If we need to go further it lines up with our existing proposal. I don't think this precludes others.
# [18:38] <dael> Rossen: I have my reservations. If we could go back I'd prefer this to be a global media feature that's set once not per psuedo-class.
# [18:38] <dael> TabAtkins: I'm not sure what you're proposing there.
# [18:38] * glazou needs to leave at :45 today, sorry for that
# [18:38] <dael> TabAtkins: Is what you're prop relevent to the fact that people can override focus rings today by messing with the outline property.
# [18:39] <dael> Florian: Authors today cannot know if they're overriding or creating one where it shouldn't be.
# [18:39] <dael> TabAtkins: Rossen reservation was about overriding. We're not introducing new functionality.
# [18:39] <dael> Rossen: Okay. Consider it a rant about past decisions.
# [18:39] <bkardell_> q-
# [18:39] * Zakim sees no one on the speaker queue
# [18:39] <dael> bkardell_: If you'd liek to talk more privatly I'd love ot hear what you have to say.
# [18:39] <dael> Rossen: Sure.
# [18:39] <bradk> :focus:not(:focus-ring) ?
# [18:40] <dael> TabAtkins: So giver that :focus-ring is a subset of :focus, any objections?
# [18:40] <dael> plinss: If this psuedo class is triggered than focus is triggered?
# [18:40] <dael> TabAtkins: Yes.
# [18:40] <tantek> are we talking about just standardizing https://developer.mozilla.org/en-US/docs/Web/CSS/%3A-moz-focusring ?
# [18:40] <dael> Florian: I've considered if a focus ring within thing would be useful and I think prob not. That extension doesn't need to be repeated.
# [18:40] <dael> TabAtkins: Yes. I think you want to be able to put a focus ring style in your doc and you don't want that to apply to everything that has a focus ring
# [18:41] <dael> tantek: Are we standardizing what moz-focusring does?
# [18:41] <dael> TabAtkins: It's basically moz-focusring.
# [18:41] <dael> tantek: Okay. That sounds good to me.
# [18:41] * Joins: MaRakow (~MaRakow@public.cloak)
# [18:41] <MaRakow> present+ MaRakow
# [18:41] <dael> bkardell_: Only caviat is we would like a way for custom elements to define their behavior. are they mroe like a button or text input field.
# [18:42] <dael> TabAtkins: Andd that's where conversations are ongoing, but that will itneract with this psuedo class.
# [18:42] <bkardell_> +1
# [18:42] <dael> tantek: I think we should capture that as an open issue rather than try and solve it.
# [18:42] <dael> tantek: WE can spec this without solving that.
# [18:42] <dael> bkardell_: I wouldn't be bowled over if the group was opposed to that. I don't see a high bar to that.
# [18:42] <dael> tantek: Let's capute the cusom element part as an issue.
# [18:43] <dael> TabAtkins: It should be a part of the custom elements. Now that we've agreed on level 1 that should arrive shortly.
# [18:43] <dael> tantek: Okay. I'm fine with caputing this whereever.
# [18:43] <dael> TabAtkins: It would go into selectors 4 or 5. It has one impl and requires no new functionality so it's apretty minor feature.
# [18:43] <dael> tantek: Is Chrome committing to shipping this soon?
# [18:44] <dael> TabAtkins: I can't speak directly to that, but I don't think we'd have opposition.
# [18:44] <dael> plinss: Objections?
# [18:44] <dael> smfr: Is the intent that the author would only chang ethe outline style?
# [18:44] <dael> TabAtkins: It's a selector. You can change what you want.
# [18:44] <dael> tantek: Yeah, we often have selectors that can limit.
# [18:44] <dael> TabAtkins: We have pseudo elements, but that's due to the nature of the elements.
# [18:44] <dael> plinss: There's no restrictions on :focus
# [18:45] <dael> bkardell_: Someone in the community group raised that they thought it should be a pseudo element.
# [18:45] <dael> TabAtkins: We're not creating anything new on the tree.
# [18:45] <dael> bkardell_: I wanted ot check for agreement
# [18:45] <dael> Florian: I agree.
# [18:45] <dael> plinss: I do too. There may be a reason for an element later, but that may be just for a11y reasons.
# [18:46] <plinss> s/element/pseudo-element/
# [18:46] <dael> smfr: I'm concerned that if this is used incorrectly y ou could get a state where it flickers in and out. You could set display: none and it would shift. I'd rather limit it to something that only applied to the focus ring
# [18:46] * glazou needs to run ; bye people
# [18:47] <dael> TabAtkins: I think there's reason to tint the background element for example. So I thinkt ehre's reason to not just focus the ring. If you change the outline it overrides whatever the browser is doing for the focus ring.
# [18:47] * Quits: glazou (~glazou@public.cloak) (glazou)
# [18:47] <bradk> Would. :focus-ring override:focus? Or would they both apply?
# [18:47] <bkardell_> a ua default sheet could !important display
# [18:47] <dael> tantek: smfr if you have specific examples that you think are problems, post them with the moz prefix and we can treat that as the canary in the coal mine.
# [18:48] <tantek> s/can treat that/can treat Firefox/
# [18:48] <dael> Florian: If there's a problem it's bigger than focus-ring. All the drag and drop might have a problem. All UI psuedo classes have that problem. We should solve this larger problem.
# [18:48] <dael> TabAtkins: This is just subsetting :focus to what the broswer would normally create a focus ring on.
# [18:48] <dael> tantek: THis is a subset of :focus
# [18:49] <dael> TabAtkins: Any arguements on this that would also apply to :focus we should approach, but it's not somethign against this. It's valid, but isn't related to this request.
# [18:49] <dael> tantek: Yes, anything that demos bad behavior we can demo with :focus.
# [18:49] * tantek has no opinion on the bikeshedding of this selector (for now ;) )
# [18:49] <dael> smfr: That sounds reasonable. I don't like the name. It's also not obvious to me what the UA would know when to stop stying it's normal focus ring.
# [18:50] <dael> TabAtkins: It appears the defactor is that if you set outline we turn off the native style. We can capture that as the default or make something more explicit, such as a subset of outline that caputres if it's being used as a focus ring. That's a generic focus ring issue.
# [18:50] <dael> Florian: I agree that however we address that should go around outline property, not around the selector
# [18:50] <dael> smfr: I'm fine with that.
# [18:51] <dael> RESOLVED: Add :focus-ring to selectors 4 or 5
# [18:51] <dael> Topic: stacking context @ animation-start
# [18:51] * TabAtkins is thinking of "outline-focus: yes | no" (with better names), set to "yes" by the UA stylesheet and defaulted to "no" by the 'outline' shorthand.
# [18:51] <smfr> https://lists.w3.org/Archives/Public/www-style/2015Sep/0279.html
# [18:52] <dael> smfr: Before Pris I inverstigated a webkit bug. In Paris I spoke to tab and dbaron about the scanrio where you have a set of keyframes and not all of them create a stacking context. So this e-mail has an example where 50% onwards in stacking. So when do they start the stacking context?
# [18:52] <dael> smfr: Originally thought it was when the animation started, but it looks like it starts at 49%. That's contrary to the opinion I got from TabAtkins and dbaron
# [18:53] <Florian> TabAtkins: Maybe. Do you want to make a Pull Request against CSS-UI, then we discuss, and I merge if we agree?
# [18:53] <dael> TabAtkins: I didn't mean to indicate contrary to that. I assume animations is applied in the simple way where you only get stacking when you run into something that requires it. Anything else would have required extra work. I think that's correct. We should let animations change properties. The will-change is appropriate for say you will change the tranform and you can create stacking earlier.
# [18:54] <MaRakow> +1 to Tab
# [18:54] <vollick> If authors wanted to avoid jank due to stacking contexts coming and going, they should use will-change as well, then?
# [18:54] <dael> Rossen: I agree. I'd like it to be that values are applied as the timeline of the animation goes. Any kind of chaining doesn't need to be analized ahead of time which could be costly. I'm not sure where you're going, but my guess is with more stacking you get better layering which would lead to better perf. As a general rule from our impl it would be hacky and combersome to analyze ahead of time.
# [18:55] <dael> smfr: I bring this up because in webkit we'd prefer to hand off the netire animation to an underlying graphics animation. I'd prefer to not re-eval while it's running.
# [18:55] <dael> Rossen: I totally sympathize, but I'd rather have a static decision where you let it be as is or you create stacking at the start of any animation. Trying to find out ahead means you have to compute a bunch of styles.
# [18:56] <dael> TabAtkins: I think it's worse in the general web animations APIs where you can have complex. I don't want to limit it to small batches of keyframes where you can create a large number. We have a property to indicate that you will create stacking.
# [18:56] <dael> Rossen: The animation graph intersecting with the inheritence isn't something you can find ahead of time.
# [18:56] <dael> smfr: I think will-change inside keyframes won't have an effect.
# [18:57] <dael> TabAtkins: It should still be respected via the resolution we made a while ago about having non-animatable ones flip.
# [18:57] * Joins: MikeJoel_real (~null@public.cloak)
# [18:57] <dael> smfr: Okay. dbaron?
# [18:57] <dael> dbaron: I think I agree with TabAtkins and Rossen
# [18:57] <dael> smfr: Okay
# [18:57] <dael> smfr: I guess we don't need new text in animations since this is the behavior that falls out from doing nothing.
# [18:57] <dael> TabAtkins: Yeah.
# [18:57] <dael> smfr: Okay.
# [18:58] <bradk> @tabatkins -internal-outline:1px dotted black; gets set to none by shorthand in shorthand.
# [18:58] * tantek "has-layout: true" ;)
# [18:58] <dael> plinss: I agree with all that, but one complaint we come up with, I hate tha we have all these behaviors that are side effects and we can't get at directly, like if it's stacking context. I think we should have stacking context always.
# [18:58] <dael> fantasai: If you set z-index to 0 it's stacking
# [18:58] <dael> TabAtkins: Not quite.
# [18:58] <vollick> plinss: +1
# [18:58] <MaRakow> https://drafts.fxtf.org/compositing-1/#isolation
# [18:58] <fantasai> TabAtkins^: You also have to set position: relative
# [18:58] * tantek "establishes-stacking-context: true"
# [18:59] * bkardell_ is disappointed that the minutes appear to have missed TabAtkins use of the word "cromulent"
# [18:59] <dael> Rossen: We do have a prop that's stacking context. It's a compound prop, but impl or exposing is straight forward. I'm not sure about useful. As to containing blocks I second that.
# [18:59] * tantek "establishes-containing-block: true"
# [18:59] <dael> plinss: It annoys me that there are so many things that say position:relative just to get the side effects.
# [18:59] <dbaron> We actually changed opacity >= 0.99 to use the cheap drawing path
# [18:59] <dael> TabAtkins: The isolation property from filter has the effect of making it stacking so it can define your filter groups. So that's one thing.
# [19:00] * tantek lim (opacity -> 1)
# [19:00] <dael> TabAtkins: For containing blocks, for bock layout the display spec defines the flow route type. For positioning we don't have a way to trigger arbitrary position containing blocking, which we should at some point.
# [19:00] <dbaron> s/route/root/
# [19:00] <dael> Rossen: We'll have to figure out how that intersects with positioning, but yes. I think we're taking a ranting detour from smfr issue.
# [19:00] * tantek is out of time
# [19:01] <dael> plinss: And we're over time. To close on smfr issue, I think everyone agrees you create stacking context when you create stacking context, not beforehand.
# [19:01] <dael> TabAtkins: Yep.
# [19:01] * dauwhe looking forward to a new task force devoted to rants
# [19:01] <dael> Florian: I added some agenda+ can we do those next week> I also wanted an update on the prefixing policy thing for next time.
# [19:01] <alex_antennahouse> bye
# [19:01] <dael> plinss: Will do.
# [19:01] <fantasai> Rossen?
# [19:01] * tantek dauwhe Operation Rantforce
# [19:01] * Quits: alex_antennahouse (~458c94ae@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [19:01] <dbaron> Also, it's raining! (Very lightly.)
# [19:02] * Quits: jihye (~jihye@public.cloak) ("Page closed")
# [19:02] * Quits: MikeJoel (~null@public.cloak) (Ping timeout: 180 seconds)
# [19:02] * dael bkardell_ That was because I couldn't spell cromulent :)
# [19:02] <fantasai> Rossen, we should probably sync up on css-break
# [19:02] * Quits: antenna (~antenna@public.cloak) ("Leaving")
# [19:02] <bkardell_> dael lol
# [19:02] * Quits: MaRakow (~MaRakow@public.cloak) ("Page closed")
# [19:02] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [19:04] * Quits: vollick (~vollick@public.cloak) ("Page closed")
# [19:05] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
# [19:05] * Quits: AH_Miller (~AH_Miller@public.cloak) ("Page closed")
# [19:06] * Quits: ChrisL (clilley@public.cloak) ("Client combusted")
# [19:07] * Joins: estellevw (~estellevw@public.cloak)
# [19:08] * Quits: MikeJoel_real (~null@public.cloak) (Ping timeout: 180 seconds)
# [19:13] * leaverou is now known as leaverou_away
# [19:17] * Quits: smfr (~smfr@public.cloak) (smfr)
# [19:27] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [19:35] * Quits: dael (~dael@public.cloak) ("Page closed")
# [19:40] * Joins: zcorpan (~zcorpan@public.cloak)
# [19:42] * Joins: adenilson (~anonymous@public.cloak)
# [19:43] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [19:47] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [19:56] * Joins: antonp (~Thunderbird@public.cloak)
# [19:56] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [19:59] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [20:01] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [20:02] * Joins: estellevw (~estellevw@public.cloak)
# [20:05] * Quits: myles (~Adium@public.cloak) ("Leaving.")
# [20:11] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [20:13] * leaverou_away is now known as leaverou
# [20:23] * Joins: estellevw (~estellevw@public.cloak)
# [20:24] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [20:32] * Joins: dbaron (~dbaron@public.cloak)
# [20:41] * Quits: stryx` (~stryx@public.cloak) ("leaving")
# [20:41] * Joins: stryx` (~stryx@public.cloak)
# [20:48] * Joins: Florian (~Florian@public.cloak)
# [20:55] * Joins: zcorpan (~zcorpan@public.cloak)
# [20:56] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [20:57] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [21:08] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [21:09] * Quits: bkardell_ (~uid10373@public.cloak) ("Connection closed for inactivity")
# [21:59] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [22:00] * Joins: dbaron (~dbaron@public.cloak)
# [22:10] * Joins: bkardell_ (~uid10373@public.cloak)
# [22:15] * Joins: myles (~Adium@public.cloak)
# [22:36] * Quits: gregdavis (~udavig4@public.cloak) (gregdavis)
# [22:38] * Quits: rego (~smuxi@public.cloak) (Ping timeout: 180 seconds)
# [22:43] * Joins: rego (~smuxi@public.cloak)
# [22:43] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
# [22:55] * Joins: adenilson (~anonymous@public.cloak)
# [23:06] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [23:12] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [23:20] * Quits: rego (~smuxi@public.cloak) (Ping timeout: 180 seconds)
# [23:27] * Quits: TabAtkins (~sid11559@public.cloak) (Client closed connection)
# [23:27] * Quits: nikos (~sid28403@public.cloak) (Client closed connection)
# [23:27] * Quits: majidvp (~sid96638@public.cloak) (Client closed connection)
# [23:27] * Quits: timeless (~sid4015@public.cloak) (Client closed connection)
# [23:27] * Quits: ojan (~sid5519@public.cloak) (Client closed connection)
# [23:27] * Quits: cbiesinger (~sid8099@public.cloak) (Client closed connection)
# [23:28] * Quits: JonathanNeal_ (~sid5831@public.cloak) (Client closed connection)
# [23:28] * Joins: TabAtkins (~sid11559@public.cloak)
# [23:29] * Joins: majidvp (~sid96638@public.cloak)
# [23:29] * Joins: nikos (~sid28403@public.cloak)
# [23:29] * Joins: timeless (~sid4015@public.cloak)
# [23:29] * Joins: ojan (~sid5519@public.cloak)
# [23:30] * Joins: cbiesinger (~sid8099@public.cloak)
# [23:31] * Quits: gregwhitworth (~uid93288@public.cloak) ("Connection closed for inactivity")
# [23:31] * Joins: JonathanNeal_ (~sid5831@public.cloak)
# [23:31] * Joins: lmclister______ (~sid13822@public.cloak)
# [23:41] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [23:42] * Joins: dbaron (~dbaron@public.cloak)
# [23:51] * Joins: Florian (~Florian@public.cloak)
# [23:53] * Quits: tantek (~tantek@public.cloak) (tantek)
# [23:57] * Quits: darktears (~darktears@public.cloak) ("Leaving...")
# [23:58] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# Session Close: Thu Oct 01 00:00:00 2015

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