/irc-logs / w3c / #css / 2015-08-27 / end

Options:

# Session Start: Thu Aug 27 00:00:00 2015
# Session Ident: #css
# [00:02] * Joins: majidvp (~sid96638@public.cloak)
# [00:07] * Joins: rachelan_ (~rachelandrew@public.cloak)
# [00:07] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [00:12] * Quits: liam_ (liam@public.cloak) (Ping timeout: 180 seconds)
# [00:12] * Joins: liam_ (liam@public.cloak)
# [00:20] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [00:20] * Quits: rachelan_ (~rachelandrew@public.cloak) (Client closed connection)
# [00:34] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
# [00:35] * Joins: adenilson (~anonymous@public.cloak)
# [00:39] * Joins: Florian (~Florian@public.cloak)
# [00:41] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [00:41] * Joins: Florian (~Florian@public.cloak)
# [00:41] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [00:42] * Joins: rachelan_ (~rachelandrew@public.cloak)
# [00:42] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [00:48] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [01:00] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
# [01:00] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [01:07] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [01:07] * Quits: rachelan_ (~rachelandrew@public.cloak) (Client closed connection)
# [01:14] * Joins: adenilson (~anonymous@public.cloak)
# [01:23] * Joins: rachelan_ (~rachelandrew@public.cloak)
# [01:23] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [01:24] * Quits: darktears (~darktears@public.cloak) ("Leaving...")
# [01:36] * Joins: jdaggett (~jdaggett@public.cloak)
# [01:40] * Quits: rachelan_ (~rachelandrew@public.cloak) (Client closed connection)
# [01:40] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [01:48] * Joins: tantek (~tantek@public.cloak)
# [01:55] * Joins: rachelan_ (~rachelandrew@public.cloak)
# [01:55] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [02:00] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [02:09] * Quits: rachelan_ (~rachelandrew@public.cloak) (Client closed connection)
# [02:09] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [02:11] <gsnedders> https://wiki.csswg.org/test/css2.1/harness doesn't give any way to find out what the "names" of testsuites should be
# [02:11] <gsnedders> given the folder for the CSS 2.1 testsuite is "css21" I assumed tools/build.py css21 would build it, but I just get an error that it cannot find any such testsuite
# [02:18] * Rossen_away is now known as Rossen
# [02:21] * Joins: adenilson (~anonymous@public.cloak)
# [02:30] * Joins: rachelan_ (~rachelandrew@public.cloak)
# [02:30] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [02:32] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [02:37] * Joins: ed_paris (~ed@public.cloak)
# [03:13] * Rossen is now known as Rossen_away
# [03:19] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [03:19] * Quits: rachelan_ (~rachelandrew@public.cloak) (Client closed connection)
# [03:19] * Quits: ed_paris (~ed@public.cloak) (Ping timeout: 180 seconds)
# [03:39] * Quits: tantek (~tantek@public.cloak) (tantek)
# [03:39] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [03:39] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [03:54] * Joins: rachelan_ (~rachelandrew@public.cloak)
# [03:54] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [04:10] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [04:10] * Quits: rachelan_ (~rachelandrew@public.cloak) (Client closed connection)
# [04:22] * Joins: rachelan_ (~rachelandrew@public.cloak)
# [04:22] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [04:23] * Quits: liam_ (liam@public.cloak) (Ping timeout: 180 seconds)
# [04:27] * Joins: skk_ (~skk@public.cloak)
# [04:31] * Quits: skk (~skk@public.cloak) (Ping timeout: 180 seconds)
# [04:38] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [04:38] * Quits: rachelan_ (~rachelandrew@public.cloak) (Client closed connection)
# [04:43] * Joins: tantek (~tantek@public.cloak)
# [04:44] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [04:48] * Quits: tantek (~tantek@public.cloak) (tantek)
# [04:54] * Quits: myles (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [04:54] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [04:54] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [05:10] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [05:10] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [05:23] * Joins: rachelan_ (~rachelandrew@public.cloak)
# [05:23] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [05:33] * Joins: myles (~Adium@public.cloak)
# [05:35] * Parts: myles (~Adium@public.cloak)
# [05:39] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [05:39] * Quits: rachelan_ (~rachelandrew@public.cloak) (Client closed connection)
# [05:54] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [05:54] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [06:09] * Joins: rachelan_ (~rachelandrew@public.cloak)
# [06:09] * Quits: rachelan_ (~rachelandrew@public.cloak) ("Leaving...")
# [06:13] * Quits: rachelandrew (~rachelandrew@public.cloak) (Ping timeout: 180 seconds)
# [06:56] * Joins: shepazu_ (schepers@public.cloak)
# [07:00] * Quits: shepazu (schepers@public.cloak) (Ping timeout: 180 seconds)
# [07:20] * Joins: antonp (~Thunderbird@public.cloak)
# [08:00] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:06] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [08:21] * Joins: Florian (~Florian@public.cloak)
# [08:26] * Joins: johanneswilm (~johannes@public.cloak)
# [08:34] * Joins: tantek (~tantek@public.cloak)
# [08:39] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [08:40] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [08:40] * Joins: johanneswilm (~johannes@public.cloak)
# [08:40] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [08:41] * Joins: Florian (~Florian@public.cloak)
# [08:44] * Quits: skk_ (~skk@public.cloak) (Ping timeout: 180 seconds)
# [08:45] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [08:46] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:48] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [08:53] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [08:57] * Joins: dauwhe (~dauwhe@public.cloak)
# [08:57] * Joins: dbaron (~dbaron@public.cloak)
# [09:02] * Joins: Florian (~Florian@public.cloak)
# [09:02] * Quits: dholbert (~dholbert@public.cloak) ("dholbert")
# [09:04] * Joins: liam (liam@public.cloak)
# [09:04] * Joins: ed_paris (~ed@public.cloak)
# [09:05] * heycam|away is now known as heycam
# [09:08] * Joins: MaRakow (~MaRakow@public.cloak)
# [09:08] * Quits: tantek (~tantek@public.cloak) (tantek)
# [09:08] * heycam ed_paris do you run this part of the meeting, or plinss? in any case, all of the items on https://wiki.csswg.org/planning/paris-2015?&#proposed-agenda-topics-fx added by me will want krit and Tav around for
# [09:09] * heycam so best to begin with the other topics
# [09:09] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [09:12] * Joins: smfr (~smfr@public.cloak)
# [09:13] * Joins: dael (~dael@public.cloak)
# [09:13] <dael> ScribeNick: dael
# [09:13] * Joins: dino (~textual@public.cloak)
# [09:13] <ed_paris> https://wiki.csswg.org/planning/paris-2015#proposed-agenda-topics-fx
# [09:13] * Joins: tantek (~tantek@public.cloak)
# [09:13] * Joins: tkonno (~chatzilla@public.cloak)
# [09:13] <dael> heycam: All the ones I added Tab and krit will need to be here.
# [09:13] * Joins: skk (~skk@public.cloak)
# [09:13] <dael> Topic: SVG resources
# [09:14] * Joins: AndreyR (~AndreyR@public.cloak)
# [09:14] * Joins: cyril (~cyril@public.cloak)
# [09:14] * krit is there a video bridge or number to call in?
# [09:14] <dael> ??: People like SVG as CSS images. We think people that would benefit from the resources, possibly only margin resources. The current behavior is given by the processing mores.
# [09:14] <smfr> https://svgwg.org/specs/integration/#secure-animated-mode
# [09:14] <astearns> s/??/smfr/
# [09:14] * Quits: AndreyR (~AndreyR@public.cloak) ("Page closed")
# [09:14] * Joins: andreyr (~andreyr@public.cloak)
# [09:14] * astearns should the minuting be here or on #fx?
# [09:14] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [09:14] <dael> smfr: The one used in SVG modes is this one ^ We think there's a use case for having a secure animated more.
# [09:15] * dael good question.
# [09:15] <cyril> s/mores/modes/
# [09:15] * ed_paris here is fine
# [09:15] * astearns OK, thanks
# [09:15] <dael> smfr: WE should have to figure out what resrounces are.
# [09:15] <dael> tantek: What are the use cases.
# [09:15] <dael> dino: Want to link to a style sheet.
# [09:15] <dbaron> what's a more?
# [09:16] <dbaron> oh, mode
# [09:16] <dael> smrf: Right now if you want to import you have to do as a div
# [09:16] <dael> tantek: A new mode?
# [09:16] <dael> smfr: I don't know.
# [09:16] <dael> tantek: We recently added CSS 3 UI cursor prop where you can do SVG cursor.
# [09:16] <dael> smfr: I think that's a special one.
# [09:16] <dael> Florian: We referred to a spec in SVG.
# [09:17] * krit again the question, is there a way to call in?
# [09:17] * hober SimonSapin ^^
# [09:17] <dael> tantek: Secure animated mode. It's a client of that mode. My pref. is that stay the same for that reason. If you have a strong reason for just secure animated mode. I'm open to being convinced otherwise.
# [09:17] * Joins: zcorpan (~zcorpan@public.cloak)
# [09:17] * Joins: jihye (~jihye@public.cloak)
# [09:17] <tantek> CSS3 UI is a client of secure animated mode, specifically, the cursor property
# [09:17] <dael> heycam: If whatever reason is still egit, we have the option of having those external resources referenced. If there's an iFrame or something like that where we have a place to specifiy a location.
# [09:18] <dael> dino: Doing it on the image element, would you put and extra parameter on the URL?
# [09:18] <dael> heycam: I really want to do this, I think this was the org. intent of SVG.
# [09:19] * Joins: hyojin (~hyojin@public.cloak)
# [09:19] <dael> dino: I think the intention with that, yes, but the browsers locked down the security as much as they could and no one remembers exactly why we wanted to disallow that.
# [09:19] <dael> heycam: Do you know if each mode might not allow some resources? Can you explain why?
# [09:19] <dael> smfr: What's the best way to move forward?
# [09:19] <dael> heycam: I'll talk to the people in a couple weeks. In principal that will be good until now.
# [09:20] <dael> antonp: One practice that's been common is use sprites on pages. That would be a use case for not logging terms.
# [09:20] * heycam krit SimonSapin is not here yet... let me see...
# [09:20] <tantek> s/antonp/tantek
# [09:21] <tantek> specifically, using data URLs for encoding SVG images as sprites on pages
# [09:21] <tantek> or icons etc.
# [09:22] <plinss> call in details: https://v.mozilla.com/flex.html?roomdirect.html&key=0PLFZo7IhLZkW7MKiYM6h93ew
# [09:22] <plinss> more details: http://www.w3.org/mid/55D5D600.2000604@exyr.org
# [09:22] <tantek> presnent+ tantek
# [09:22] <TabAtkins> present+ Tab Atkins
# [09:22] <fantasai> present+ fantasai
# [09:22] <Bert> Present+ Bert
# [09:22] <Florian> present+ FLorian
# [09:22] <gregwhitworth> present+ gregwhitworth
# [09:22] <hober> present+ hober
# [09:22] <dauwhe> present+ dauwhe
# [09:22] <smfr> present+ smfr
# [09:22] <birtles> present+ Brian Birtles
# [09:22] <nikos> present+ nikos
# [09:22] <astearns> present+ astearns
# [09:22] <liam> Present+ Liam
# [09:22] <ed_paris> present+ Erik Dahlström
# [09:22] <dino> present+ Dean Jackson (dino)
# [09:22] <MaRakow> present+ Matt Rakow
# [09:22] <plinss> present+ Peter Linss
# [09:22] * Rossen_away is now known as Rossen
# [09:22] <dael> present+ dael jackson
# [09:22] <tkonno> present+ Tomoaki Konno
# [09:22] <skk> present+ skk(hiroshi)
# [09:23] <Rossen> present+ Rossen
# [09:23] <shane> present+ Shane Stephens
# [09:23] <flackr> present+ Rob Flack
# [09:23] <heycam> present+ Cameron McCormack
# [09:24] <rachelandrew> present+ Rachel Andrew
# [09:24] * heycam krit we are now dialled in here -- use this link https://v.mozilla.com/flex.html?roomdirect.html&key=0PLFZo7IhLZkW7MKiYM6h93ew
# [09:24] * Joins: SteveZ (~SteveZ@public.cloak)
# [09:25] * Joins: projector_ (~projector@public.cloak)
# [09:25] <esprehn> present+ Elliott Sprehn
# [09:25] <andreyr> present+ Andrey Rybka
# [09:25] <dael> ed_paris: krit did you have anything to add?
# [09:25] <dael> heycam: He wanted to be able to hear
# [09:26] * hober should we be doing this in #fx or #css?
# [09:26] * krit #css was decided
# [09:26] * dael mostly because I was there and didn't think to switch :)
# [09:27] <dael> TopicL SVG images w/o interinsic size
# [09:27] <dael> dino: This is an edge case that's being discussed internally and TabAtkins has an opposite opinion. I don't know what else to say, this is an instance where we want to encourage people not to use intrinsic siz in their SVG, but when there's border you need to know intrinsic size.
# [09:28] * Joins: ed_work_ (~ed@public.cloak)
# [09:28] <dael> TabAtkins: You do not. We have some bugs in chrome but it's roughly correct. Yours for background is completely correct, but you used something odd for border.
# [09:28] * ed_work_ is now known as ed_paris__
# [09:28] <dael> dino: So you work out the size of the border, rasterize the SVG in and slice it.
# [09:28] * Ms2ger waves at fantasai
# [09:28] <dael> TabAtkins: That's what the spec says. The SVG side of how to figure out hte coordinate space is hard to read.
# [09:29] <dael> krit: SVG spec is missing a lot of info on intrinsic sizing. There's an open issue for this.
# [09:29] <cyril> s/TopicL/Topic:/
# [09:29] <cyril> s/interinsic/intrinsic/
# [09:30] <dael> TabAtkins: The one that's hard to find is how, given no other sizing information but being embedded in some other document, the SVG docuement takes its coordinate space. If you set up in a 300 px wide, the SVG was 300 units. It's in the spec, but hard to find. I think it would have made this more onvious.
# [09:30] <dael> TabAtkins: Just making sure this is an issue you'll address.
# [09:30] <dael> dino: We have 3 browsers with 3 different impl all of which are buggy.
# [09:30] <dael> TabAtkins: Chrome and FF are consistant.
# [09:30] <dael> dino: FF is radically different. It was drawing same image in all cells.
# [09:31] <dael> TabAtkins: If it was then yes, I agree. It's odd.
# [09:31] <dael> TabAtkins: Rossen where are you tracking issues.
# [09:31] * Quits: ed_paris (~ed@public.cloak) (Ping timeout: 180 seconds)
# [09:31] <zcorpan> present+ Simon Pieters
# [09:31] <dael> Rossen: We had to impl this in edge and we're matching chrome mostly, in some cases FF where it made more sense. As part of this came up with a whole bunch of text cases. I'll record all this, get an agreement, submit test cases and move on.
# [09:32] <dael> dino: Where documented?
# [09:32] <dael> Rossen: There's the integration spec or it could be in SVG spec.
# [09:32] <dael> dino: In the current, what' TabAtkins is suggesting there's a sig. difference between SVG that has and does not have intrinsic size.
# [09:32] <dael> TabAtkins: That's what the spec has.
# [09:32] <dael> Rossen: There's a bunch of permutations there.
# [09:33] <dael> ed_paris__: You satisfied?
# [09:33] <dael> dino: Yeah.
# [09:33] <dael> tantek: Quick question, include intrinsic aspect ratio?
# [09:33] <dael> TabAtkins: You get that from the view box, it doesn't matter. You can have width and or height, you can have a viewbox, you can have both, you can have neither and that gives you all valid combinations.
# [09:34] <dael> tantek: I think we ran into a bunch of these when trying to test the box sizing.
# [09:34] * heycam hi jdaggett
# [09:34] <dael> Florian: I don't know how extensively they've been test, but there's more bugs if we poke at it.
# [09:34] * jdaggett hi!
# [09:34] <dael> tantek: So if you're looking for places with bugs that's a good place to look.
# [09:34] <dael> dino: I think this is where we found the original bug.
# [09:34] * Florian Hi John
# [09:34] * tantek agenda question: where is it?
# [09:35] <dael> Topic: Matrix interpolation revisited.
# [09:35] * dael tantek bottomo f the agenda wiki
# [09:35] * tantek https://wiki.csswg.org/planning/paris-2015#thursday just says "FXTF" - no link
# [09:35] * Florian tantek: https://wiki.csswg.org/planning/paris-2015#proposed-agenda-topics-fx
# [09:35] * tantek thanks dael Florian
# [09:36] <dael> shane: I wanted to revisit the interprolation for matrixes. There's two cases where we fall into a matrix decomposition. The first is when applying to matrix componants and the other is interp on transform lists that don't match.
# [09:36] <dael> shane: I don't think that there are 2 matching. I think we should not attemp anything clever and adjust to 50% clip.
# [09:36] <dael> TabAtkins: Like all the prop that don't have an animation, they flip at 50% progress.
# [09:37] <dael> dino: Webkit is close to moz with the exception of one interp that goes through an undefined case. In that cae the rotation, it's had to say if it's rotation- it goes in a different direction.
# [09:37] <dael> dino: Otherwise in teh vast majority of cases it's identical
# [09:37] <dael> shane: The direction of rotation is something different browsers disagree on.
# [09:37] <dael> dino: The algo is in the spec
# [09:37] * tantek agenda "FXTF" now linked to that list
# [09:38] <dael> shane: It's demonstratably incomplete and I don't think anyone impl what's in the spec.
# [09:38] <dael> dino: I impl what's in the spec and dbaron gave us what are the incompatabilities. I think krit was going to put it in the spec.
# [09:38] <dael> shane: This comes out again and again.
# [09:38] <dael> dino: Compat behavior is easy to define. It's 10-20 lines of code. One person could look at all the browsers and make the change.
# [09:39] <dael> shane: It's been this way for 5+ years.
# [09:39] <dael> dino: Because it's such a rare case.
# [09:39] <dael> shane: People hit them all the time. There's number of demos.
# [09:39] <dael> dino: Let's fixt he bug.
# [09:39] <dael> shane: So there's matrix to matrix and I think we want to fix the bugs. There's transform list to transform list and the issue there is there isn't a meaningful thing to do.
# [09:40] <dael> shane: WE should be working out the cases where we can augment transform matching. When it comes to matching transform matching, doing matrix decomp doesn't give the correct result.
# [09:40] <dael> dino: it's very weel defined.
# [09:40] * Rossen Dirk can you hear the conversation?
# [09:40] <dael> shane: I disagree becuase we don't have matching impl.
# [09:40] * jdaggett dean is good, shane mumbles... :P
# [09:41] <dael> dino: WE had a whole e-mail thread about what to do and we impl. Yes we could augment the case with two non-matching transform lists if we could work out what the authors intended and this is something we could fix, that seems like an okay theme to follow.
# [09:41] <dael> dino: I don't understand why interpolate between two matrix is a big deal.
# [09:41] * krit rossen, no
# [09:42] <dael> shane: This is when the transforms don't match. In that case what happens is authors will much around witht he transform lists until they get something and it doesn't look good in a broswer.
# [09:42] <dael> shane: So a 50% flip when they don't match is a clear sign something is wrong.
# [09:42] <dael> dino: I think we should enumerate the cases where the browsers don't match.
# [09:42] <dael> shane: We've been doing that for the last 5 years.
# [09:42] <dael> dino: We decided on an algo.
# [09:43] <dael> shane: So there's the rotation issue where you need a short of long path and this is where you flip. That never made it into the spec.
# [09:43] <dael> dino: krit did we ever agree to put updated matrix intrep in the spec?
# [09:43] <dael> krit: We agreed to and we did add it, the one for 2d transforms
# [09:43] <dael> dino: 3d transformations
# [09:44] <dael> krit: I thinkt he bigger issue was on 2d, not 3d. We went to 3d and this was the reason we had the diff issues between browsers.
# [09:44] <dael> shane: That's the point.
# [09:44] <dael> dino: I think we can come up with an algo, this isn't rocket science. This won'tb e diff for browsers to impl same.
# [09:44] * heycam matrices probably feature heavily in rocket science
# [09:44] <dael> shane: We could. I'm arguing there isn't compat right now and it's better to break.
# [09:45] <dael> dino: So break exisiting content instead of have a future where things work prop. You're saying you want to break matrix interp in all cases.
# [09:45] <dael> shane: The space in transforms is evenly propulated.
# [09:45] <dael> smfr: I think the remaining scale works just fine. I think breaking it to address rotations is bad.
# [09:45] <dael> shane: We're only hitting this when transformers don't match anything.
# [09:45] <dael> dino: Maybe you should come up with a list that seems brokens and we can eval if it's worth breaking everything.
# [09:45] <smfr> s/remaining/rotation and scale/
# [09:46] <dael> shane: You're asking for a list of sites that are not working right now.
# [09:46] <dael> dino: We've got to choose between two groups of 'working' and 'broken' and that ratio is going to change. We have to decide which decision will change the amount of broken content.
# [09:46] <dael> shane: I'm happy to go and get that.
# [09:46] <dael> dino: And balance that against the overhead.
# [09:47] <dael> shane: It's might harder to get the broswers to introp then remove that.
# [09:47] <dael> krit: Currently there's 2d and 3d matrix interp. There are differences in 3d. The 2d there were patches to FF and they didn't accept them. That's why you see many diff.
# [09:47] <dael> krit: Blinka nd webkit aren't identical. The algo got into the spec after the fork.
# [09:48] <dael> shane: We've also made fixes both on the browser and render side and neither of those match the spec.
# [09:48] * heycam hi little one!!
# [09:48] <dael> dino: So leave as-is, fix the spec, or break the content and do the 50% split. We need data. I like fix the spec, you like option 3, and we need data to decide.
# [09:49] <dael> shane: Fair enough. I did want to raise this issue. There also was an internest in augementing where we do list matching. Is that true?
# [09:49] <dael> dino: It would be interesting to see what intel you could gain to see what matches.
# [09:49] <dael> shane: There's simple ideas we've had in the past.
# [09:49] <dael> dino: I don't know what causes incompat lists.
# [09:49] * astearns new invited expert from the Daggett feed
# [09:49] <dael> shane: Most common is leaving the last componant.
# [09:50] * cyril the youngest maybe
# [09:50] <dael> dino: At the moment we say if you do anything from ID you could fill it in. There's another slightly less complicated way, but I think we can deal with that. If we did just those 2 things we'd remove 90% of the cases.
# [09:51] <dael> krit: The interpolation we removed a smarter way and we removed that for smarter matrices.
# [09:51] * jdaggett she seems to like dirk's voice...
# [09:51] <dael> krit: If you have 2 lists of transforms and the last element is missingon the last transform. You do not need to fall back to matrix intrepo. I had to remove that from the spec.
# [09:51] <dael> shane: What were the requests.
# [09:52] <dael> krit: The spec was updated 2 years ago, so it was 2 years ago.
# [09:52] <dael> shane: I will write up something and send it to the list.
# [09:52] <dael> krit: And it's somewhere in the older modules.
# [09:52] <dael> Topic: SLERPing and 0deg angles.
# [09:53] * hober would like to point out that Tab just said "axes" TWICE.
# [09:53] <dael> TabAtkins: Whenever we have 2 3d roatations we're transforming between. WE have well defined if the axes are identical. If they're different there's no good way to interpo. We need to do it using SLERPS. That's all background.
# [09:53] * hober (not axises)
# [09:53] * Ms2ger gasps
# [09:54] * ed_paris__ axii?
# [09:54] * astearns perhaps that's just how he pronounces "axises"
# [09:54] <dael> TabAtkins: If you have an ID 3d rotation pointing in any direction whatsoever and you're transitioning. That the axes might be different is irrelevant. IN this case we should basically pretent he axes are aligned if one is 0deg rotation so we can get proper agruements.
# [09:55] <dael> shane: That behavior is what happens already in that the 0deg axis snaps to the non-0. Rather than a paramenter, you get the shortest path.
# [09:55] <dael> TabAtkins: Does anyone object to making that clear in the spec. That 0deg rotation pretend the axis is aligned. Anddoes anyone object that anit-par work the same?
# [09:56] <dael> krit: We can't have lots of special cases. The reason why we didn't change is certain browser vendors like Safari said they couldn't change their background for that. Safari relies on the OS for this calculation.
# [09:56] <dael> TabAtkins: Either of these two cases are addressible for massaging inputs pre-OS.
# [09:56] <dael> krit: I'm not against, but we can't add dozens os special cases. It makes the code more complex and less readable.
# [09:57] <dael> TabAtkins: I thinkthe 0deg is important because when you're going from an ID transform it shouldn't matter.
# [09:57] <dael> krit: Just ID to 3d transform.
# [09:57] <dael> TabAtkins: If it's a 0deg rotation, it's an ID transform.
# [09:57] <dael> krit: I'm not sure I follow.
# [09:58] <shane> transform: rotate3d(0, 1, 0, 0); to transform: rotate3d(1, 0, 0, 20);
# [09:58] <dael> TabAtkins: Take a 0deg rotation around the y axis, say that's the start, end is 720deg around X axis. That you're 0deg around Y doesn't matter.
# [09:58] <dael> TabAtkins: Rotation has this thing where we can only do arguement based is the axes match.
# [09:58] <dael> krit: I see.
# [09:58] <dael> MaRakow: HAs Chrome proto?
# [09:58] <dael> TabAtkins: Yes.
# [09:59] <dael> TabAtkins: Obj to treat 0deg as argumeent interp with a real rotation?
# [09:59] <dael> smfr: What part of the spec will have this?
# [09:59] <dael> shane: I think this is best before decomp.
# [09:59] <dael> TabAtkins: This is a matter of figuring out which list of transforms are matching.
# [09:59] <dael> dino: You could prob extend that to be any transform.
# [09:59] <dael> TabAtkins: I don'thtink any of the other have this fiddlyness.
# [10:00] <dael> dino: If it's a previous thing where you're making matching smarter. It seems like it would fall in.
# [10:00] <dael> shane: That might not be good because that rotate 0 might be a placeholder to intrepo with something else.
# [10:00] <dael> shane: How about we do this patch now and we try and come up with something more complete.
# [10:00] * Joins: Tav (~tbah@public.cloak)
# [10:01] <dael> krit: If we say the transform is an ID transform, it might have a translation +20 and -20?
# [10:01] <dael> TabAtkins: If they use rotate that's a semantically meaningful choice. Going from a rotate to a translate has meaning.
# [10:01] <dael> krit: It seems odd that we say for rotate that's the only thing we do not do that. We say you rotate with 0deg we treat it as an ID, but for the others we say it's different.
# [10:02] <dael> TabAtkins: Might be diff of opinion, but it makes sense that if we're going 3d to 3d rotate it is acceptable.
# [10:02] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [10:02] <dael> shane: There's nothing special, it's that there's a unique ID for everything except transform.
# [10:02] * Joins: dbaron (~dbaron@public.cloak)
# [10:02] <dael> TabAtkins: So, obj to treating all 0deg rotate 3d as a single eq. ID transform?
# [10:03] <dael> RESOLVED: treat all 0deg rotate 3d as a single eq. ID transform
# [10:03] <dael> TabAtkins: Obj to treating rotate 3d with anti-par axis as interperable?
# [10:04] <dael> TabAtkins: If you have one rotation 90deg in +x and 45 in -X, they are eq.
# [10:04] <dael> TabAtkins: You don't even need to do a neg axis.
# [10:04] <iank> Present+ Ian Kilpatrick
# [10:04] <dael> shane: You have to choose a direction to rotate in this case and we should make this work as close to spec as possible.
# [10:05] <dael> TabAtkins: So should we agree on that, or do we want prop text.
# [10:05] <dbaron> Present+ dbaron
# [10:05] <dael> smfr: It's okay.
# [10:05] <dael> dino: We can agree.
# [10:05] <dael> RESOLVED: treat rotate 3d with anti-par axis as interperable
# [10:05] <dbaron> s/interperable/interpolable/
# [10:05] <dael> krit: In the future it would be better to come with a demo for that.
# [10:05] <dbaron> s/anti-par/anti-parallel/
# [10:05] <dael> shane: We did send a list of the issues.
# [10:06] <dael> Topic: text-orentation
# [10:06] <dael> heycam: There were two things in writing-modes.
# [10:07] <jdaggett> yay!!!!!!!!
# [10:07] <dael> heycam: One was the values for compat with SVG 1.1 for text-orientation. We've discussed this before but there had been holdouts on our side, but we now all agree that we don't need them. They're not compat impl everywhere.
# [10:07] <dael> heycam: I'd like to prop removing.
# [10:07] <jdaggett> delete, delete, delete...
# [10:07] <dbaron> re "RESOLVED: treat all 0deg rotate 3d as a single eq. ID transform" -- presumably the rotate3d() is only compatible with other rotate3d functions, and not an identity relative to arbitrary other transform functions?
# [10:07] <dael> fantasai: I think there'sprob some impl that need some values to work. Last time we discussed maybe 0deg needed to work in glyph orentation vertical.
# [10:08] <dael> fantasai: I think 270 doesn't have use cases. If exact compat isn't an issue, treat glyph orented vertical, you can treat those as an alias.
# [10:08] <dael> krit: Since they're diff prop, I'd prefer to depricate them.
# [10:09] <MaRakow> dbaron I think it would be compatible with rotateX/Y/Z too, right?
# [10:09] <dael> fantasai: We shouldn't change in the new prop. You can't support two things that control the same behavior without defining how they interact. How it's def. currently is text-orientation has a special keyword. I suggest we drop the keyword and have the three values that are used map as alises to the text-oreitnetation prop.
# [10:09] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [10:10] <dael> fantasai: We did this with page break. The technical way we did this is we defined page break inside as a shorthand of page break inside. IT gets all the aliasing. The prop would be for impl that need to support glyph orientation. If no one needed it we could drop.
# [10:10] <dael> heycam: I thought we might be htere.
# [10:10] <dael> krit: I'd rather the text-orientation. I was verifying that what the new prop supports is things that make sense.
# [10:11] <dael> heycam: The day before we were talking about support for glyph oreitnation vertical itself. Do you think we can drop that whole property?
# [10:11] <fantasai> Proposal would be that 'glyph-orientation-vertical: 0deg' is shorthand for 'text-orientation: upright', 'glyph-orientation-vetical: auto' is shorthand for 'text-orientation: mixed', and 'glyph-orientation-vertical: 90deg' is shorthand for 'text-orientation: sideways-right'
# [10:11] <dael> krit: One moment
# [10:11] <fantasai> And glyph-orientation-vertical is not a real property, only a shorthand
# [10:12] <fantasai> And the other values of glyph-orientation-vertical are dropped
# [10:12] * Quits: skk (~skk@public.cloak) (Client closed connection)
# [10:12] * Quits: dino (~textual@public.cloak) (Client closed connection)
# [10:12] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [10:12] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [10:12] <dael> krit: It only has upright, sidways-right and -left. So as an alternative to 0deg, 180 deg and 270deg.
# [10:12] <dael> jdaggett: We've been talking about a prop for sideways-lr and -rl going into the writing of shorthand which would nec. making sideways be sideways right.
# [10:12] <dael> fantasai: I don't think that effects too much what we're doing here. It might effect the mapping of 90deg.
# [10:12] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [10:12] * Joins: dauwhe (~dauwhe@public.cloak)
# [10:12] <dael> jdaggett: Is anyone in the room talking about impl this value? glyph orientation?
# [10:13] * Joins: skk (~skk@public.cloak)
# [10:13] <dael> fantasai: I'm prop we drop. If there is no impl, if everyone will drop and not be able to read glyph orientation then we can drop it and def that glyph orientation vertical isn't valid.
# [10:13] <dael> krit: I'd rather if we have text-oreintation support and you ignored it.
# [10:14] <dael> fantasai: That's not a great interaction between prop. I'd rather we define the interaction between aliasing because that gets everything to work correctly. You impl as a short hand and glyph orientation 0, auto, and 90 are upright mixed and sideways. So it only needs the orientation plus this shorthand.
# [10:14] <dael> krit: It sounds complex. It's backwards compat and spec how it works witht he new, but it seems a lot of work.
# [10:15] * Joins: johanneswilm (~johannes@public.cloak)
# [10:15] <dael> fantasai: It's less work because no where in your code base is checking two prop. You only support glyph orientation when you're doing the parsing stage because it will map directly intot he text orientation. It saves you data.
# [10:15] <dbaron> MaRakow, I think that's implied by the primitives stuff
# [10:15] <dael> krit: Maybe not in FF, but having a new structure for a shorthand prop is a lot of work.
# [10:15] <dael> Florian: It's not a lot. Support short hands engines support already.
# [10:16] <dael> heycam: To get back to impl. For webkit and blink, do you support glyph orientation vertical 0 now?
# [10:16] <dael> krit: Just for SVG
# [10:16] <dael> heycam: DO you plan to remove?
# [10:16] <dael> krit: The problem with removal is we have content out there.
# [10:16] <dael> fantasai: If your'e going to remove it, we'll remove the mention from all spec. If you're not we need to come up with a better definition.
# [10:17] <dael> jdaggett: Do we know there's content using this?
# [10:17] <fantasai> s/need to come up with/need to define it, and this is/
# [10:17] <dael> krit: It was used, yes. Illustrator does.
# [10:17] <dael> jdaggett: Illisutrator is ancient.
# [10:18] <jdaggett> um, if no user agent implements this value I think we should drop it
# [10:18] <dael> fantasai: But Illustrator is an impl. If they want to be able to implement that we need to support it. If any SVG reader needs it we have to define how to handle it in the new world in a way they can read their old content. This solves their problem. We try and avoid situations with two prop that control the same thing. In CSS the override mech is the cascade for when two things control the same thing.
# [10:19] <dael> fantasai: This lets us use the cascade and that's the same thing we've done for other issues. If we dont' have to support 180 and 270 this is the best way.
# [10:19] <jdaggett> legacy relationships do exist but if there's not a lot of content that uses this
# [10:19] * Joins: lajava (~javi@public.cloak)
# [10:19] <dael> Florian: We spent a bunch of time looking at mech to handle this and this was best.
# [10:19] <dael> heycam: Okay, in the case that we're not as close to removing, this keyword is a smart way to do it.
# [10:20] <fantasai> jdaggett, the issue is non-Web content. We need to define how it works for those implementations, even if no browser ever needs to implement it
# [10:20] <dael> krit: I disagree short hands are easier to handle. Illustrator is interested in the new text orientation property.
# [10:21] <dael> fantasai: Prop is drop glyph-orientation vert drop 270 and 180, drop glyph oreitnation horz entirely. Drop text-orientation use glyph orientation value. Treat glyph oreitnation 0, auto, and 90 as aliases of the corrisponding values of text orientation
# [10:21] <dael> heycam: I agree with that concept.
# [10:21] <dael> krit: I agree witht he first points. You know my opinion on the last, but I'm not going to obj.
# [10:22] <dael> fantasai: If we're doing mapping, this is the way we should do it.
# [10:22] <dael> RESOLVED: drop glyph-orientation vert drop 270 and 180, drop glyph oreitnation horz entirely. Drop text-orientation use glyph orientation value. Treat glyph oreitnation 0, auto, and 90 as aliases of the corrisponding values of text orientation
# [10:22] <Florian> Here is a page on the csswg wiki exploring different aliasing mechanism: https://wiki.csswg.org/ideas/aliasing
# [10:22] <dael> Topic: writing-mode values from SVG 1.1
# [10:23] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [10:23] <dael> heycam: I was initially opposed to including the old keywords as aliases but my obj wasn't particularly strong. I tried to e-mail Jonathan Kew, but I didn't get a reply.
# [10:24] <dael> fantasai: I think the spec needs that table. I don't think we need to require that every impl includes it. We need that mapping for those that support the values. I think IE does.
# [10:24] <dael> heycam: Unless anybody remains objecting, that's fine.
# [10:24] <dael> krit: So what elements would be supported for SVG?
# [10:25] <dael> fantasai: You either support the values or you don't. If you don't support SVG you need to support those values.
# [10:25] <dael> krit: You suggested there's an ability to write it to the UA stylesheet.
# [10:25] <dael> fantasai: If you only need to support the presentation attr ayntax you can do that. If you need CSS values you'll end up parsing in all contexts.
# [10:25] <dael> krit: Will that be req for all UA that support SVG?
# [10:26] <dael> fantasai: That's up to SVG group.
# [10:26] <dael> heycam: I would say yes. Given that IE has the old values and others do, we might as well have unconditional support.
# [10:26] <dael> heycam: What does it say in the spec re: required?
# [10:26] <fantasai> "Implementations that wish to support these values in the context of CSS must treat them as follows: "
# [10:27] <dael> fantasai: I should qualify that for writing modes conformance it's optional and SVG can say it's required.
# [10:27] <dael> ??: I think it should be req. for SVG
# [10:27] <dael> fantasai: It's required in CSS in general if you don't support SVG you might not need to, but most UA will.
# [10:27] <ed_paris__> s/??/Tav
# [10:27] <dael> heycam: I'm fine with it.
# [10:27] <heycam> s/??/Tav/
# [10:28] <dael> ed_paris__: Do we need a resolution?
# [10:28] <dael> heycam: If that's the current state, then I guess it's fine to leave as-is.
# [10:28] <fantasai> ACTION fantasai add RFC2119 optional wording to svg writing-modes keywords
# [10:28] * trackbot is creating a new ACTION.
# [10:28] <trackbot> Created ACTION-716 - Add rfc2119 optional wording to svg writing-modes keywords [on Elika Etemad - due 2015-09-03].
# [10:28] <dael> Topic: Transform to element for geometry
# [10:29] <ed_paris__> getTransformToElement
# [10:29] <dael> heycam: In the SVG WG we just removed some method that was under defined that was get transform to element. The intention was to give you a matrix that transforms between one element in a system to another. One undef was what happens when you have two SVG frag.
# [10:29] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [10:30] <dael> heycam: If you're going to support anyting like that it should be more general than SVG elements. We wanted to find out if that's something people wanted to see. It's not urgent, but to see if people were opposed.
# [10:30] <dael> smfr: It would work across 3d transforms? There are problems comp martixes with flattened. I'd like to see points and rect. between coord systems which I think is geom.
# [10:31] <dael> heycam: Converting points and things is ususally what you'll want.
# [10:31] <dael> shane: So this returns a matrix, is that right?
# [10:31] <dael> heycam: The old does a mtrix. It was a SVG matrix and recently changed to the added DOM. What's the actual method that does the transform.
# [10:32] <ed_paris__> s/added DOM/added DOMMatrix/
# [10:32] <dael> smfr: Do you have a link?
# [10:32] <heycam> http://dev.w3.org/fxtf/geometry/
# [10:32] * Joins: dino (~textual@public.cloak)
# [10:32] <zcorpan> https://drafts.csswg.org/cssom-view/#the-geometryutils-interface
# [10:33] <dael> heycam: So that relates to take a point, intrep and take it to a point in another one.
# [10:33] <dael> zcorpan: I don't really remember.
# [10:33] <dael> krit: If you have a transofrm you can apply it to a point. You cant take it from one point to another point in a diff coord system.
# [10:33] <dael> heycam: The main def seems to be missing.
# [10:34] <dael> heycam: The answer is prob that these methods will do what they need to or that's an obvious place to put something.
# [10:35] <dael> Topic: path animation
# [10:35] <dael> Tav: One piece that's missing is part animation. I think there's a lot of support for an interest in. I'd like to see it be impl somehow. If you can just use a string or not and how you do that, I think birtles might know more.
# [10:36] * Joins: nvdbleek3 (~nvdbleek@public.cloak)
# [10:36] <astearns> s/part/path/
# [10:36] <dael> birtles: I'm not sure how much more. We dicussed the other day and more or less agree on the attr on a prop so that we can animate CSS transitions and animations. The part we need is the syntax for that. Having looked at what we have in motion path that could be more consistant to wrap up the SVG path function and allow using the shape functions.
# [10:37] <fantasai> s/This lets us use/This mechanism lets us use/
# [10:37] <fantasai> s/for other issue/in equivalent situations like page-break-inside/break-inside, where we've had legacy syntax we needed to map over/
# [10:37] <dael> birtles: We haven't quite resolved. We also talked about making it easier to intrerpolate. I wanted to try and solve that problem, but I want to adjust to the same thing SVG does. I think that's the state at the moment. I'm not sure there's anything to discuss.
# [10:37] <fantasai> s/180 and 270 this/180 and 270, which have no equivalent in text-orientation, this/
# [10:37] * Quits: nvdbleek (~nvdbleek@public.cloak) (Ping timeout: 180 seconds)
# [10:37] * nvdbleek3 is now known as nvdbleek
# [10:38] <dael> heycam: It got on the agenda to disucss the syntax issues. It's in the motion path animation and it's clear we should do that. Not sure who would be drivingthis.
# [10:38] * Ms2ger plinss r? https://github.com/w3c/csswg-test/pull/833
# [10:38] <dael> TabAtkins: Do we have a spec for the SVG stuff as properties?
# [10:38] <dael> heycam: IN the SVG 2 spec, yeah.
# [10:38] <dael> TabAtkins: So put it there. It's a paragraph for the simpliest form. I nominate heycam to write it.
# [10:38] <dael> heycam: Okay.
# [10:39] <dael> heycam: We'll discuss further in SVG.
# [10:39] <dael> krit: We have CSS shapes split to diff specs. Level 1 had circle, ellipse and polygon. Motion path has the path. Can we combine so future spec would reference this one?
# [10:40] <dael> heycam: You want ot move all the shape def into a single spec?
# [10:40] <dael> krit: I'm asking if that would make sense.
# [10:40] <dael> Tav: Where?
# [10:40] <dael> TabAtkins: Shapes.
# [10:40] <dael> astearns: I have an issue in shapes level 2 to add path.
# [10:40] <dael> astearns: We can add it there.
# [10:40] <dael> krit: Sure, that would work for me.
# [10:41] <dael> krit: I want to have it in one spec, I don't care where.
# [10:41] <dael> Tav: Animation between path and shapes is non-trivial. I don't want to create something very complicated.
# [10:41] <dael> heycam: I think that's a sep. decision as to if the new CSS shapes will be used in this.
# [10:42] <dael> krit: The motion spec defines the start point of the motion of the shape.
# [10:42] <dael> Topic: Zoom features for Media Queries
# [10:42] <tkonno> https://lists.w3.org/Archives/Public/www-style/2015Aug/0224.html
# [10:42] <tkonno> http://rawgit.com/satakagi/mediaQueryZoom/master/index.html
# [10:42] <tkonno> http://svg2.mbsrv.net/devinfo/devstd/css-mediaquery-zoom/20150825_zoom_media_features.pdf
# [10:44] <dael> tkonno: Today for the presentation we have the prop for media features for MQ. The two topics are the basic functionality and features.
# [10:44] <dael> tkonno: First is overview of zoom media features. First the e-mail above has a draft spec. This is an overview.
# [10:45] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [10:45] <dael> tkonno: I prop a new feature to control the styles or content to zoom. We prep this to confirm the concept. The goal of my presentation is to get approval to proceed to an ED.
# [10:46] <dael> tkonno: The use cases, we are interested in the mapping using SVG. For mapping, the map is zoomed out and the user wants the overview. On the other hand when the map is zoomed in they want the details such as landmarks.
# [10:46] <dael> tkonno: The generated map consits of the marker areas so if the content switched according to zoom the user can get the appropriate information. It is essential for mapping to switch the content radius accoring to zoom.
# [10:47] * heycam massive.js
# [10:48] <dael> tkonno: Also zoomable high resolution features. This diagram is zoomable. In this case the user the feels tht low res is enough when zoomed out. Then the diagram is zoomed in and they want high res images. These use cases are realized by JS or other then web standard. We'd like to recognize this with web standards.
# [10:48] * Quits: projector_ (~projector@public.cloak) (Ping timeout: 180 seconds)
# [10:48] <dael> tkonno: Assuming these use cases are good, how can we do them? min-zoom is the new feature. In this example, if the ZoomRation is <2.0 the content would be displayed.
# [10:49] <dael> tkonno: The details. I explained the overview, but it is unclear how can we define soom.
# [10:49] <dael> tkonno: We think zoom is in two types. One is UA zoom, which is page and pinch zoom.
# [10:50] <dael> tkonno: The pinch zoom is controlled by the user pinch zoom gesture and it doesn't effect the viewport.
# [10:50] <dbaron> the term "zoom" seems quite overloaded
# [10:50] <dbaron> and I'm not sure what some of these numbers in the slide actually mean
# [10:51] <dael> tkonno: Second is webapps control. They control the scale of the contents. So ZoomRatio should be rep as these parameters (page 8 of slide show)
# [10:51] <dael> tkonno: This formula indicates the relation between the device size and the content size.
# [10:52] <dael> tkonno: This chart (slide 9) corrisponds to the previous formula. There are 6 types of zoom types. I'm not sure all are needed or should be prescribed. From the viewpoint of mapping we need to prescribe #3.
# [10:54] <dael> tkonno: As for the other types of the document zoom, it depends on the use case. So we'd like to prop the document zoom feature. Imagine the use case, the web page has a map in an iframe. The user might zoom the map content, but the user might zoom all content. It can be realized by the CSS transform.
# [10:54] <dael> tkonno: When the webpage is zoomed in using pinch zoom it's the transform. In the case of the map, that should be changed witht he pinch zoom.
# [10:54] <dael> tkonno: As we look back, if you agree with us we'd like to proceed to ED. Thank you.
# [10:55] <dael> Florian: I read the mail, sorry I didn't reply on the list. I think you did a through job of desc how zoom can interact. There's one thing. Can you put back on screen slide 9?
# [10:55] <dael> Florian: Jsut ot be clear, when you're talking about document scale this is when the iframe is being engaleged by a doc arond it. All the zoom you're talking about here is pinch zoom or transforms. That's the major difficulty. having a MQ on pinch zoom changes the game. Normally pinch zoom is magnifying glass and not an opp for re-layout.
# [10:56] <dael> Florian: I don't think this is compat with how browsers do zoom. It's also not clear this is user friendly. YOur cases are places that it can be user in a friendly way, but there are ways that can not be. Thought the model makes sense, that in your examples you had pinch zoom or transforms it makes me think this might not work.
# [10:57] * leaverou_away is now known as leaverou
# [10:57] <dael> Florian: What we can use in MQ is custom MQ. That way the app is control of what it's doing. If you have the +/- it wouldn't be browser supported, but browser assitasted. This wouldn't natively interact with pinch zoom, but you can hook events into doing this. You get less help from the broswer, but you get some. It would be interesting to hear form browser vendors.
# [10:58] <dael> tkonno: It's different then people with impl.
# [10:58] <dael> Florian: From the user's PoV there are many bad ways of doing this. If you do what you had with the map that's fine, but if you re-layout while you pinch that is a bad interaction.
# [10:58] <dael> TabAtkins: We can expose soem events, but doing it directly is weird interaction with the compositor.
# [11:00] <dael> smfr: We agree. We have a posilcy of not exposing pinchzoom for that reason. I think the map examples are deceptive. You could end up devoting too many resources. The author would think you could load high reslution as you zoom in, but it would be for the whole page. IN the map example the author needs more control than responding to a zoom MQ. I don't think this is something we would be interested in.
# [11:00] <dael> dino: It would be difficult to spec what would be used. What labels would interestect etc. You can't do a static dom on a pinch zoom level. There would be a lot of code on every frame.
# [11:00] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [11:01] <dael> Florian: Even though in the general case thsi doesn't work, but in some specialized cases you can have this. yOu can have a custom MQ with JS that could work.
# [11:01] <dael> dino: It could be a case where it makes sense in a containment element that would never re-layout.
# [11:01] <dael> Florian: For some simple examples it might work out.
# [11:01] <dael> dino: You can think of it as another way to do it where instead of different resources you're swapping.
# [11:01] <dael> tantek: Can you get the zoom level in JS?
# [11:02] <dael> dino: Sometimes, depending on the browser.
# [11:02] <dael> tantek: Well what the MQ would be relying on.
# [11:02] <dael> Florian: In a mapping situation with just pinch, you don't instercept a touch event.
# [11:02] <dael> tantek: That's not the question. In maps today they do take over all the mouse events and don't let the browser zoom. What I'mtalking about is there a way for a web page to jsut query.
# [11:03] <dael> iank: Some google maps do this, but it's horrible.
# [11:03] <dael> tantek: I'd argue that if you're interested in this we should do that first and before that a MQ is premature.
# [11:03] * Joins: MozParis (~MozParis@public.cloak)
# [11:04] <dael> MaRakow: This is, it seems you're trying to have a MQ that's the ratio of CSS px to screen px. I would echo the same concern that this isn't going to be only the map in reality. Trying to do this as a MQ imples the switch would be immediate upon crossing that threshold. I think some browsers defer that activity to a later point.
# [11:05] <dael> MaRakow: I think to emulate a native pinch zoom by incresing fidelity I think needs to be more sophisticated. I do think there might be a good case to detect your screen to local CSS px ratio. I can see that, though maybe not as a MQ.
# [11:05] <iank> s/google maps/google apps/
# [11:05] * leaverou is now known as leaverou_away
# [11:05] <dael> ???: There's also an interaction with A11y issues. When I zoom in on a map I do it because I can't see the details. If the details change I'm going to be frustrated. There's a diff between zooming in for details and for what's there.
# [11:06] <liam> s/???/liam/
# [11:06] <dael> tantek: Talking about this in thoery is pointless. The wide variety you could do is incredible. All the paralax stuff added to scroll, for example. We don't have a MQ for scrolling either. I want to keep pushing back and saying no this is premature. Let's start with a simple JS DOM API and see what people build and we can see if there's a pattern in what people build.
# [11:07] <tantek> e.g. http://www.sbs.com.au/theboat/ (parallax example)
# [11:07] <dael> dbaron: It also focuses most on the most global zoom. Many things want to be just this local document zooms and not say someone is in the middle of zooming your be app. Some browsers might use zoom to show it, not the webpage reacting to that.
# [11:08] <dael> Florian: this is an interface that happened in old Opera where you have a zoom out preview of your content and MQ starts making things strange, that doesn't quite work.
# [11:08] <dael> Florian: Being liam's reasons, I'm not even sure the API from tantek is right because even the mag. glass is just ot make things bigger. I'm reluctant to hijack things. There are good things to do here, but I'm hesitant to have the porblems.
# [11:09] <MaRakow> s/going to be only the map in reality/going to be 1:1 with real map scenarios in reality/
# [11:10] * dbaron wonders if we should move on to other items
# [11:10] <dael> liam: There is an analogy to open type fonts. They can remove detail when the font is rendered small. There's precident for this kind of behavior. But you don't change e to w as you zoom, but you can change serif to be flat instead of curved. I could see merit in that for SVG, but the set of use cases is different. That's done partly for making rendering fast. Fetching a network resource would slow things down.
# [11:10] <dael> tantek: Thats' what google maps do.
# [11:10] <dael> Rossen: This is almost like saying you shouldn't do xhr based on user interaction. It's overstating.
# [11:10] <SimonSapin> leaverou_away, Skia has SkTwoPointConicalGradient but Direct2D apparently only has gradient mesh since Windows 10 https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/D2DGradientMesh
# [11:10] <dael> tantek: Authors can do stupid thing, that's not a for or against.
# [11:11] <dael> zcorpan: For the high resolution use case, there's a source for the x decriptor. When the user zooms in the browser can load high resolution?
# [11:11] <dael> Florian: And that works better than MQ. The trigger points for MQ are basic. The logic for SourceSet approach is left to the browser and it can be smart.
# [11:11] <heycam> s/a source/srcset/
# [11:12] <dael> zcorpan: So if you start zoom in and you load the high image, there's no reason to download the low resolution.
# [11:12] <dael> Florian: And in MQ if you go up and down it reloads every time.
# [11:12] * krit SimonSapin SkTwoPointConicalGradient are still normal radial gradients IIRC
# [11:12] <dael> ed_paris__: It seems the group doesn't agree with publishing. Do we want to resolve?
# [11:13] <dael> heycam: It sounds like starting with JS API to expose zoom levels and events when zoom level changes.
# [11:13] * krit SimonSapin Just that the focal point and center point can be different
# [11:13] * krit SimonSapin so normal SVG radial gradients :)
# [11:13] <dael> Rossen: Yes. That is an old discussion we had in Shenzen (sp) where there was a spec that was supposed to be written by various members of the group and this didn't go well.
# [11:14] <dael> Rossen: I think this is something that comes up more and more. WE better get this spec done and doc the different zoom types and then expose some minimal OM hooks so that people who care can build.
# [11:14] <dael> dino: One thing that put me off it is any time the topic was brought up the response we we agree and you should do it our way. So maybe we should agree that we should come up with a new way.
# [11:15] <dael> Rossen: I think theres'a strong signal that we need something.
# [11:15] <dael> Florian: In terms of exporing the different types, today's proposal does a good job of looking at the different types and how they interact.
# [11:15] <dael> tantek: Rossen I'm not seeing the strong signal that you are.
# [11:16] <dael> tantek: which is why I'm advoacting for the JS API for people to experiment and develop us cases.
# [11:16] <dael> Rossen: JS API is fine, I wasn't suggesting anything.
# [11:16] <dael> dbaron: What Rossen is saying is before we have the API we should have a list of what the different types of zoom are and we don't have it.
# [11:16] <Florian> s/types/types of zoom/
# [11:16] <dael> Rossen: In our impl we've been trying to reduce the crazy things we were trying to do before.
# [11:17] <tantek> also, zoom property?
# [11:17] <tantek> are you (Rossen) going to drop that?
# [11:17] <dael> Rossen: I proposed a spec in the NY F2F on the zoom property.
# [11:17] <dael> smfr: I was waiting on you for sites that do that.
# [11:17] <dael> shane: I've collected data.
# [11:18] <dael> Rossen: There were very few sites using zoom. There was one site trying to use zoom for some really weird reason and getting lucky, but as soon as you throw in different API and other user settings, it was a mess.
# [11:18] <dael> birtles: Before we get on the zoom prop, can we tie up the previous conversation?
# [11:19] <dael> birtles: What is lacking in the current analysis of the zoom types?
# [11:19] <dael> dbaron: In that doc? I couldn't understand the types so I couldn't map.
# [11:19] <dael> birtles: So we need more data?
# [11:19] <dael> tantek: Is that doc in IRC?
# [11:19] <dael> several: yes
# [11:20] <dael> birtles: I wasn't sure what use cases are lacking? The prop isn't abstract, it is for maps they want to use it for.
# [11:20] <dael> dbaron: I think a lot of people are saying this is not a good way to do maps.
# [11:21] <dael> birtles: I'd be curious for a way ahead. KDD was looking at picutres with media attr and I think that's where MQ entered the equasion. I htink it's clear that MQ in the general case isn't for this. I think high resolution photography use case isn't clear. You have low and high res and want to break up the tiles so just source doesn't address that.
# [11:21] <dael> hober: Once you start talking tiles it's custom.
# [11:21] <dael> tantek: Tiling is hte abstract that covers maps and these photos.
# [11:21] <tantek> s/abstract/abstraction
# [11:22] <dael> birtles: They had some use cases covering this type of feature. I think it's clear that MQ isn't the way forward. There's more forward and for the tiles which is the way forward.
# [11:22] <dael> ed_paris__: Do we need a formal conclusion?
# [11:22] <dael> ed_paris__: I think that was the last FX topic?
# [11:23] <dael> <break=15min(ish)>
# [11:23] * Joins: ChrisL (clilley@public.cloak)
# [11:23] <birtles> s/KDD was/KDDI was/
# [11:23] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [11:23] * Quits: smfr (~smfr@public.cloak) (smfr)
# [11:23] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [11:29] * Quits: cyril (~cyril@public.cloak) (Ping timeout: 180 seconds)
# [11:30] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [11:32] * Quits: Tav (~tbah@public.cloak) (Ping timeout: 180 seconds)
# [11:32] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [11:36] * Joins: BogdanBrinza (~bbrinza@public.cloak)
# [11:37] * Quits: ed_paris__ (~ed@public.cloak) (Ping timeout: 180 seconds)
# [11:39] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [11:40] * Joins: Tav (~tbah@public.cloak)
# [11:41] * Joins: Florian (~Florian@public.cloak)
# [11:43] <fantasai> ACTION fantasai to add note about baseline-table property
# [11:43] * trackbot is creating a new ACTION.
# [11:43] <trackbot> Created ACTION-717 - Add note about baseline-table property [on Elika Etemad - due 2015-09-03].
# [11:44] * Joins: smfr (~smfr@public.cloak)
# [11:49] * Joins: ed_paris__ (~ed@public.cloak)
# [11:49] * leaverou_away is now known as leaverou
# [11:49] <SimonSapin> leaverou, Skia has SkTwoPointConicalGradient but Direct2D apparently only has gradient mesh since Windows 10 https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/D2DGradientMesh
# [11:50] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [11:53] * Joins: ChrisL (clilley@public.cloak)
# [11:53] <leaverou> shans: TabAtkins: Check out SimonSapin’s message above. Skia does support conical gradients it seems.
# [11:55] * Joins: tkonno_ (~chatzilla@public.cloak)
# [11:55] * Quits: tkonno_ (~chatzilla@public.cloak) ("ChatZilla 0.9.92 [Firefox 40.0.2/20150812163655]")
# [11:56] * Quits: tkonno (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [11:58] * Joins: tkonno (~chatzilla@public.cloak)
# [11:59] <dael> plinss: Let's get started.
# [11:59] <TabAtkins> leaverou: kk, so we need to see if CoreGraphics has the necessary primitive too
# [12:00] <dael> Topic: writing-modes
# [12:00] <dael> Topic: Selectors
# [12:01] <fantasai> https://drafts.csswg.org/selectors-4/
# [12:01] * Joins: MaRakow (~MaRakow@public.cloak)
# [12:01] <dael> fantasai: We need to pub an update. I finished going through allthe changes. There's a few TabAtkins and I don't agree on. There's also a bunch of issues we want to clear out. I'll start with issues.
# [12:01] <fantasai> https://drafts.csswg.org/selectors-4/#issues-index
# [12:01] <fantasai> https://drafts.csswg.org/selectors-4/#issue-eb31bbbc
# [12:02] <tantek> fantasai: minor editorial edit: s/www.tantek.com/tantek.com - thanks!
# [12:02] <dael> fantasai: 1st issue is #4 which is we have 2 syntaxes for :before, after, first-line and first-letter. There's single and double colon and right now we don't say which. TabAtkins wants a req. on authors that they should us ::. That means a validator of CSS should throw an error with single colon.
# [12:03] <dael> TabAtkins: I think it's good to call single color to depricate is authors have no clude between pseudo class and element and it's highly exasperated with the single colon syntax. let's make sure the rec syntax is double.
# [12:03] <dael> rachelandrew: I'd agree.
# [12:03] <dael> fantasai: Other opinions?
# [12:03] <tantek> yes let's fix it!
# [12:03] <TabAtkins> s/color/colon/
# [12:04] <dael> zcorpan: I think it's slightly a case where it generates warnings from validators for something that works fine. It doesn't make them understand the difference better.
# [12:04] <dael> TabAtkins: Depends on how much you want to change a validator for this will break you or one for linting. That's personal opinion and what you codein your validator.
# [12:04] <dael> hober: Nothing stops validators for warning about single colon.
# [12:05] <dael> TabAtkins: There's nothing presenting a validator today from saying you shouldn't use single and nothing making a validator do it tomorrow.
# [12:05] <dael> fantasai: But saying what an author should do informs the validator.
# [12:05] <dael> tantek: Should not must?
# [12:05] <dael> fantasai: Def. There's a reason for the single which is if you have to support really down level.
# [12:05] <Ms2ger> I don't think the validator should warn, that just makes it less useful for authors
# [12:05] <dael> tantek: I'm fine. If you'd like you can include suggested validator text. I think it would lower the barrier to have it show up.
# [12:05] <dael> TabAtkins: Okay. I can do.
# [12:06] <TabAtkins> Ms2ger: That's for validators to decide, shrug.
# [12:06] <dael> fantasai: So Ms2ger says he doesn't want the validator to warn because it dilutes the real errors.
# [12:06] <TabAtkins> Like I said, "this is a problem" validators vs linters.
# [12:06] <dael> plinss: I'm not hearing strong opinions.
# [12:07] <dael> plinss: I'd say, the old syntax was depricated 15 years ago and we should put the recommendation in to not use them.
# [12:07] <plinss> s/opinions/objections/
# [12:07] <dael> RESOLVED: put a should recommendation in for authors to use the double colon not the single colon.
# [12:07] <fantasai> https://drafts.csswg.org/selectors-4/#issue-99d9962ehttps://drafts.csswg.org/selectors-4/#issue-99d9962e
# [12:07] <fantasai> https://drafts.csswg.org/selectors-4/#issue-99d9962e
# [12:08] <dael> fantasai: Next issue is this. It's about pseudoclassing pseudo elements. If you have a pseduo element, in the past that was the end of your selector. yOu couldn't select anything special about that. We're prop in level 4 to allow user action pseudoclasses to match against pseudo elements.
# [12:09] <dael> fantasai: If I use :hover ::first-line that will match whenever the text is hovered it highlights, but ::first-line :hover will only highlight if you hover. over the first line.
# [12:09] <dael> tantek: Why useful?
# [12:09] <dael> TabAtkins: Before hover, being able to use the pseudo class on the element.
# [12:09] <dael> tantek: What case of generated content before you hover?
# [12:09] <dael> fantasai: He wants a specific.
# [12:10] <dael> plinss: There's a use case on the IRC. If you hover before the line the click handler pops up.
# [12:10] <dael> fantasai: The element in the DOM, why isn't it...why can't you use :hover on that element.
# [12:10] <dael> TabAtkins: You can't for the same reason you can't on the parent of any child. It's too large.
# [12:11] <tantek> you're using generated content to create UI?!? Ok I'm out.
# [12:11] * tantek SMH.
# [12:11] <dael> fantasai: For his case it's a click target. You're clicking on the before pseudo.
# [12:11] <dael> TabAtkins: For the UI think your doing it's the before that's important.
# [12:11] <dael> hober: The only reason is because you can't put it directly on the pseudo.
# [12:12] <dael> fantasai: But you can put it on the target. If the click target is visible somewhere else and you've got a before somewhere else, you might want to highlight if either are being hovered.
# [12:12] <plinss> http://log.csswg.org/irc.w3.org/css/2015-08-27/
# [12:12] * leaverou is now known as leaverou_away
# [12:12] <dael> plinss: Right now if you look at the IRC log, if you hover over the # at the beginning you get the flag.
# [12:12] * leaverou_away is now known as leaverou
# [12:12] <dael> plinss: Ideally the flag should show when you hover over the flag, not the thing next to it.
# [12:13] * tantek Florian you think this is a good idea?
# [12:13] <dael> fantasai: To the point where we don't have click event handling it doesn't make sense....we should fix them together unless someone has another use case.
# [12:13] <dael> plinss: First-line and first-letter are also useable. There will be more pseudo elements.
# [12:13] * Quits: jihye (~jihye@public.cloak) (Ping timeout: 180 seconds)
# [12:14] <dael> fantasai: It's additional stuff to impl and we might as well wait until it's useful to impl, i think that's tantek point.
# [12:14] <dael> tantek: Encouraging people to build UI of generated content is a mistake.
# [12:14] <dael> tantek: You're lowering the barrier so you are.
# [12:14] <dael> TabAtkins: It's already used widely.
# [12:14] <dael> plinss: I don't htink it' smore of a layering violation. There's lots of UI dependant on the presentation. It's not more then generated content.
# [12:15] <dael> tantek: Generated content is different.
# [12:15] * Florian I am not opposed to it in general, but the specific use case brought up here is weak. Real, but weak. I am not so worried about the layering violation here.
# [12:15] <dael> plinss: There's bits of the UI that will differ depending on if they want to show.
# [12:15] <dael> tantek: That's decorative.
# [12:15] <dael> Bert: The region spec at some point could style regions, but I think it's not there anymore. It might need the same mech.
# [12:16] <dael> fantasai: The latest idea is, we shifted a rough desc into Scoping module. The plan is to contiune and use the same mech for styling pages and fragement and regions. They should share the same syntax. We haven't fleshed that section out.
# [12:16] <dael> fantasai: Any opinions to add?
# [12:16] <dael> Florian: Even if you're not doing interacting UI bits, it's useful to have little bits of decoration. I don't see it as critical.
# [12:17] <dael> fantasai: Does anyone here want to impl in the next 2 years? We're at the point that we need to trim to impl or imminently impl.
# [12:17] <dael> gregwhitworth: I see the use case, but I can't stand before and after.
# [12:17] * Joins: johanneswilm (~johannes@public.cloak)
# [12:18] <dael> dbaron: I see tantek point, but I think there are other elements where we want the pseudo-classes. I'm trying to figure out what gecko does right now. I think we support some.
# [12:18] <Bert> -> https://drafts.csswg.org/css-template/#select-after-pseudo Some musings on styling content (incl. other elements) inside pseudo-elements.
# [12:18] <dael> gregwhitworth: I think we should bust hte two apart.
# [12:18] <dael> dbaron: I think it would be nice if the selectors module provided a mech for pseudo elements to have pseudo classes, but we should apply to before or after.
# [12:18] <dael> tantek: or first letter and first line.
# [12:19] <dael> esprehn: We'd rather pseudo elements were exposed as events first than add new selector features.
# [12:19] * leaverou is now known as leaverou_away
# [12:19] <dael> tantek: I agree with dbaron scoping. For pseudo elements trying to address pieces of UI in the doc that makes sense.
# [12:19] <fantasai> https://drafts.csswg.org/selectors-4/#pseudo-element-states
# [12:19] * leaverou_away is now known as leaverou
# [12:19] <dael> fantasai: The section we're discussing is this^ which allows for specific pseudo elements to say specific pseudo classes apply to them.
# [12:20] <dael> fantasai: I'm hearing we should keep this but remove the statement in :hover that it applies to everything.
# [12:20] <dael> tantek: I'd restrict to a pseudo that's accessing a piece of UI.
# [12:20] <dael> fantasai: That's a guideline we can use when writing.
# [12:20] <dael> tantek: I'm saying it should be in that intro paragraph to provide guidance.
# [12:21] * Joins: jihye (~jihye@public.cloak)
# [12:21] <dael> fantasai: So I'm hearing we should keep the section overall, add guidance to people developing new pseudo elements as to if they should accept user action pseudo classes and remove the statement from :hover that it applies to all
# [12:21] <dael> TabAtkins: The only one it will apply to are the undefined pseudo that people build.
# [12:21] <dael> RESOLVED: keep the section overall, add guidance to people developing new pseudo elements as to if they should accept user action pseudo classes and remove the statement from :hover that it applies to all
# [12:22] <dbaron> Gecko supports pseudo-classes on :-moz-number-wrapper, :-moz-number-text, :-moz-number-spin-box, :-moz-number-spin-up, :-moz-number-spin-down, :-moz-progress-bar, :-moz-range-track, :-moz-range-progress, :-moz-range-thumb, :-moz-meter-bar, :-moz-placeholder, and :-moz-color-swatch.
# [12:22] <dael> fantasai: Next is, we're allowing in general pseudo elements to take things like :hover and :focus. If that pseudo element doesn't support that pseudo element, does that make the syntax invalid?
# [12:22] <dael> fantasai: As a syntax error, or never match?
# [12:22] <dael> zcorpan: It seems to me better to not match. That allows you to have a group of selectors.
# [12:22] <dael> dbaron: The current is it's a syntax error.
# [12:23] <dael> dbaron: The question is do we want to change it from being a syntax error to not being one.
# [12:23] <dael> Florian: Can we?
# [12:23] <dael> dbaron: We could if we wanted to, but I'm inclinded it's better to not.
# [12:23] <dael> tantek: We only should if we have a good reason.
# [12:23] <dael> fantasai: Pseudo element and pseudo class combos are invalid.
# [12:23] <dael> TabAtkins: They're invalid or they don't match, that's what we're deciding on.
# [12:24] <dael> RESOLVED: Pseudo element and pseudo class combonations are invalid unless defined to be a valid thing that could potentially match something
# [12:24] <dael> TabAtkins: There is a sub issue of that
# [12:24] <dael> fantasai: ::fist-line :not :focus?
# [12:24] <dbaron> (this resolution is for pseudo-classes *on* pseudo-elements)
# [12:24] <dael> fantasai: Given what we resolved that's invalid.
# [12:24] <fantasai> ::first-line:not(:focus)
# [12:25] <dael> TabAtkins: If you're accepting any pseudocall on a pseudo element, should we require accepting the inherent...[missed]
# [12:25] <dael> fantasai: :not and :matches should be corrilated to if it matches that element.
# [12:25] <dael> TabAtkins: If it accept :hover shoudl we require it accepts :not and :matches.
# [12:26] <dael> fantasai: As long as the contents of :not and :matches are valid indepentaly. This is a bug fix.
# [12:26] * fantasai just assumed this was fallout from the previous resolution
# [12:26] <dael> dbaron: It's fine with me, though it's not what we do now. It shouldn't be hard. Is it well defined what happens if you say pseudo element :not p?
# [12:26] <dael> TabAtkins: Yes, they don't have names.
# [12:27] <dael> dbaron: If the pseudo element is on a p element, is that invalid, valid but not matching?
# [12:27] <dael> fantasai: The first.
# [12:27] <dael> dbaron: I don't care about what the answer is, I just care what the answer is.
# [12:27] <dael> TabAtkins: So it doesn't match.
# [12:27] <dael> fantasai: We ned to make sure it's invalid.
# [12:27] <dbaron> s/just care/just care that the spec says/
# [12:27] * fantasai invalid all the things!
# [12:28] * zcorpan doesn't follow why it wouldn't match
# [12:28] <dael> TabAtkins: We can do that too. I'm happy to do it either way so we only allow use of the valid pseudos. If we do that it's minimum insertion of abilities.
# [12:28] <fantasai> zcorpan, the pseudo-element is not the originating element
# [12:28] <fantasai> they're bound, but not the same
# [12:28] <dael> TabAtkins: The syntatic pseudo classes are allowed we will make them only valid when they contain only pseudo classes that are valid in that context.
# [12:28] <dael> fantasai: :not and :matches. :has is not allowed.
# [12:28] <zcorpan> fantasai: yeah, and :not negates the result
# [12:29] <dael> RESOLVED: syntatic pseudo classes are allowed we will make them only valid when they contain only pseudo classes that are valid in that context for :not and :matches.
# [12:29] <fantasai> https://drafts.csswg.org/selectors-4/#pseudo-element-structure
# [12:29] * TabAtkins zcorpan: If ::before.foo is invalid, then ::before:not(.foo) should probably be invalid too.
# [12:29] <dael> fantasai: If you scroll down to this section ^ we define that some pseudo elements have an inherit structure and theresfore may be followed by child. They are otherwise invalid. This is why :has needs to be invalid in the above.
# [12:30] <dael> TabAtkins: Okay. I don't feel strongly.
# [12:30] <dael> dbaron: I agree with fantasai
# [12:30] <dael> TabAtkins: Sure.
# [12:30] <dael> TabAtkins: I get the distinction, I just like keeping the three together. I'm okay with it.
# [12:31] <dael> fantasai: The reason we added this expansion is becuase the ::shadow requires it. Also the things for ::page ::region and ::fragment also req. this syntax so we were opening it up for those to be defined. Also defining that these will be invalid with decendant combinators.
# [12:31] <dael> fantasai: Does that all work for everyone?
# [12:31] <Florian> wfm
# [12:32] <hober> s/decendant/descendant/
# [12:32] <dael> fantasai: So behavior defined for combinators after pseudo elements as writting in the pseudo spec is okay.
# [12:32] <dael> fantasai: And we need to clarify that :has and those pseudo elements should also accept :has.
# [12:33] <dael> TabAtkins: If any simple selector accept a given type of selector it must also accept :not and :must. If it has a combinator after it it also must accept :has:
# [12:33] <dael> RESOLVED: If any simple selector accept a given type of selector it must also accept :not and :must. If it has a combinator after it it also must accept :has:
# [12:33] <dael> RESOLVED: behavior defined for combinators after pseudo elements as writting in the pseudo spec is okay.
# [12:33] <TabAtkins> s/:must/:matches/
# [12:34] <leaverou> what about ::attr():hover? Invalid or not matching?
# [12:34] <dael> tantek: Since you brought up content, do we have any way of selecting an element based on its content?
# [12:34] <dael> fantasai: no.
# [12:34] <dael> TabAtkins: deliberatly omitted. If you look at selectors 3 there's a black section that removed the :content.
# [12:34] <dael> fantasai: We have ::content and if we add that back we have :content with parens.
# [12:35] <dael> TabAtkins: Let's not re-open naming discussions.
# [12:35] <TabAtkins> leaverou: In the absence of a spec defining it as valid, it's invalid.
# [12:35] <dael> tantek: It couldn't have began with shadow to distinguish?
# [12:35] <leaverou> http://www.w3.org/TR/selectors-nonelement-1/
# [12:35] <dael> fantasai: There's two types of elements. real you can select with tags and they can have attr and types?
# [12:35] <tantek> e.g. ::shadow-content since it applies specifically ONLY to shadow projected content
# [12:36] <dael> TabAtkins: Unless specifically allowed, they're disallowed.
# [12:36] <fantasai> yeah, we discussed it, came up with several options, and Blink didn't want to rename 'coz they'd shipped
# [12:36] <dael> Florian: Everything is opt in.
# [12:37] <dael> tantek: The reason I asked is I was trying to come up with contridictions to not putting pseudoclass after pseudo element. The one that's useful is some kind of content on first-letter. I previously prop this as parenthetical syntax.
# [12:37] <dael> fantasai: That seems like a reasonable request, but it would go against psedo elements spec. WE split pseudo elements from selectors because they're specific to CSS.
# [12:37] <dael> fantasai: Throw an e-mail onto the ML and we'll track it.
# [12:38] <tantek> specific example: ::first-letter("A") to select first letters when they're an "A"
# [12:38] <dael> fantasai: We have an issue on naming :any-link Unless there's suggestions we should close it and ship.
# [12:38] <dael> Florian: Hasn't it shipped?
# [12:38] <tantek> pretty sure I've proposed that in the past (like many years ago)
# [12:38] <dael> fantasai: Prefixed in Moz, I think.
# [12:38] <dael> Florian: I'm fine as-is.
# [12:38] <dael> fantasai: Anybody else?
# [12:39] <dael> RESOLVED: close issue on naming :any-link because there's no better ideas
# [12:39] <dael> fantasai: Next is about :user-error pseudo class. Has anybody impl unprefixed?
# [12:39] <dael> TabAtkins: We have not.
# [12:39] <SimonSapin> Servo implements :any-link, but it might not count as "shipping"
# [12:39] <dael> fantasai: Moz calls it moz-ui-invalid
# [12:39] <dael> smfr: Nope.
# [12:39] <dael> gregwhitworth: I don't think we do.
# [12:42] <TabAtkins> SimonSapin: No, Servo doesn't count as a shipping implementation yet.
# [12:42] <dael> fantasai: It was raised we should add the moz-ui-invalid pseudo class. It is taking from the pseudoclass in moz. It's only if you try and submit the form that it turns red. It has a certain statefulness. :invalid is still useful for JS, but the uI wants statefulness if the user has interacted. moz-ui-valid is the opposite if the user has interacted and it's valid
# [12:42] <dael> fantasai: :user-error we had because we were incorp valid and omission. You could be valid but an empty form control that was omitted. If we want valid it should be paralel naming. I can't think of something that would match user-error. Does anybody have an answer or we can rename to user-invalid and add user-valid
# [12:42] <fantasai> https://drafts.csswg.org/selectors-4/#issue-baf555b0
# [12:42] <dael> dbaron: One data point is we have this valid selector and we have no uses outside of tests. Our user stylesheet uses invalid.
# [12:42] <dael> TabAtkins: I've seen this in the wild. It' smore usual to not do something for the valids, but it's done.
# [12:43] <dael> tantek: It's rare, but it's the better practice to show that things are correct.
# [12:43] <fantasai> tantek: It's like carrot vs. stick gamification of forms
# [12:43] <dael> Florian: If this is useful pattern and moz has the tool, are people not using it because they don't know, because it's only moz, or because it doesn't do quite what they want?
# [12:44] <dael> fantasai: I don't know. We can not add it in this level, but we intend to add it, we want the names as a pair.
# [12:44] * MaRakow :user-get-carrot
# [12:44] <dael> fantasai: Either somebody comes upw ith a new name or we rename to user-invalid and ship that in this level.
# [12:44] <dael> Florian: I don't have a strong pref between the two. The distinction is too small to be noticed.
# [12:44] * zcorpan :user-hit-with-a-stick
# [12:45] <dael> RESOLVED: rename :user-error to :user-invalid
# [12:45] * Florian :user-good-job :user-insert-coin-and-try-again
# [12:45] * MaRakow :wg-gets-lunch
# [12:45] <dael> fantasai: So do you want us to add user-valid to this level, or next level?
# [12:45] <dael> tantek: We have an impl.
# [12:46] <dael> dbaron: It's worth being clear about what it means. Does it mean...is user valid the same as...is it a time when we would have marked it as user-invalid, but it's valid.
# [12:46] <dael> TabAtkins: The same criteria for when we would start using user-invalid would be for user-valid.
# [12:46] <dael> Florian: Does that match impl?
# [12:46] <dbaron> we also have a separate :-moz-submit-invalid for controls (button, input type=button) that would submit the form
# [12:46] <dael> fantasai: Prob. close enough.
# [12:46] * ChrisL user:irrigation
# [12:47] <dael> fantasai: Our criteria in the spec is looser. You have to do it between these two times, you can do it ourside these times.
# [12:47] <dael> Florian: Maybe we'll require later.
# [12:47] <dbaron> although :-moz-submit-invalid appears to predate :-moz-ui-invalid and :-moz-ui-valid
# [12:47] <dael> fantasai: Yes, for now we're leaving it out so UA can represent their best.
# [12:47] <dbaron> (it comes from https://bugzilla.mozilla.org/show_bug.cgi?id=580575)
# [12:48] <dael> Florian: So should it be at risk?
# [12:48] <dael> fantasai: both should be.
# [12:48] <dael> RESOLVED: add :user-valid, mark :user-valid and :user-invalid as at-risk
# [12:48] <fantasai> https://drafts.csswg.org/selectors-4/#the-blank-pseudo
# [12:48] <dbaron> (seems like :-moz-submit-invalid used to be in our UA sheet but no longer is)
# [12:48] <dbaron> (or maybe it never was)
# [12:49] <dael> fantasai: Next is on :blank. We have :empty that selects if an element is completely empty. If you have an element that's effectively empty, like if you have a <p> with white space inbetween and it's going to be empty for all general purposes. There's no way to select that because they show as not empty.
# [12:50] <dael> fantasai: We added :blank, but it might imply that it's for things that should be filled out so the name isn't great. There's change empty to also match thigns with white space or call it :no-content. So change def of :empty to accept whitespace. Rename :blank or drop.
# [12:50] <dael> TabAtkins: The pref is the first one to redefine. Will there be compat problems?
# [12:50] <dael> zcorpan: We need to research.
# [12:50] <dael> dbaron: It's hard to know. I thinkthe most likely compat problem comes from people who wrote it in their stylesheet, it didn't work, and they left it.
# [12:51] <dael> TabAtkins: For now we leave an issue in the spec that impl are experimenting with change :empty to also match CSS whitespace and drop the other suggestions for now and we'll finish with data later.
# [12:52] <dael> Florian: I'm not sure we don't want both. If you do whitespace pre or something these will show up. If you know I have things that only have whitespace, you might want to decide if you select these things.
# [12:53] <dael> fantasai: You can't select things that only have whitespace. YOu can select nothing or stuff. I thinkt he case of whitespace pre isn't used a lot. That's basically code blocks and I can't see this being used for stuff inside codeblocks. This doesn't seem a common usecase.
# [12:53] <dael> Florian: I meant not matching on clodeblocks.
# [12:53] <dael> TabAtkins: So write your selector ot not match those elements.
# [12:54] <dael> fantasai: You're more likely to want this on table elements. So highlight all the empty table elements to style as empty. table elements have an optional close tag and your selector won't work.
# [12:54] <dael> esprehn: Authors already assume it works this way and their pages are broken.
# [12:54] <dael> fantasai: Once we fix this they'll work as intended. Our fear is they have been designed past.
# [12:54] <dael> RESOLVED: drop :blank
# [12:55] <dael> fantasai: We should resolved ot change the spec to trigger on white space and we're waiting on compat data
# [12:55] <dael> RESOLVED: change the spec so :empty to trigger on white space and we're waiting on compat data
# [12:55] <dael> tantek: I thought we tried to change this and we failed.
# [12:56] <dael> fantasai: I think the group was more adverse to changing existing spec. It might not have to do with content.
# [12:56] <dael> tantek: If we can do it, sure, but I'm skeptical.
# [12:56] <dael> TabAtkins: We'll tell you if it works.
# [12:56] <dael> dbaron: I'm skeptical too.
# [12:57] <dael> Bert: What's your def of fix.
# [12:57] <dael> TabAtkins: Growing the web platform is bad. We can change legacy.
# [12:57] <dael> Bert: You can start over.
# [12:57] <dael> TabAtkins: That's growing.
# [12:57] <dael> TabAtkins: We can review what to cut after lunch. We'll cut up the cut and keep.
# [12:57] <dael> plinss: Have we published a FPWD of this?
# [12:57] <leaverou> "Growing the web platform is bad. We can change legacy." THIS. Yes!
# [12:57] <dael> fantasai: We have.
# [12:58] <dael> plinss: I'm not finding it.
# [12:58] <fantasai> http://www.w3.org/TR/selectors4/
# [12:58] <dael> dbaron: It's /selectors4
# [12:58] <dbaron> http://www.w3.org/TR/selectors4/
# [12:58] <dbaron> http://www.w3.org/TR/2013/WD-selectors4-20130502/
# [12:58] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [12:58] <dbaron> previously http://www.w3.org/TR/2012/WD-selectors4-20120823/ and http://www.w3.org/TR/2011/WD-selectors4-20110929/
# [12:58] <zcorpan> i see 32,464 matches for :empty in text/css files in httparchive
# [12:58] <dael> plinss: So some discussion over lunch, after lunch we'll decide if we publish or not.
# [12:58] * Quits: smfr (~smfr@public.cloak) (smfr)
# [12:59] <dael> [lunch break]
# [13:00] <dael> dbaron: Did you fix the what counts as white space? We had a similar problem with first-letter. I went through and no one matched.
# [13:00] <dael> TabAtkins: I can reference the rec spec.
# [13:00] <dael> [lunch break for realz]
# [13:05] * Rossen is now known as Rossen_away
# [13:08] * Joins: smfr (~smfr@public.cloak)
# [13:08] * Quits: jihye (~jihye@public.cloak) (Ping timeout: 180 seconds)
# [13:09] <fantasai> s/cut up/write up/
# [13:10] <fantasai> Tantek just noted that the trigger times for :user-invalid and :user-valid should be different
# [13:10] <fantasai> So we need to make sure the spec allows for that (i.e. doesn't bind them together)
# [13:11] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [13:17] * Quits: smfr (~smfr@public.cloak) (smfr)
# [13:19] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [13:20] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [13:20] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [13:23] * Quits: tantek (~tantek@public.cloak) (tantek)
# [13:25] * Joins: smfr (~smfr@public.cloak)
# [13:28] * Joins: johanneswilm (~johannes@public.cloak)
# [13:29] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [13:31] * heycam is now known as heycam|away
# [13:34] * Joins: bkardell_ (~uid10373@public.cloak)
# [13:36] * Joins: hgl (~hgl@public.cloak)
# [13:37] <bkardell_> Present +bkardell_ :)
# [13:37] * Quits: hgl_ (~hgl@public.cloak) (Ping timeout: 180 seconds)
# [13:37] * heycam|away is now known as heycam
# [13:39] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [13:44] * Quits: ed_paris__ (~ed@public.cloak) ("Leaving")
# [13:51] * Quits: skk (~skk@public.cloak) (Client closed connection)
# [13:52] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [13:52] * Joins: skk (~skk@public.cloak)
# [13:54] <zcorpan> afaict the most common usage of :empty, from looking at a few at random, is from bootstrap: https://github.com/twbs/bootstrap/search?utf8=✓&q=%3Aempty which presumably won't break with the proposed change
# [13:55] * Joins: ChrisL (clilley@public.cloak)
# [13:56] <liam> isn't the potential breaking case where :empty was used erroneously & didn't match, but now will start matching?
# [13:57] <zcorpan> liam: yeah
# [14:00] * Quits: smfr (~smfr@public.cloak) (smfr)
# [14:01] <zcorpan> excluding "bootstrap" leaves 16,624 matches for :empty
# [14:05] * Joins: smfr (~smfr@public.cloak)
# [14:05] * Quits: smfr (~smfr@public.cloak) (smfr)
# [14:05] <liam> that doesn't sound huge unless they're on major sites, but maybe major sites would fix the problem
# [14:07] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [14:09] * Joins: smfr (~smfr@public.cloak)
# [14:10] * Joins: MaRakow (~MaRakow@public.cloak)
# [14:16] <dael> plinss: Let's start up.
# [14:17] <dael> Topic: selectors
# [14:17] * Joins: Florian (~Florian@public.cloak)
# [14:17] * bkardell_ I like them, let keep them
# [14:19] * Joins: tantek (~tantek@public.cloak)
# [14:19] * astearns bkardell_ http://1.bp.blogspot.com/-SRf_tuCALSE/Vd7uwDfVjyI/AAAAAAAAA2g/mnlynYPlgwc/s1600/NO-www-scarfolk-blogspot-com.jpg
# [14:20] <bkardell_> astearns lol
# [14:20] <dael> fantasai: We wanted to go over the features we want to keep vs defer and make the edits.
# [14:21] <tantek> present+ tantek
# [14:21] <dael> fantasai: We're def keeping everything in L3. We're keeping the case insenetive :matches, :not :dir and lang. Any-link. user-invalid we're keeping
# [14:21] * Joins: MaRakow_ (~MaRakow@public.cloak)
# [14:21] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [14:21] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [14:22] * Joins: jihye (~jihye@public.cloak)
# [14:22] <dael> tantek: We want to allow different tirgger points for user valid and invalid. From a user presepctive you wait to wait for the user to leave for user-invalid, but for user-valid it's a more friendly experience to have it turn green as you type. We should undo the decsion to keep the triggers to same and instead give flexibility and guidance.
# [14:22] <dael> Florian: We might want the same definition where you can be flexible.
# [14:22] <dael> Florian: The current definition doesn't say where it is.
# [14:23] <dael> tantek: We souldn't say it should be the same. We should provide guidance that they should be different because it better guides.
# [14:23] <dael> tantek: I have no idea how to select an input element that's empty vs has one that a user has selected.
# [14:23] <dael> dbaron: We've talked about it but it's abstract
# [14:23] <gregwhitworth> input:not(:empty)
# [14:23] <dael> tantek: You can't use attr selector because the user is typing.
# [14:24] <gregwhitworth> input:not():empty
# [14:24] <dael> fantasai: (:value=token)
# [14:24] <gregwhitworth> ^^lol
# [14:24] <dael> tantek: Does an impl have a prefix to select empty vs not empty?
# [14:24] <dael> fantasai: So prob not this level, but it should be level 5.
# [14:24] <dael> tantek: I just want to make sure this gets in the minutes.
# [14:24] <dbaron> s/(:value=token)/[:value=token]/
# [14:25] <dael> action fantasai add value selector to level 5
# [14:25] * trackbot is creating a new ACTION.
# [14:25] <trackbot> Created ACTION-718 - Add value selector to level 5 [on Elika Etemad - due 2015-09-03].
# [14:25] <tantek> request: a way to select an input element that has a value or not or has a specific value (:empty doesn't apply since input is always an empty element, and [value] selector applies to static attribute, not what the user has typed in)
# [14:25] * zcorpan tantek: what's the use case?
# [14:25] <dael> fantasai: We have :drop pseudo class and I think moz has a prefix subset of the functionality. Are other people interested in impl?
# [14:25] <dael> TabAtkins: Moz has a selection of them with some type of names. I forget if we do have a version in webkit.
# [14:26] <dael> Florian: I think we went back and forth on semantics. If we're sure we have the right one and there's impl, it's fine to keep, poss. at-risk. If we're not sure it's maybe level 5.
# [14:26] <dael> fantasai: We have a function syntax that lets you select active, valid and invalid drop target.
# [14:27] <dael> tantek: Does this include items that are so covered you can't drop in invalid? And is can drop determind the way of hit testing?
# [14:27] * Rossen_away is now known as Rossen
# [14:27] <dael> fantasai: It could match valid, but never active.
# [14:27] <dael> tantek: So how useful is that?
# [14:28] <dael> fantasai: It's a lot harder to detect that case than if this is a drop target you can drag to.
# [14:28] <dael> fantasai: This is eq. to people asking for a visible pseudo class.
# [14:28] <dael> tantek: I'm trying to provide and arguement for a half useable feature.
# [14:29] <dael> plinss: It could be exposed and I can't get to it. Do I want it to have never shown up? By your logic yes, but that's a lot of code to figure that out? How far to we want to go?
# [14:29] <tantek> s/for/against
# [14:29] <dael> rachelandrew: There are some things where you have to assume the person developing the interface has some idea of what they're doing.
# [14:30] <dael> tantek: So is this the distinction is between active and valid?
# [14:30] <dael> TabAtkins: Valid is all the things that can accept the dropping
# [14:30] <dael> tantek: And active requires hit testing?
# [14:30] <dael> Florian: Yes.
# [14:30] <dael> tantek: So the only request is the doc refers to hit testing.
# [14:30] <dael> TabAtkins: The doc refers to how the drop works and doing it via hit testing.
# [14:31] <dael> dbaron: It could be that HTML defines when you drop something on the label of the form control it drops onto the form control and we don't want to define CSS differently.
# [14:31] <dael> tantek: Whatever you're using to drag the thing, finger or mouse.
# [14:31] <dael> fantasai: Voice interface.
# [14:32] * zcorpan face guestures
# [14:32] <dael> Florian: The semantics we have now. We know we can go back and forth. Are we confident we're not going to change this?
# [14:32] <dael> tantek: Has anyone else impl?
# [14:32] <bkardell_> does that mic near on podium work?
# [14:32] <gregwhitworth> https://drafts.csswg.org/selectors/#drag-pseudos
# [14:32] <MozParis> https://drafts.csswg.org/selectors/#drag-pseudos
# [14:32] * zcorpan s/u//
# [14:32] <dael> TabAtkins: FF has different names versions.
# [14:32] <dael> TabAtkins: And I think you have moz-drag-over
# [14:33] <dael> tantek: That's the one. Last time this was on the wiki it was different names.
# [14:33] <dael> dbaron: Is anyone planning to impl this in the near future?
# [14:33] <dael> fantasai: Next two-ish years.
# [14:33] <dael> TabAtkins: I have no idea.
# [14:33] <dael> tantek: That says to me it should punt.
# [14:33] <dael> fantasai: Authors want this.
# [14:33] <dael> Florian: at-risk is reasonable.
# [14:34] <dael> fantasai: Okay.
# [14:34] <tantek> at a minimum at-risk
# [14:34] <Florian> http://www.w3.org/mid/55AEABE6.9010001@inkedblade.net
# [14:34] * MaRakow_ :drop(bear)
# [14:34] <dael> fantasai: our goal is to put everything into keep, at-risk, or drop.
# [14:35] <dael> fantasai: We have :has which it sounded like the WG wanted to keep. Since there were strong opinions I suggest we don't drop. There's :focus-withing pseudo class
# [14:35] <dael> Florian: You can use it in style sheets.
# [14:35] <dael> Florian: It does doc magic through labels and you can't use has in stylesheets.
# [14:36] <dael> fantasai: We don't have impl currently. If anyone is interested in impl we should at-risk. If there's no interest we should drop.
# [14:36] <dael> dbaron: I think it's trivial once you have :first. Was there demand?
# [14:36] <dael> fantasai: Yes.
# [14:36] <dael> dbaron: I'd keep and mark at-risk.
# [14:36] <dael> plinss: Is it completely eq to :has?
# [14:36] <dael> TabAtkins: Yes.
# [14:36] <dael> Florian: No becuase it's smarter and deals with the shadow dom
# [14:37] <dael> TabAtkins: shadow dom surfaces focus to the outer doc.
# [14:37] <dael> TabAtkins: Eq to has-focus if we had a deep combinator still.
# [14:37] <dael> fantasai: That's at risk. We have read-only and read-write. I recall issues.
# [14:38] <dael> dbaron: Aren't they not new?
# [14:38] <dael> Florian: They're in gecko prefix and ?? non-prefix.
# [14:38] <dael> dbaron: Aren't they in 3?
# [14:38] * Joins: antonp1 (~Thunderbird@public.cloak)
# [14:38] <dael> Florian: They're in HTML 5 which is REC
# [14:38] <Florian> http://www.w3.org/TR/html5/disabled-elements.html#selector-read-only
# [14:38] <dael> TabAtkins: Trying to remember why issues.
# [14:38] <dael> fantasai: content: editable, I think.
# [14:38] <dael> TabAtkins: I think it was hixie that wanted it.
# [14:38] <dael> Florian: Read-write by three browsers, read-only is by two.
# [14:39] <dael> fantasai: So we'll keep those
# [14:39] <dael> fantasai: placeholder: shown
# [14:39] <dael> Florian: webkit in nightlys
# [14:39] <dael> TabAtkins: Yes.
# [14:39] <dael> dbaron: We used to as :placeholder. I should put it back.
# [14:39] <Florian> webkit has place-holdershown in nightlies https://trac.webkit.org/changeset/172826
# [14:39] <dael> fantasai: So keep that.
# [14:40] <dael> TabAtkins: nth child (An+B) of selector syntax. This is impl interest as to if it stays or is punted.
# [14:40] <dael> fantasai: So if you have a bunch of hidden alli and you want to have even/odd striping you could hid every other.
# [14:41] <dael> dbaron: webkit has this.
# [14:41] <dbaron> s/dbaron/dean/
# [14:41] <dael> fantasai: We have one impl, it's useful. Everyone else think this is a thing to keep.
# [14:41] <dael> Florian: There's author demand in the room.
# [14:41] <dael> tantek: Anyone else will impl?
# [14:41] <dael> tantek: It's prob at risk since no one else is jumping.
# [14:42] <dael> esprehn: We're not exsited about impl ever increasing complications. We'd rather authors added classes.
# [14:42] <dael> Bert: But that's in the HTML
# [14:42] <dael> esprehn: I think we can ask authors to change their HTML.
# [14:42] <dael> fantasai: We're failing to fulfill the common use case.
# [14:42] <dael> tantek: This is an expansion of nth of type that's what's going on.
# [14:42] <dael> dbaron: I thought there was a bunch of author demand. I found a moz bug from Mar 2013 which has 3 people cc'ed.
# [14:43] <dael> fantasai: It's not immediatly obvious what this bug is.
# [14:43] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [14:43] <dael> dbaron: I have seen demand in other places.
# [14:43] * antonp1 is now known as antonp
# [14:43] * Joins: dauwhe (~dauwhe@public.cloak)
# [14:43] <dael> leaverou: Authors have been asking for this since nth child was impl. They thought it would do this and were disappointed it didn't.
# [14:44] <dael> leaverou: I don't think we can make them change their HTML.
# [14:44] <dael> tantek: You don't like nth
# [14:44] <dael> esprehn: It's linear behavior in the browser, which isn't desirable.
# [14:44] <dael> dbaron: There are perf problems with this stuff that aren't present with classes and authors use slow selectors without knowing what's slow.
# [14:44] <esprehn> or n^2
# [14:45] <dael> ChrisL: Forcing people to do even/odd with classes seemed wrong.
# [14:45] <dael> plinss: I think we're going in a rat hole.
# [14:45] <dael> dbaron: I'm vaguely interested in impl but it's decent work?
# [14:45] <dael> fantasai: You can't hook into nth type code?
# [14:45] <dael> dbaron: It's sim.
# [14:45] <dael> tantek: Are there limits that can go on the s?
# [14:45] <dbaron> s/sim/similar/
# [14:45] <dael> fantasai: Maybe. I think the dynamic profile should only allow some selectors.
# [14:46] <dael> dbaron: I don't think limiting helps.
# [14:46] <dael> tantek: If you're doing nth of type and you get attr, you've got attr and class and you can stick lang in there.
# [14:46] <dael> hober: Our impl supports complex selectors because authors want it.
# [14:46] <dael> TabAtkins: Complex is combinators.
# [14:47] <dael> esprehn: What we're not interested in impl is the nestability. You can nest nth child inside as deep as you want.
# [14:47] <dael> fantasai: Noooo. that's terrible. I'm 100% for disallowing nth child nesting.
# [14:47] <dael> tantek: I'm going back to limiting to element names, lang and class.
# [14:47] * leaverou Yo dawg, I heard you like :nth-child()…
# [14:48] <dael> TabAtkins: The feature selectors are things that don't have colons on it.
# [14:48] <dael> fantasai: feature selectors, :matches and :not and we'll run with that for now.
# [14:48] <dael> liam: The contents of not have the same restrictions?
# [14:48] <dael> fantasai: Yes.
# [14:49] <dael> Florian: So Apple since you have more are the rest used?
# [14:49] <dbaron> I think people might want pseudo-classes, but...
# [14:49] <dael> hober: We haven't checked.
# [14:49] <zcorpan> s/of not/of :not/
# [14:49] <dael> fantasai: It's okay if you implmore.
# [14:49] * astearns I'm a featuretarian - I only use selectors that don't have colons
# [14:49] <dael> tantek: If you want to be able to write tests shrinking the canvas is good.
# [14:49] <dael> fantasai: I like your thinking.
# [14:49] * Quits: MaRakow_ (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [14:49] <tantek> s/canvas/surface
# [14:49] * Joins: MaRakow (~MaRakow@public.cloak)
# [14:49] <hober> s/hober: We haven't checked./smfr: we haven't shipped it yet/
# [14:50] <dael> dbaron: I think the perf characteristics won't be as good as nth child because we can have caches for levels and it depends on there only being two things to cache. This extends to having an arbitrary number of things to cache. I think if it's not cachable the perf isn't acceptable.
# [14:50] <dael> fantasai: On the plus side, the vast majority of use cases will have two ways of counting the thing.
# [14:51] <dael> TabAtkins: We don't cache nth of type so it shouldn't be work.
# [14:51] <dael> dbaron: The obvious stupid way to hash is by the memory address
# [14:51] <dael> SimonSapin: Do we want a single selector or more than one?
# [14:51] <dael> esprehn: Compound selector is fine.
# [14:51] <dael> fantasai: It's the same caching.
# [14:52] <dael> fantasai: The descendant selector which is written as >>, we're proposing to drop.
# [14:52] <dael> TabAtkins: We liked it better when we had deep.
# [14:52] <dael> fantasai: Everybody agrees?
# [14:52] <dael> RESOLVED: drop >>
# [14:53] <dael> fantasai: The next is column selectors. For styling tables people want to do striping on the tables and you can do that by styling the column elements themselves. We don't have a way to say I want all the cells in this column to be algined center. You have to put it on each cell.
# [14:54] <dael> fantasai: This only works on HTML tables. It's based on the semantic markup. Even if you display the table in another transformed way, the selections will work. This solves most of the use cases because the tables where you want to do this are those with data.
# [14:54] <dael> leaverou: Is this solved by the last issue? fantasai: nth child doesn't work with spanning.
# [14:54] <dael> ChrisL: How does this work with spanning?
# [14:54] <dael> fantasai: Depends on your cascade.
# [14:54] <dael> leaverou: So is this a pseudo class that relies on DP?
# [14:55] <dael> fantasai: There's acolumn combinator that expresses the relationship between a column element and it's TD. And there's the nth column pseudo classes that apply to the TD
# [14:55] <dael> liam: I don't see anything in the spec that defines what a column is.
# [14:55] <dael> TabAtkins: It's up to the document language to define what a column is.
# [14:56] <dael> liam: [hesitant yeah]
# [14:56] * Joins: jdaggett (~jdaggett@public.cloak)
# [14:56] <dael> TabAtkins: The document says what cells make up a column.
# [14:56] <dael> liam: It wasn't clear if multi-col is a part of this.
# [14:56] <dael> TabAtkins: Not in the document language.
# [14:56] <dael> leaverou: So to use this you still need column nav?
# [14:56] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [14:56] <dael> fantasai: Not for the nth child, but to use column combinator it only makes sense if you have column.
# [14:57] <dael> tantek: Implementations?
# [14:57] <dael> TabAtkins: No. I suspect interest is low enough we should put.
# [14:57] <dael> tantek: I'd tend to agree.
# [14:57] <dael> dbaron: I've seen more demand for this than other things in here.
# [14:57] <dael> several: yeah.
# [14:57] <dael> dbaron: I don't like the column combinator syntax. I liked the pseudo class one better.
# [14:58] <leaverou> s/So to use this you still need column nav?/So to use this you still need to add <col> elements to your markup, right?/
# [14:58] <dael> fantasai: This is structural, it's representing the relationship in the tree whichi s what a combinator is. It's just not expressed by parentage.
# [14:58] <dael> dbaron: The number of performance comprimises we make with combinators wants me not to do combinators.
# [14:58] <dael> fantasai: How is that different than syntax.
# [14:58] <dael> dbaron: It's not that simple. We're not going to re-write all the selectors.
# [14:59] <dael> TabAtkins: I'll trust you if you say it's difficult for implementations reasons because we also have wierd things and it's harder to optimize combinators.
# [14:59] * tantek do we have a group photo scheduled?
# [14:59] <dael> dbaron: There's a lot of code where you have to think carefully about every combinator. When there's 4 that's doable, when it's 10 you start being unable to think about that problem.
# [14:59] <leaverou> tantek: There is a bikeshed downstairs. We must absolutely take the group photo there!!
# [14:59] <dael> Florian: And the pseudo classes that behave like combinators don't behave like that?
# [14:59] * Joins: plh (plehegar@public.cloak)
# [14:59] <dael> dbaron: No because they don't break the chain.
# [15:00] <SimonSapin> div col || td p
# [15:00] <dbaron> td:column(.heading)
# [15:00] <dael> dbaron: What I was prop was something like ^
# [15:00] * Joins: MaRakow (~MaRakow@public.cloak)
# [15:00] <TabAtkins> div td:column(col) p
# [15:00] <dael> dbaron: That would match a cell with class=heading
# [15:00] <TabAtkins> ^^^ translation of Simon's case
# [15:00] <fantasai> div td:column(.heading) td p
# [15:00] <dael> leaverou: What selectors would grant that.
# [15:01] <dael> dbaron: I don't care that much. It has the advantage authors can see it and figure out what it is what is harder than two double bars.
# [15:01] <leaverou> s/What selectors would grant that./What selectors would that pseudoclass accept?/
# [15:01] * liam td:column(:nth-child(3+not(.heading)))
# [15:01] * Quits: jihye (~jihye@public.cloak) (Ping timeout: 180 seconds)
# [15:01] <dael> TabAtkins: It's prob eq. The only thing that would make it not eq...you could do something with the col and the cobinator, but I don't care.
# [15:02] <TabAtkins> s/with the col/with a <colgroup> and <col> and their relationship/
# [15:02] <dael> fantasai: the diff is you could say I'm in [irc]
# [15:02] <fantasai> .foo td:column(.highlight) p
# [15:02] <dael> fantasai: Or if you have the column cobinator
# [15:02] <fantasai> .foo .highlight || td p
# [15:02] <dael> leaverou: What i like about dbaron suggestion is it's more readable.
# [15:02] <dael> fantasai: In the first case the .foo could be the table row but in the second case it had the be the parent
# [15:03] <dael> fantasai: So you couldn't select in col groups.
# [15:03] <leaverou> s/What i like about dbaron suggestion is it's more readable./What i like about dbaron’s suggestion is that it's more readable, whereas another combinator is turning Selectors even more into ASCII art./
# [15:03] <dael> dbaron: You could if you allow combinators
# [15:03] <dael> fantasai: Do you want to?
# [15:03] <dael> dbaron: Not really.
# [15:03] <dael> fantasai: Combinators keep a single path up the tree. You walk to the tree.
# [15:03] <dael> dbaron: Impl prespective that's a massive disadvantage.
# [15:04] <dael> fantasai: With your syntax you could branch. Being able to select on the col group is important. Sometimes you'll want the col, sometimes the col group.
# [15:04] <dael> tantek: I'd like to repeat what leaverou said. The more you add the more CSS resembles purl
# [15:04] <dael> fantasai: We don't add many, we have 4.
# [15:04] <leaverou> s/purl/Perl/
# [15:04] <SimonSapin> https://xkcd.com/1306/
# [15:05] <dael> tantek: We have a lot of combinators and punctuation. That cost should not be underestimated. I don't htink it's worth it.
# [15:05] <dael> TabAtkins: I have nothing against the column pseudo class. I think the combinator is more elegant, but if it's easier to impl or read that's fine.
# [15:05] <dael> fantasai: I want this to work for column groups
# [15:05] <dael> TabAtkins: It'll be fine.
# [15:06] <dael> leaverou: If we add combinators it should be for cases where people would see them against and again so they learn them. If it's for columns people will see them so rarely people won't get it. And it's hard to google for it.
# [15:06] * dauwhe The two rules of the CSSWG: Rule 1: dbaron is always right. Rule 2: If dbaron is wrong, see rule 1.
# [15:06] <dael> fantasai: If this works for column groups it's fine either way.
# [15:07] <dael> TabAtkins: So are we marking this as at-risk or punting to level 5. It sounds like there's impl interest so we should keep it at 4. Are you okay with this dbaron?
# [15:07] <dael> dbaron: I'm okay either.
# [15:07] <dael> tantek: I don't see a downside to punting this.
# [15:07] * fantasai thinks it'll be super great when we have :column() and :nth-column() and ::column() and ::nth-column()
# [15:07] <dael> fantasai: We've had this in since we first drafted this.
# [15:08] <dael> rachelandrew: I think it's very useful. It depends on what you're doing and I spend a lot of time building data tables and this would be useful. As soon as I saw this I thought it would be great.
# [15:08] <leaverou> Relevant re:authors needs https://twitter.com/w3cmemes/status/636886455902711808
# [15:08] <dael> fantasai: There hasn't been discussion on changing nth-column adn nth-last-column and that would get you most of them
# [15:08] <dael> dbaron: And I think their easier to impl.
# [15:09] <dael> fantasai: So push :column to level 5 unless an inpl wants to do this, mark :nth-column and nth-last-column as at-risk
# [15:09] <dael> TabAtkins: I'm okay with that.
# [15:09] <dbaron> ... though maybe handling dynamic changes for :column() isn't actually any harder than the others
# [15:09] <dael> dbaron: I think maybe.
# [15:09] <dael> fantasai: Okay, I think that's everything in selectors.
# [15:09] <dael> TabAtkins: Yes.
# [15:10] <dael> fantasai: In that case we should switch. There's still a couple of issues, but I think I need to talk with dbaron and TabAtkins seperately.
# [15:10] <dael> plinss: So not ready to publish?
# [15:10] <dael> fantasai: Not yet.
# [15:11] <dael> fantasai: Let me pull up the issues. There's one major one that's still open. I'm going to show you what it is and if no one else cares we can resolve to publish pending the people that do care agreeing.
# [15:11] <SimonSapin> fantasai is showing https://drafts.csswg.org/selectors-4/#evaluating-selectors
# [15:12] * bkardell_ raises hand
# [15:12] <dael> fantasai: This is a section where dbaron had comments on it being the wrong algo. If people care how it's written, raise your hand. I see TabAtkins dbaron and SimonSapin.
# [15:12] <dael> fantasai: So this is a section with a few problems. The algo isn't used by an UA. The hooks the DOM is using isn't correct.
# [15:12] <dael> ChrisL: Why different?
# [15:13] <dael> TabAtkins: Because you can define selectors going left or right or right to left, explaining it left to right is easier once you get multiple trees. But right to left is still the best in an impl.
# [15:13] <dael> hober: Within each tree you can go left to right and read right to left.
# [15:14] <dael> TabAtkins: If people really think it's important to desc the evalutation to be right to left I can do that.
# [15:14] <dael> dbaron: My concern is that there are going to be something things that are easy to desc in one way. If we build a spec that's the opposite of how specs build it we'll end up with things that are easy to spec or hard to builld or the reverse. There's also a risk of thinking things are the same and they're not.
# [15:14] * astearns how did "I need to talk to x and y separately" become "let's discuss this in the group without a way to resolve anything"?
# [15:15] <dael> TabAtkins: The easy to impl, hard to desc is the situation we have today.
# [15:15] <bkardell_> the spec does say that it's valid to eval them rtl as long as that elements returned are the same tho
# [15:15] <dael> fantasai: The point is nobody idsagrees on the functionality. How do we desc the functional. I agree with dbaron we should try, but I don't htink this is the setting. I wanted to bring this up and find out who is interested.
# [15:15] <dael> ChrisL: And how does rewriting it affect the HTML WG?
# [15:15] <dael> TabAtkins: None. THis is internal lang.
# [15:16] <dael> ChrisL: I thought hte contraint was schedle and content.
# [15:17] <dael> fantasai: That is one problem. I have a proble with how 'this' is used as the hook. It takes a bunch of inputs that are hard and it gives you a bunch of outputs that you have to tell it how to give you. I feel like these are user things the dom api should specify. We should only say if the selector matches and the dom can say go over the chain and return the list and that would make the interface a lot simplier
# [15:18] <dael> fantasai: The idea of matching a selector is an old concept and it's easily consitant forward whereas this will not be easy to understand and it doesn't match the dom spec. That's one of the problem I hav and that impacts HTML4.
# [15:18] <dael> TabAtkins: I disagreew ith everything fantasai said and I explained in an e-mail why so we don't need to discuss it here.
# [15:18] <dael> fantasai: These are what needs to be discussed, we should figure out soonish.
# [15:18] <dael> ChrisL: If another group is looking into this that is in scope for us so I think this does matter.
# [15:19] <dael> TabAtkins: In general I agree with that concept.
# [15:19] <dael> fantasai: I prop that if people care about how this section is worded and how dom and seelctors spec interact I'd like to know so we can have those people discuss it.
# [15:19] <dael> astearns: bkardell_ raised his hand too.
# [15:19] <dael> tantek: I am interested in contributing.
# [15:19] <dael> zcorpan: I'm interested.
# [15:20] <dael> fantasai: So if we can take a resolution pending agreement of this subset we can do that. Discussing it here won't be helpful. Does that sound good?
# [15:20] <dael> hober: We can pub now with a note saying this might be wrong.
# [15:20] <dael> TabAtkins: That we might change all this.
# [15:20] <dael> fantasai: The wording might change and that would effect people.
# [15:21] * dbaron thinks the resolution should be 96dpi
# [15:21] <dael> fantasai: Do we want to resolve with wording that this whole section might be changed?
# [15:21] * TabAtkins that's old school, dbaron
# [15:21] <dael> fantasai: It's a WD. We're far from CR.
# [15:21] * hober dbaron: why so coarse?
# [15:22] <dael> tantek: A bunch of these features we've asked if anyone has impl. There's a handful of selectors I had captured for css ui 4 there's no evidence of them being considered. These are all prefix in moz.
# [15:22] <dael> fantasai: I went through the whole list and don't remember seeing those.
# [15:22] <dael> tantek: Broken, surpressed, and a few others.
# [15:22] <dael> hober: They're tracked as issues.
# [15:22] <dael> tantek: They were considered for UI 4.
# [15:22] <dael> Florian: They're in the wiki of 4.
# [15:22] <dael> tantek: You want the considered.
# [15:23] <dael> hober: Yeah, but I don't care about document.
# [15:23] <hober> s/about document/about which document they get specced in/
# [15:23] <dael> fantasai: I think the, we wanted to have things that has a spec and review and impl. Things that start from scratch take several levels. We want this in CR by end of year.
# [15:23] <dael> tantek: The things I menationed are in mdn so it's not from scratch.
# [15:23] <dael> fantasai: Do they need to be in?
# [15:24] <dael> tantek: If there's any other impl that's interested, yes. at-risk.
# [15:24] <dael> Florian: Could we start level 5 and if they're ready first we suck this in?
# [15:24] <dael> TabAtkins: We have a doc of things we've pulled from selectors 4.
# [15:24] <tantek> here is where I've been collecting them: https://wiki.csswg.org/spec/css4-ui#more-selectors
# [15:24] <dael> Florian: So call that 5 and put them there.
# [15:24] <dael> tantek: Because it's a WD why not 4?
# [15:25] <dael> fantasai: I want to trim this and review the heck out of it to get it ready. To write things will slow this down.
# [15:25] <dael> tantek: These are above the bar on what we've kept.
# [15:25] <tantek> FYI:
# [15:25] <tantek> https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-broken
# [15:25] <dael> fantasai: There's a limitation on editor resources.
# [15:25] <tantek> https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-user-disabled
# [15:25] <tantek> https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-suppressed
# [15:25] <tantek> https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-loading
# [15:25] <tantek> https://developer.mozilla.org/en-US/docs/Web/CSS/::-moz-progress-bar
# [15:25] <dael> hober: That's the key. I don't think we should hold up your work for these.
# [15:25] <dael> fantasai: If this is all I was working on, sure, but I have 7 other specs.
# [15:25] * Joins: lajava (~javi@public.cloak)
# [15:26] <fantasai> 7 other specs to publish next week, and that's not even all of them
# [15:26] <dael> tantek: I pasted into IRC where I was tracking the features for UI 4 and I posted links to the ones that mozilla has implemented so that any other impl can look and speak up and push something forward. So we can take the burdon off you on evalutating.
# [15:26] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [15:27] <dael> fantasai: So. The goal is we want to pub asap. We should resolve to pub with all edits agree with the group for editing or with a note saying this section might be changed or deleted or whatever. HTML WG wanted us to pub a week ago.
# [15:27] <dael> tantek: The HTML group?
# [15:27] <dael> plinss: Let's not rat hole.
# [15:27] <tantek> there hasn't been an HTMLWG telcon in months
# [15:27] <tantek> so I don't understand how this request can come from "The HTML group"
# [15:27] <dael> dbaron: Is the thing they want to reference is the algo? IF that's the case I'dlike to hold off until we sort it out.
# [15:27] <dael> TabAtkins: What are they caring about?
# [15:28] <dael> fantasai: Dom 4
# [15:28] * dauwhe DAMN THAT DOM!
# [15:28] <dael> TabAtkins: It's an obsolete spec. It has a lot of errors. We block it and we actively block it. I will block it for you.
# [15:28] <dael> tantek: The easiest way to block would be to drop this section.
# [15:28] <dael> TabAtkins: The real dom needs it and is using it so it needs to stay.
# [15:29] <dael> fantasai: If we don't pub we'll have plh say we're publishing now.
# [15:29] <dael> plinss: Can we move on?
# [15:29] <dael> fantasai: We'll worry about publishing after solving this thing.
# [15:30] <dael> action work on the algorithm problem with the team yo have assembled
# [15:30] * trackbot is creating a new ACTION.
# [15:30] <fantasai> s/thing/thing per dbaron's request/
# [15:30] <trackbot> Error finding 'work'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [15:30] <tantek> trackbot, you're fired
# [15:30] <trackbot> Sorry, tantek, I don't understand 'trackbot, you're fired'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
# [15:30] <dael> action fantasai work on the algorithm problem with the team yo have assembled
# [15:30] * trackbot is creating a new ACTION.
# [15:30] <trackbot> Created ACTION-719 - Work on the algorithm problem with the team yo have assembled [on Elika Etemad - due 2015-09-03].
# [15:30] <dael> plinss: Has anyone heard from jdaggett?
# [15:30] <dael> dbaron: He said he'd be back after 2pm.
# [15:30] <dael> Topic: will-change
# [15:31] <dael> smfr: I recently put it in webkit. The first one is uncontriversal. It imples that will-change creates a stacking context.
# [15:32] <dael> smfr: Second concerns me more if you say will change transform and apply it to something it doesn't work for it currently imples you get a stacking context. I'm worried that we'll have memory overhead and I'd prefer to avoid if the prop doesn't apply.
# [15:32] * Joins: jihye (~jihye@public.cloak)
# [15:33] <dael> TabAtkins: I would like to keep it with current behavior because the def of if something like transform applies can be complex over the tree. If you're the child of a flexbox you'll get blockifed eventually. We try to limit the info to eveal a prop.
# [15:33] <dael> smfr: The stacking context issue is normative. I'd like to hear from other impl if it's a problem.
# [15:33] <dael> ojan: Is this not a problem today with *-position?
# [15:33] <dael> smfr: They don't for performance but they will for transform?
# [15:33] <dael> ojan: Wont the page fall over if they do that?
# [15:34] <dael> TabAtkins: Half fall over.
# [15:34] <dael> smfr: So you'll have z-index tree building every time.
# [15:34] <dael> dbaron: I think it's a way for authors to shoot themselevs in the foot.
# [15:34] <dael> hober: If we're tyring to replace it to 0 we shouldn't replace with worse performance. Transform to 0 would only happen for things that transofrm applies to.
# [15:35] <dael> dbaron: Do we see authors using it with *? The translate Z hacks?
# [15:35] <dael> smfr: Occationally, yes.
# [15:36] <dael> ojan: My pers is we obsv people doing bad things all the time. We thinkw e just need to make it cheaper. THat's our plan, we haven't gottent here. Is creating a stacking context expensive for you? It is for us but we're trying to make it less
# [15:36] <dael> Rossen: It could be for us.
# [15:36] <dael> dbaron: My intuation is it doesn't seem that expensive but I haven't measuerd.
# [15:36] <dael> ojan: The degree in webkit doesn't seem fundimental. I don't feel too strongly for performance.
# [15:37] <dael> ojan: I don't think it's fundimentally efficient. We have to fix it anyways because there's so much context being relaxed about creating stacking. We were going to fix it anyways.
# [15:37] <dael> tantek: If I understand in terms of being a hook for UA to optimize, was there a reason why a no value was omitted?
# [15:37] <dael> gregwhitworth: That's the default.
# [15:38] * dauwhe will-change: hell-no
# [15:38] <dael> tantek: It's auto. If you can know it will not change you can do optimize. We have this table-layout fixed in CSS 2.1 you know it will not change.
# [15:38] * hober will-change: ftfy
# [15:38] * bkardell_ will-change: maaaayyybbbeee;
# [15:38] <dael> TabAtkins: One reason is the opimizations you use will layout horribly if the author lies. If the author says it will transform it produces correct even if it doesn't.
# [15:39] <dael> TabAtkins: If I say will-change: none and you've optimized, you're not incorrectly rendering. if you say will-change:transform and you don't it's fine.
# [15:39] <dael> zcorpan: I htink tantek is changing the semantic where if you say 'no' the UA will actively ignore changes.
# [15:39] <dael> smfr: That makes will-change more powerful. This is meant as a hint to optimize.
# [15:40] <dael> TabAtkins: The only effects it has that are obserable except for performance is for those things that you say would be visiable. I would have had it have no observable effects if poss.
# [15:40] <dael> plinss: What you're suggesting is doable, but should it be a part of will-change. You could have a prop that says freeze.
# [15:40] <bkardell_> maybe it should have been called change-hint
# [15:41] <dael> zcorpan: It seems to me if something doesn't change it's not going to be performance. It's not worth optimizing. There's no reason to introduct will-change: no.
# [15:41] <dael> TabAtkins: Everything else is as fast as we can make it.
# [15:41] <dael> zcorpan: It seems like another source of vice.
# [15:41] <dael> tantek: You couldn't cache whole sub trees?
# [15:41] <shane> /me will-not-change: yup
# [15:41] <dael> TabAtkins: If we were it would be a whole new prop.
# [15:41] <zcorpan> s/vice/bugs/
# [15:42] <zcorpan> s/be performance./be a performance bottleneck./
# [15:42] <dael> TabAtkins: The complixity of tryign to determine if this would apply I think makes this unadvisable. Putting *will-change is bad because everything says don't do that. If they do that, screw them.
# [15:42] * astearns yes, "screw"
# [15:43] <dael> shane: Will-change is desgned as a hint.
# [15:43] <dael> dino: Except it has normative behavior.
# [15:43] <dael> shane: If you say will-change you're sayign whatever values I put in willchange.
# [15:43] <dael> dino: Browsers without will-change will get better perf.
# [15:43] * dauwhe * { will-change: ... } should alias to * { display: none }
# [15:43] <dael> TabAtkins: On the pages where the authors have screwed themselevs yes. Well desgined pages no.
# [15:44] <dael> TabAtkins: This is complicated and reduces the ability of servo's efforts to do parlealization.
# [15:44] <dael> smfr: I'm willing to live with this if the other venders think it's okay.
# [15:44] <dael> gregwhitworth: No strong opinion.
# [15:44] <zcorpan> s/parlealization/parallelization/
# [15:44] <dael> ojan: I could go either way.
# [15:44] * TabAtkins dauwhe: Definitely.
# [15:45] <astearns> s/gregwhitworth/marakow/
# [15:45] <dael> smfr: Third question is should will-change with animations create stacking context.
# [15:45] <dael> smfr: But you can also say will-change: display or position and those aren't animatable.
# [15:45] <dael> TabAtkins: They are animatable. They flip at 50%
# [15:45] <dael> smfr: It doesn't benefit from optimization
# [15:46] <dael> TabAtkins: It prevents you from opacity 100 to opacity 99.9999 flickerting. You'd have a layout change. I think it's still preferable to apply stacking context.
# [15:46] <dael> smfr: Other opinions?
# [15:46] <dael> smfr: Again, I'm good as long as other broswers think it's okay.
# [15:46] <bkardell_> https://twitter.com/iamdevloper/status/636897190078640130
# [15:46] <dael> ojan: seems fine to me.
# [15:46] <dael> hober: Opinions from moz?
# [15:46] <dael> dbaron: Not particularyl.
# [15:47] <dael> TabAtkins: If you're doing hacky position:sticky and you have things that care about stacking it would be nice if you get a nice position change.
# [15:47] <dael> Topic: scroll snap
# [15:48] <dael> dbaron: Yesterday we were talking about changing snap points to address feedback from a few years ago. It sounded like abunch of others were okay with changing. The concern we had is we're willing to hange to mtch the new thing, but if no one else does the new thing we'll have to change back.
# [15:48] <dael> dbaron: The question is, even if you ship with prefixes, the authors will write the prefixes.
# [15:49] <dael> dbaron: So basically we sort of said yesterday people were okayw ith changing the spec and that should be contigent on the people being willing to ship the new thing and get rid of the old thing.
# [15:49] <dael> TabAtkins: Agreed.
# [15:49] <dael> TabAtkins: I need to discuss further with Mat. The only thing on the table for changing was scroll-snap-coordinate.
# [15:50] <dael> TabAtkins: I agree. Even if we decide we should change to -align if the currently shipping browsers don't drop and change we'll have to change the spec.
# [15:50] <dael> dbaron: I'd ben interested in hearing form apple and MS.
# [15:50] <dael> MaRakow: Ours is old so it's not compliant right now. We have just snap-points-x and -y.
# [15:50] <dael> ojan: There's another difference that no one has shipped which is snapping with layer changes.
# [15:51] <dael> MaRakow: We don't. Our is from 4 yars ago.
# [15:51] <dael> TabAtkins: Theirs is setting up distances on a container.
# [15:51] <dael> ojan: If the height of an item changes...
# [15:51] <dael> TabAtkins: You're fine. Their impl doesn't care, it's too old.
# [15:51] <dael> ojan: My understanding is Apple and Moz do not resnap if the height of an item changes.
# [15:52] <dael> smfr: I forget what we decided to do. I don't htink it'sr elevent to this discussion.
# [15:52] <dael> ojan: It's the what's happening in the spec. What people have shipped doesn't match spec.
# [15:52] <dael> dino: Spec doesn't say what to do.
# [15:52] <dael> ojan: It does.
# [15:52] <dael> dino: Isn't that a bug?
# [15:52] <dael> Florian: If nothing matches nothing okay, but the more things that match the harder it is to change.
# [15:53] <dael> Florian: That MS impl is signif different makes this easier.
# [15:53] <dael> smfr: And the interop is on scroll-snap-points which is prop to drop
# [15:53] <dael> fantasai: We can keep it. I'd rahter keep it than not change the model. We don't see the use case, but it's not blocking us from going forward.
# [15:53] <dael> plinss: Sounds like everyone is okay with dropping the bits you want.
# [15:54] <dael> fantasai: Everyone wants to keep the bits we wanted to drop, but is okay changing the things we want to change.
# [15:54] <dael> TabAtkins: That would leave me 80% happy.
# [15:54] <dael> fantasai: I don't have an obj to -x and -y. If that's where we start it's not harmful in any way. You impl with the repeat?
# [15:55] <dael> MaRakow: We have list and repeat. The repeat syntax I think there might be a small syntax difference but it's functionally the same.
# [15:55] <dael> fantasai: Okay. That's helpful to know.
# [15:55] <dael> MaRakow: We're prefixed also.
# [15:55] <dael> fantasai: So we need a new model. We're not constrained because the only introp is repeat.
# [15:55] <dael> MaRakow: I'm not sure how interop moz and apple are.
# [15:56] <dael> ojan: Some anal that one of our folks did is there is quite a bit of difference. The sepcfic thing can think of is if descnedants feed into your snap points.
# [15:56] <dael> ojan: I think that was the big one so maybe that's not true anymore.
# [15:56] <dael> ojan: I think the layout thing is the only thing.
# [15:57] <dael> ??: I don't htink any snap on program scroll.
# [15:57] <dael> smfr: We decided not to.
# [15:57] <dael> fantasai: If you want it you could add an API.
# [15:58] <dael> MaRakow: We had an open issue, but that was removed when we decided we wanted to clamp down to the stuff agreed on. We're still insterested in a snap to next or snap to page 20. As it's currently written any type of scroll, the snap points talk about the stasis state. Once you've reached steady it's maditory you be attached to a snap point.
# [15:58] <dael> MaRakow: If you're programmatically scrolling to 99 you go to 100.
# [15:58] <dael> ??: What's a steady state?
# [15:58] <astearns> s/??/rbyers/
# [15:58] <dael> TabAtkins: You've stopped moving.
# [15:59] <dael> MaRakow: There are going to be issues for users that don't support animations. I think everyone has a definition of having reached a destination.
# [15:59] <dael> smfr: Is there text in the spec that says that?
# [15:59] <dael> MaRakow: Yeah, there's text.
# [15:59] <dael> plinss: So are we dont on scroll-snap?
# [15:59] <dael> fantasai: I think so.
# [16:00] <dael> dbaron: I think we heard from one impl, but not from apple.
# [16:00] <dael> dino: We don't comment on future
# [16:00] <dael> dbaron: I'm inclinded to say given that response we should leave as is
# [16:01] <MaRakow> In the definition of mandatory-type snap points: "it must come to rest on a snap point at the termination of a scroll, if possible"
# [16:01] <dael> dino: You're not asking if we would impl the new and improved spec you're asking if we'd stop impl what we have.
# [16:01] <fantasai> s/future/future releases/
# [16:01] <MaRakow> http://www.w3.org/TR/css-snappoints-1/#scroll-snap-type
# [16:01] <dael> dbaron: We've impl what the spec has now. If the spec improves we'd impl the new thing if we have reasonable confidence that we don't have to go back to the old thing because people are writing for apple
# [16:02] <dael> dino: What you really want to know is would we drop our support for the old spec. I don't know...
# [16:02] <dael> smfr: We'd be willing to impl new stuff if the existing stuff is still mostly compat.
# [16:02] <dael> Florian: I would be eq concerned if the apple impl and MS had been similar. Given that what we want to change is not interop I feel less bad about not having an answer.
# [16:02] <dael> ojan: I think dbaron point stands. If Apple is unwilling to remove others must impl.
# [16:03] <dael> fantasai: Not nec. true. They haven't shipped yet so if we could get the stuff out quickly...
# [16:03] <dael> dino: 3 months ago.
# [16:03] <dael> fantasai: Testing builds are sep.
# [16:03] <dael> astearns: But they're a good indicator for future things.
# [16:03] <dael> fantasai: But websites won't build thing that only work in a testing broswers.
# [16:03] <astearns> s/future/very close future/
# [16:03] <dael> dbaron: It's not just web that will be on it.
# [16:04] <dael> fantasai: If we get something in the next year and people are working toward interop apple will move to that.
# [16:04] <dael> dbaron: I may want to come back.
# [16:04] <dael> dino: If theres a new spec we'll want to support that with others. If we want to remove something we'll have ot make that decision whent he time comes.
# [16:05] <dael> Rossen: That's fair.
# [16:05] <dael> rbyers: Do you have concerns about shipping prefix and unprefix that aren't the same.
# [16:05] <dael> dino: It's annoying but.
# [16:05] <dael> plinss: It's prefixed.
# [16:05] <dael> dino: Yes.
# [16:05] * zcorpan -webcat-
# [16:06] * Joins: nvdbleek3 (~nvdbleek@public.cloak)
# [16:06] <dael> MaRakow: this will be easier to have once i"ve talked more with TabAtkins and fantasai. We both want to be cautios about not changing thigns we don't need to.
# [16:06] <dael> dino: The best way to address this is get the spec out.
# [16:07] <dael> fantasai: We have a rough draft. Our goals should be something tht's stable enough that it's clearly better in three weeks. Work on something until TPAC. If we can maintain that timeline we can make a decision on what's going on and people should be able to build and ship in a reasonable timeframe.
# [16:07] <fantasai> http://dev.w3.org/csswg/css-2015/
# [16:07] * Quits: nvdbleek (~nvdbleek@public.cloak) (Ping timeout: 180 seconds)
# [16:07] * nvdbleek3 is now known as nvdbleek
# [16:07] <fantasai> https://drafts.csswg.org/css-2015/#experimental
# [16:08] <dael> fantasai: That's the snapshot. There was the discussion on this ^ section. I did a bunch of rewording and you can see where the changes are. Please take a look over the break so if we agree or if you have concerns we can talk about that I can keep working on it until we're happy.
# [16:08] <dael> tantek: Can we slot time into the agenda
# [16:08] <tantek> this is important enough to get folks in the room to hopefully agree
# [16:08] <bkardell_> are we taking a break?
# [16:08] * Quits: smfr (~smfr@public.cloak) (smfr)
# [16:08] <dael> [break=15min]
# [16:09] <dael> bkardell_: Yes.
# [16:09] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [16:10] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [16:10] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [16:16] * Quits: dael (~dael@public.cloak) (Ping timeout: 180 seconds)
# [16:18] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [16:19] <bkardell_> ironically I can make out every word of the conversation being had a few feet back from the podium, but couldn't make out a single word when fantasai was speaking right there *at* the podium
# [16:20] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:23] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [16:26] * Joins: smfr (~smfr@public.cloak)
# [16:27] * dauwhe I've never been in a room where the sound quality was so dependent on the position of both the speaker and listener
# [16:28] * Quits: MaRakow (~MaRakow@public.cloak) ("Page closed")
# [16:28] * Joins: dael (~dael@public.cloak)
# [16:29] <dael> Topic: input modality
# [16:29] * Joins: MaRakow (~MaRakow@public.cloak)
# [16:29] <dael> plinss: Are we waiting for bkardell_ to call in?
# [16:29] <dael> bkardell_: I'm here.
# [16:29] * dauwhe bkardell_: you're larger than life :)
# [16:30] <dael> bkardell_: So basically if you create a n interactive element in HTML,s ince around 2007 browsers have been figuring out what to do with the focus rectangle so it's optimal regarless of the browser.
# [16:30] * Joins: ChrisLilley (clilley@public.cloak)
# [16:31] <dael> bkardell_: When you're clicking people have different expectations the keyboard. When we did selectors focus we were only on focus. When an author uses focus they're not consulting the same source of truth as the native style and the result is the author disables focus rings all together.
# [16:31] <dael> bkardell_: There's no way to deal with this without really specific rules.
# [16:32] <dael> bkardell_: Alice Kartal (sp) and i got together and wrote a proposal that would expose the user's modality that would explain how you interact. We wrote the governance rules around what browsers do.
# [16:32] <astearns> s/alice Kartal (sp)/Alice Boxhall/
# [16:32] <bkardell_> https://github.com/alice/modality/tree/master/docs
# [16:32] * fantasai wonders if koji is still awake, and if jdaggett will ever return
# [16:32] <dael> bkardell_: We created a policy around how to do it and retain the A11y aspects. We created a prop that was originally MQ based. After discussions with other folks there was an idea it was better off being a pseudo class.
# [16:32] * fantasai thinks we should have covered writing modes earlier in the day
# [16:33] * koji I'm still awake
# [16:33] * astearns or yesterday
# [16:33] <dael> bkardell_: I'm pretty okay witht he pseudo class. I think the MQ made more sense for author, but it's marginal.
# [16:33] <skk`> I tried to have contact with jdaggett, but no reply.
# [16:33] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [16:34] <dael> Florian: It seems to me either way to make this work yu're relying on the same logic as pointer and hover MQ which is given a set of imput connected to a device figure out which one is primarily being used. So even if there's a mouse and a keyboard, theuser is primarly on the mouse so use that. That's the same consideration.
# [16:34] <dael> Florian: Having looked briefly at your prop, should we design these together or seperate? They seem similar enough to think together
# [16:34] * fantasai how late is it wrt your bedtime?
# [16:34] * fantasai koji ^
# [16:34] <dael> rbyers: There's a fundemental diff between MQ and this where MQ are saying at any given time what is the state of the system.
# [16:35] <dael> Florian: You're impl wrong. YOu don't need to flicer every time the user is close, but there's a notion of what is the primary thing.
# [16:35] <dael> rbyers: In many cases there is no input.
# [16:35] * koji wish to wait up to any time ;)
# [16:35] <dael> rbyers: In bkardell_ case the user just introduced with something. THe MQ was before they interact.
# [16:36] * koji but the conf is only 1.5hrs left, right?
# [16:36] * fantasai yeah
# [16:36] <dael> Florian: Just because the user touched the mouse, but you are primarily nav between with tab, you're clearly on the keyboard. yOU need heuristics to deal with that. The MQ were designed for similar logic. It's the same logic.
# [16:37] <dael> rbyers: It sounds to me like bkardell_ thing is meant to have context. It sounds to me like how is this being handled. If I click with the mouse and touch the touch screen it could cause two different modalities.
# [16:37] <dael> Florian: I'm not saying one replaces, I'm saying they're similar enough that we should have a common model.
# [16:37] <dael> rbyers: MQ have to rely on some heuristic whereas I'm hoping bkardell_ can be very specific.
# [16:38] <dael> bkardell_: That's interesting because I had not considered that. In our discussions we did discuss the doc had the modality which is more along the lines with the MQ things. It's an interesting point as to what if you did both ast the same time. What would happen? broswers are single threaded.
# [16:38] <dael> TabAtkins: This is a red herring.
# [16:38] <dael> TabAtkins: One will happen before the other.
# [16:39] <dael> TabAtkins: You can multi touch, but it's one event at the same time.
# [16:39] <dael> Rossen: And they can sometimes be in the same frame.
# [16:39] <dael> TabAtkins: But one fires before the other.
# [16:39] <dael> bkardell_: Basically there can be only one.
# [16:40] <dael> TabAtkins: The use cases for modality, the mixture is the best use case. You want focus rings as you tap through a form, but not the button after you click.
# [16:40] <dael> Florian: Both have a primary thing, but this is more fine grained. YOu want to switch on and off at a higher grained.
# [16:40] <MaRakow> q+ MaRakow
# [16:41] <zcorpan> s/tap/tab/
# [16:41] <dael> TabAtkins: The point is how you have focused something. That's what the modality is about. IN addition to the semantics talk, MQ for something changing rapidly are the worst.
# [16:41] <dael> TabAtkins: I was confused when I first read it as a MQ, but the intention is how you interact with a given input is how it works.
# [16:41] <dael> esprehn: This is how the broswer works. When you click an input you get a focus ring. If you tab to a button you get a focus ring.
# [16:42] <dael> Florian: I don't know what is the latest version, but does it need to enumerate the things.
# [16:42] <dael> TabAtkins: There are two modalities, keyboard and mouse.
# [16:42] <dael> bkardell_: Keyboard and not keyboard.
# [16:42] <dael> Florian: If it's bianry that's fine.
# [16:43] <dael> TabAtkins: It's all about, like, if you're activating something by literally touching it vs the computer moving you through the doc that effects if you want a focus ring.
# [16:43] <dael> bkardell_: There's been discussion on the spec and we've had feedback. Maybe call it sequential. Part of why it's a modality thing is we can build up abstract names that include more or less that way. Sequental is better than keyboard.
# [16:43] <dael> Florian: It's still wrong because you can have spacial nav.
# [16:44] <dael> TabAtkins: We can name later. There are two modes. The computer sending and your physical actions.
# [16:44] <dael> Florian: You're on a phsyical keyboard, but when you get close enough to a button it snaps there.
# [16:44] <dael> TabAtkins: The presence of your pointer is enough to call that mouse.
# [16:44] <dael> Florian: I prob agree, but this is gray zone.
# [16:44] <dael> TabAtkins: Basic prop is as some pseudoclass on some elements
# [16:44] <dael> Florian: focusable elements
# [16:45] <dael> TabAtkins: Yeah. This is exposed with the two values. fantasai has a regisered dislike of mode. Does the WG feel this is useful in terms of explaining in the platform?
# [16:45] <dael> tantek: I would like to know if authors care and would they do the work?
# [16:45] <dael> TabAtkins: Authors right now just turn off the focus ring a lot.
# [16:46] <dael> TabAtkins: The reason that even a11y guide that says don't do that isn't too sucessful, what they want which is no focus ring on button is why. I think as general a11y tutorials will get it.
# [16:47] <dael> tantek: For that use case, anyone could provide a style rule that says if you're going to do outline none thing, do the button. Authors are good at copy/paste.
# [16:47] <dael> Florian: There's nothing they can copy. If you do focus outline none it will remove the outline.
# [16:47] <dael> TabAtkins: It's bad a11y. They can say use this with the thing that means cursor with focus and you're golden.
# [16:47] <tantek> if this is just about how something acquired focus, then what about just :focused(modality)
# [16:48] <tantek> e.g. :focused(keyboard)
# [16:48] * Quits: jihye (~jihye@public.cloak) (Ping timeout: 180 seconds)
# [16:48] <tantek> "modality" is an unnecessarily abstract term
# [16:48] <dael> bkardell_: I think any time we do anything we are to an extent spec if authors will use it or get it. I really believe we should do things based on data. We've proven the need because this has been experimented since 2007 at least and there have been lots of feedback. Every user of the web has tested it as useful
# [16:49] <dael> bkardell_: If we can write something intuitive enough...we have a polyfill of it. The model should be for us to write a spec and provide a polyfill that's cross browser and give it to early adopters to find if we missed the boat.
# [16:49] <tantek> bkardell_ are you committed to the term "modality" or are you open to alternatives?
# [16:49] <Florian> modality -> focus-source
# [16:49] <bkardell_> t very open
# [16:49] <Florian> not-keyboard -> pointer
# [16:49] <dael> TabAtkins: I think this will be used because you can write a simple rule and copy paste and it does the thing you want. This feels like the kind of a11y improvement that will succeed.
# [16:49] <dael> bkardell_: I think we could prove it easily.
# [16:49] <tantek> Florian I think the choices are keyboard vs. direct-manipulation (pick a better name)
# [16:50] <tantek> where direct-manipulation could further be broken down into touch vs pointer
# [16:50] <tantek> note that touch != pointer
# [16:50] <tantek> but they behave *somewhat* similarly, not the same
# [16:50] <tantek> and both very different from keyboard
# [16:50] <tantek> like no need to even use :focus
# [16:50] <dael> MaRakow: On author interest, this is functionality that the winJS team asked for. The intention there was to change the style drastically. They were using a think board...this wasn't jsut focus, but active and hover. There is interest there. tantek pasted a suggestion in chat that was very similar.
# [16:50] * Quits: Tav (~tbah@public.cloak) (Ping timeout: 180 seconds)
# [16:50] <tantek> if you have :focused()
# [16:50] * astearns keyboard and counter-keyboard
# [16:50] <bkardell_> http://discourse.wicg.io/t/exposing-a-users-input-modality/1067/33 some good discussions on this here re: naming and all the WG should look at
# [16:50] <Florian> tantek: good point.
# [16:50] <tantek> or heck :focus(keyboard)
# [16:51] <dael> MaRakow: This is ideally how you would want to impl as an active state for touch. This matches what we've heard req or in the past.
# [16:51] <tantek> why do we need anything new besides a param for :focus?
# [16:51] <tantek> (sorry if this is premature bikeshedding)
# [16:51] <Florian> tantek, because we need it on active as well?
# [16:51] <zcorpan> :keyboard
# [16:51] <Florian> tantek, and maybe on hover as well?
# [16:51] <dael> rbyers: Chrome has exposed a source capability on events. Whatever we want to name this we want to expose on device capabilities. Today when something gets focused you can say was this focused by something that is touch event.
# [16:51] <TabAtkins> tantek, Matt just said the WinJS team wanted to do it with more than just :focus, yeah
# [16:51] <dael> bkardell_: Is there...that gives you back a string as an answer?
# [16:51] <tantek> ok
# [16:51] <tantek> thanks TabAtkins Florian
# [16:52] <dael> rbyers: There's an object that only has one thing right now, but we'll want to add to that.
# [16:52] <tantek> I still dislike the abstract jargon of modality
# [16:52] <dael> bkardell_: I'll read up on that.
# [16:52] <tantek> would prefer something like :from
# [16:52] <tantek> e.g. :focus:from(keyboard) or :active:from(pointer)
# [16:52] <dael> TabAtkins: It sounds like at least minimal browser support for adding this. Anybody oppose?
# [16:53] <tantek> I like more readable selectors
# [16:53] <bkardell_> jquery votes +1 ;)
# [16:53] <tantek> +1 on what?
# [16:53] <dael> Bert: The distinguising factor if you want to include the focus does it matter on what the iser did or the next expected action?
# [16:53] <bkardell_> s/votes/supports
# [16:53] <bkardell_> tantek the name is discussable for sure
# [16:54] <dael> TabAtkins: I think it is how you aquire focus. I think the thing is how you aquire focus. The point that makes the focus ring extra important is it's not predicatable going between elements to know which one is next. When you're clicking it's not a mystery, it's what you just clicked on.
# [16:54] <bkardell_> tantek +1 on adding this
# [16:54] <dael> Bert: But clicking on something like a text area, I want the focus ring.
# [16:54] <dael> tantek: You can do that today. Regardless of how this got there. Just using :focus as is
# [16:55] <dael> TabAtkins: Right now the choices between authors always turning off outlines or getting an outline where most of the time you need it you get a focus ring.
# [16:55] <rbyers> UIEvent.sourceCapabilities: https://github.com/RByers/InputDevice
# [16:56] <dael> bkardell_: Your inturtive thing is if you're going to touch the focus ring it has to do with your branding or design. As soon as you touch it your intuition is just write one rule. yOu say :focus, you give it a new outline, and quickly you'll realize it doesn't look right and people will see rings where an avg user won't and that's because it's not the same sourse as the native styling.
# [16:56] * fantasai wonders if we want MQs for keyboard
# [16:56] <dael> Bert: I can see you select elements visually, but I was hoping for something where I could say all elements.
# [16:56] * fantasai and if this would integrate with it
# [16:56] <dael> Florian: Focusable is something different that we don't have.
# [16:56] <dael> TabAtkins: On a well designed page this is maybe only buttons.
# [16:57] <fantasai> @media (keyboard) { has a keyboard }
# [16:57] <dael> TabAtkins: So obj to the feature and, if so, should we agree to write up an ED
# [16:57] <dael> Florian: Yeah.
# [16:57] <fantasai> @media (keyboard-primary) { mainly using keyboard }
# [16:57] <dael> TabAtkins: bkardell_ as editor?
# [16:57] <dael> RESOLVED: bkardell_ as editor of new ED for input modality (name pending)
# [16:58] <dael> Topic: page floats
# [16:58] * MaRakow input preference is difficult to define as a boolean. MQ might not be well suited (or would require a more complex syntax)
# [16:58] <dael> johanneswilm: We would like to have a FPWD on that. More importantly we have some doubts as to who this interests. We can impl what we have now, it's a relatively basic model, but we would like to know if this is interesting at all to browsers or if we should make it more advanced. If you want to do print you want more.
# [16:58] * Joins: darktears (~darktears@public.cloak)
# [16:59] <dael> johanneswilm: What we have only works in fragmented contexts. In any single fragmenet you can only have floats in the line or block direction. So say you want a float that goes to the right in a fragement that goes to the top, the float will move on. And you won't have 2d floats.
# [17:00] <fantasai> bkardell_: http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSPseudoClassList.h#166
# [17:00] <dael> johanneswilm: And as liam pointed out on the list, you would want to have a way of stacking those floats. Right now they are display in doc order, but you might want two floats in a doc with a large float that's at the top, you might want the two small at top, but that's a more complex discription
# [17:00] <dael> Florian: So there's conflict between what you want and what is impl by browsers.
# [17:00] <dael> TabAtkins: And what you can reasonably spec.
# [17:01] <dael> Florian: And depending on what interest, if the browsers say we'll never do this, we can go for the fancy thing, but that's not a desireable outcome. That's the underlying tension.
# [17:01] <dael> Florian: Maybe having the general model supported and a switch saying do it slow and fancy.
# [17:01] <dael> TabAtkins: If you're doing a customer printer thing you can do what you want.
# [17:01] <dael> Florian: The printer and web aren't disjointed.
# [17:01] <dael> TabAtkins: But high quality printing is different.
# [17:02] <dael> Florian: And an ebook is in between.
# [17:02] <dael> TabAtkins: If you're doing a pixal perfect thing that's fine and you can use magic, but we don't need it on the web.
# [17:02] <dael> liam: I don't think it's px perfect.
# [17:02] <dael> TabAtkins: But with the small thigns you can adjust your sizing.
# [17:03] <dael> Florian: Since we're working with active media, it's not inDesign. You're righting a stylesheet for print, but for paperback and hard cover and kindle.
# [17:03] <dael> TabAtkins: But if you want ideal design that is what you want or your a smart formatter that can do the magic, go ahead. We're not going to do a make my page magic script.
# [17:04] <dael> johanneswilm: We do it on top of you, that's fine. LAst time Rossen presented something that's simple page floats but wouldn't work with more than one in a column, the basic version we have should be able to handle that. If browsers are interested in that, we'll make sure the spec is written so that you can use that. If you don't care we'll write advance stull.
# [17:04] <dael> dino: Is the simple thing of use to authors?
# [17:04] <dael> johanneswilm: Yes. When you start to make things more complex it's not.
# [17:04] * Quits: tkonno (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [17:05] <dael> TabAtkins: We're not against the idea, esepcially if they start to obey simple restrictions. Something to remove the craziness of floats. So if you're doing newspaper layout you make the images siblings of the paragraphs not children you're fine. We're fine with this though we may have more feedback on the exact details.
# [17:05] <dael> dino: We'd be interested.
# [17:05] <dael> johanneswilm: What would you guys need for us to do FPWD?
# [17:06] <dael> ojan: The thing chrome is most interested in, we haven't reviewed everything, but extending floats in general we'd like a caret appraoch so we can remove the crap features from floats.
# [17:06] * Joins: POCEH (~POCEH@public.cloak)
# [17:06] <dael> TabAtkins: That might manifest by saying these aren't floats, they're a new property.
# [17:06] <dael> SteveZ: Is there a list of these things you want tog et rid of?
# [17:06] <dael> TabAtkins: We're making it, yes.
# [17:06] <dael> Florian: Do you want this addressed before FPWD?
# [17:07] * tantek fantasai did we already discuss the prefix policy changes?
# [17:07] <dael> TabAtkins: I don't htink so. I'm happy to not block now, but our review might involve lets put more restrictions on this.
# [17:07] * fantasai no
# [17:07] * tantek :/
# [17:07] <dael> Florian: I think the goal is to make something useful for both.
# [17:07] <dael> TabAtkins: We don't have philosophical problems.
# [17:07] <dael> TabAtkins: I'm okay with pub FPWD.
# [17:07] <dael> plinss: obj?
# [17:07] <dael> RESOLVED: Publish FPWD of page floats
# [17:08] <dael> plinss: Anything more?
# [17:08] <dael> plinss: Do we loop back to writing modes?
# [17:08] <dael> Florian: We deferred to the F2F to have him.
# [17:08] <dael> plinss: If we don't get him, should we do it here or wait for him?
# [17:09] <dael> fantasai: I think we should get through it here and jdaggett can add his thoughts and all resolutions are pending his thoughts.
# [17:09] <dael> Topic: Writing modes
# [17:10] <fantasai> https://drafts.csswg.org/css-writing-modes/issues-cr-2014
# [17:10] <dael> fantasai: I have DoC^
# [17:10] * Joins: adenilson (~anonymous@public.cloak)
# [17:10] <Florian> s/is to make something useful for both./is to make something which is both useful and implementable in browsers without major headaches, so we should be able to converge without problems, at least not philosophical ones/
# [17:10] <dael> fantasai: I'll skip issue 2.
# [17:12] <dael> fantasai: There is a caption side prop in CSs that defines what side of the table you put your caption. It takes top and bottom and in the past left and right. Moz impl all, but we dropped the sides because no one else did. Now we have writing modes and if you don't have the sides, you can only do block start and block end. So if we have top and bottom keywords we want left and right. And since those are physical when you go into vertical, they stay physical.
# [17:12] <dael> fantasai: But if you don't support all 4 you have to do something about that. [whiteboards]
# [17:13] * Quits: POCEH (~POCEH@public.cloak) (Ping timeout: 180 seconds)
# [17:13] <dael> fantasai: If you only support top and bottom and you impl writing modes, you can put the top at the top in vertical mode. We need a map of those impl. We decided top and bottom should go to the default caption side.
# [17:14] <dael> fantasai: We added new keywords of block start and end keywords and made the initial to be block start
# [17:14] <dael> Rossen: This is what we're impl. We ended up mapping top and bottom to be logical, jsut like float left and right mapped logical.
# [17:15] <dael> fantasai: Float left and right maps into the line left and right whcih are logical, but not start and end. It means float to wherever left and right text will start.
# [17:15] <dael> fantasai: If I have right to left text, right is the start but not the left.
# [17:15] <dael> fantasai: We could put top and bottom, but what happens to moz where they can do that, it becomes incompat.
# [17:16] <dael> Rossen: We impl left and right and we dropped it.
# [17:16] <dael> fantasai: B/c nobody supported.
# [17:16] * hober plinss: what's the japanese emoticon for yanking a doorknob out?
# [17:16] <dael> Florian: Having left and right without vertical writing is not so nice.
# [17:16] <dael> Rossen: There are casesf
# [17:17] <dael> fantasai: If you have a table and side captions on the right, it looks ugly and no one does it. It doesn't look attractive unles syou support vertical writing.
# [17:17] <dael> fantasai: We all agree to add logical eq and we want authors in vertical writing modes to use those.
# [17:18] <dael> fantasai: We wanted it to be clear that the caption side phsyical values don't have an effect in vertical writing modes. Top and bottom end up on the side if you don't support veritcal.
# [17:18] <dael> fantasai: Do you want top and bottom to behave logically or fallback to the block start.
# [17:18] <dael> Florian: It's a usability question, not feasibility.
# [17:18] * dbaron koji, fantasai was wondering if you were on the call
# [17:18] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [17:19] <dael> Rossen: We have real use cases where people use vertical tables with captions, mostly for displaying odd tabular data. I don't know about them, but they were using top and bottom just fine.
# [17:19] <tantek> sidenote: re: selectors-4 issue 12 ":dirty" pseudo-class - I really dislike the term :dirty - it is very programmer specific. I think something like :user-changed would be better since it parallels :user-invalid / :user-value - and should be triggered by ANY user action that changes the state of the control, e.g. typing, paste from clipboard, and right click / context-menu to insert (or again, paste)
# [17:19] * koji yes, I'm on the call. Can't hear most voices but can read IRC
# [17:19] <dael> fantasai: It's toally logical, but as soon as you support side cations, top need to be on the actual top.
# [17:19] <dael> fantasai: The ones in moz are in the e-mail I wrote. Side captions don't exist right now, but people want them.
# [17:19] <skk`> how about the fantasai's voice? koji
# [17:19] <dael> Florian: Can left and right be logical?
# [17:20] <dael> fantasai: That's opp of everywhere else.
# [17:20] <dael> Rossen: What about rows and columns?
# [17:20] * koji a little
# [17:20] <dael> Rossen: You're making everything in the table logical.
# [17:20] <dael> fantasai: So your'e suggesting drop block end a start and decide that top goes on the other side.
# [17:21] <dael> Rossen: All table prop are in a logical way without redefining them with logical prop. Just like we do for rows and columns.
# [17:21] <dael> ojan: I wish we had done that for the whole platform, but it's done.
# [17:21] <dael> fantasai: So this will be an acception to the rule that top/bottom/left/right are physical.
# [17:21] <dael> Rossen: For tables only. It's legacy feature retrofit into writing modes.
# [17:21] <dael> fantasai: Anything else to add?
# [17:22] <dael> Rossen: Otherwisey ou're half logical and half phsyical.
# [17:22] <dael> fantasai: I don't buy your arguement. Margin-left margin-right are all physical. The only thing logical is caption side.
# [17:22] <dael> dbaron: I think of table captions as a feature that was a mistake.
# [17:22] * skk` koji, how about now?
# [17:23] <dael> dbaron: So I kind of don't really care. I'm tempted to just remove the left and right support from gecko except that's work and I don't see the point of doing that.
# [17:23] <tantek> +1 on removal
# [17:23] * koji much better, I can hear fantasai and dbaron qutie well
# [17:23] <dael> Rossen: Comment out the property support.
# [17:23] <dael> ojan: Sounds great to me for what it's worth.
# [17:23] <dael> fantasai: dauwhe do you have opinions?
# [17:24] <dael> dauwhe: I got a req from a friend of mine in pub that had been switching to figure for a11y and wanted fig caption display the same as caption inside table and we had to get those to be the same. So there's a movement away from caption.
# [17:24] <dael> tantek: He likes how cpation displays
# [17:24] <dael> dauwhe: It's fairly easy to get it to follow the length.
# [17:24] <tantek> caption element is so broken that the more we unsupport it the better
# [17:24] <astearns> s/displays/displays??!??/
# [17:24] <dbaron> s/was a mistake/was a mistake, since authors can just use other markup and style to put the caption next to the table, rather than having browser features to move the caption from the inside of the table to the outside/
# [17:24] <dael> fantasai: It only works in moz. The combination you want is writing modes plus side captions an no one has that.
# [17:25] <dael> Florian: You can do it...
# [17:25] <dael> fantasai: With?
# [17:25] <dael> Florian: Multi elements.
# [17:25] <dael> fantasai: The way side captions are defined is if you're centering it your centering the table and this is off the side.
# [17:25] <dael> dauwhe: I'd like to take this use case back to dpub.
# [17:26] <dael> fantasai: That's what a side caption does, but that's becides the point. All that matters here is its been prop to drop the block start and end and make caption side a logical prop.
# [17:26] <dael> TabAtkins: If we should drop side captions, I don't see why not treat them logical. We call it line-top or whatever. Sometimes you got to retrofit.
# [17:26] <tantek> why is this only about tables?
# [17:27] <dael> fantasai: How it maps goes in writing modes.
# [17:27] <dael> Rossen: Sure, you can have an exception.
# [17:27] <dael> fantasai: We have to spec for 2.1, we're not waiting on tables.
# [17:27] * Joins: antonp1 (~Thunderbird@public.cloak)
# [17:28] <dael> fantasai: So the caption side property which currently takes top and bottom, or if you support side cpations also left, right. WE also added block start and block end. The prop is to remove block start and end and to make top, bottom, left, and right logical
# [17:28] <dael> Bert: I prefer the solution in the ED, but I see why people want the other. I'd rather add more keywords for logical directions.
# [17:28] <dael> fantasai: Anything else to add?
# [17:29] <dael> Florian: I agree with bert. I pref the other but only mildly.
# [17:29] <dael> fantasai: obj to making the block caption side property logical
# [17:29] <dael> RESOLVED: make the block caption side property logical
# [17:29] <astearns> s/obj/any obj/
# [17:29] <koji> 20?
# [17:30] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [17:30] <dael> fantasai: Propigation of direction to body. Prop from the body tag to the viewport, we don't have a you didn't set this value value. Every element has a value. We got some feedback that there's web compat issues so we should prop from the body tag to the viewport.
# [17:31] <dael> fantasai: The compat motly comes from epub and people prop writing modes and wanting to prop direction with it. So don't change the spec, you only use the writing mode and direction of the root element and the dir attr from body to HTML. Second is the viewport and initial containing block use the writing mode and direction of the body, third is we ignore the directionand writing mode prop on the body and copy that only the root element.
# [17:31] <dael> dbaron: Didn't we spend an hour or two on this at a prevoius meeting?
# [17:32] <dael> Rossen: I thought we wuld do what we did for BG prop.
# [17:32] <dael> Rossen: That's what current impl do
# [17:32] <dael> fantasai: We had a resolution to propigate dir from body, but then thought there might be conpat concern.
# [17:32] <dael> esprehn: I don't htink we can change.
# [17:32] <dael> fantasai: Everyone is buggy on what aspects they prop up.
# [17:33] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [17:33] * antonp1 is now known as antonp
# [17:33] <dael> fantasai: You can say for each effect that gets propigated, use the direction but the computed value on the root isn't changed. The other is change the writing mode and computed value on the root which would keep everything in sync.
# [17:33] <dael> Florian: Both these are done in browsers?
# [17:33] <dael> fantasai: No, this is what we can put in. Browsers are incomplete in how they translate it. Scrolling is inconsistant. Stuff is buggy.
# [17:33] <dael> Florian: Buggy weird?
# [17:34] <dael> fantasai: In that people have bugs and only prop for some effects, but not others. Nothing depends on it being broken. Some of it depends on stuff working. We can define the prop in two different ways, what is a better way to do it?
# [17:35] <dael> Florian: You're suggesting here are a few things that would keep compat, which is easier to impl?
# [17:35] <dael> fantasai: First we could do if direction is the only thing we care about, but it doens't handle writing mode. The second is the way impl sort of do it now. The third would be a different appraoch to doing it. Either way people ahve to fix impl.
# [17:35] <dael> fantasai: No matter what we pick we'll have to do work.
# [17:36] <dael> koji: I'm not familiar with direction buggy, but if author spec on HTML or body the three browsers are quite similar. As long as either is honored, the web compat is good, at least for writing mode.
# [17:37] <dael> fantasai: We can't detect if the author spec two values. There's no none on writing mode. The computed is one thing or the other thing. BG has a transparent and that's the initial. If you set it to color or image, we can see the author set it to not default. So we would be ignoring writing mode on the HTML because we can't tell if the author set it.
# [17:37] <dael> fantasai: The q is do we change the computed value on the HTML element or do we leave it computing to what it had and take all the effects, scrolling and alignment, and make them depend on the body
# [17:38] <dael> Rossen: That's what current impl do. How they got on body no one cares.
# [17:38] <dael> Florian: And you don't retro-fix the HTML. Seems simple enough.
# [17:38] <dael> esprehn: It does this.
# [17:38] <dael> Rossen: It's already simple enough to explain so if we keep it this way it's better.
# [17:39] <dael> fantasai: The advantage of copying is if the entire author says the whole doc is this, you get it into the metadata at the top and the logical prop behave the same way on the root as it does elsewhere on your doc.
# [17:39] <dael> fantasai: You do the inheritence and then you don't have to special case code for the scrolling and the like. As long as you did upward inheritence it will all just work. YOu don't have to handle each of these individually. It's clearly an impl bug that things aren't there, but there's more opp to trigger that switch.
# [17:40] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [17:40] <dael> Florian: So it's one complicated fix or a bunch of simple ones and you forget half of them.
# [17:40] <dael> fantasai: Does that makes sense.
# [17:40] <dael> dbaron: I'm trying to find the list from the last discussion.
# [17:41] <dael> dbaron: I'd be worried about time switching to something that doesn't matchw aht everybody does.
# [17:41] * Joins: antonp (~Thunderbird@public.cloak)
# [17:41] <dael> Rossen: The only thing that propigates up is overflow, writing mode and background.
# [17:41] <dael> ojan: You said the direction doesn't get property.
# [17:41] <dael> Rossen: To the viewport.
# [17:42] <dael> esprehn: fantasai is asking us to inherit everything up into the view. That's not what anybody does today.
# [17:42] <dael> esprehn: The body inherits into the root.
# [17:42] <dael> [whiteboard]
# [17:43] <tantek> upward propagated? or hoisted?
# [17:44] <dael> rossen: overflow writing mode and background on gets cascaded to body. As soon as we have the cascade down to body, they upward propigate to the canvas.
# [17:44] <dael> fantasai: There's two ways to get this. If you dont have a body you have to have code for getting HTML to canvas.
# [17:44] <astearns> https://lists.w3.org/Archives/Public/www-style/2015Mar/0188.html
# [17:44] <dael> dbaron: The list I had that astearns found had 4 things.
# [17:45] <dael> dbaron: {reads the list] 1 and 4 are the main compat risks.
# [17:46] <koji> Which part of the minutes is dbaron reading?
# [17:46] <dael> Florian: I believe fantasai point is if you do reverse inheritience you can't forget to handle one of thes on 4.
# [17:46] <dbaron> https://lists.w3.org/Archives/Public/www-style/2015Mar/0188.html
# [17:46] <koji> never mind, I found it
# [17:46] <dael> dbaron: I believe we can't fix it. People already write sript.
# [17:47] <dael> dbaron: Also the code for the other thing we do in 4 is awful. The code for reverse inheritence.
# [17:47] <dael> dbaron: Do we even still do reverse inheritince of the other property?
# [17:47] <astearns> in the link search for "Gecko seems confusing" :)
# [17:47] * Quits: hyojin (~hyojin@public.cloak) ("Page closed")
# [17:47] <dael> fantasai: Overflow, background, cursor (maybe), direction and writing mode propigate up
# [17:48] <dael> ojan: For good measure, we dont' do cursor, we do image running and column gap.
# [17:48] <dael> Florian: By spec cursor goes from root, not from body.
# [17:48] <dael> fantasai: So image rendering is because it effect BG
# [17:48] <dael> esprehn: Yes.
# [17:48] <SimonSapin> s/image running/image-rendering/
# [17:49] <dael> fantasai: Backgrounds and overflow have I didn't set this values and they will prop based on if you set it on the root. If you didn't set it on root it prop from body. Cursor direction and writing modes are all inheritable. You can only tell if you have a body and you grab it and if you don't you use the root.
# [17:49] * Joins: antonp1 (~Thunderbird@public.cloak)
# [17:49] <dael> ojan: I don't think we do the thing where if the value isn't set we don't prop
# [17:50] <dael> fantasai: If you set a BG on the root and on the body, you need to assign the root element to the canvas.
# [17:50] <dael> ojan: I think we don't do that for overflow.
# [17:50] <dael> dbaron: BG doesn't effect computed values.
# [17:50] <dael> fantasai: If you set overflow scroll on the body and overflow hidde on the HTML then you scroll the doc and ignore the hidden?
# [17:50] <dael> ojan: I think so.
# [17:50] * Joins: johanneswilm (~johannes@public.cloak)
# [17:51] <dael> esprehn: Our code follows the spec. Where's rbyers? You wrote this.
# [17:51] <dael> esprehn: We don't look to see if it's set, we look to see what the viewport is set by and we pick that except for BG.
# [17:52] <dael> ojan: The thing on BG is more complicated, just for the record.
# [17:52] <dael> fantasai: [writes options on board]
# [17:52] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [17:53] <zcorpan> cursor doesn't propagate from body per spec, only from root. (seems blink follows the spec; gecko doesn't propagate cursor at all)
# [17:53] <dael> koji: The other option is that, I know it's from the last F2F, but since mostly the combine is about writing mode, we don't propigate but we just use HTML and body to decide principal writing mode. I guess thats' what we do. I haven't checked IE yet.
# [17:53] * zcorpan maybe that was already known
# [17:54] <dael> 1) propagate 'dir' attr, not 'direction' or ;writing-mode'
# [17:54] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [17:54] <dael> 2) propigate 'direction' and 'writing-mode' from BODY to FOO (HTML if not body)
# [17:54] * Joins: antonp (~Thunderbird@public.cloak)
# [17:54] <dael> 3) Propigate 'direction; from 'writing-mode' from BODY to HTML
# [17:55] <dael> fantasai: The first I don't think we can due to digipub.
# [17:55] <astearns> 3rd option replace the first 'from' with 'and'
# [17:55] <fantasai> (always from HTML to FOO)
# [17:55] <dael> fantasai: I think we can allow either 2 or 3, we can do both in the spec, it gets the same result.
# [17:55] * skk` lots of epub are distributed based on 2)
# [17:55] * Quits: antonp1 (~Thunderbird@public.cloak) (Client closed connection)
# [17:55] <dael> Florian: I'm not hearing anyone want to do 3.
# [17:55] <fantasai> s/do both/allow both/
# [17:55] <dael> Rossen: What was my kind of more general question. Are we trying to doc what everyone does or spec something most likely no one will impl.
# [17:56] <dael> fantasai: What do we want to do to get the content to work in the future?
# [17:56] <dael> dbaron: I think you should start form a table of accurate checked data of what each impl does in detail rather than figure it out in a working group.
# [17:56] <dael> Rossen: There's 4 prop and 2 elements to test.
# [17:56] <dael> astearns: And these tests should be in the test suit.
# [17:57] <dael> dbaron: I think we had a previous resolution to do the same thing for writing mode and direction, it wasn't defined what that thing was.
# [17:57] <dbaron> https://lists.w3.org/Archives/Public/www-style/2015May/0313.html
# [17:57] <dbaron> has a previous resolution
# [17:57] <dbaron> I think we should stick to the second relevant one
# [17:58] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [17:58] <dael> fantasai: The previous resolution was to handle the direction property by prop the dir at the HTML level so you would only look at the root, but then that won't work for writing mode if we need to do that. So we can't use that and writing mode and direction shoudl be same.
# [17:58] * astearns https://www.pinterest.com/pin/32088216067877852/
# [17:58] <dbaron> (I'm quoting indirectly via https://bugzilla.mozilla.org/show_bug.cgi?id=1169065#c1 )
# [17:58] <dael> Rossen: How about we come up witht he test cases.
# [17:58] <tantek> aside: I now have a public real world example of an input using :-moz-ui-invalid and :-moz-ui-valid - polyfilled to "work" while the user is typing, even before blurring the input element (which is the desired behavior) http://tantek.com/relmeauth/
# [17:58] <dael> fantasai: Let's resolve to propigate both and it doesn't matter how, we'll sort that our later.
# [17:58] * zcorpan Rossen you can still write the test cases :-)
# [17:58] <dael> ojan: I'm okay witht hat. If we resolve to spec what browsers do there would be agreement from the broswers here.
# [17:59] <dael> Florian: So we resolve to do 2 and if we discover it's more complex with test cases we'll deal with it.
# [17:59] <dael> Rossen: Yes.
# [17:59] * fantasai invite r12a
# [17:59] * Rossen zcorpan I'm very selective on how I spend my time
# [17:59] <dael> dbaron: I think 2 is prob the most compatable, but we should check.
# [17:59] * Joins: r12a (rishida@public.cloak)
# [17:59] * fantasai waves to r12a
# [18:00] <fantasai> we're dicussing writing modes
# [18:00] * zcorpan Rossen then what are you doing here?
# [18:00] * r12a waves back
# [18:00] <dael> Florian: If test cases expose that as not what broswers do then depending on what we've found we discuss again.
# [18:00] <dael> RESOLVED: propigate 'direction' and 'writing-mode' from BODY to FOO (HTML if not BODY)
# [18:00] * Rossen zcorpan selecting work
# [18:00] <dael> to be reopened if tests show this isn't the way it's being done already
# [18:00] <dael> fantasai: Next is the sideways-left value
# [18:00] * astearns Rossen you can't be that selective since you agreed to co-chair
# [18:01] <fantasai> https://drafts.csswg.org/css-writing-modes/issues-cr-2014#issue-41
# [18:01] <dael> Florian: This one we agreed except jdagget.
# [18:01] <dael> hober: Sideways-left is when you need to know how long the run is?
# [18:01] <fantasai> https://drafts.csswg.org/css-writing-modes/issues-cr-2014#issue-41
# [18:01] <fantasai> https://lists.w3.org/Archives/Public/www-style/2015May/0092.html
# [18:01] <dael> Florian: It lets you have arabic and japanese and they both go down and we're switching to a model where you cannot switch that inline anymore. S
# [18:02] <dael> fantasai: We're at the issue that's been discussed. I went over it on the call before.
# [18:02] <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jul/0060.html
# [18:02] <dael> fantasai: Prop is to change the way writing mode and text oreintation are org to remove sideways left from text orientation and instead add to writing mode sideways-lr and -rl
# [18:03] * r12a https://www.w3.org/2015/08/mail.php?subject=https%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fwww-style%2F2015Jul%2F0060.html&;list=
# [18:03] <dael> Florian: By removing sideways left from text orientation it means we only have sideways and sideways right which means we don't need wideways right. So that applies to some, but not all writing modes. So CJK works the same. In addition to text orientation doing nothing on horizontal, it also does nothing on sideways-lr and -rl
# [18:03] <liam> why doesn't it show the mailing list?
# [18:04] <dael> Florian: So sideways-lr is the one you put on the left side cation in english and they do everything you would expect. It's one value that says do the right thing when flipping a language on the side.
# [18:04] <liam> s/why doesn't it show the mailing list?//
# [18:04] * liam oops, wrong window
# [18:05] * Joins: adenilson_ (~anonymous@public.cloak)
# [18:06] <dael> Florian: In the addition to the impl difficulty of sideways-left, another downside is that it was biased to CJK. We are losing the ability to do downwards arabic in Japanese or similar. According to liam they exist. I've tried to find examples by contacting professors and eventually pointing me to r12a after a few hops. It's rare and we can add it back later if we want to.
# [18:06] <dael> Florian: We can fix it later, but we may never need to given how few people care.
# [18:07] <dael> dbaron: Who is the audience for this. One of the people that cares deeply isn't here. But it's not an empty set, so okay.
# [18:07] <dael> astearns: As far as I understand the prop I like it and don't need it desc further.
# [18:08] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [18:08] <dael> fantasai: The ML comments were jdaggett didn't think this made sense initially and now I'm not sure where he thinks it is. r12a thought about it for a while and said he likes it a bit better and all of the questions I've been getting are from non-CJK users asking if this will solve their prblems. This prop would make it more straight foward for those people.
# [18:09] * Quits: adenilson (~anonymous@public.cloak) (Client closed connection)
# [18:09] * adenilson_ is now known as adenilson
# [18:09] <dael> Florian: Gievn that everyone who cares except jdagget agrees and he disagrees less than he used to...we had two threads one where he said if we do this can we change the name which isn't an objection.
# [18:10] <r12a> note that i actually think the new approach *solves* some problems i was struggling with with the old approach (see https://lists.w3.org/Archives/Public/www-style/2015Aug/0217.html)
# [18:10] * Quits: antonp (~Thunderbird@public.cloak) (Ping timeout: 180 seconds)
# [18:10] <dael> liam: You mentioned my name by saying these exist. We had a question in XSLFO working group about where an underline would go in that odd case, but because someone asked doesn't mean some one does it. We just had an impl who was talking about it.
# [18:10] * Quits: dino (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
# [18:10] * Joins: antonp (~Thunderbird@public.cloak)
# [18:11] <dael> SteveZ: I don't understand b/c I haven't looked carefully. It seemed the critical thing was instead of being enginers and giving a matrix, you said what do people want to do and give a label to those things and make those easy to do.
# [18:11] <dael> Florian: [goes through and points out how most cases are covered]
# [18:11] <liam> s/odd case/case/
# [18:11] <dael> SteveZ: For the two verticals I use text orientation to say if I rotate the embedded non CJK things.
# [18:12] <dael> SteveZ: Since japanese are often trying to choose between upright and sideways
# [18:12] <dael> Florian: Yes. The CJK authors are more likely to be away of having something like this exist.
# [18:12] <dael> SteveZ: Without deep thought I like it.
# [18:12] <dael> fantasai: I would have made the initial value upright if we had thought of this originally.
# [18:13] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [18:14] <dael> hiroshi: sideways-rl and -lr are a bit confusing because writing-mode is to make the characters vertical. sideways it to make latin go to the side. In this situation, my opinion is to get rid of sideways for not and use only rotate. That's enough fo rthe side captions and think about bidi in level 4.
# [18:15] <dael> fantasai: We don't have to worry about bidi. It's for the line orientation. Transformations doesn't solve the problems of non-CJK users. If you transform from horizontal text you are not taking up space in the layout. If you use vertical-lr and try and use sideways you have a problem where scrollbars and buttons do not look the right way. A lot of things won't work correctly.
# [18:15] * Quits: kwkbtr (~kwkbtr@public.cloak) ("")
# [18:15] <dael> hiroshi: There might be a lot of discussion concerning sideways-lr.
# [18:15] <dael> Florian: Maybe a middle of at-risk.
# [18:15] * Joins: MaRakow (~MaRakow@public.cloak)
# [18:16] <dael> fantasai: Maybe. I think it's a strong use case outside of Japan. I think web authors would be upset if they couldn't get the effects that are important to have. AS r12a said in IRC there are a lot of people that cared about those cases.
# [18:16] <dael> Florian: Marking at-risk might be good because if browsers support them they're okay and Japaense users won't agonize because they won't be waiting on those for it to progress.
# [18:16] * Bert 's first idea was like Hiroshi's: transform would do it... if only it affected layout.
# [18:17] <dael> RESOLVED: switch to the new model, make sideways-lr and -rl at risk. Revisit if jdagget objects because he's not here.
# [18:17] <dael> plinss: We're over time, is the more urget thigns on writing modes?
# [18:17] * Ms2ger zcorpan / krit / cabanier: r? https://github.com/w3c/csswg-test/pull/834
# [18:17] <dael> fantasai: That's it.
# [18:17] <dael> Topic: Mozilla being okay with keyframes.
# [18:17] <koji> 47?
# [18:17] <dael> dbaron: I need to read the text. If I'm okay with it I can edit into the spec
# [18:18] <dael> ACTION dbaron review the keyframes proposal
# [18:18] * trackbot is creating a new ACTION.
# [18:18] <trackbot> Created ACTION-720 - Review the keyframes proposal [on David Baron - due 2015-09-03].
# [18:18] <dael> Topic: snapshot
# [18:18] <fantasai> https://drafts.csswg.org/css-2015/#experimental
# [18:18] <dael> fantasai: How do people feel about thenew text? I've gotten positive feedback, do we want to adopt thenew text.
# [18:18] <dael> Florian: I do.
# [18:18] <dael> tantek: It's good enough to ship. Do the people who obj before think it's good. enough.
# [18:18] <dael> gregwhitworth: I'm good.
# [18:19] <dael> dbaron: Is this revised since dinner?
# [18:19] <dael> fantasai: Yes, I tried to handle your concerns.
# [18:19] <dael> smfr: I don't find the wide things helpful.
# [18:19] <smfr> s/wide/why
# [18:20] <dael> TabAtkins: I try to use those when it's a long note that's not helpful to everyone.
# [18:20] * heycam is now known as heycam|away
# [18:20] <dael> Florian: I think the why is important so it's better not to hide. This isn't spec level prose with unambig meaning and therefore the why is important.
# [18:20] <dael> TabAtkins: Okay.
# [18:21] <dael> plinss: Everyone okay? Need more time?
# [18:21] <dael> smfr: You talked to hober?
# [18:21] <dael> fantasai: About the part he was obj to. There's three sub sections. First was the one hober was unhappy about. The other two have also been revised based on other feedback.
# [18:21] <dael> smfr: I think we'd like to review internally more because I think there are people itnerested who aren't in the group.
# [18:22] * zcorpan Ms2ger r+
# [18:22] <dael> tantek: Can we give you to the next telecon?
# [18:22] <dael> fantasai: Two weeks?
# [18:22] * Ms2ger zcorpan thanks
# [18:22] <dael> SimonSapin: Is there a meaning to the green text?
# [18:22] <dael> Florian: What changed at dinner.
# [18:22] <dael> fantasai: I'll remove the underlines once dbaron says okay.
# [18:23] <Florian> s/at dinner/after dinner/
# [18:23] <dael> plinss: So we'll loop back next telecon.
# [18:23] <dael> fantasai: I want a sense if everyone i nthe room agrees.
# [18:23] <dael> astearns: I suspect Tav will be very interested in the insert that says support for prefixes should be removed.
# [18:24] * Rossen is now known as Rossen_away
# [18:24] <tantek> s/Tav/Ted
# [18:24] <tantek> hober (I think)
# [18:24] <smfr> yes, hober
# [18:24] <fantasai> s/Tav will/Apple will/
# [18:24] <dael> Florian: This is the model where prefixes are shipped early when unstable and then once it ships the regular version should be used. Since we don't live in the perfect world it might work differenlty. This isn't you should remove the old fashioned prefixes.
# [18:25] <dael> plinss: Anyone in the room have comments?
# [18:25] <dael> fantasai: Positive or negative.
# [18:25] <tantek> +1
# [18:25] <plinss> +1
# [18:25] <Florian> +1
# [18:25] <dauwhe> +1
# [18:25] <dael> fantasai: Type +1 if you like it -1 if you don't, 0 if you don't care.
# [18:25] <leaverou> +1
# [18:25] <ChrisLilley> +1
# [18:25] <dael> dbaron: I might have worded one of the thing differently.
# [18:25] <dael> fantasai: Suggest edits.
# [18:25] <rachelandrew> +1
# [18:25] <liam> +1
# [18:25] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [18:25] <MaRakow> 0
# [18:25] <SimonSapin> +1
# [18:25] <gregwhitworth> +1
# [18:26] <dael> plinss: We'll loop back to this on telecon.
# [18:26] <jet> +1
# [18:26] <astearns> 0
# [18:26] * dauwhe needs more rfc6919
# [18:26] <dael> Florian: Do we discuss in 2 weeks or resolve for now.
# [18:26] <dael> plinss: We're expecting more feedback so we'll resolve in two weeks.
# [18:26] <dael> Topic: flexbox % follow-up
# [18:26] <dael> TabAtkins: There has not been further discussion.
# [18:27] * Quits: smfr (~smfr@public.cloak) (smfr)
# [18:28] <dbaron> Vendors should make it possible for other implementors to freely
# [18:28] <dbaron> implement any features that they do ship. To this end, they should
# [18:28] <dbaron> provide spec-editing and testing resources to complete standardization
# [18:28] <dbaron> of such features, and avoid other obstacles (e.g., platform dependency,
# [18:28] <dbaron> licensing restrictions) to their competitors shipping the feature.
# [18:28] <dael> tantek: Only futher I remember is looking at the way abspos handles % in general is internally inconsitant in abspos. You've got top where % is height and margin where it's % in width etc. So in al the different ways there are potential tradeoffs, changing vertical % on abspos elements to also be % height based makes the more interally consistant. All the horx become wdith based and vert becomes height. That adds more weight to option 1
# [18:28] <dael> s/1/3
# [18:28] <dael> tantek: I don't know if that changes anyone's opinion, but it may add more weight to solve this disagreement.
# [18:28] <dael> plinss: Anyone who weighed in have you changed your minds? Or people willing to raise new objections?
# [18:29] <dael> tantek: There was new information to keep considering this, so who knows if someone will find more information.
# [18:30] <dael> fantasai: The other thing tantek brought up, which I totally disagreew ith block beign legacy, but the usage of % will be much reduced because the kinds of layout where you'll use % margins and padding you'll prob be in grid or flex not block.
# [18:30] <dael> plinss: Alright.
# [18:30] <tantek> agreed with fantasai
# [18:30] <dael> plinss: It sounds like we can't close this, so continue discussion.
# [18:31] <dael> esprehn: Would you withdraw your obj to withdraw your obj to flexbox if we persued the same mode prop (?)
# [18:31] <astearns> s/same/sane/
# [18:31] <dael> tantek: I think this would help move a mode forward. We could treat this like an error where the web community says they're fixing this or they say this is crazy stupid and helps us judge if the sane mode would be judged as sane. I see this as a good idea and a way to gain market feedback. Does that make sense?
# [18:31] <dael> esprehn: Yes.
# [18:32] <dael> Jet: Does MS and Google both have interop shipping?
# [18:32] <dael> gregwhitworth: They're not the same.
# [18:32] <dael> jet: WE're about the ship.
# [18:32] <dbaron> dbaron: We shipped already
# [18:33] <dael> gregwhitworth: MS edge and flexbox agree and moz. In NY the abspos situation was brought up. And as tantek says we'll continue the discussion.
# [18:33] <dael> tantek: It's clear we have to say something. But it's more clear to me this is the way to solve it.
# [18:33] <tantek> the way being dimensionally consistent
# [18:33] <dael> ojan: We can experiemnt in chrome to see if there's mostly mobile content that would breka, btu I don't know if that's useful.
# [18:34] <dael> gregwhitworth: By all means share, but it's not like we don't do mobile testing. YOu have much larger market share. I think that Apple would have the same.
# [18:34] <dael> gregwhitworth: I don't know how many hundreds of millions we do, but I recieve a lot of bugs so we test a lot.
# [18:34] <dael> ojan: On Tuesday gregwhitworth you said you could find us a list of sites. that use % in margins, if you could bring that.
# [18:34] <dael> ojan: I'm trying to understand the non-aspect ratio cases.
# [18:35] <dael> tantek: Did we capture that there's user demand for aspect ratio.
# [18:35] <dael> TabAtkins: It's in the minutes. Lots of time.
# [18:35] * Quits: BogdanBrinza (~bbrinza@public.cloak) ("")
# [18:35] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [18:35] <leaverou> aw, and we didn't take a group photo in the bikeshed downstairs after all :(
# [18:35] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [18:35] <dael> plinss: We are adjourned. Thank you mozilla!
# [18:36] <tantek> leaverou: no group photo at all!
# [18:36] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [18:36] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [18:36] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:37] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [18:40] * Quits: MozParis (~MozParis@public.cloak) (Ping timeout: 180 seconds)
# [18:43] * Quits: skk (~skk@public.cloak) (Ping timeout: 180 seconds)
# [18:43] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [18:44] * Joins: skk (~skk@public.cloak)
# [18:44] * Quits: ChrisLilley (clilley@public.cloak) (Ping timeout: 180 seconds)
# [18:44] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [18:46] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [18:48] * Quits: dael (~dael@public.cloak) ("Page closed")
# [18:53] * Joins: dauwhe (~dauwhe@public.cloak)
# [18:59] * Quits: skk (~skk@public.cloak) (Ping timeout: 180 seconds)
# [18:59] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [19:03] * shepazu_ is now known as shepazu
# [19:03] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [19:08] * Joins: Tav (~tbah@public.cloak)
# [19:08] * Quits: joone (~joone@public.cloak) (Client closed connection)
# [19:08] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [19:10] * Joins: joone (~joone@public.cloak)
# [19:10] * Joins: darktears (~darktears@public.cloak)
# [19:12] * Quits: tantek (~tantek@public.cloak) (tantek)
# [19:21] <SimonSapin> leaverou: http://result.dabblet.com/gist/228f4333784188df9ea2/94cdb6490c910ac60215d44e45557f218b0c18c9
# [19:23] <leaverou> SimonSapin: ping
# [19:23] <SimonSapin> leaverou: http://result.dabblet.com/gist/228f4333784188df9ea2/94cdb6490c910ac60215d44e45557f218b0c18c9
# [19:35] * Quits: andreyr (~andreyr@public.cloak) (Ping timeout: 180 seconds)
# [19:40] * leaverou is now known as leaverou_away
# [19:44] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [19:58] * Joins: myles (~Adium@public.cloak)
# [20:01] * Joins: {Darktears} (~darktears@public.cloak)
# [20:06] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [20:17] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [20:39] * Quits: bkardell_ (~uid10373@public.cloak) ("Connection closed for inactivity")
# [20:43] * Joins: nvdbleek3 (~nvdbleek@public.cloak)
# [20:44] * Quits: nvdbleek (~nvdbleek@public.cloak) (Client closed connection)
# [20:44] * nvdbleek3 is now known as nvdbleek
# [20:59] * Joins: darktears (~darktears@public.cloak)
# [21:01] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [21:02] * Quits: {Darktears} (~darktears@public.cloak) (Ping timeout: 180 seconds)
# [21:11] * Quits: Ms2ger (~Ms2ger@public.cloak) ("Leaving")
# [21:37] * Quits: myles (~Adium@public.cloak) ("Leaving.")
# [21:40] * Joins: dauwhe (~dauwhe@public.cloak)
# [21:55] * Quits: nvdbleek (~nvdbleek@public.cloak) (Client closed connection)
# [21:58] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [22:00] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [22:08] * Joins: darktears (~darktears@public.cloak)
# [22:09] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [22:11] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [22:18] * Joins: dauwhe (~dauwhe@public.cloak)
# [22:29] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [22:30] * Joins: dauwhe (~dauwhe@public.cloak)
# [22:37] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [22:56] * Joins: liam (liam@public.cloak)
# [22:56] * Joins: dauwhe (~dauwhe@public.cloak)
# [22:57] * Joins: antonp1 (~Thunderbird@public.cloak)
# [22:57] * Quits: antonp (~Thunderbird@public.cloak) (Client closed connection)
# [22:57] * antonp1 is now known as antonp
# [22:57] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [22:58] * Joins: tantek (~tantek@public.cloak)
# [23:04] * Joins: skk (~skk@public.cloak)
# [23:06] * Joins: Florian (~Florian@public.cloak)
# [23:09] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [23:15] * Joins: johanneswilm (~johannes@public.cloak)
# [23:24] * Rossen_away is now known as Rossen
# [23:24] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [23:24] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [23:25] * Joins: dauwhe (~dauwhe@public.cloak)
# [23:25] * Joins: johanneswilm (~johannes@public.cloak)
# [23:26] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [23:26] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [23:26] * Quits: dauwhe_ (~dauwhe@public.cloak) ("")
# [23:29] * Joins: estellevw (~estellevw@public.cloak)
# [23:30] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [23:39] * Quits: skk (~skk@public.cloak) (Ping timeout: 180 seconds)
# [23:46] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [23:46] * Joins: johanneswilm (~johannes@public.cloak)
# [23:50] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [23:54] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [23:55] * Quits: darktears (~darktears@public.cloak) ("Leaving...")
# [23:56] * Joins: myles (~Adium@public.cloak)
# Session Close: Fri Aug 28 00:00:00 2015

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