00:00:08 Florian: target-counteR(), when it doesn't refer to pages, I don't see any reason why it wouldn't be useful o nthe Web. 00:00:19 Florian: Can do "See Figure 17", nothing wrong with having that on the Web. 00:00:29 Florian: Until you care about pages, might not do page counter references, though. 00:00:54 TabAtkins: Mark it at-risk 00:01:12 ojan: What if we had two specs. "here's generated content as it is in browsers today" and "here's generated content for print" 00:01:20 s/print/pagination/ 00:01:22 ... 00:01:44 plinss: If you say never gonna implement this, I think you're going to be wrong. Can't tell your business interests 5 years from now. 00:01:44 q? 00:01:49 plinss: But also, you're not the only browser 00:02:07 esprehn: If you have something doing layout totally diferent, e.g. mathml 00:02:13 esprehn: We're not goin gto spec that, you can't do that 00:02:31 esprehn: I think making the string thing, take the text content value of a node, it's a cycl ein aglorithm, violates fundamental constraints of how the system work 00:02:53 Florian: I agree with that, and that's why I want this discussed here so that we spec it in a way that doesn't violate fundamental constraints 00:03:23 [repetition of existing points] 00:04:11 fantasai: also Elliot I think you're missing the point, gcpm can be used for other things 00:04:15 q? 00:04:17 s/gcmp/target-counter/ 00:04:33 esprehn: We're not going to ever add more features to counters. 00:04:41 esprehn: We want people to write JS for counters. 00:04:59 plinss: CSS doesn't define what's implemented in C++ 00:05:11 q? 00:05:15 esprehn: Do you realize that there are tons of CSS authors that do not *know* JS? 00:05:30 esprehn: you are complicating the web platform for authors with this kind of thinking. 00:05:45 esprehn: HTML had a sorting algorithm, was never implemented, and it was removed, and people can implement it in JS 00:05:50 leaverou: implemented in JS won't mean unusable by CSS authors - the whole point of Houdini is to open CSS up to extensibility 00:05:58 q+ 00:06:09 tantek: That was also before incubation and stuff 00:06:25 shane: Using libraries has a ton of overhead. First you need to find the best library, you need to bear the bandwidth cost, you need to learn its documentation, often switch to another library halfway through etc etc 00:06:46 fantasai: this is a draft, you can cut this down we get to the put that browsers need to consider implementing it 00:06:47 shane: Libraries are not the solution for essential functionality. Library authors are not spec writers and will often create worse APIs 00:06:53 q? 00:06:54 leaverou: Yes, of course we realize that. We also realize that the stdlib *cannot* be extended infinitely, nor do we want to forever hijack *every feature forever* on how quickly browsers can cycle their implementation. 00:06:55 Tantek: if that is true then call it something else 00:07:33 fantasai: we are replacing those drafts with something new, and we're going for a FPWD from the old scope of that module and should have the same shortname, etc. 00:07:43 TabAtkins: Then allow people to conditionally import modules, but standardize said modules instead of having them hunt down libraries which could be terrible. 00:07:55 tantek, you wanted to discuss positive framing of implementation types 00:08:00 tantek: I want to suggest a path forward, if there's a dispute wrt implentability, indicate in the draft 00:08:13 tantek: e.g. put a box explaining the implementaiton experience 00:08:25 tantek: and caveat of whether it's stabilizing, or is very shaky etc. 00:08:31 it seems to me that Houdini is used as an excuse to not implement anything Google devs don't like 00:08:35 tantek: Give authors anyone els reviewing spec a chance of what's the context of evaluating this feature 00:08:57 tantek: This feature has some print implementation, but no browser implementations yet, pls send feedback, at least that's conveyed to authors. 00:08:58 dael has joined #css 00:09:03 tantek: Rather than misconveying any intent 00:09:37 tantek: E.g.features that are widely-implemented vs not implemented at all labelled separately to help with reviewers 00:09:42 q? 00:09:52 tantek: So my request is to put per-feature, implementation experience and suggestions for feedback 00:10:00 rniwa has joined #css 00:10:12 dauwhe: We have a mechanism for doing that already: test results per browser 00:10:30 dauwhe: If we extend that alittle bit, can see that Prince/ AH/etc. that are passing, that gives you the information you need 00:10:41 dauwhe: If yo usee that the tests pass in blink/safari/edge, useful information too 00:10:48 astearns: Script that does the annotations could be more verbose 00:11:00 dauwhe: You can filter on that information, all sorts of things. This is data we can get 00:11:09 dbaron, you wanted to ask about flip side of not saying where things are targeted 00:11:09 dauwhe: Might make us write more test,s, all sorts of things 00:11:10 q? 00:11:22 dbaron: Peter said something earlier about not wanting the spec to say that a spec was intended for print 00:11:25 ? 00:11:52 dbaron: My general feling is that we don not write enough of what our intent was into the specs, and that hurts our ability communicate with the ppl reading the specs and tryin got understnad them. 00:12:03 dbaron: I think we should have more informative text in specs saying why what's there is there and what it was intended for and so on 00:12:42 dbaron: And one of the other worries I have is, if we don't say that things rae intended for print, then essentially there's an incentive for me to try and make things not be in the spec because i'm worried about the risk that some junior developer at Mozill awill try to implement a thing that they shouldn't spend time on 00:12:46 exactly the problem 00:12:58 dbaron: But they saw it in the spec and thought we should implement it 00:13:01 or you get some advocacy groups pushing for something 00:13:17 jensimmons: I just wanted to toss in that I think we should be careful not to assume what a browser is 00:13:33 jensimmons: Not say "there's real browsers and there's ebook readers, and there's print, and we don't care about B and C" 00:13:39 q+ 00:13:42 jensimmons: There are lots of experiments happening around what is a browser 00:13:54 jensimmons: This is goint ot come up a lot. What a browser is is going to change. 00:14:13 gregwhitworth: Lea commented in IRC. 00:14:18 q? 00:14:29 q- 00:14:50 gregwhitworth: She was saying that there are a lot of CSS devs that don't know JS, and we're overcomplicating things 00:15:09 ChrisL: Lea doesn't disagree with Houdini existing. Disagrees that Houdini should be used as a blunt hammer for everything. 00:15:18 yup 00:15:41 I've seen it used way too much as an excuse to not implement or spec things that authors need. 00:15:45 no no, we have incubation to use as the blunt hammer for everything. 00:16:08 TabAtkins: The circular ones should be dropped from expectation for browser implementations 00:16:39 TabAtkins: depends on what you define as a browser. Is a print formatter a browser? 00:16:54 fantasai: I'm happy to keep discussing technical issue,s would like to close the scoping issue 00:17:24 Florian: Other topic, not GC, is interaction between Media Queries and @page { size } 00:17:28 Florian: Anyone want to discuss this now? 00:17:54 Florian: Probably shoudl talk about something other than pages, because everone is hating on pages right now. 00:18:02 dauwhe: 3D transforms? :) 00:18:10 astearns: Test metadata!!!!!! 00:18:14 Topic: Testing 00:18:43 gsnedders: We basically have consensus on getting rid of a lot flags 00:19:09 I'm curious how many folks in the room are actively interested in this subject 00:19:29 http://testthewebforward.org/docs/css-metadata.html 00:19:56 For the purpose of this discussion, "a browser" is "the things developed by the browser vendors here in the room". 00:20:01 gsnedders: If we want to get browsers actually running the test suite, then we need to get browser vendors to actually talk about this. 00:20:41 tantek: What spec is held up in CR that's going to motivate this discussion 00:20:58 fantasai: Geoffrey is the hammer that's going to motivate us 00:21:14 gsnedders: The metadata thing is actually smaller bit 00:21:16 Geoffrey, The Scottish Hammer https://www.youtube.com/watch?v=15M9b6PAdro 00:21:30 gsnedders: Big thing I want to discuss is stuff like how we want to deal with test review in the future 00:21:36 gsnedders: How we want to deal with issues on tests in the future 00:21:55 gsnedders: Because at the moment we have this weird split system with pull requests on GitHub which get reviewed before merging 00:22:07 gsnedders: whereas other things are just pushed directly to Mercurial 00:22:14 gsnedders: In principle, sometime in the future, butrealistically never, they get reviewed 00:22:32 gsnedders: in my opinion it makes sens to move everything to github PRs with review before merging 00:22:44 gsnedders: realistically, there's no motivating factor for ppl to review tests before they're landed 00:22:50 gsnedders: saw this with 2.1 as well 00:22:58 gsnedders: Just moved everything to approved, thousands of tests never gonna review 00:23:07 gsnedders: Would like to avoid ending up in that state again 00:23:13 first piece of feedback, no content in HTML/SGML comments please. e.g. "" bad. Instead, slap it on the end of the title attribute, e.g. title="NAME_OF_REVIEWER, YYYY-MM-DD" 00:23:26 (kind of like how people sign documents) 00:23:28 astearns: Got a bit of history because we had tons of tests waiting for review in Shepherd, that we new would never get fixed 00:23:36 old man tantek, actually typing the letters "sgml" in sequence 00:23:44 astearns: tests hanging as Github PRs isn't great either 00:23:55 TabAtkins: (yeah so busted) 00:24:02 dbaron: I don't think reviewing tests is particularly a good use of time. Particularly the way they have been reviewed so far 00:24:18 dbaron: I think a bunch of test reviewers have given feedback of more or less "go away" 00:24:29 dbaron: Also best way to to review tests is to write an impl, and to see if the tests pass 00:25:09 dbaron: And the important thing to check for is that the test tests what it thinks it's testing. 00:25:30 1) Test pass when it's supposed to pass 00:25:39 2) Test fails when it's supposed to fail 00:25:39 could http://testthewebforward.org/docs/css-metadata.html cite the previous documentation of the CSS WG test suite documentation? 00:25:44 3) Tests what it thinks its testing 00:25:46 fantasai: 3 things to check: (1) passes when it's supposed to pass, (2) fails when it's supposed to fail, and (3) tests what it's thinks it's testing 00:26:09 ScribeNick: iank_ 00:26:30 fantasai: I've seen some tests which only pass sometimes, for example when it depends on the width of the window 00:26:33 dbaron: Implementers are probably going to catch 2 00:26:38 s/2/1/ 00:26:59 what happened to atomic vs basic tests as Hixie and I had distinguished so you could check whether something implemented anything at all? 00:27:15 fantasai: You can have tests which are mislabled. 00:27:21 digs up https://www.w3.org/Style/CSS/Test/testsuitedocumentation.html 00:28:10 tantek: we badly need to sort out the fact we have contradictory documentation all over the place… 00:28:16 fantasai: I think that dbaron has a good point that (1) is going to be checked by browsers, (2) & (3) you should check for, you may as well check for everything 00:28:26 gsnedders: could you start by citing the previous documentation? 00:28:29 dbaron: I think that web platform tests have worked out a model that works here. 00:28:37 (I mean inline in the css-metadata doc) 00:28:50 dbaron: I'm pretty close to telling people to create a folder in the wpt repo at the moment. 00:29:16 fantasai: in terms of review process to we review then land or visa versa? 00:29:48 ah this is the one I was looking for https://www.w3.org/Style/CSS/Test/guidelines.html is a good predecessor to cite for css-metadata.html 00:29:52 dbaron^: This is largely due to preprocessing issues 00:30:05 fantasai^: Agree that this is an issue we should fix, but back to gsnedders issue on review 00:30:11 dbaron: for wpt as a gecko dev, i can just check in the repo, and a moz dev will deal with it working. 00:30:17 in w-p-t there's an extra motive to review: you start running them when they land 00:30:20 e.g. that guidelines.html has the rel=author, and rel=help aspects 00:30:29 in csswg-test, there isn't that if the test is already in the repo 00:30:54 ojan: we have chrome folks that are working on better wpt integration tests. 00:31:13 zcorpan: WPT, review from the browser vendor means you just merge the tests 00:31:20 ojan: Doing future things in wpt will be good for us. 00:31:49 for w-p-t, the browser vendor review must be public for free landing 00:33:19 Florian: Simply the review process, decrease the amount of meta-data, remove the build system, and once we've done that we've done a lot. If we do this, then we can re-evaluate if we need to do other things. I would not want to start by dropping things that we know that have value. 00:34:08 ChrisL: Should keep the metadata, as difficult for people to know what the test is testing. 00:34:28 gsnedders: WPT has loose rule that the reviewer must be able to understnad what hte test is doing 00:34:35 gsnedders: How you communicate that to the reviewer, isn't really statd 00:34:38 gsnedders: can put in an HTML comment 00:34:44 gsnedders: Could be completely obvious cuz it's a 2-line test 00:34:51 gsnedders: No point in actually stating forms of how it must be 00:34:55 gsnedders: Merely gate it on the review 00:35:05 gsnedders: but that only works if you do the review before merging 00:35:16 q+ 00:35:18 MaRakow has joined #CSS 00:35:28 zakim, open the queue 00:35:28 ok, astearns, the speaker queue is open 00:35:31 fantasai: For our purposes, having links to the sections test helps us a lot 00:35:34 q+ 00:35:58 fantasai: Not just for revie,w but also to generate test coverage reports, implementation reports, and to know which tests need to be updated when the spec changes. 00:36:08 q+ 00:36:12 q+ 00:36:14 fantasai: So I think having this in a fixed format is useful and important to try to keep 00:36:20 fantasai: With regards to other metadata 00:37:01 fantasai: WPT have slightly different format because they use a lot of JS tests that are combined in one file, so having HTML comments etc. as documentation makes sense, per-file dat is not going to be as useul 00:37:27 fantasai: Whereas in reftests ,more granular per test 00:38:12 fantasai: I don't see a problem with pulling out the comment on the test, having it in a standard format rather than just in a random HTML comment somewhere 00:38:22 fantasai: Comment being the documentation of what it's testing 00:39:03 fantasai: Just as a function has a formalized comment at the top saying its purpose and its parameters, 00:39:15 fantasai: So that it can be used and understood and reimplemented if necessary, so should a test 00:39:25 fantasai: This is independent of clearly-written code with good comments. 00:39:27 bradk_ has joined #css 00:39:28 q- 00:39:43 Florian: On the assertion itself, I think that's one of the things that we may need to come back to later 00:39:49 Florian: if it's getting in the way 00:39:56 Florian: But I don't think we should do this until we've cleared out all the other problems 00:40:10 Florian: And have determmined that it's still a blocker. Not a godo place to start from 00:40:28 Florian: Fwiw, this is less necessary in JS tests. Because yo uhave an assertion written as code. 00:40:32 Florian: But in CSS tests, that's not the case 00:40:47 Florian: We might need to drop that description eventually, but let's not start here. 00:40:59 Florian: As for what we cando, with regards to links to specs, I think we can sort of have best of both world 00:41:10 Florian: You store your test in predefined directory structure, points to the right par to fthe spec 00:41:15 bradk__ has joined #css 00:41:25 Florian: But should you wish to link to extra information to link to other sections of the spec, then you can add more such links 00:41:30 Florian: Not blocking 00:41:39 Florian: Another bit of metadata is the title 00:41:52 Florian: HTML requires a so we have to have one, But can say put anything in it 00:41:58 <fantasai> Florian: Wrt author /reviewer, leave that to source control 00:42:05 <fantasai> Florian: Wrt flags, I think we can get rid of most of them 00:42:09 <fantasai> Florian: Make them a niche occurrance 00:42:18 <fantasai> Florian: Spending something like 10-15 min going thorugh list might be useful 00:42:29 <fantasai> Florian: but should do that 00:42:35 <astearns> q? 00:42:39 <tantek> I don't think it's useful to brainstorm this realtime here 00:42:49 <fantasai> Florian: I think we do that for title, keep assert meta, get rid of author meta etc. simpify flags, simplify reviewer process 00:42:58 <fantasai> Florian: If we just do these bits then we'll have done a lot 00:42:58 <tantek> I'd rather read a proposal, e.g. a delta on what gsnedders has already put forth 00:43:06 <fantasai> Florian: Then we can discuss why not 00:43:13 <fantasai> Florian: But not to do more than that 00:43:15 <fantasai> Florian: yet 00:43:25 <fantasai> zcorpan: In WPT, you can put link to the spec using <link> element 00:43:33 <fantasai> zcorpan: But can also infer from directory structure 00:43:36 <gsnedders> tantek: as would I, but there's almost no replies on the mailing list to much of what I say :( 00:43:40 <fantasai> zcorpan: by spec/id 00:44:00 <tantek> gsnedders, yes, I understand why you brought it to the f2f agenda, that part makes sense 00:44:17 <fantasai> fantasai: I'm ok with this, as long as that information is avialable nad ppl writing tests for cross-seciton or cross-spec interaciton are able to add <link>s 00:44:33 <fantasai> zcorpan: OK with requiring assert for reftests, but less so for testharness.js 00:44:37 <fantasai> Florian and fantasai agree 00:44:37 <astearns> ack next 00:44:38 <tantek> my point is that if someone here wants to take the time to make counter proposals beyond "here's a simple fix" (e.g. see my suggestions above ;) ) then they can be actioned to write up a longer proposal 00:44:45 <astearns> ack next 00:45:21 <tantek> q+ to request a resolution to not put content in HTML comments, e.g. use title attr instead 00:45:31 <fantasai> [discussion of where to track reviewer information] 00:45:49 <fantasai> plinss: I would argue against removing any existing metadata, but remove requirement to put it in 00:45:53 <tantek> +1 00:46:01 <fantasai> gsnedders: Question remains, how do we flag that a test has been reviewed? 00:46:19 <fantasai> plinss: If there is a reviewer flag, shepherd will mark it reviewed. But otherwise Shepherd will track it 00:46:32 <fantasai> plinss: Merging GitHub PR also counts as a reviewer 00:46:44 <fantasai> RESOLVED: Drop requirement for author or reviewer metadata 00:47:27 <fantasai> RESOLVED: Move to primary <link> to spec being inferred from directory structure. Supplemental <link>s must be inline. 00:47:43 <fantasai> s/spec/spec+section/ 00:48:27 <tantek> not hearing consensus 00:48:35 <fantasai> plinss: Do we have nested sections? 00:48:41 <fantasai> fantasai: No. Just spec/fragID 00:48:53 <fantasai> fantasai: We move sections around or change their nesting level. But we keep the fragID stable. 00:48:57 <rniwa> rniwa has joined #css 00:49:14 <fantasai> plinss: So I propose we have shortname + leafesectionid and N levels in between 00:49:25 <fantasai> plinss: We ignore the levels in between, they can be named anything. 00:50:03 <fantasai> fantasai: I don't think there's a need for intermediary directories... 00:50:51 <fantasai> RESOLVED: spec-shortname/N-levels-of-ignored-subdirectory-names/frag-id-of-section 00:51:29 <fantasai> RESOLVED: for 2.1 use css2/filename/frag-id-of-section 00:51:46 <dbaron> ?: or for 2.1 we can require help links 00:51:49 <fantasai> (remove previous RESOLVED) 00:52:05 <fantasai> plinss: If spec doesn't match this format (e.g. 2.1 which has chapters) then have to use <link> 00:52:13 <tantek> q? 00:53:08 <fantasai> RESOLVED: Remove any title requirement, other than having one (implied by validity of HTML requirement) 00:53:37 <fantasai> tantek: Want to say, don't keep content in HTML comments. 00:54:14 <tantek> can we get a resolution on not putting content in HTML comments? 00:54:43 <fantasai> RESOLVED: testharness.js tests don't need a meta assert (but reftests still do) 00:54:57 <tantek> PROPOSED: Drop any requirements or even suggestion to put test meta info into HTML comments 00:55:10 <tantek> ^^^ yes this is about reviews 00:55:11 <fantasai> gsnedders: Basic agreement on the flags to keep/drop on ML 00:55:26 <fantasai> ... 00:55:37 <fantasai> gsnedders: For WPT, if there's a public review, you can use that to upstream it to WPT repo 00:55:42 <fantasai> gsnedders: I think that only affets Edge now :) 00:56:07 <teoli> teoli has joined #css 00:56:23 <fantasai> Florian: I'm in favor of that, one thing that we're losing if we move away from Shepherd way of doing things.. 00:56:33 <fantasai> Florian: If you are using Shepherd to review, you have access to a view of tests 00:56:38 <fantasai> Florian: You don't have that view in GitHub 00:56:48 <fantasai> Florian: We're assuming ppl will be diligant and look at the test on their own machine 00:57:19 <fantasai> .... 00:57:25 <zcorpan> q+ 00:57:29 <fantasai> fantasai: I think the biggest thing is being able to understnad the test when reviewin it 00:57:53 <fantasai> fantasai: For me at least, I understand better when I can see the output and try to connect that to the code I'm looking at 00:58:21 <fantasai> fantasai: So it's much harder for me to review tests from a GH PR than to pull down the repo and look at the test locally 00:58:44 <fantasai> gsnedders: For WPT, PRs by some people ... 00:58:59 <fantasai> zcorpan: I'm on the whitelist, so if I make PR, my PR gets mirrored on w3ctest.org 00:59:05 <fantasai> zcorpan: In a subdirectory, where I can run it 00:59:14 <fantasai> zcorpan: Right now there's no automatic link in teh PR itself, but we could add that 00:59:23 <fantasai> zcorpan: So could add a link directly 00:59:40 <fantasai> zcorpan: I agree it's useful to be able to easily run the tests without having to checkout 01:00:08 <fantasai> Florian: so you can also whitelist PRs from other people 01:00:16 <fantasai> zcorpan: The whitelist is there to avoid security problem 01:00:19 <Florian> Florian has joined #css 01:00:31 <fantasai> astearns: So it wouldn't be a problem to take anyone that's interested in revieweing tests on the whitelist 01:00:39 <astearns> ack next 01:00:40 <Zakim> tantek, you wanted to request a resolution to not put content in HTML comments, e.g. use title attr instead 01:00:43 <zcorpan> ack zcorpan 01:01:02 <fantasai> Florian: I think having a system like that is valuable, not sure about blocking on it 01:01:20 <fantasai> Florian: gtalbot feels pretty strongly against a system which doesn't have that (ability to easily run the tests) 01:02:02 <fantasai> gsnedders: I think that's fine, practically already have it for WPT, should make it explicit 01:02:08 <fantasai> zcorpan: Should make it easier to get there, from the PR 01:02:16 <fantasai> zcorpan: e.g. have a bot add a link 01:02:28 <Florian> q+ 01:02:54 <fantasai> Florian: Are we resolving to move to GitHub, review then merge, and also to merge the system 01:03:01 <fantasai> Florian: Or is the system a dependency on moving to GitHub 01:03:02 <fantasai> ? 01:04:42 <fantasai> gsnedders: Should be easy to set up as long as don't need to build 01:04:54 <fantasai> fantasai: Shouldn't need to build exception [weird cases that we don't really have any reason to support] 01:05:05 <fantasai> astearns: So seem to want to move to GitHub 01:05:16 <fantasai> plinss: Suggestion to move all of our tests to WPT repo 01:05:26 <fantasai> gsnedders: That's a long-term goal shared by browser vendors (except MS hasn't said anything) 01:05:37 <fantasai> Florian: Short term or long term goal? 01:05:45 <fantasai> plinss: Long term goal since beginning of WPT 01:05:50 <fantasai> plinss: Block has been our dependency on build system 01:06:01 <fantasai> plinss: If we eliminate that, then no reason not to move to other repo 01:06:37 <fantasai> plinss: I'm happy doing that. Takes Shepherd out of the feature. I can maintain the historica data, but won't run against WPT for a long time if ever 01:07:03 <fantasai> plinss: Would need to keep build system and parts that help us generate implementation reports 01:07:19 <fantasai> Meeting closed. 01:07:27 <fantasai> [discussion deferred to later] 01:43:54 <tantek> tantek has joined #css 03:05:14 <jensimmons> jensimmons has joined #css 03:08:22 <astearns> Trackbot, end meeting 03:08:22 <trackbot> Zakim, list attendees 03:08:22 <Zakim> As of this point the attendees have been (no one) 03:08:30 <trackbot> RRSAgent, please draft minutes 03:08:30 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/10-css-minutes.html trackbot 03:08:31 <trackbot> RRSAgent, bye 03:08:31 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2016/05/09-css-actions.rdf : 03:08:31 <RRSAgent> ACTION: Peter Linns to file an issue against the TAG to fix the general pushState / url reference problem [1] 03:08:31 <RRSAgent> recorded in http://www.w3.org/2016/05/09-css-irc#T19-37-49 03:08:31 <RRSAgent> ACTION: TabAtkins to look into supports on mq [2] 03:08:31 <RRSAgent> recorded in http://www.w3.org/2016/05/09-css-irc#T21-35-32 16:11:05 <RRSAgent> RRSAgent has joined #css 16:11:05 <RRSAgent> logging to http://www.w3.org/2016/05/10-css-irc 16:11:07 <trackbot> RRSAgent, make logs member 16:11:07 <Zakim> Zakim has joined #css 16:11:09 <trackbot> Zakim, this will be Style_CSS FP 16:11:09 <Zakim> ok, trackbot 16:11:10 <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:11:10 <trackbot> Date: 10 May 2016 16:11:25 <Florian> Florian has joined #css 16:11:27 <gregwhitworth> gregwhitworth has joined #css 16:11:37 <gregwhitworth> gregwhitworth present+ 16:13:36 <Rossen> present+ 16:13:48 <Florian> prensent+ Florian 16:13:49 <astearns> present+ 16:14:59 <Rossen> starting at 9:20am 16:15:51 <fremy> fremy has joined #css 16:16:52 <zcorpan> present+ 16:16:58 <jihye> present+ 16:17:31 <dbaron> Zakim, remind us in 9 hours to go home 16:17:31 <Zakim> ok, dbaron 16:17:34 <dbaron> present+ 16:17:38 <plh> plh has joined #css 16:18:32 <bradk__> present+ 16:18:34 <skk> skk has joined #css 16:18:34 <hober> present+ 16:18:38 <gsnedders> present+ 16:18:41 <gregwhitworth> present+ 16:18:43 <shane> present+ 16:18:43 <babatakao> babatakao has joined #css 16:18:44 <skk> present+ skk (Hiroshi) 16:18:46 <TabAtkins> present+ 16:18:49 <myles> myles has joined #css 16:19:05 <dauwhe_> present+ dauwhe 16:19:06 <plinss> present+ 16:19:09 <myles> present+ myles 16:19:16 <babatakao> present+ 16:19:18 <bradk__> percent+ 16:19:35 <dbaron> ScribeNick: dbaron 16:19:53 <jensimmons> jensimmons has joined #css 16:19:56 <dbaron> Topic: Next face-to-face after TPAC 16:20:08 <dbaron> Rossen: we previously proposed to have January-February-ish F2F in Seattle 16:20:15 <dbaron> Rossen: we'd be happy to host 16:20:22 <dbaron> Rossen: unless people have a better location to propose 16:20:33 <dbaron> Rossen: If we're hosting it, it would be in Redmond rather than Seattle. 16:21:48 <dbaron> Rossen: If we don't have other offers on the table, we can do Redmond -- or change later if we have other options. 16:22:02 <dbaron> Rossen: Still settled for Kyoto for following one? 16:22:10 <dbaron> Florian: either Tokyo or Kyoto 16:22:17 <dbaron> skk: want to do Tokyo area 16:22:24 <dbaron> Florian: easier to meet developer communities in Tokyo 16:22:55 <dbaron> skk: I'm talking to some Japanese publishers, we could arrange an industry meetup 16:23:04 <dbaron> Florian: I'll try to organize something in parallel in Kyoto to see what we end up with 16:23:09 <dbaron> skk: April or May? 16:23:51 <dbaron> dbaron: might want to look for dates with conflicts 16:24:42 <dbaron> Rossen: If you have conflicts around April/May, please send conflicts to mailing list. 16:25:09 <dbaron> Florian: Are we necessarily CSS and Houdini, or just CSS? 16:25:19 <dbaron> Rossen: don't know yet. Will discuss during Houdini meetings. 16:25:49 <fantasai> Woo! Sizing has been published!!! 16:26:47 <dbaron> Topic: Round Display 16:27:05 <dbaron> jihye: first thing is about the shape media feature, suggested by Florian 16:27:14 <dbaron> jihye: the device radius in css-round-display detects shape of the display 16:27:25 <dbaron> jihye: it lets us apply different styles according to display shape 16:27:34 <tantek> tantek has joined #css 16:27:37 <dbaron> jihye: but can't cover all shapes since it combines shape with roundness of corners 16:27:38 <jihye> https://lists.w3.org/Archives/Public/www-style/2016Apr/0273.html 16:27:43 <dbaron> jihye: so Florian suggested shape media feature 16:27:49 <dbaron> Florian: already talked at previous f2f about this 16:28:09 <dbaron> Florian: 2 reasons to query for shape: (1) if it's not rectangular putting things at some places like corners might not work, want to know about this to avoid corners. 16:28:18 <dbaron> Florian: we'd been discussng visibility(coordinates) query 16:28:22 <tantek> present+ 16:28:30 <dbaron> Florian: (2) stylistic reasons -- want round design if screen is round 16:28:33 <dbaron> Florian: this media query is for that 16:28:40 <dbaron> Florian: it tests whether the screen is round or not 16:28:56 <dbaron> Florian: as of today the only OS that can let the browser know about this is Android, and it has a boolean saying round-or-not 16:29:06 <dbaron> Florian: so it's all we can realistically implement 16:29:19 <dbaron> TabAtkins: [joking] so we need to round off to the nearest value? 16:29:34 <dbaron> Florian: what I propose is rect or round media query 16:29:42 <dbaron> Florian: we might fall back into yesterday's discussion 16:29:50 <dbaron> Florian: this design assumes we have the "unknown" state. 16:30:04 <dbaron> Florian: if you have the Android API you know -- but otherwise you really don't know 16:30:17 <dbaron> fantasai: presumably once you have screens that are really not rectangular, you'll have new APIs 16:30:28 <dbaron> Florian: this assumes unknown semantics which are close enough to false 16:30:39 <dbaron> tantek: is this just for 2 dimensional displays, or 3d as well? 16:30:55 <dbaron> Florian: this is intentionally fuzzy -- not exact circle or exact rectangle 16:31:10 <dbaron> Florian: it's about whether round enough that round designs that round designs are preferable 16:31:34 <dbaron> plinss: ... 2d display wrapped in a 3d space 16:31:58 <dbaron> Florian: ... 16:32:08 <andrey-r> andrey-r has joined #css 16:32:23 <dbaron> Tantek: using a simple term like round will mean different things to different people 16:32:30 <dbaron> tantek: if you saw the TVs at CES... 16:32:45 <dbaron> TabAtkins: round is the correct short and easy-to-type word for this 16:33:14 <dbaron> plinss: users percieve those as rectangular 16:33:34 <dbaron> plinss: but there are also phones with screens that wrap around the edge -- the edge is logically like a different screen, but part of the same one 16:33:57 <dbaron> Florian: this media query could be extended to a long list of shapes, but it's about design trends that exist 16:34:07 <dbaron> bradk: what's the chance the OS or browser will be aware of shape of screen 16:34:22 <dbaron> Florian: Android has a boolean that says round or not 16:35:00 <dbaron> Florian: this is about design styles, not exact geometry. Star-shaped displays aren't a thing. 16:35:05 <Rossen> q? 16:35:12 <dbaron> Florian: if want to know what's hidden, need actual geometry of screen 16:35:29 <dbaron> Rossen: why is it not rectangular or not in the query? 16:35:58 <dbaron> Florian: there isn't a design trend of putting circular designs on rectangular screens. 16:36:03 <dbaron> Florian: people want to be round on round screens 16:36:16 <dbaron> Florian: if there are star-shaped screens, we can discuss it then 16:36:30 <dbaron> Florian: it's intentionally not a boolean query, so we can extend the list if we need to. 16:36:36 <dbaron> Florian: we have 2 shapes for now, but can extend 16:36:40 <tantek> ponders <iframe shape="round"> 16:36:46 <dbaron> Florian: there's no false-y value in the list, so we can add more if we need to 16:36:56 <dbaron> Florian: if we give up on unknown semantics 16:37:08 <dbaron> Florian: if you're a star-shaped UA and you know it, you can be false for both rectangle or round 16:37:37 <dbaron> bradk: I would think asking if it's a rectangle or not you might want more stuff toward the center of the screen 16:37:57 <shepazu_> shepazu_ has joined #css 16:38:00 <dbaron> Florian: that's a separate problem about what points are visible. This is about design 16:38:12 <dbaron> TabAtkins: the screens that exist are rect, rounded-rect, and round 16:38:46 <dbaron> TabAtkins: we should not be in the weeds about all sorts of bizarre shapes. MQ aren't the place for fine-grained information passing. At some point you want a JS API. Let's stop talking about stars. 16:38:50 <fantasai> +1 to not talking about stars 16:39:02 <dbaron> Florian: if we end up caring about other shapes, this is extensible since it's not a boolean media query 16:39:02 <tantek> even Twitter switched from stars to hearts 16:39:38 <dbaron> jihye: a question about your suggestion: if the UA doesn't knows about shape of display, then shape:rect and shape:round evaluate to unknown 16:39:42 <dbaron> Florian: yes 16:40:01 <tantek> dbaron: on some operating systems it may be reasonable for the UA to know that the OS has rectangular displays and that's that 16:40:15 <tantek> dbaron: you shouldn't try and say that if there is no API, then the UA must not deny that is rectangular 16:40:31 <dbaron> Florian: no, not trying to say that. Up to UA to figure out whether or not it knows. 16:41:01 <dbaron> Florian: I'd assume that authors, in this case, knowning vast majority of screens are rectangular. Authors likely to assume rectangular if the UA doesn't know... but in that case we expose full info to author 16:41:34 <dbaron> bradk: from an article viewpoint, wouldn't most authors assume that if it's unknown, would assume it's rectangular. 16:41:43 <dbaron> Florian: I wouldn't have come up with unknown just for this, but since we have it... 16:42:05 <dbaron> TabAtkins: unknown only happens for unrecognized things -- we don't have a semantic for known values being unknown 16:42:39 <dbaron> TabAtkins: the assumption that if you don't know, you're rectangular, is perfectly valid -- and we should define that you're going to be rectangular if you don't know that you're not 16:42:53 <dbaron> TabAtkins: the thing that we gain is that naive code works just as if it were assuming rectangular 16:43:15 <dbaron> TabAtkins: we don't have a semantic for defined things returning unknown and I don't think we want to add it 16:43:27 <dbaron> TabAtkins: unknown is just a way to not cancel out the entire M 16:43:27 <dbaron> Q 16:43:36 <bradk> s/article/practical 16:43:38 <dbaron> TabAtkins: we can just assume rectangular unless known otherwise 16:43:56 <dbaron> Florian: I think it makes sense for authors to do that, but not UAs 16:44:14 <dbaron> TabAtkins: what else would you do other than assuming rectangular? 16:44:29 <dbaron> Florian: if you're designing widgets for round screens... 16:44:54 <dbaron> TabAtkins: 99.9% of authors, if they don't know -- probably rectangular. If OS isn't giving you information, assume rectangular. 16:45:01 <dbaron> Florian: what do you gain? 16:45:04 <dbaron> TabAtkins: simple semantics 16:45:25 <dbaron> TabAtkins: if your screen doesn't know, it's rectangular... 16:45:40 <dbaron> tantek: I tend to agree -- better start with fewer values until there's a case for more 16:45:45 <dbaron> Florian: fewer? I have 2. 16:45:56 <dbaron> TabAtkins: you're defining a third value that's "neither", that's confusing 16:46:09 <dbaron> TabAtkins: the unknown logical value acts in a counterintuitive way if you don't know you're dealing with it 16:46:36 <dbaron> jensimmons: I think there's a big difference for authors. We'll have screens that know they're rectangles, that know they're round, and those that have no idea. 16:46:37 <joone1> joone1 has joined #css 16:46:53 <dbaron> jensimmons: can we say that all the screens that don't know what they are, definitely know they're rectangular 16:46:55 <dbaron> q+ 16:47:16 <dbaron> jensimmons: authors know how to deal with not having media queries, e.g., on IE6, not knowing width 16:47:21 <dbaron> jensimmons: .. 16:47:42 <dbaron> bradk: danger is having code for rectangular screens that gets excluded 16:47:58 <Florian> q+ 16:48:06 <dbaron> jensimmons: risk that if every single screen ??? 16:48:23 <TabAtkins> dbaron: I don't think this discussion about screens that don't know what they are makes sense. 16:48:28 <zcorpan> scribenick: TabAtkins 16:48:34 <SimonSapin> shane, should the same Hangout link still work? 16:48:36 <TabAtkins> dbaron: I don't think somebody's gonna ship a browser UI that works on a round screen without kinowing they're doing so. 16:48:53 <TabAtkins> dbaron: So I think the only real risk is that somebody ships an engine without updating it, because they updated the browser UI and forgot about the negine. 16:48:55 <shane> SimonSapin: yeah, I'll set it up 16:49:08 <TabAtkins> dbaron: So we should just assume things are rectangular. 16:49:17 <TabAtkins> dbaron: Unless somebody knows they're on an OS they can detect being round. 16:49:20 <zcorpan> scribenick: dbaron 16:49:29 <shane> SimonSapin: does it work for you? 16:49:54 <dbaron> ChrisL: asserting not knowing it's rectangular is ostrich-like -- we know the shapes of most screens 16:50:04 <ChrisL> ChrisL has joined #css 16:50:12 <dbaron> tantek: before mobile -- having unknown screen wouldn't have helped with screen vs. handheld 16:50:31 <dbaron> Florian: I think I have 2 counterpoints -- UAs that don't implement this media query we behave the same as those that implement rect as unknown 16:50:31 <SimonSapin> shane: "Requesting to join…" 16:50:39 <shane> SimonSapin: OK, one secnod 16:50:50 <dbaron> Florian: so I'm not sure it's useful to have different behaviors between UAs that don't know about screen and those that don't know about media query 16:51:01 <dbaron> Florian: having the same information in practice it's the same 16:51:21 <dbaron> TabAtkins: I'm not interested in defining backwaords-compat of media query relative to their non-existence 16:51:35 <dbaron> Florian: if you want to write a MQ for round design, query for shape:round 16:51:43 <shane> SimonSapin: let me know if you need us to start using microphones 16:51:45 <dbaron> TabAtkins: if we returned unknown, what should an author be doing? 16:51:49 <shane> you should be able to just talk too if you want 16:51:55 <dbaron> Florian: in most cases it's useless to query for am-I-rectangle 16:51:58 <SimonSapin> shane, it’s good for now, thanks 16:52:14 <dbaron> Florian: if that's what you want people to query 16:52:15 <dbaron> ... 16:52:26 <tantek> this is silly, saying authors may do not(rect) is a strawman 16:52:27 <dbaron> TabAtkins: what's the benefit of this more complicated unknown value? 16:52:48 <dbaron> TabAtkins: what will authors assume if it's not round? 16:52:50 <dbaron> Florian: rectangle 16:53:08 <dbaron> Florian: in that case the MQ should be round: yes | no 16:53:49 <dbaron> TabAtkins: the unknown thing exists so we can do boolean logic without breaking the entire media query and repeating the selectors mestake 16:54:31 <dbaron> Shane: I don't think there will be cases of people building browsers for mobile devices without knowing the shape of the device 16:55:03 <tantek> straw poll time? 16:55:03 <dbaron> zcorpan: the case you're worried about is authors doing not (shape:rect) and assuming circle and this will break if we add a third shape 16:55:24 <dbaron> zcorpan: I don't think we should use unknown value to protect for that. We should have tutorials/notes that advocate using only round 16:55:49 <dbaron> hober: if the only query is rect, then you might ask for not(rect), but if you have round, it's the obvious way to ask the question of whether it's round. 16:55:57 <dbaron> hober: I think it's just a non-issue 16:56:07 <dbaron> TabAtkins: what is the benefit to authors? 16:56:28 <dbaron> TabAtkins: doing what you're suggesting is making it easier to write it otherwise 16:56:35 <flackr> flackr has joined #css 16:56:46 <dbaron> TabAtkins: I'll object to making known things unknown values as an editor and implementor 16:56:54 <dbaron> jensimmons: Useful to target rect 16:57:00 <dbaron> Rossen: anyone other than Florian who wants this? 16:57:06 <dbaron> Florian: seems not, and I'm not objecting 16:57:15 <dbaron> Florian: I think better extensibility my way, but most of time won't make a difference 16:57:36 <dbaron> jihye: if the rounded rectangle that is not also round -- in this case unknown? 16:57:51 <dbaron> Florian: if you're a rounded corner rectangle, the browser decides if you're closer to a rectangle or closerto a circle 16:58:03 <dbaron> fantasai: I'm worried about people using to see if it's a circle 16:58:11 <dbaron> fantasai: want to make sure querying what parts of the screen are visible is ?? 16:58:26 <dbaron> Florian: browser on egg/ellipse that opt in to roundish designs, that browser will want the roundish designs 16:58:49 <dbaron> fantasai: we have just this and we don't have ability to query what part sof the screen are visible,' then authors will use this to query what partso f the screen are visible 16:58:55 <dbaron> TabAtkins: at first approximation, that's reasonable 16:59:02 <dbaron> Florian: might put things off corners .... 16:59:13 <dbaron> Florian: we might want MQ for geometry detection, but OSes don't want report that 16:59:20 <dbaron> TabAtkins: MQ dcan't do fine-grained things 16:59:27 <dbaron> Florian: we discussed in Sapporo 16:59:31 <dbaron> TabAtkins: I disagree with all that 16:59:57 <dbaron> Florian: back to question -- if neither strictly rectangle or strictly a circle, it's a design choice of whether the browser prefers round designs 17:00:15 <dbaron> jihye: ?? idea of categorize the shape of round and rect only, and not unknown? 17:00:47 <dbaron> fantasai: should put a note in the spec that really doesn't fit in these categories, should contact the WG 17:00:51 <dbaron> ??: and return false for both 17:00:55 <dbaron> TabAtkins: that's what the advisement class is for 17:00:59 <dbaron> Tantek & TabAtkins: ... 17:01:18 <dbaron> hober: the lesson from that is that we shouldn't add MQ without having actual implementations 17:01:42 <dbaron> tantek: yes, don't add unless imminent implementation 17:02:03 <dbaron> joone: some round display are not perfect circle, e.g., Moto 360 has round display but bottom part cut out like flat tire 17:02:14 <dbaron> joone: many smart watch has round display but bottom part are ... 17:02:27 <dbaron> Florian: maybe a MQ, maybe a JS API giving details of screen 17:02:36 <dbaron> Florian: also can't be implemented today because OS won't tell you 17:02:53 <dbaron> joone: in some cases user cannot see bottom part 17:03:17 <dbaron> Florian: I don't think this MQ is appropriate for circle, circle-with-10px-cut-off-at-botom, etc. 17:03:36 <dbaron> Florian: for that we need another query, as discussed in Sapporo 17:03:41 <dbaron> s/botom/bottom/ 17:04:04 <dbaron> Rossen: Florian, did you want a resolution on that MQ 17:04:16 <dbaron> Florian: I think it would be good to resolve if we agree 17:04:28 <dbaron> jihye: I would like to change device-radius to shape... is it ok? 17:04:37 <dbaron> Florian: this is instead of, not in addition, to device-radius 17:04:47 <dbaron> Florian: add this and remove device-radius 17:04:55 <dbaron> Florian: or other thing later 17:05:09 <dbaron> TabAtkins: or do something about that when implementations can do something about it 17:05:45 <dbaron> RESOLUTION: remove device-radius MQ, add MQ for shape: rect | round with traditional boolean semantics 17:05:52 <dbaron> jihye: we also need JS api to detect shape of screen 17:06:08 <dbaron> jihye: in view of manufacturer, api to directly tell us what shape of screen is 17:06:15 <jihye> https://developer.tizen.org/dev-guide/2.3.1/org.tizen.web.apireference/html/ui_fw_api/wearable/circular_support/circular_support.htm 17:06:16 <dbaron> jihye: there are some APIs in Tizen (Samsung) OS 17:06:27 <dbaron> jihye: they use these APIs to detect if screen is round or not 17:06:41 <dbaron> jihye: media query with window.matchMedia can know shape of device 17:06:50 <dbaron> jihye: but we have to define media query before that to use that 17:06:59 <dbaron> jihye: so I suggest a new attribute to screen interface to know directly 17:07:04 <dbaron> jihye: ... the shape of the device 17:07:11 <dbaron> jihye: something like round attribute can do that 17:07:24 <dbaron> Florian: why not use the media query we just defined from javascript? 17:07:26 <dbaron> jihye: matchMedia? 17:07:27 <dbaron> Florian: yes 17:07:36 <dbaron> jihye: we have to define media query always to use that api 17:07:46 <dbaron> jihye: but when we implement scrolling effect, we mostly implement it by javascript 17:07:54 <dbaron> florian: but media queries are accessible from javascript 17:08:03 <dbaron> fantasai: I think she's trying to say it's harder to polyfill. 17:08:19 <dbaron> TabAtkins: we're not going to throw in arbitrary new apis to handle all new media queries 17:08:35 <dbaron> zcorpan: authors typically feature test things using something like modernizr, which has its own API 17:08:53 <plh> plh has joined #css 17:08:55 <dbaron> zcorpan: authors could use modernizr.screenshape.circle -- could use matchMedia if supported or fall back to polyfill if not supported 17:09:06 <dbaron> Florian: jihye, what's the problem for you with using matchMedia? 17:09:20 <dbaron> jihye: I think matchMedia can do that 17:09:28 <dbaron> Florian: the syntax is ugly, but that's not specific to round shapes 17:09:42 <dbaron> Florian: side question, is this something typed OM from Houdini can fix? 17:09:54 <dbaron> TabAtkins: we're not currently planning anything for media queries 17:10:02 <dbaron> shane: but we'll need to have a typed interface to media queries 17:10:09 <dbaron> shane: wvon't help with keywords, but will help with lengths 17:10:23 <dbaron> Rossen: next topic, then? more to discuss? 17:10:26 <dbaron> Topic: viewport fit 17:10:37 <Rossen> https://drafts.csswg.org/css-round-display/#extending-viewport-rule 17:10:54 <jihye> https://drafts.csswg.org/css-round-display/#extending-viewport-rule 17:10:54 <astearns> https://drafts.csswg.org/css-round-display/#viewport-fit-descriptor 17:11:02 <dbaron> jihye: we need to define viewport-fit 17:11:06 <dbaron> Florian: it's a descriptor in @viewport 17:11:09 <zcorpan> @viewport { viewport-fit: ... } 17:11:15 <dbaron> jihye: I wrote spec for this in round-display 17:11:27 <dbaron> jihye: on rectangular display viewing area is screen rectangle 17:11:40 <dbaron> jihye: but on rounde display viewing area is not always bounding box of screen 17:11:49 <dbaron> jihye: viewport-fit ... 17:11:59 <dbaron> jihye: on round display, if viewport-fit is cover, as rectangular 17:12:16 <dbaron> jihye: but if viewport-fit: contain, on round display, viewing area is inscribed rectangle 17:12:25 <dbaron> jihye: how can we call the viewing area? 17:12:44 <dbaron> jihye: we can call viewing area as the visual viewport 17:12:56 <dbaron> jihye: there is only ??? viewport and ??? viewport in the device adaptation spec 17:13:02 <dbaron> jihye: we haveto add new term, visual viewport 17:13:06 <zcorpan> s/???/initial viewport/ 17:13:12 <zcorpan> s/???/actual viewport/ 17:13:19 <dbaron> jihye: in this visual viewport, the viewing area ??? 17:13:41 <dbaron> Florian: as currently proposed, why do we need this at all 17:14:00 <dbaron> Florian: one problem we have with round displays, is that without anything, viewport is bigger than screen, and you have areas that are not visible 17:14:14 <dbaron> Florian: for CSS we've been writing so far, by default things are readable and not hidden off screen 17:14:25 <dbaron> Florian: if you don't style for specific device, still get something usable 17:14:40 <dbaron> Florian: so by default should get something readable by default 17:15:00 <dbaron> Florian: so by default fit the viewport in the screen, and then have a switch if you can deal with the corners being hidden -- media queries, shape-inside, etc. 17:15:05 <dbaron> Florian: if you don't, safe by default 17:15:12 <dbaron> Florian: how does this proposed thing work? 17:15:31 <dbaron> Florian: if you do viewport-fit: contain or cover on a rectangular screen, you get the usual results 17:15:52 <dbaron> Florian: on a round screen, it influences the initial viewport (as defined in device adaptation), should probably talk about as initial layout viewport 17:16:04 <dbaron> Florian: it's what you have before you apply the constraining procedure 17:16:19 <dbaron> Florian: once you're done with that the visual viewport is also sized to that size 17:16:29 <dbaron> Florian: so you if you have other stylesheet rules that ask for a viewport that's 1000px 17:16:49 <dbaron> Florian: then your layout viewport will be larger and go whereever it wants, but your visual viewport will be instcribed in the screen 17:17:13 <dbaron> Florian: if you do cover then you get th opposite, then layout viewport and visual viewport will contain the round screen 17:17:23 <dbaron> Florian: there's a third value proposed in the spec which is auto 17:17:46 <dbaron> Florian: which should be implemented as contain if you don't have a better idea, but it allows browsers to say that this is a waste of screen real estate, usually nothing in the corners anyway 17:18:07 <dbaron> Florian: so do something somewhere in between that cuts the corners a little and uses much more of the screen and only hides a bit of the corners 17:18:23 <dbaron> Florian: in addition, if you're in auto mode, you can have an extra scrolling mechanism 17:18:42 <dbaron> Florian: if the user drags to try to see what's in the corners, lets the users drag to see all of the visual viewport 17:18:52 <dbaron> Florian: but if you don't have anything smart to do, just stick to contain 17:19:26 <dbaron> Florian: maybe we need a word for the screen, unless screen works fine, or maybe we need a word for the bounding box of the screen, or maybe that works 17:19:33 <dbaron> bradk: when is the visual viewport not the initial viewport? 17:20:00 <dbaron> Florian: initial viewport (should be changed to initial layout viewport), in the world where everything is rectangular, is the size of the screen 17:20:17 <dbaron> Florian: maybe in the UA style sheet maybe there's a rule forcing it to 800 or 900 pixels to deal with mobile devices 17:20:44 <dbaron> Florian: after the constraining procedure the actual layout viewport is what was in the UA style sheet, unless author says to make it fit. That's how it's now described in device adaptation. 17:21:09 <dbaron> Florian: then you view this through your visual viewport (term not actually in spec) 17:21:51 <dbaron> bradk asks questions about viewports 17:21:59 <dbaron> Rossen: ? and ? are different if you're pinch-zoomed 17:22:26 <dbaron> Florian: all this terminology is fuzzy; visual viewport not discussed anywhere in specs 17:22:43 <Rossen> s/? and ? are different if you're pinch-zoomed/physical and layout are different if you're pinch-zoomed for example/ 17:22:51 <dbaron> Florian: most of things in spec that talk about viewport talk about actual layout viewport -- but not quite all 17:22:56 <dbaron> Florian: some refer to visual one 17:23:05 <dbaron> Florian: maybe in background-attachment??? 17:23:16 <dbaron> Florian: visual viewport has same dimensions as initial layout viewport 17:23:21 <dbaron> Florian: but easier to think of them as separate things 17:23:57 <dbaron> Florian: I'm mostly going by terminology used by ppk on his blog, inspired by internal terminology at Opera. 17:24:56 <dbaron> [ discussion about what goes in the unused space ] 17:25:38 <dbaron> Florian: ok for UA to put background color there, but authors shouldn't rely on that 17:25:46 <dbaron> bradk: authors will want to put things there 17:25:53 <dbaron> (reverse previous two lines) 17:26:22 <dbaron> bradk: if I have control, I'll use cover so I can control what's in that space 17:26:38 <dbaron> Florian: that's fine. But if you take Web pages designed prior to round displays, don't want half the text to be hidden 17:26:54 <dbaron> bradk: I want something in between, I can put things there but can rely on important being contained 17:27:22 <dbaron> plinss: you don't get control if it's outside the viewport 17:27:45 <dbaron> bradk: How come I get control over that space if I say cover, but not if I say contain? 17:27:47 <mstange> mstange has joined #css 17:28:04 <dbaron> TabAtkins: there's nothing underneath there -- since any arbitrary webpage *can* draw there 17:28:17 <dbaron> Florian: Web page can request full screen 17:28:21 <dbaron> TabAtkins: with permissions only. 17:28:31 <dbaron> TabAtkins: let's not pretend the whole viewport isn't under their control 17:28:49 <dbaron> Florian: I'm ok with a MAY that the background extends -- not necessarily controllable space 17:29:24 <TabAtkins> dbaron: I think Brad has a good point. 17:29:24 <dholbert> dbaron: I feel like there's a bunch of absolutism here 17:29:32 <TabAtkins> dbaron: The author is specifically choosing to say "i don't know how to fill that space" 17:29:45 <TabAtkins> dbaron: So it's not clear why the UA should then say "ok, then you're not allowed to touch it at all" 17:30:03 <TabAtkins> fantasai: We can reuse similar functionality to @page which lets you touch the margin area 17:30:03 <dbaron> fantasai: could use @page 17:30:16 <TabAtkins> bradk: It sounds like the only way to get what I actually want is to use cover and do JS math. 17:30:29 <dbaron> Florian: [question] 17:30:30 <TabAtkins> Florian: How much do we allow to link out? 17:30:35 <dbaron> TabAtkins: yes, it's still addressible area 17:31:10 <dbaron> Florian: contain is the default value 17:31:14 <dbaron> Florian: it's the compatibility mode 17:31:32 <dbaron> [discussion of negative positioning just off the edge] 17:31:41 <dbaron> peterl: people sometimes do just off the edge so they can transition it on 17:31:56 <mstange> mstange has joined #css 17:31:57 <fantasai> I think this should be under the control of the UA. It MAY extend the canvas to bleed outside the viewport area, if it wants. 17:32:12 <dbaron> Florian: open to leaking canvas color to that area, but not any of the other stuff 17:32:37 <dbaron> zcorpan: it seems reasonable to me to hide the unscrollable area but show the scrollable area part of the screen 17:33:09 <dbaron> zcorpan: you have 2 directions that are unscrollable, typically above and left 17:33:23 <dbaron> zcorpan: but you can scroll right and down -- not reason to hide these 17:33:33 <dbaron> zcorpan: kinda ugly, but just accessible fallback 17:33:42 <dbaron> bradk: but once you scroll... 17:33:52 <dbaron> zcorpan: yes, once you scroll down, can render things at the top 17:34:33 <dbaron> Florian: this is not dangerous -- but is it ugly? 17:35:20 <dbaron> TabAtkins: minus the canvas that escapes the element, root element is contain;paint by default 17:35:22 <dbaron> q+ 17:35:40 <dbaron> TabAtkins: the objection was the elements are outside there -- they'll look ugly 17:35:54 <dbaron> Rossen: for clipping purposes, containing block is still clipping in negative scroll direction 17:36:04 <dbaron> TabAtkins: ICB contents ...?? 17:36:31 <TabAtkins> ICB clips its contents (elements, etc), but canvas background still renders 17:36:40 <TabAtkins> that feels like it'll look good 17:37:07 <fantasai> dbaron: We're doing UX design here, and that's not something we should be doing here. 17:37:25 <zcorpan> 👏 17:37:26 <fantasai> dbaron: We should have other people design the right thing for round displays, and experiment with products, and then come back to this group 17:37:45 <fantasai> dbaron: It's not clear to me that this is the right thing 17:37:54 <Rossen> bradk, so we should just punt on this? 17:38:00 <dbaron> Florian: worried that if we do taht we end up with a web for watches and a web for this 17:38:06 <fantasai> Florian: I see your concern, but my concern is that if we do that we'll end up with Web for Watches and Web for Everyone Else 17:38:29 <Rossen> s/bradk, so we should just punt on this/bradk: so we should just punt on this/ 17:38:30 <dbaron> TabAtkins: the relevant people implementing things are in this room or adjacent to this room 17:38:42 <dbaron> TabAtkins: we have examples of this not working well, <meta viewport> is a trash fire 17:39:12 <dbaron> Florian: with variants discussed today, this is one proposal to avoid having at rash fire 17:39:23 <dbaron> Florian: do we want to write it up as a proposal and at risk 17:39:28 <gregwhitworth> s/rash/trash 17:39:43 <dbaron> Rossen: in favor of not influencing it now 17:40:23 <dbaron> jihye: we first proposed contain, guarantees element contained in screen 17:40:33 <dbaron> jihye: so you can guarantee that all the elements are in the screen 17:40:40 <dbaron> jihye: we need that design when we implement scrolling 17:40:49 <dbaron> TabAtkins: so have you tried to implement contain yet? 17:40:52 <dbaron> jihye: not yet 17:40:58 <dbaron> jihye: we do that by javascript translate 17:41:11 <dbaron> TabAtkins: so you do show what's in the background of the page in the areas that aren't covered 17:41:23 <dbaron> jihye: we divided the pages with grid 17:41:38 <dbaron> jihye: we don't use that space 17:41:42 <dbaron> TabAtkins: what shows in the space? 17:41:46 <dbaron> jihye: maybe transparent? 17:42:05 <dbaron> Florian: one option is don't write anything in the spec; let LG figure out 17:42:18 <dbaron> Florian: or, write something loose in the spec giving some guidance and letting implementors figure out details 17:42:23 <dbaron> Florian: or write exactly what I like 17:42:28 <dbaron> plinss: I think middle solution 17:42:40 <dbaron> plinss: write up problem and possible solution and being open to improvements 17:42:54 <dbaron> plinss: I'd rather give some guidance and leave details up to UX experts 17:43:29 <dbaron> jensimmons: seems to me that doing absolute simplest thing possible might be good direction -- and contain -- just make it tiny 17:43:41 <dbaron> jensimmons: this isn't at all what I thought it was when I read it 17:44:13 <dbaron> jensimmons: if I want to design a layout, and have background colors show up in the extra space 17:44:15 <dbaron> q+ 17:44:31 <dbaron> jensimmons: smallest thing -- take a website and make it small and maybe put black around it 17:44:42 <dbaron> bradk: not sure making it small is the best thing , though 17:44:54 <dbaron> Florian: contain is meant to be the default 17:45:00 <dbaron> bradk: I'd rather see the default be cover 17:45:26 <fantasai> plinss: Auto can do what cover would do, if you have the ability to scroll to see all of it 17:45:34 <Rossen> plinss: auto can do that in the presence of scrolling 17:45:37 <fantasai> dbaron: I think we need a switch to say whether the page was designed with round displays in mind or not 17:46:01 <fantasai> dbaron: And I think we should leave it up to people who are trying to build a good UX on round display, to figure out what the best thing is to do for a Web page designed for not a round display 17:46:09 <fantasai> plinss: What's the trigger? 17:46:13 <fantasai> dbaron: Could be something like this 17:46:26 <fantasai> fantasai: That's why we have 'auto' as the initial value 17:46:34 <fantasai> dbaron: Maybe we should just have 'cover' and 'auto'. 17:46:38 <fantasai> TabAtkins: That's fine. 17:46:51 <fantasai> Florian: And some notes that if you have no idea what to do, do contain. 17:47:09 <fantasai> Florian: Should we say, "however you do it, you must show all the content" 17:47:28 <fantasai> dbaron: UA must provide a reasonable way to show content that has not been designed for round display 17:47:36 <dbaron> jensimmons: another variable here that might or might not matter -- some sites use and don't use media queries 17:47:55 <dbaron> jensimmons: some pages have made designs that are made to work on 150px wide screen 17:48:08 <dbaron> Florian: width and height media queries work just fine here 17:48:28 <dbaron> Rossen: where is this going to go into which spec? 17:48:43 <dbaron> Florian: round display spec for now, but when both this and the natural host are stable enough, can shuffle around 17:48:55 <dbaron> Rossen: action for jihye? 17:49:33 <dbaron> Rossen: proposed resolution on having viewport-fit: cover | auto, with loose guidance for auto that says the whole Web page should be viewable 17:49:40 <dbaron> bradk: [question scribe missed ] 17:50:11 <dbaron> fantasai: proposal is to accept viewport-fit with cover and auto, and auto must require that content can be made visible and handle pages not designed for round displays 17:50:18 <dbaron> fantasai: I agree with this 17:50:40 <dbaron> fantasai: one thing w.r.t. contain is some websites where you want the whole viewport visible at all times, like a game, you don't want the UA to do smart scrolling 17:50:54 <dbaron> fantasai: so I think author should be able to opt in for certain types of things 17:50:59 <dbaron> fantasai: pick a rectangle that's inscribed 17:51:11 <dbaron> fantasai: what you do with the space outside of that rectangle is up to UA 17:51:26 <dbaron> fantasai: can use canvas bg, @page bg, pick first BG image, whatever they want 17:51:44 <dbaron> fantasai: I think that for certain types of Web pages they might want to opt in to having entire viewport always visible, in that case contain is your best option. 17:52:01 <dbaron> bradk: so saying that if there's no scrolling mechanism you should always have the entire page visible? 17:52:10 <dbaron> fantasai: contain should be about the viewport visible entirely on screen 17:52:47 <dbaron> Florian: I agree with that about making the visual viewport fit in the screen; we already have viewport-width:auto to make the layout viewport fit in the visual viewport 17:53:30 <fantasai> 1) Accept viewport-fit with three values: cover, containe, auto 17:53:36 <dbaron> s/containe/contain/ 17:53:53 <fantasai> 2) Initial value is auto. UA can do anything it wants as long as the content not designed for round screens is easily 100% viewable by the reader 17:54:28 <fantasai> 3) Undefined what is outside the contained viewport for 'contain'. UA can paint anything it ants, chrome, black, canvas background, @page background , photo of SF Bay Bridge, whatever 17:54:43 <dholbert> s/it ants/it wants/ 17:54:45 <ChrisL> s/ants/wants 17:54:53 <dbaron> Florian: I'd add -- not sure if needs to be part of the resolution -- add note that these are early thoughts by the WG. Requesting feedback. 17:55:16 <dbaron> bradk: note that if you use contain, that most webpages will be unreadably small 17:55:51 <dbaron> RESOLUTION: [ 1-2-3 above typed by fantasai ] 17:56:08 <rachelandrew> rachelandrew has joined #css 17:56:09 <dbaron> <br duration="calc(15*60s)" 17:56:23 <TabAtkins> calc(20 * 60s), actually 17:57:59 <teoli> teoli has joined #css 18:14:12 <glazou> glazou has joined #css 18:14:44 <ekimber> ekimber has joined #css 18:16:08 <shepazu> shepazu has joined #css 18:17:38 <zcorpan> ScribeNick: zcorpan 18:18:26 <zcorpan> Topic: polar coorinates 18:18:46 <zcorpan> jihye: so far as we discussed i think there are some ??? 18:18:53 <zcorpan> jihye: there is 2 points of disagreements 18:19:06 <zcorpan> jihye: 1) i think polar anchor can be used in polar layout 18:19:17 <zcorpan> jihye: 2) the way the polar origin works 18:19:31 <zcorpan> jihye: polar origin can decide the ??? of the polar coordinates 18:19:41 <zcorpan> jihye: the element can be decided by the polar anchor 18:19:51 <dholbert> s/???/"pole"/ 18:20:07 <zcorpan> bradk: polar origin you're putting in a value and the end result is that the element is shifted over 18:20:21 <zcorpan> bradk: the current spec it's not shifted over by the amount you put in 18:21:00 <zcorpan> bradk: i'd like that to be more direct, so that if you shift it 3px to the right, you set the polar origin 3px and 0px (rather than -1.5px) 18:21:07 <zcorpan> bradk: i'd also change the name to "nudge" 18:21:13 <zcorpan> bradk: the effect is that you move the element 18:21:30 <zcorpan> bradk: it's using percentages by itself 18:21:34 <zcorpan> Florian: so it's anchor? 18:21:53 <zcorpan> Florian: the one that's related to the container is origin 18:21:57 <zcorpan> Florian: these names are confusing 18:21:58 <zcorpan> bradk: yeah 18:22:03 <zcorpan> bradk: you're right 18:22:12 <zcorpan> bradk: origin is relative to CB 18:22:19 <zcorpan> bradk: forget what i said earlier 18:22:49 <zcorpan> Florian: i think what we've said so far, the direction you move into is polar angle 18:22:57 <zcorpan> Florian: the distance and angle work from there 18:23:05 <zcorpan> Florian: the default is auto 18:23:19 <zcorpan> Florian: if you set center, the center is of the CB 18:23:38 <zcorpan> Florian: polar anchor let's you use some other point of the element 18:24:02 <zcorpan> bradk: percentage resolving is just for the anchor 18:24:19 <zcorpan> Florian: if we switch to the model you're proposing then it's like transforms but in ??? 18:24:27 <zcorpan> bradk: you're adding an additional movement to it 18:24:41 <zcorpan> bradk: the end result is the same, you're just moving it 18:24:57 <zcorpan> fantasai: let's say we want to position it ??? 18:25:17 <zcorpan> fantasai: the center of the box is 125,125 18:25:34 <zcorpan> fantasai: the positioning scheme that backgrounds use require you to ??? 18:26:07 <zcorpan> Florian: if you want to be at 25%,25% it would start at 0,0 and to do this in polar anchor you do -25%,-25% becaue you're moving the point 18:26:13 <zcorpan> fantasai: it's what relative positioning does 18:26:26 <zcorpan> Florian: the difference is whether it's relative to the element itself or CB 18:26:35 <zcorpan> fantasai: i don't like having yet another way to do relative positioning 18:27:30 <zcorpan> fantasai: if we want a generic shift this thing by xxx, we need a different way of measuring, not a different way of shifting the element 18:27:44 <zcorpan> Florian: the difference is if we're not doing positioning, we already have transforms 18:28:09 <zcorpan> Florian: the distance that doesn't stick you out of the container, not taking transforms into account there is weird 18:28:23 <zcorpan> Florian: for the sake of polar positioning we need something like transforms but happens at layout time 18:28:33 <zcorpan> bradk: why do we need it for polar but not in general 18:28:43 <zcorpan> bradk: we need something that nudges it over... 18:28:57 <zcorpan> fantasai: i want to align this point of the box to another point of the container 18:29:01 <zcorpan> fantasai: by default it's the center 18:29:11 <zcorpan> fantasai: we could say it is like background-position 18:29:23 <zcorpan> fantasai: or we can have a switch between the two 18:29:33 <zcorpan> fantasai: yes you can use transforms to get the same effect 18:29:42 <zcorpan> fantasai: but we're not trying to nudge the element 18:30:06 <zcorpan> fantasai: you only need this if you need the points working together 18:30:31 <zcorpan> Florian: polar distance has a switch, which is 100% means don't overflow, move as far as you can without overflowing 18:30:48 <zcorpan> Florian: that operation can't reasonably take transforms into account, therefore it can't be using transforms 18:30:58 <zcorpan> fantasai: right 18:31:10 <zcorpan> Florian: because transforms are out, we need to use polar anchor 18:31:29 <zcorpan> bradk: it seems weird that we have this thing that does the same thing as transforms but only for this other thing 18:31:42 <zcorpan> Florian: there are many ways you can move things around the screen. this is a different model 18:32:08 <zcorpan> fantasai: i'd like to drop `??? value and instead have the initial value of polar anchor be auto 18:32:29 <zcorpan> fantasai: so that 50% places it in the center ,100% places it as far as it will go without overflow 18:32:58 <zcorpan> fantasai: if you want to center you say "center" 18:33:03 <zcorpan> fantasai: like backgrounds 18:33:18 <zcorpan> fantasai: for shifting things around then also allow you to set an explicit point 18:33:28 <zcorpan> Florian: why doen't it stick out? 18:33:38 <zcorpan> Florian: for origin center distance 100% 18:33:44 <zcorpan> Florian: that's what contain is for 18:33:49 <zcorpan> fantasai: ok 18:33:58 <zcorpan> Florian: there are 2 ways to do that 18:34:11 <zcorpan> Florian: one can stick out and the other not 18:34:17 <zcorpan> bradk: i think contain is still weird 18:34:34 <zcorpan> bradk: what you end up wanting is that the center of the element to line up in a circle 18:34:38 <zcorpan> bradk: not so much the ends 18:34:45 <zcorpan> Florian: there are varying behaviors you may want 18:34:58 <zcorpan> Florian: sometimes you want it to stick out and sometimes not 18:35:17 <zcorpan> Florian: i think this is also a tricky discussion 18:35:30 <zcorpan> Florian: if we want an auto value that does some magic but that sounds weird to me 18:35:48 <zcorpan> bradk: maybe the polar anchor if it's 100% would be 100% of the distance of the polar distance? 18:35:55 <zcorpan> Florian: ??? 18:36:12 <zcorpan> TabAtkins: i'm happy with contain being polar distance, seems reasonable 18:36:19 <zcorpan> TabAtkins: seems like the right place for it 18:36:36 <zcorpan> Florian: i'm suggesting that when polar distance is a percentage 18:36:47 <zcorpan> Florian: we should have a few keywords for what 100% means 18:37:03 <zcorpan> Florian: is it against the edge, same distance in all directions or follow the edge? 18:37:11 <zcorpan> Florian: which switches we need can be discussed 18:37:19 <zcorpan> TabAtkins: put if far out but make sure you can still see 18:37:37 <zcorpan> Florian: these switches make sense as keywords 18:37:48 <myles> myles has joined #css 18:37:50 <zcorpan> Florian: trying to do that with polar anchor is wrong 18:37:59 <zcorpan> Florian: i think using transforms is also wrong 18:38:23 <zcorpan> Florian: to do nudge instead of anchor, i think that only makes sense if there's a usecase outside polar coordinages where .... would not work 18:38:27 <hober> hober has joined #css 18:38:37 <zcorpan> bradk: you may want to use it on something else, like animate 18:38:42 <zcorpan> bradk: that would apply to anything 18:39:04 <zcorpan> bradk: if you need to move it a little bit one way or the other to get the position just right, why does it not apply to other things? 18:39:25 <zcorpan> bradk: to me it seems if you want to limit it to polar you need to justify why it only does that 18:39:45 <zcorpan> TabAtkins: for round screens you need geometry ???? 18:40:05 <zcorpan> bradk: you can use polar origin to move things around in a box, to center it 18:40:15 <zcorpan> Florian: polar distance 0 puts you in the center 18:40:24 <zcorpan> bradk: you can use polar origin and polar anchor together 18:40:43 <zcorpan> bradk: people will use them to center or whatever using the percentage of the CB 18:41:17 <zcorpan> Florian: polar is generic, switching the name makes it more general, is your point? 18:41:20 <zcorpan> bradk: yeah 18:41:37 <zcorpan> bradk: if you want to move something 3px to the right it shouldn't be negative, it should be just 3px 18:41:47 <zcorpan> Florian: it would be harder to use for the intended use case 18:42:03 <zcorpan> TabAtkins: can we move this to hallway conversation? it's just 4 of you discussing this 18:42:50 <zcorpan> Rossen: if the conversation has proven to be ineffective for the past year we should maybe discsus this 18:43:15 <zcorpan> shane: can we give them 2 mins each to present their case. arguing like this doesn't help 18:43:34 <zcorpan> Florian: should we write or say this? 18:43:51 <zcorpan> shane: prepare at lunch, present after lunch 18:44:13 <zcorpan> fantasai: my proposal is what we resolved on in sydney, it's written up 18:44:47 <zcorpan> topic: css tables status update 18:45:08 <gregwhitworth> https://drafts.csswg.org/css-tables-3/ 18:45:15 <zcorpan> gregwhitworth: in sydney we asked for the opportunity to work on the tables spec 18:45:56 <zcorpan> gregwhitworth: we've made good progress 18:46:04 <zcorpan> gregwhitworth: the blink team reached out 18:46:12 <zcorpan> gregwhitworth: regarding height distribution 18:46:22 <zcorpan> gregwhitworth: we handle border painting 18:46:35 <zcorpan> gregwhitworth: html5 says you can have empty tables ,we need to figure out how to lay that out 18:46:58 <gregwhitworth> https://github.com/w3c/csswg-test/tree/css-tables/work-in-progress/microsoft/css-tables 18:47:05 <zcorpan> gregwhitworth: we were asked for the tests. we've begun putting them into a branch 18:47:17 <zcorpan> gregwhitworth: as you can tell we have a ton of investigations 18:47:27 <zcorpan> gregwhitworth: we'll contine to port those over into the test area 18:47:46 <zcorpan> gregwhitworth: the goal is what the test represents and you can match the test against the spec text, should be straightforward what is tested 18:48:00 <zcorpan> gregwhitworth: other browsers to review height distribution etc 18:48:17 <zcorpan> gregwhitworth: things we've ported over from 2.1 that were previously undefined 18:48:38 <astearns> s/this type of spec/all specs/ 18:48:41 <zcorpan> gregwhitworth: if you can review it, we're not at FPWD right yet but review is welcome 18:48:46 <zcorpan> Florian: comment on the methology 18:48:53 <zcorpan> Florian: if browsers do the same you spec that 18:49:05 <zcorpan> Florian: if nobody makes sense and everyone is different you spec something that does make sense 18:49:18 <zcorpan> Florian: wrt table topics that relate to fragmentation 18:49:29 <zcorpan> Florian: page UAs have considered this more than browsers 18:49:37 <zcorpan> Florian: please consider such UAs also 18:49:52 <zcorpan> Rossen: there's no fragmentation definition... 18:49:58 <zcorpan> fantasai: for tables there is 18:50:16 <zcorpan> Rossen: the majority is in css fragmentation 18:50:37 <zcorpan> Florian: table headers and footers, whether they fragment or not, browsers are not the primary things to look at 18:50:52 <zcorpan> TabAtkins: let's describe compat right now 18:51:05 <zcorpan> gregwhitworth: i said slot is not defined, it's an issue 18:51:21 <zcorpan> gregwhitworth: we're early on on this, we are not going to tackle this in this level 18:51:33 <zcorpan> Florian: 2.1 says it's undefined, now you're removing it 18:51:48 <zcorpan> Florian: i'd rather not say print UAs are irrelevant 18:52:05 <zcorpan> gregwhitworth: hopefully the next time we talk, we can present issues 18:52:21 <zcorpan> gregwhitworth: we don' tneed to handle this now. we haven't begun to investigate it yet 18:52:34 <zcorpan> Rossen: is that everything you have? 18:52:36 <MaRakow> MaRakow has joined #CSS 18:52:38 <zcorpan> gregwhitworth: one more link 18:53:03 <zcorpan> gregwhitworth: if you go to the github repo you can see the issues 18:53:19 <zcorpan> gregwhitworth: external people having input and we're working on addressing that 18:53:28 <zcorpan> Rossen: thx greg 18:53:44 <zcorpan> Topic: CSS UI 4 18:53:46 <Florian> https://drafts.csswg.org/css-ui-4/#issue-2e1305f8 18:53:56 <gregwhitworth> table issues readme: https://github.com/w3c/csswg-drafts/tree/master/css-tables-3 18:54:02 <zcorpan> Florian: user-select: none should be applies to button, ... 18:54:08 <zcorpan> Florian: should the spec say anything about that? 18:54:21 <zcorpan> Florian: should it list which elements it applies? 18:54:28 <zcorpan> Florian: WDYT? 18:54:38 <zcorpan> Florian: should it say which elements explicitly? 18:54:46 <zcorpan> TabAtkins: yes. it should say what UAs do 18:54:58 <zcorpan> Florian: is any browser interested in helping wit hthis? 18:55:07 <zcorpan> dbaron: i can tell you what we have in our UA stylesheet 18:55:15 <zcorpan> dbaron: marker, canvas are none 18:55:27 <zcorpan> dbaron: input on textarea have text 18:55:31 <zcorpan> dbaron: select has none 18:55:34 <zcorpan> dbaron: option has none 18:55:41 <zcorpan> dbaron: optgoup has none 18:55:46 <hober> search for user-select in http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css 18:55:54 <zcorpan> Florian: can you dump this? 18:56:00 <zcorpan> dbaron: things that look like buttons 18:56:36 <zcorpan> Florian: i can read the UA stylesheets myself but there may be knowledge about things that are known bugs etc 18:56:44 <zcorpan> tantek: we can dig into the impls 18:56:51 <zcorpan> Florian: ok, i'll do that 18:56:54 <Florian> https://lists.w3.org/Archives/Public/www-style/2016Mar/0190.html 18:57:01 <dbaron> https://mxr.mozilla.org/mozilla-central/source/layout/style/res/ua.css 18:57:01 <dbaron> https://mxr.mozilla.org/mozilla-central/source/layout/style/res/html.css 18:57:01 <dbaron> https://mxr.mozilla.org/mozilla-central/source/layout/style/res/forms.css 18:57:03 <zcorpan> Florian: q from tab 18:57:18 <zcorpan> TabAtkins: as i said in the email, safari and chrome allow pseudo-elements on form inputs 18:57:32 <zcorpan> TabAtkins: it's used on more than our removal threshold allows, about 20x more 18:57:55 <zcorpan> TabAtkins: there's a haldful that are possible to describe 18:58:05 <zcorpan> TabAtkins: we'd like to allow them when appearance is none 18:58:14 <zcorpan> TabAtkins: and make that interoperable with other stylesheets 18:58:29 <zcorpan> hober: this is allowing ::before / ::after? 18:58:42 <zcorpan> TabAtkins: yes 18:58:58 <zcorpan> dbaron: text input? 18:59:08 <zcorpan> dholbert: a non-themed box 18:59:19 <zcorpan> dbaron: there's also a complex structure for scrolling 18:59:35 <zcorpan> dbaron: if you type enough such that the text needs scrolling, does that work with appearance: none ? 18:59:55 <zcorpan> TabAtkins: whatever element you have that is user editable, the before/after would be children of that 19:00:08 <zcorpan> TabAtkins: it becomes an ordinary box that is user editable 19:00:19 <zcorpan> dbaron: it's -webkit-apperance in chrome? 19:00:21 <zcorpan> TabAtkins: yes 19:00:31 <zcorpan> dbaron: which type of input? not text inputs for me 19:00:38 <zcorpan> TabAtkins: checkboxes and radio buttons 19:00:43 <zcorpan> TabAtkins: i thought text inputs as well 19:00:55 <zcorpan> dbaron: i see it on checkboxes, not text inputs 19:01:09 <zcorpan> [room is testing] 19:01:11 <dbaron> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ainput%20%7B%20-webkit-appearance%3A%20none%20%7D%0Ainput%3A%3Abefore%20%7B%20content%3A%20%22hello%22%20%7D%0A%3C%2Fstyle%3E%0A%3Cinput%20type%3D%22text%22%3E%0A%3Chr%3E%0A%3Cinput%20type%3D%22checkbox%22%3E 19:01:26 <zcorpan> TabAtkins: hum 19:01:37 <zcorpan> TabAtkins: checkbox and radio are the big ones 19:01:54 <zcorpan> dbaron: if the idea is that appearance: none on checkbox and raido means all styling goes away 19:02:03 <zcorpan> TabAtkins: still atomic inlines, just empty, 0x0 19:02:45 <zcorpan> bradk: for search? placeholders? 19:03:11 <dbaron> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ainput%20%7B%20-webkit-appearance%3A%20none%3B%20border%3A%20medium%20solid%20green%3B%20display%3Ainline%20%7D%0Ainput%3A%3Abefore%20%7B%20content%3A%20%22hello%5Ca%20world%22%3B%20white-space%3A%20pre%20%7D%0A%3C%2Fstyle%3E%0A%3Cinput%20type%3D%22text%22%3E%0A%3Chr 19:03:11 <dbaron> %3E%0A%3Cinput%20type%3D%22checkbox%22%3E 19:03:12 <zcorpan> dbaron: an appearance: none checkbox is display: inline-block 19:03:53 <zcorpan> TabAtkins: can you implement this? appearance: none and before/after on checkbox and radio 19:03:56 <zcorpan> dbaron: yeah probably 19:04:02 <zcorpan> dbaron: ok with that 19:04:15 <zcorpan> TabAtkins: happy to explore more, but start with this 19:04:19 <dbaron> s/probably/basically that appearance:none checkboxes and radios are no longer replaced elements/ 19:04:25 <fantasai> +! 19:04:26 <zcorpan> Florian: the generalisation is the next topic 19:04:27 <fantasai> +1 19:04:45 <zcorpan> Rossen: anyone against this resolution? 19:05:18 <zcorpan> Proposed Resolution: appearance: none for checkbox and radio become non-replaced elements 19:05:33 <zcorpan> RESOLVED: appearance: none for checkbox and radio become non-replaced elements 19:05:47 <zcorpan> topic: generalization of previous topic 19:06:03 <zcorpan> Florian: we're going to have this discussion for lots of topics 19:06:09 <jensimmons> jensimmons has joined #css 19:06:16 <zcorpan> Florian: form controls are full of quirks, need to look at each one by one 19:06:25 <zcorpan> Florian: some are easy like checkboxes 19:06:37 <zcorpan> Florian: some where you can do that but you need to keep some UA stylesheet 19:07:00 <zcorpan> Florian: for compat reasons some things need to remain, like range you need the knob 19:07:44 <zcorpan> Florian: we need to do this at some point, but not right now 19:07:52 <zcorpan> fantasai: who's not interested? 19:08:00 <zcorpan> dbaron: the spec needs an editor 19:08:09 <zcorpan> Florian: i'm editor but i don't want to do it alone 19:08:30 <zcorpan> Florian: OK with an co-editor, also OK staying alone as editor if nobody steps up 19:08:48 <zcorpan> dbaron: the spec needs an editor who does the work, not in a WG meeting 19:09:13 <zcorpan> Florian: i have a google engineer who can help me, maybe that's enough 19:09:31 <zcorpan> gregwhitworth: it would be good to have other vendors also 19:09:43 <zcorpan> gregwhitworth: i can't commit editor time but i want to help 19:10:16 <zcorpan> gregwhitworth: does anyone have an issue with propagating appearance: none to the controls? 19:10:29 <zcorpan> gregwhitworth: there's an endless cycle 19:10:37 <zcorpan> gregwhitworth: this just exists because webkit compat 19:10:40 <zcorpan> Florian: no.... 19:11:04 <zcorpan> Florian: i have some general principles that google engineers have agreed with 19:11:21 <zcorpan> Rossen: seems like more work is necessary before this is actionable 19:11:39 <zcorpan> Florian: this is an appearance property, not a behavior property 19:11:46 <zcorpan> Florian: it shouldnt' change what you can do with it 19:11:54 <zcorpan> Florian: the other principle is you can't break web compat 19:12:09 <zcorpan> Florian: it might as well be useful so long as it doesn't violate the above 2 principles 19:12:13 <rniwa> rniwa has joined #css 19:12:24 <zcorpan> fantasai: the other one is also, maintain the ability to improve the UI 19:12:49 <zcorpan> fantasai: whatever we do here should not prevent improvements in the UI 19:12:56 <zcorpan> Florian: ok i agree with that 19:13:07 <zcorpan> fantasai: we should adopt the principles, sounds great 19:13:18 <zcorpan> Rossen: anything else? 19:13:58 <teoli> teoli has joined #css 19:14:06 <tantek> I like things with URLs 19:14:39 <zcorpan> Proposed Resolution: principles for 'appearance' (1) it shouldnt' change what you can do with it (2) you can't break web compat (3) should not prevent improvements in the UI (4) ??? 19:14:45 <ChrisL> ChrisL has joined #css 19:14:53 <hober> https://wiki.csswg.org/spec/css4-ui 19:15:06 <BogdanBrinza> BogdanBrinza has joined #css 19:15:06 <zcorpan> topic: ??? 19:15:17 <fantasai> (4) It might as well be useful so long as it doesn't violate the other two principles 19:15:20 <zcorpan> hober: playing paused pseudo-elements for media elements 19:15:20 <tantek> Topic: potential features for CSS4-UI 19:15:28 <tantek> per: https://wiki.csswg.org/spec/css4-ui 19:15:30 <fantasai> s/two/three/ 19:15:40 <zcorpan> hober: last time we got side-tracked and it got hairy 19:15:54 <zcorpan> hober: does anyone object to playing/paused pseudo-classes? 19:16:18 <zcorpan> TabAtkins: we existance proof that morphs on those two categories so i agree 19:16:29 <dholbert> s/proof that/proof for a button that/ 19:16:37 <zcorpan> Florian: putting things into the UI spec or selectors spec.... 19:16:50 <fantasai> tantek, here's a URL http://logs.csswg.org/irc.w3.org/css/2016-05-10/#e683601 19:16:59 <zcorpan> RESOLVED: add :playing and :paused pseudo-classes 19:17:40 <fremy> fremy has joined #css 19:18:05 <zcorpan> Topic: page MQ 19:18:27 <zcorpan> Florian: the size property inside @page should relate to MQ in the same way as viewport 19:18:34 <zcorpan> Florian: i've written an email with use cases 19:18:44 <hober> fantasai: https://logs.csswg.org/irc.w3.org/css/2016-05-10/ still works 19:18:47 <zcorpan> Florian: the viewport should respond the MQs in the same way 19:18:57 <fantasai> Florian's proposal: https://lists.w3.org/Archives/Public/www-style/2016May/0071.html 19:19:00 <zcorpan> s/respond/respond and influence/ 19:19:05 <tantek> fantasai, those principles sound vaguely ok, but too ambiguous to actually +1. Needs a more precise writeup, e.g. "it shouldnt' change what you can do with it" is so ambiguous as it could be used to justify anything 19:19:12 <zcorpan> TabAtkins: page size seems like the same thing as viewport 19:19:16 <zcorpan> Rossen: sounds reasonable 19:19:29 <zcorpan> dbaron: do we have impls of what @viewport says to do? 19:19:32 <fantasai> tantek, it's not a spec, it's guidance for the spec writers. It's fine as such imho 19:19:33 <zcorpan> Florian: Edge does it 19:19:37 <plinss> CSSWG_LogBot_: pointer? 19:19:37 <CSSWG_LogBot_> http://log.csswg.org/irc.w3.org/css/2016-05-10/#e683638 19:19:43 <tantek> so yeah, I guess as written up on the JS-dependent URL of http://logs.csswg.org/irc.w3.org/css/2016-05-10/#e683601, I would -1 as is 19:19:56 <zcorpan> dauwhe: ??? 19:20:04 <zcorpan> Florian: the size that you query 19:20:09 <astearns> s/???/asks about bleeds/ 19:20:11 <tantek> guidance which can be used to justify anything is useless and not worth giving 19:20:11 <fantasai> tantek, suggest improvements? 19:20:22 <fantasai> tantek, I have no idea what you're objecting to 19:20:28 <tantek> I did, "Needs a more precise writeup" 19:20:30 <zcorpan> Rossen: any objections? 19:20:44 <zcorpan> dauwhe: do the keywords cause problems? 19:20:47 <zcorpan> Florian: don't think so 19:20:55 <tantek> fantasai, how about dereference the pronouns in "it shouldnt' change what you can do with it" to more precise expressions 19:20:55 <fantasai> tantek, that's not a suggestion for improvement, that's a complaint 19:21:22 <zcorpan> Proposed Resolution: apply the same logic as @viewport has for @page size for viewport size 19:21:38 <zcorpan> RESOLVED: apply the same logic as @viewport has for @page size for viewport size 19:22:04 <zcorpan> <break> 19:59:17 <myles> myles has joined #css 20:00:03 <ChrisL> ChrisL has joined #css 20:00:16 <ChrisL> present+ ChrisL 20:04:36 <andrey-r> andrey-r has joined #css 20:09:57 <ekimber> ekimber has joined #css 20:11:01 <jensimmons> jensimmons has joined #css 20:11:54 <dholbert> present+ 20:22:16 <Florian> Florian has joined #css 20:25:48 <andrey-r> andrey-r has joined #css 20:26:50 <ChrisL> ChrisL has joined #css 20:33:24 <jensimmons> present+ 20:34:59 <ChrisL> scribenick: ChrisL 20:35:34 <Florian> Florian has joined #css 20:35:39 <dbaron> ScribeNick: ChrisL 20:35:39 <TabAtkins> emotion-origin 20:35:47 <ChrisL> fantasai: over lunch, looking at motion path, open issue for motion-origin which pegs a point on an element to the path 20:35:57 <ChrisL> ... very similar to polar anchor property 20:36:27 <ChrisL> ... in fact these are basically the same, polar angle implicitly defines a path 20:36:39 <ChrisL> ... polar distance is like motion offset 20:37:05 <ChrisL> fantasai: so we should combine them, have motion path accept an angle as well, then merge the rest of the properties 20:37:24 <ChrisL> ... resolves theissue in the spec 20:37:46 <ChrisL> fantasai: "and rename all the properties of course" (flames, fireworks, kaboom) 20:37:56 <ChrisL> fantasai: (draws on board) 20:39:12 <ChrisL> fantasai: also we said, what about making offset anchor easier so make it behave like background position, auto instead of center, point that correspoonds to the percentage in offset origin 20:39:27 <ChrisL> ... so it takes the same syntax as background position 20:40:08 <hober> q+ 20:40:13 <ChrisL> fantasai: this combines two positioning systems, solves the fact that they motion stuff is not actually yabout motion, and we have a combined model 20:40:31 <ChrisL> ... and we position elements using the background position model which aiuthors are familiar with 20:40:45 <ChrisL> TabAtkins: missing the rotation property 20:40:52 <ChrisL> fantasai: we can add it 20:41:04 <ChrisL> TabAtkins: and the bearing property 20:41:38 <ChrisL> shane: motion os 0 to 100%, you may need an angle element 20:41:51 <ChrisL> Florian: keywords like closest side, etc 20:42:01 <ChrisL> bradk: contain as the default 20:42:25 <ChrisL> TabAtkins: no contain anymore. and contain in transform space is more difficult 20:42:32 <ChrisL> fantasai: not sure why 20:43:03 <ChrisL> Florian: contain keyword on polar distance would be on offset path which defines the path 20:43:11 <shane> s/need an angle element/need a length value/ 20:44:21 <ChrisL> fantasai: origin for path is set by positioning, offset origin, calculate path according to keywords to set the length. offset distance says how far along the path 20:44:22 <hober> q? 20:44:59 <ChrisL> dbaron: does motion path have relative vs absolute paths? 20:45:09 <ChrisL> TabAtkins: aiuto-adds an initial M 20:45:54 <ChrisL> ChrisL: SVG path always defines the starting point of the path 20:46:16 <dbaron> ?: motion path always appends to the transform starting from the current position 20:46:24 <TabAtkins> s/and the bearing property/we dont' need <angle>, SVG has bearing commands now/ 20:46:34 <Rossen> q? 20:46:39 <ChrisL> hober: motion path is fancy transform, and doesn't affect layout - does this? 20:46:55 <ChrisL> TabAtkins: does not affect layout except for scrollable area 20:46:56 <hober> q- 20:46:58 <ChrisL> hober: ok 20:47:49 <ChrisL> Florian: other transforms are after motion path? 20:47:57 <ChrisL> TabAtkins: yes 20:48:08 <ChrisL> shane: sh owe define what a percentage means... 20:48:11 <ChrisL> fantasai: yes 20:48:58 <ChrisL> fantasai: combine polar-distance and motion-offset -> offset-distance 20:49:10 <ChrisL> polar-angle -> offset path 20:49:24 <ChrisL> polar-anchor and mortion-oroigin -> offset anchor 20:49:31 <ChrisL> initial value is auto 20:50:01 <ChrisL> which copies the percentages from offset-origin so offset-position behanves like background position 20:50:40 <ChrisL> Florian: offset-path newly takeas an angle plus a keyword (as yet undefined list, including contain) 20:50:46 <ChrisL> rrsagent, here 20:50:46 <RRSAgent> See http://www.w3.org/2016/05/10-css-irc#T20-50-46 20:51:27 <ChrisL> bradk: to go out at an angle, the offset-anchor is where? 20:51:35 <ChrisL> Florian: you start where you are 20:51:46 <ChrisL> bradk: for motion path it is the center 20:52:08 <ChrisL> Florian: same, for straight lines 20:52:14 <ChrisL> bradk: not for curved ones 20:53:29 <ChrisL> ???; there is also a side 20:54:36 <ChrisL> s/???/jihye 20:54:49 <ChrisL> Rossen: souns like a good proposal now 20:54:54 <dbaron> whiteboard: https://lists.w3.org/Archives/Public/www-archive/2016May/att-0000/whiteboard.jpg 20:55:33 <ChrisL> resolution: accept current proposal as outlined by fantasai 20:55:39 <jihye> s/???/polar-distance 20:55:54 <ChrisL> shane: names TBB 20:56:22 <jihye> in current spec of round display, there is <side> value in polar-distance 20:56:49 <ChrisL> hober: we should tell fxtf that we did this :) 20:56:50 <jihye> the concept of <side> also can be used in offset-path 20:57:05 <ChrisL> shane: apart from naming, this is a functional superset 20:57:16 <dbaron> shane: the only thing we've changed is (1) addition of angle to offset-path and (2) naming 20:57:30 <ChrisL> Florian: does offset-origin go into motion path spec? 20:58:12 <ChrisL> fantasai: spec needs renamed, it is not about motion. it is positioning. path positioning. it can be used to build motion 20:58:26 <ChrisL> Rossen: spec to be renamed 20:59:16 <ChrisL> shane: I can make these changes 20:59:24 <ChrisL> jihye: happy with this resolution 20:59:37 <ChrisL> and there was much rejoicing 20:59:56 <ChrisL> fantasai: add jihye as motion path editor? 21:00:07 <ChrisL> jihye: it would be an honour 21:00:15 <ChrisL> woohoo!! 21:00:51 <dauwhe> https://drafts.csswg.org/css-content/ 21:00:55 <ChrisL> topic: generated content spec 21:01:16 <Rossen> RESOLVED: jihye added as an editor of Motion Path spec 21:01:41 <ChrisL> dauwhe: it has been less than 13 years since my last confession 21:02:09 <Rossen> s/resolution:/RESOLVED:/ 21:02:26 <ChrisL> dauwhe: pending pseudoclass, 21:02:31 <ChrisL> ChrisL: handwaving 21:02:48 <ChrisL> dauwhe: have solidly reworked this spec and removed all the cruft 21:03:03 <ChrisL> ... some migration from gcpm also 21:03:27 <ChrisL> dauwhe: content property applies to elements as well as pseudos 21:03:52 <ChrisL> (discussion on which browsers do this already) 21:04:14 <gregwhitworth> https://bugs.chromium.org/p/chromium/issues/detail?id=597466&can=4&colspec=ID Pri M Stars ReleaseBlock Component Status Owner Summary OS Modified 21:04:23 <gregwhitworth> https://bugs.chromium.org/p/chromium/issues/detail?id=597466 21:04:27 <ChrisL> TabAtkins: if we have exactly one image in the content property it is replaces 21:04:36 <ChrisL> TabAtkins: if we have exactly one image in the content property it is replaced 21:05:08 <ChrisL> Florian: content property on elements in Presto - was removed. Everything turns into periods 21:06:08 <ChrisL> dauwhe: also a mecahanism for alt text for generated content, at the end of the endless stri ng there is a slash and then the alt text 21:06:21 <ChrisL> Florian: or use the image function? 21:06:35 <dbaron> s/function/function and have the fallback inside that/ 21:06:46 <ChrisL> fantasai: disadvantage - its nore complex, and you only want alt text for other image uses. just for content 21:07:31 <ChrisL> fantasai: (example of three stars for an HR but don't want that as alt text 21:07:39 <ChrisL> ... want it to cascade with the content 21:07:53 <ChrisL> ... so the syntax for the alto and the content it is replacing 21:08:09 <ChrisL> dauwhe: should be the value of the string by default 21:08:27 <ChrisL> Florian: ok 21:09:25 <ChrisL> TabAtkins: remember when we wanted to replace arbitrary elements with arbitrary strings .... 21:09:32 <ChrisL> ... with images is fine 21:09:56 <ChrisL> Florian: do we need an extra keyword to opt-in? 21:10:31 <ChrisL> fantasai: in general, make it work and find a workaround if it breaks 21:11:16 <ChrisL> TabAtkins: prefer we don't do it, only as an image replacement. replacing arbitrary elements with arbitrary text has no good use cases 21:11:43 <ChrisL> astearns: qould it make sense to have a replace function where this is wanted? 21:12:12 <ChrisL> Florian: shortening for small screens 21:13:00 <ChrisL> ChrisL: as long as the text is cominhg from an attr like data-whatevs in the content, so available to AT 21:13:16 <ChrisL> ... not replacing with random stuff from a stylesheet 21:14:05 <ChrisL> TabAtkins: if it is decorative, still don't like it. there is already replacement with alt if img doesn't load 21:14:53 <ChrisL> Florian: with cross references, may be easier to write the markup, but you need more functions than this. 21:15:04 <ChrisL> fantasai: there is a content keyword to do this 21:15:31 <ChrisL> dbaron: at some pojunt you are reinventing web components in css sytnax 21:16:16 <ChrisL> dbaron: it got abandoned when hixie went to work on XBL2 intead which eventually became web components 21:16:30 <dbaron> s/it got/one of the reasons it got/ 21:17:09 <ChrisL> TabAtkins: no diff between a literal string and an attr function 21:17:37 <joone1> joone1 has joined #css 21:17:38 <ChrisL> fantasai: you might want to get title of an abbr and rteplace with the title. A11y folks want this 21:18:44 <ChrisL> fantasai: should not need javascript to use this 21:19:13 <ChrisL> fantasai: alternate ways to express same concept, selection between them inline. needed in publishing 21:19:42 <ChrisL> Florian: non-metaphor substitutions for people confused with metaphor 21:20:03 <ChrisL> TabAtkins: don't put text in attra, you need markup for lang etc 21:21:29 <ChrisL> Florian: so only for images, then? 21:21:59 <ChrisL> dbaron: what do you use this for? 21:22:10 <ChrisL> TabAtkins: it is one way to do an image replacement 21:22:20 <ChrisL> gregwhitworth: I posted the bug earlier 21:22:32 <ChrisL> hober: custom image replacement 21:23:28 <ChrisL> Florian: prince, antenna house and pdfreactor all do text replacement on arbitrary elements 21:24:47 <ChrisL> ChrisL: for a pdf output, the user sees the output only. so different from the web browser case where the content, not the output of rendering, is used 21:25:06 <ChrisL> Florian: maybe vivliostyle too, need to check 21:25:26 <ChrisL> Florian: it is proven to be web compatible 21:25:32 <BogdanBrinza> BogdanBrinza has joined #css 21:25:45 <ChrisL> ... and may be web required. chrome does it 21:26:34 <ChrisL> resolved: content property allpies to all elements, only url values apply to real elements. other values will be ignored 21:27:05 <dbaron> it's pretty weird 21:27:20 <ChrisL> resolved: add trailing-slash alt-text to content property 21:28:18 <ChrisL> s/allpies/applies/ 21:29:11 <fantasai> ChrisL: It's relatively easy to explain, at least 21:29:30 <fantasai> ChrisL: Certainly there are a11y concerns with replacing the document content, so it's reasonable 21:30:41 <fantasai> gregwhitworth: I'd prefer we didn't do this, but if rest of WG feels it's worth going after, not going to push back too hard 21:30:53 <fantasai> ScribeNick: fantasai 21:31:13 <fantasai> astearns: In some ways doing something a little weird in order to reflect reality, but also have this mechanism by which some browser shave implemented some things that have not been specced with prefixes 21:31:18 <fantasai> astearns: Others are implementing just to be web compatible 21:31:36 <fantasai> astearns: We could wait to put this in, until such a time that other browsers find it necessary to implement for Web compat 21:31:48 <fantasai> gregwhitworth: We could also suggest that said browsers remove it to be compatible with the spec 21:31:59 <fantasai> Rossen: Do we have any kind of usage data? 21:32:02 <Florian> I just checked, and Vivliostyle does not apply the content property to ordinary elements. (neither for strings or for images) 21:32:03 <fantasai> TabAtkins: ?? 21:32:13 <fantasai> s/??/No/ 21:32:39 <fantasai> fantasai: I'm okay with either way, really want to update the rest of the spec 21:32:46 <fantasai> fantasai: Can always revisit this 21:32:51 <fantasai> plinss: Why URL and not image()? 21:33:07 <fantasai> fantasai: In theory, you can insert an mp3 into the speech output 21:33:42 <joone1> joone1 has joined #css 21:33:48 <fantasai> fantasai: Be cool if you can do image replacement on text, could do audio replacement on it too 21:34:19 <fantasai> plinss: Should be an image() 21:34:26 <fantasai> fantasai: I think it should be <image> or <uri> 21:34:30 <fantasai> s/image()/<image>/ 21:34:53 <fantasai> RESOLVED: s/<url>/<image>|<url>/ 21:35:02 <fantasai> dauwhe: Had some general questions about a11y 21:35:12 <fantasai> dauwhe: Existing bugs about generated content not being searchable, selectable, etc. 21:35:16 <fantasai> dauwhe: I think it should be 21:35:19 <fantasai> dauwhe: Can we just say that in the spec 21:35:27 <fantasai> Florian: These various things are related 21:35:46 <fantasai> Florian: Tricky for selectable, because APIs for selection are in JS/DOM world 21:35:55 <fantasai> hober: Need to ask editing TF to improve their APIs 21:36:05 <fantasai> Florian: ... 21:36:09 <fantasai> hober: Let's just ask them to do it 21:36:24 <fantasai> Florian: Do we ask them to do it, and then do our thing in the meanwhile? 21:36:39 <fantasai> fantasai: I think we put how we think it should work in the spec, and then have them figure it out 21:36:42 <fantasai> dbaron: Shouldn't assume they'll do it 21:36:50 <fantasai> hober: Hence why I suggest we ask them to do it 21:37:15 <fantasai> Rossen: A couple months ago, had a conversation with Richard ??? 21:37:18 <fantasai> Rossen: As well as Michael Cooper 21:37:34 <fantasai> Rossen: Their request was to create a spec which is similar to the other accessibility mapping specs, but for CSS 21:37:42 <fantasai> Rossen: What you're describing would be a perfect fit for that spec 21:37:43 <BogdanBrinza> GC is selectable and users can copy it in Edge - https://jsfiddle.net/3m3Lx0nw/ 21:37:47 <fantasai> dauwhe: That was my next question... 21:37:59 <fantasai> dauwhe: Whose responsibility is this? 21:38:02 <Florian> q+ 21:38:08 <fantasai> Rossen: There are two types of things that we do in CSS that make a11y hard 21:38:09 <astearns> \0/ BogdanBrinza 21:38:13 <fantasai> s/hard/harder/ 21:38:16 <gregwhitworth> ^^ Is not in Chrome/FF 21:38:22 <gregwhitworth> not sure if it works in webkit or not 21:38:24 <fantasai> Rossen: One is generated content, which adds more visible content, which is not accessible through the DOM 21:38:38 <fantasai> Rossen: We also create box structure that is not backed up by elements 21:38:44 <gsnedders> gregwhitworth: I don't think it ever has been elsewhere. Including (Zombie)Presto. 21:38:51 <fantasai> Rossen: e.g. anonymous boxes 21:38:57 <fantasai> Rossen: Not something that OM can query. Nor AT should care about 21:39:21 <gregwhitworth> gsnedders: what? 21:39:23 <fantasai> Rossen: Point of that spec was to define all of the different ways that we are affecting accessiblity, and specify what the UA is supposed to provide so that a11y doesn't suffer 21:39:36 <fantasai> Rossen: Other one was 'order' property, which we partially address with prose in the spec 21:39:39 <fantasai> Rossen: But still on the hook for that 21:39:49 <fantasai> Rossen: My feedback would be to start focusing on that spec 21:39:59 <fantasai> Rossen: Maybe point CG to that spec 21:40:45 <fantasai> fantasai: While I think it's fine to point to that spec for more details, I think we should be very clear in this spec that generated content is to be accessible. 21:41:03 <fantasai> Florian: Is visiblity of a piece of content in teha11y tree and selectability of a piece of content, and searchability of a piece of content the same thing, or is it not? 21:41:07 <fantasai> ChrisL: It should not be 21:41:14 <fantasai> ChrisL: They're not orthogonal, but not completely independent either 21:41:15 <astearns> q+ to go back to the previous GC issue for a second 21:41:20 <fantasai> Rossen: You're describing different views of a document 21:41:26 <fantasai> Rossen: You're describing views for presentation on screen 21:41:29 <fantasai> Rossen: And view for an editor 21:41:31 <fantasai> Rossen: And view for an AT 21:41:46 <fantasai> Rossen: editor being selection 21:41:53 <fantasai> Florian: I disagree that eidting and selection are the same 21:41:59 <fantasai> Rossen: Then your engine is weird 21:42:10 <fantasai> Florian: If these things are not the same, which are affected by 'user-select: none' 21:42:13 <fantasai> ? 21:42:30 <fantasai> Florian: If you 'user-select: none' is it searchable? Is it in the a11y tree? Obviously it's not selctable 21:43:13 <fantasai> Florian: One suggestion has been, make ::before/::after as 'user-select: none' by default, can be overridden, would get you current behavior 21:43:23 <fantasai> fantasai: ..... no, I don't think that's a good idea. That's just a bug. 21:43:36 <dbaron> I think these are just explaining why generated content is a bad idea. 21:43:36 <fantasai> dauwhe: Would this be a good guinea pig for starting work on AT typ ethings? 21:43:38 <fantasai> Rossen: Totally 21:44:12 <gsnedders> gregwhitworth: It's not ever been selectable anywhere except Edge, not in Chrome/FF/ not even in Presto with it's general content: support 21:44:29 <fantasai> Rossen: Sounds like we should start a spec for this, would you co-edit with me? 21:44:33 <gregwhitworth> gsnedders: so what you're saying is we're awesome 21:44:34 <fantasai> dauwhe: Sure 21:44:41 <gsnedders> gregwhitworth: yeah, you're the best <3 21:44:56 <fantasai> astearns: So we should go back to the editing task force 21:45:37 <Florian> q+ 21:45:39 <fantasai> astearns: And then put a note that we want to do that 21:46:02 <fantasai> fantasai: I think we should just have the spec require it, and then add more details and better improvements to make it easier to implement elsewhere 21:46:12 <Rossen> q? 21:46:24 <astearns> ack astearns 21:46:24 <Zakim> astearns, you wanted to go back to the previous GC issue for a second 21:46:43 <fantasai> dbaron: I think generated content is a feature of the Web platform that doesn't get along with a lot of other features of the Web platform, and we can try to make a bunch of things work, but we're going around the way it works 21:46:49 <fantasai> plinss: But there's lots of uses for GC in publishing 21:46:56 <fantasai> TabAtkins: /??/ 21:47:06 <fantasai> plinss: Replacing content has been a thing in word preocessors for a long time 21:47:13 <fantasai> dbaron: But CSS is probably the wrong layer to do it 21:47:17 <TabAtkins> s/??/Printing doesn't have the same weaknesses as an active DOM/ 21:47:19 <fantasai> dauwhe: Yeah, but this is the world we're in 21:47:45 <Rossen> q? 21:48:03 <fantasai> dbaron: I'm not happy about expanding it. Also should not have to tell other group to fix our problems. 21:48:15 <fantasai> fantasai: Well, we can't not fix the problem, or pretend it doesn't exist 21:48:22 <fantasai> hober: The Editing TF is where the expertise is for this. 21:48:39 <fantasai> [discussion about accessibility mapping specs] 21:48:55 <fantasai> Florian: UI question, but related, 21:49:01 <Rossen> ack Florian 21:49:05 <fantasai> Florian: Not speaking about searchability, but selectability. 21:49:25 <fantasai> Florian: We previously resolved that 'user-select' property applies to ::before/::after and if it does, it's defaulted to none 21:49:33 <fantasai> Florian: Do we go away from that ? 21:49:42 <fantasai> Florian: Edge makes it selectable 21:49:46 <fantasai> Florian: Or do we discuss this some other day 21:50:09 <fantasai> dauwhe: Why did the spec say it shouldn't be selectable? 21:50:11 <zcorpan_> zcorpan_ has joined #css 21:50:17 <fantasai> Florian: Because a lot of time it's decorative 21:50:32 <fantasai> Florian: Should be able to flip it 21:50:36 <fantasai> Florian: what's the default? 21:50:51 <fantasai> gregwhitworth: There are far more people using it for non-decorative uses than you think 21:52:04 <fantasai> fantasai: I would prefer if the spec didn't say "go this direction" when we actually want to go in a different direction 21:52:11 <fantasai> TabAtkins: Then make it an issue in the spec 21:52:34 <fantasai> dauwhe: There's a bunch of old stuff about datetime() and document-url() 21:52:45 <fantasai> dauwhe: I would have use cases for this, but do we think this stuff should be in there? 21:52:49 <dauwhe> https://drafts.csswg.org/css-content/#content-datetime 21:52:57 <dauwhe> https://drafts.csswg.org/css-content/#content-document-url 21:53:14 <fantasai> dauwhe: These are really useful things in my world 21:53:23 <fantasai> dauwhe: Left them in 21:53:27 <fantasai> dauwhe: wanted to hear from CSSWG 21:53:35 <fantasai> dauwhe: Prince does not have these. Don't know AH status 21:53:50 <fantasai> TabAtkins: Without any real definition, not very useful to have in the spec :-) 21:54:07 <fantasai> dbaron: I'm going to suggest that they be removed 21:54:23 <fantasai> TabAtkins: One good reason to remove is to just establish them as variables 21:54:29 <fantasai> TabAtkins: Use cases are obvious 21:54:37 <fantasai> TabAtkins: Show up in footer of everything you print off the Web 21:55:33 <fantasai> fantasai: You could write a whole book about formatting dates and times. Think we should drop 21:55:44 <fantasai> RESOLVED: Drop <datetime> 21:55:58 <fantasai> Next: document-url 21:56:10 <fantasai> ekimber: Should be call it document-url 21:56:11 <fantasai> plinss: No. 21:56:16 <fantasai> ekimber: No? 21:56:17 <fantasai> plinss: No. 21:56:37 <plinss> s/document-url/document-uri/ 21:56:38 <fantasai> TabAtkins: Could also get this from a variable 21:57:15 <fantasai> RESOLVED: Drop document-url 21:57:41 <fantasai> Rossen: Anything else? 21:57:49 <fantasai> fantasai: Can we publish a new WD? 21:57:56 <fantasai> TabAtkins: There's a ton of new stuff here 21:58:07 <fantasai> fantasai: Was copied over from GCPM, per WG resolution on GCPM split. 21:58:17 <fantasai> hober: I'm in favor of publish an update to this. 21:58:33 <fantasai> RESOLVED: Publish new WD of Generated Content 21:58:47 <fantasai> dbaron: And do various renaming dances 21:59:01 <astearns> s/renaming/shortnaming/ 21:59:55 <fantasai> ChrisL: If not yet published under patent policy, then FPWD from patent policy 22:00:02 <fantasai> Florian: Some parts were published under GCPM FPWD 22:00:06 <zcorpan_> i added a new proposed agenda topic for wednesday: https://lists.w3.org/Archives/Public/www-style/2016May/0098.html [css-logical-props][css-writing-modes] Margins and margin collapsing and writing modes 22:00:15 <dbaron> s/renaming/shortname/ 22:00:18 <fantasai> [basically, deferring FPWD/WD distiction to staff contacts] 22:00:29 <fantasai> zcorpan_: I wanted to discuss this issue tomorrow 22:01:42 <fantasai> <br> 22:06:03 <tantek> tantek has joined #css 22:14:08 <joone1> joone1 has joined #css 22:20:50 <ChrisL_> ChrisL_ has joined #css 22:23:30 <Florian> Florian has joined #css 22:27:46 <bradk> bradk has joined #css 22:28:00 <gregwhitworth> ScribeNick: gregwhitworth 22:28:36 <gregwhitworth> Topic: Report on vertical writing award website 22:31:27 <tantek> tantek has joined #css 22:39:55 <myles> myles has joined #css 22:45:30 <myles> myles has joined #css 22:50:34 <fantasai> plinss, csswg.org is giving a 500 error 22:50:43 <fantasai> for the agenda 22:50:45 <plinss> fantasai: looking 22:51:49 <fantasai> ScribeNick: fantasai 22:51:56 <fantasai> Notes from skk's presentation 22:52:10 <fantasai> Kanji are often rendered at a larger font size than kana 22:52:27 <fantasai> Link underlining is not working interoperably in vertical text 22:52:45 <fantasai> fantasai: That's specified in text-decoration 22:52:58 <fantasai> dbaron: It's also possible to control it 22:53:12 <fantasai> fantasai: The spec has UA style sheet rules 22:53:42 <gregwhitworth> https://drafts.csswg.org/css-text-decor/#propdef-text-underline-position 22:54:07 <fantasai> dbaron: I think technically we implemented as an initial value, but that's hard to detect as different from the spec 22:54:33 <ChrisL> ChrisL has joined #css 22:55:14 <fantasai> skk: We have grid sheets for writing, to keep characters on the grid. 22:55:19 <dbaron> or maybe we implemented the initial value of the property but didn't implement the property? 22:55:33 <fantasai> skk: When we use ruby we cannot put each character inside the grid box 22:55:49 <fantasai> skk: In this example here, each character is inside its grid box 22:56:04 <fantasai> skk: This is a very discussionable point, but governmental document, they use character grid 22:56:13 <fantasai> skk: That document grid does not use ... 22:56:27 <fantasai> Florian: Japanese does not breaks at spaces, it breaks anywhere except before comma, before period, etc. 22:56:39 <fantasai> Florian: Government documents break anywhere, no exceptions. 22:56:48 <fantasai> Florian: Not a small corpus, government writes a lot... 22:56:57 <fantasai> Florian: Because it looks like ancient Chinese, looks formal. 22:57:43 <fantasai> fantasai: Doesn't word-wrap: wrap-word do that? 22:57:57 <fantasai> fantasai: I hate the names of these properties. Wish I had tried harder to rename them... 22:58:00 <zcorpan_> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4187 (test for underline with vertical japanese text) 22:58:23 <fantasai> Florian: It's interesting that there were no good designs submitted 22:58:42 <fantasai> Florian: There was a lot of time between the Web and Web that looks good, so seems like we have something similar here. 22:58:56 <fantasai> Florian: Maybe takes awhile before we have design that looks good 22:59:25 <gregwhitworth> ScribeNick: gregwhitworth 22:59:45 <gregwhitworth> Topic: Testing stuff 22:59:49 <myles> myles has joined #css 23:00:03 <tantek> tantek has joined #css 23:00:06 <gregwhitworth> gsnedders: I had a list of what we needed to do 23:00:20 <gsnedders> discuss for testing? when-does-review-happen, do-we-move-to-git-only, do-we-move-issue-tracking-to-github 23:01:13 <gregwhitworth> astearns: whatever we resolve on we should use the table spec as guinea pig (cc franremy) 23:03:50 <gregwhitworth> gsnedders: should have everything go in/out of git or mirroring with mercurial 23:04:03 <gregwhitworth> gsnedders: there are constraints on mercurial that aren't on git, etc 23:04:14 <gregwhitworth> gsnedders: like branches on the root 23:04:20 <gregwhitworth> plinss: that's a policy only 23:04:30 <gregwhitworth> plinss: the bridging handles branches just fine 23:05:01 <gregwhitworth> gsnedders: it feels repetitive, we should just standardize on one and if we're trying to move to WPT 23:05:12 <gregwhitworth> Florian: maybe we should have a one-way mirror 23:05:18 <gregwhitworth> TabAtkins: yes please 23:05:33 <gregwhitworth> TabAtkins: no one rebases in mercurial 23:05:51 <teoli> teoli has joined #css 23:05:56 <gregwhitworth> fantasai: a lot of people do 23:06:04 <gregwhitworth> shane: 23:06:11 <gregwhitworth> shans: can we relax the policy 23:06:32 <gregwhitworth> plinss: it's not my decision, but yes we can - but there was consensus a long time ago because it's confusing 23:06:52 <gregwhitworth> shans: I've contrib to a ton of GitHub projects and the branches are not confusion 23:07:05 <gregwhitworth> plinss: it's a policy about how it's used, I don't care one way or the other 23:07:35 <fantasai> dbaron: branches cause confusion, people have committed on the wrong branch 23:07:47 <gregwhitworth> shans: if we only do PRs on branches 23:07:52 <gregwhitworth> plinss: that's what we do already 23:08:06 <gregwhitworth> gsnedders: do we have a two way mirror between mercurial and git 23:08:28 <gregwhitworth> gsnedders: it makes it confusing on review because git gets reviewed before PR and on mercurial does not 23:08:44 <gregwhitworth> Florian: people who use mercurial use shepherd for review 23:08:52 <gregwhitworth> shans: yes that does sound like an issue 23:09:20 <gregwhitworth> shans: ignoring which control system is used it makes sense to have the review done before the merge 23:09:44 <gregwhitworth> astearns: we had this discussion and it was leaning towards moving to WPT 23:09:59 <gregwhitworth> dbaron: I'm fine with that if the browser vendors can push with the review like in WPT 23:10:11 <gregwhitworth> astearns: yes, the goal of this is to ultimately merge into WPT 23:10:46 <gregwhitworth> Florian: do we currently have the capability to push via mercurial via a diff branch 23:11:07 <gregwhitworth> plinss: there is nothing in the tool stopping you, but there is a policy and we could make it happen 23:11:21 <gregwhitworth> plinss: there is no tooling that is going to say oh this branch is a PR, etc 23:11:34 <gregwhitworth> plinss: but if we're moving to GitHub let's not re-invent the wheel 23:11:51 <gregwhitworth> Florian: given the current state then should we stop pushing to mercerial 23:11:54 <gregwhitworth> plinss: sure 23:12:29 <gregwhitworth> plinss: my only issue is that there are people that push tests that use mercurial and don't want to loose git, we run the risk of loosing their contribution 23:12:52 <gregwhitworth> Florian: the main problem here is that we loose the shepherd cycle, and that's what we no longer want 23:13:05 <gregwhitworth> Florian: we could build another tool 23:13:22 <gregwhitworth> plinss: the mirroring that does the work in mercurial can point to anything and that adds another level of complexity 23:13:31 <gregwhitworth> gsnedders: yeah, we should be trying to remove complexity 23:13:41 <gregwhitworth> Florian: this is an explicit question 23:14:02 <gregwhitworth> Florian: it will upset some people and given their contributions... 23:14:06 <gregwhitworth> Florian: I don't know 23:14:06 <bradk> bradk has joined #css 23:14:19 <gregwhitworth> plinss: maybe we can teach them and maintain the workflow 23:14:39 <gregwhitworth> Florian: the problem is that they don't want to just use merc but also shepherd with merc 23:14:50 <gregwhitworth> gsnedders: anyone else have an issue with git? 23:14:53 <gregwhitworth> <silence> 23:15:08 <gregwhitworth> Florian: if we make the change we should take them into account 23:15:38 <gregwhitworth> ChrisL: But part of the problem is we want more people doing it and if switching to git gets us that 23:16:00 <gregwhitworth> fantasai: my only concern is that GitHub makes it harder to review the tests 23:16:33 <gregwhitworth> fantasai: and while it may be annoying, if we provide clear steps on how to use it and map them to mercurial then it can make it easier to get started 23:16:41 <gregwhitworth> fantasai: we don't do very complicated here 23:17:24 <gregwhitworth> ChrisL: it was asserted that it was harder in git than shepherd, but I disagree because right now they live in two different areas and no one knows really where to look for the tests 23:17:40 <gregwhitworth> ChrisL: this makes things particularly hard 23:18:05 <gregwhitworth> gsnedders: as said yesterday, we can do mirroring and provide a link on PR to view them live 23:18:51 <gregwhitworth> ChrisL: we have contribs from years ago 23:19:17 <gregwhitworth> fantasai: there are comments has 2.1 comments from years ago on Microsoft but no email is sent, etc 23:19:39 <gregwhitworth> dbaron: then the changes go back into shepherd and can't be reviewed again or searched 23:21:16 <rbyers> q+ 23:21:41 <gregwhitworth> fantasai: plinss can you please make it that automatic bits from needs review to "needs work" 23:22:01 <gregwhitworth> dbaron: I'm asking to limit that change to only ones that are manually switched to "needs work" 23:22:19 <gregwhitworth> dbaron: I've submitted ~300 tests like this because the auto one is falsey 23:22:33 <gregwhitworth> plinss: there is a pref in shepherd to allow them to auto resubmit 23:22:44 <gregwhitworth> plinss: this is all irrelevant though if we're moving to git 23:23:06 <fantasai> s/because the auto one is falsy/where it was flagged as incorrect because of formatting problems that I then fixed by just pushing a fix; these should stay as resubmitted for review/ 23:23:24 <gregwhitworth> rbyers: going back to it being hard on reviewing the changes online, you can use rawgit 23:23:42 <gregwhitworth> gsnedders: some of them may not be able to do that due to .htaccess files 23:23:55 <gregwhitworth> Florian: does rawgit deal with relative urls 23:24:03 <gregwhitworth> rbyers: yes 23:24:14 <gregwhitworth> plinss: even images in another dir 23:24:17 <gregwhitworth> rbyers: yes 23:24:17 <fantasai> ACTION plinss Flip auto-resubmitted tests back to Needs Work if Needs Work was not auto-flagged 23:24:17 <trackbot> Created ACTION-771 - Flip auto-resubmitted tests back to needs work if needs work was not auto-flagged [on Peter Linss - due 2016-05-17]. 23:24:57 <gregwhitworth> rbyers: any tests that you can't run statically then we should put in another folder 23:25:10 <gregwhitworth> rbyers: the static ones are easier to run in browser and in impl test suites 23:25:26 <gregwhitworth> gsnedders: anyone going to object to us resolving to test submission solely to GitHub? 23:25:48 <rbyers> q- 23:26:18 <gregwhitworth> RESOLVED: All tests are added to csswg-test via GitHub PR, if implementation already reviewed push directly 23:26:41 <fantasai> https://wiki.csswg.org/tools/hg 23:26:51 <gregwhitworth> fantasai: florian can you please convert our tools mercurial page to git 23:28:33 <gregwhitworth> fantasai: basically we should have a contrib in README.md 23:28:44 <fantasai> s/fantasai/gregwhitworth/ 23:28:46 <gregwhitworth> ACTION: gregwhitworth to write basic contrib 23:28:46 <trackbot> Created ACTION-772 - Write basic contrib [on Greg Whitworth - due 2016-05-17]. 23:29:05 <fantasai> fantasai: And also create a page that explains how to pull down a PR locally, review, possibly edit, and merge into master 23:29:06 <gregwhitworth> gsnedders: issues about tests, should they be GitHub issues 23:29:28 <gregwhitworth> <bang, door doesn't open, bang> 23:29:39 <gregwhitworth> Florian: other issue is the tests on the mailing list 23:29:49 <gregwhitworth> gsnedders: currently we have issues in three different areas 23:30:08 <gregwhitworth> Florian: issues in shepherd are they issues on tests that we've approved already 23:30:10 <gregwhitworth> plinss: sure 23:30:21 <tantek> tantek has joined #css 23:30:22 <gregwhitworth> ChrisL: it can happen for a number of reasons 23:30:33 <gregwhitworth> Florian: interesting, didn't know people did that 23:30:40 <gregwhitworth> gsnedders: I would assume it's ok... 23:31:00 <gregwhitworth> plinss: define what you're asking then, are you asking for new issues or moving all shepherd issues to GitHub? 23:31:13 <gregwhitworth> gsnedders: I would prefer that but that's a lot 23:31:15 <gregwhitworth> plinss: yeah 23:31:32 <gregwhitworth> fantasai: is there a way to create a map of all of the issues for a given test? 23:31:37 <gregwhitworth> Florian: not really 23:31:54 <gregwhitworth> dbaron: I do use the shepherd issue searching stuff and that is useful 23:32:04 <gregwhitworth> fantasai: that is the primary reason we built shephard 23:32:16 <TabAtkins> github issues are a support forum 23:32:19 <tantek> tantek has changed the topic to: https://wiki.csswg.org/planning/san-francisco-2016 - IRC publicly logged: http://log.csswg.org/irc.w3.org/css/ 23:32:32 <gregwhitworth> dbaron: if we have the GitHub issues it'll be like the mailing list 23:32:43 <gregwhitworth> Florian: most people don't find mail issues 23:32:59 <gregwhitworth> gsnedders: also on mail you have no context of close issues 23:33:04 <tantek> on email, all issues are always open 23:33:18 <gregwhitworth> gsnedders: I'll note we have under 200 tests open on WPT 23:33:31 <gregwhitworth> dbaron: I can't filter for our recent moz tests 23:33:42 <gregwhitworth> Florian: I think ext contribs can't tag things 23:33:58 <gregwhitworth> fantasai: yeah that doesn't scale much unless it's just the vendors 23:34:19 <gregwhitworth> rbyers: the tagging issue with ext contribs is a common complaint 23:34:36 <gsnedders> q+ for shepherd's big issue 23:34:38 <gregwhitworth> fantasai: shepherd has its weaknesses but being able to search for all of the issues of their tests is very helpful 23:34:54 <gregwhitworth> dbaron: the big issue with shepherd is that no emails are sent 23:35:20 <gregwhitworth> Florian: they're slightly related, without knowing the issues are there you can see them and find them and issues don't pile up 23:35:31 <gregwhitworth> fantasai: can we just fix shepherd, how hard is that 23:35:38 <gregwhitworth> plinss: it's not too hard 23:35:56 <gregwhitworth> dbaron: my first thought is to file all new issues in GitHub and see how it goes 23:36:14 <gregwhitworth> plinss: getting all issues into GitHub is not something I'm signing up for today 23:36:32 <gregwhitworth> plinss: nothing we've discussed today kills off shepherd 23:36:49 <gregwhitworth> plinss: always on the roadmap is to integrate GitHub issues with shepherd issues 23:36:55 <gregwhitworth> fantasai: how do you key that? 23:37:11 <gregwhitworth> fantasai: if there was a field that allowed you to have a test id you could map them 23:37:28 <gregwhitworth> fantasai: one thing with shepherd is you can't see one issue that addresses 50~n tests 23:37:47 <gregwhitworth> fantasai: if you have a problem in a test you have that same problem everyone, that is one of the great weaknesses of shephard 23:38:04 <fantasai> s/everyone/lots of tests/ 23:38:16 <gregwhitworth> fantasai: if we can figure out a way to map the issues with the tests then that only improves github 23:38:16 <fantasai> s/of shephard/of shepherd, that you can't file a single issue against a bunch of tests/ 23:38:31 <gregwhitworth> ChrisL: if shepherd is just a filter on the GitHub info then that only improves it 23:38:55 <gregwhitworth> gsnedders: my only other issue is that shepherd is just another bug tracking issue, and they're complex 23:39:02 <gsnedders> q- 23:39:09 <gregwhitworth> ChrisL: that isn't a barrier though because they can file the issue on github 23:39:28 <gregwhitworth> fantasai: I would like for us to find a way to get the issues into shepherd so that they're searchable 23:39:37 <gregwhitworth> Florian: the labels and tags can help 23:39:52 <gregwhitworth> gsnedders: WPT adds the tags automatically based on dir 23:40:04 <gregwhitworth> fantasai: because we will have a billion tags 23:40:14 <gregwhitworth> fantasai: maybe if you put in some comment block 23:40:22 <gregwhitworth> Florian: can you machine read comments 23:40:27 <gregwhitworth> gsnedders: yeah, use the API 23:40:54 <gregwhitworth> fantasai: perfect, that would allow Shephard to track that to search issues by test 23:41:17 <gregwhitworth> gsnedders: if a code block contains a bunch of paths then it refers to those files, most issues already do that 23:41:32 <gregwhitworth> gsnedders: more specific we make that the less likely it is to be picked up by the system 23:41:53 <gregwhitworth> ACTION gsnedders: come up with a syntax for shepherd to be able to get the issues 23:41:53 <trackbot> Created ACTION-773 - Come up with a syntax for shepherd to be able to get the issues [on Geoffrey Sneddon - due 2016-05-17]. 23:42:26 <gregwhitworth> RESOLVED: All new issues for test should be on github 23:42:40 <gregwhitworth> ACTION gsnedders: get the automatic tagging setup - figure it out 23:42:41 <trackbot> Created ACTION-774 - Get the automatic tagging setup - figure it out [on Geoffrey Sneddon - due 2016-05-17]. 23:43:03 <gregwhitworth> ACTION plinss: get the GitHub issues reflected in Shephard 23:43:03 <trackbot> Created ACTION-775 - Get the github issues reflected in shephard [on Peter Linss - due 2016-05-17]. 23:43:53 <gregwhitworth> Topic: Issues on the specs 23:44:05 <gregwhitworth> ChrisL: It's up to everyone on what to do 23:44:18 <gregwhitworth> ChrisL: I would like to suggest moving those issues to GitHub 23:44:23 <gregwhitworth> ChrisL: Labelling, tagging, etc 23:44:42 <gregwhitworth> ChrisL: I was skeptical at first at web audio WG and it turned out I was wrong 23:45:06 <gregwhitworth> Florian: I partly disagree with the problem statement, they are not filed everyone 23:45:13 <fantasai> s/everyone/everywhere/ 23:45:19 <fantasai> Florian: They are filed in the ML, and tracked various places 23:45:27 <gregwhitworth> dbaron: I think having issues in the spec is very good 23:45:45 <gregwhitworth> ChrisL: I'm not saying remove them from inline, but the thread should be in Github 23:46:19 <gregwhitworth> dbaron: I think forcing the editor to file a GitHub issue and I'm going to write them down, I don't think we should file GitHub issues for that 23:46:31 <gregwhitworth> dbaron: I think it's ok to have an issue only in the spec 23:46:48 <tantek> hmm - how much time do we set aside to discuss issue tracking systems? 23:46:48 <gregwhitworth> ChrisL: I think once there is a discussion, that discussion should be on Github 23:47:20 <fantasai> ScribeNick: fantasai 23:47:40 <Rossen> q? 23:48:04 <fantasai> Florian: So, does filing issue in Github mean we move technical discussion out of the ML into Github, or no? 23:48:10 <fantasai> ChrisL: That's not what I was saying 23:48:13 <fantasai> dbaron: I would like to do that 23:48:33 <fantasai> gregwhitworth: I think the best benefit of discussions on Github is that the thread ends, there's a close button 23:49:16 <fantasai> gregwhitworth: Can't say how many times on an ML thread, the closed discussion is reopened by someone making more comments 23:49:31 <TabAtkins> q+ 23:49:44 <fantasai> gregwhitworth: You know that the discusison is close 23:49:54 <fantasai> gregwhitworth: Can directly correlate a push to a closed issue 23:50:05 <fantasai> gregwhitworth: People can continue to comment, but the issue is closed 23:50:18 <fantasai> gregwhitworth: Additionally, Disposition of Comments becomes easy once the issues are tagged 23:50:24 <fantasai> gregwhitworth: Makes the process a lot easier 23:50:39 <fantasai> TabAtkins: While on this topic, bikeshed doeshave support for easily inlining GitHub issue 23:50:46 <fantasai> TabAtkins: [..] 23:50:55 <fantasai> TabAtkins: Grabs contents of the first comment, and links back to github for you 23:51:11 <zcorpan_> s/[..]/you do ISSUE(num):/ 23:51:15 <ChrisL> q+ to say more about disposition of comments 23:51:27 <Rossen> q? 23:51:37 <Rossen> ack TabAtkins 23:51:39 <fantasai> ChrisL: I wanted to add on something wrt what Greg said 23:51:40 <Rossen> ac ChrisL 23:51:44 <Rossen> ack ChrisL 23:51:44 <Zakim> ChrisL, you wanted to say more about disposition of comments 23:51:47 <fantasai> ChrisL: DoC is definitely better on GitHub 23:51:51 <tantek> +1 23:51:53 <Rossen> q? 23:52:18 <fantasai> fantasai: You were so adamant about having multiple statuses per DoC issue, and that's impossible on GitHub, what gives. 23:52:25 <fantasai> ChrisL: I changed my mind 23:52:33 <tantek> besides, we can use labels for multiple statuses per DoC issue on GitHub 23:52:59 <TabAtkins> q+ 23:53:04 <fantasai> ChrisL: It's possible to prove onGitHub that the person who commented was CCd on the resolution 23:53:19 <tantek> (and impossible on the mailing list) 23:53:20 <tantek> yes! another convert! 23:53:35 <fantasai> Florian: If all issues are filed on GitHub, then only can talk to people on GitHub. How do you CC somebody who's not on GitHub? 23:53:41 <fantasai> ChrisL: You can send them a link 23:53:59 <fantasai> ChrisL: Transcribe their comment into Github issue 23:54:10 <fantasai> Florian: GitHub is much better at tracking whether or not something was closed. 23:54:21 <fantasai> Florian: Doesn't make it better to track whether someone has been informed and whether or not they agree. 23:54:27 <TabAtkins> ack TabAtkins 23:54:38 <fantasai> TabAtkins: The benefit of github here is that when you do that nice, give me date range of these issues 23:54:45 <fantasai> TabAtkins: I can drop labels on everything, easily see it and track it 23:54:55 <fantasai> TabAtkins: Anything is going to be easier than our manual text-based tracking 23:55:20 <fantasai> ChrisL: Yes. Especially if director wants to figure out why thread is not in the DoC 23:55:33 <fantasai> ChrisL: Etc. So annoying. 23:55:40 <fantasai> tantek: So we're done with that? 23:55:48 <fantasai> TabAtkins: Lets be done with that 23:56:04 <fantasai> gregwhitworth: Is there some kind of W3C archiving requirement? How would we manage that requirement? 23:56:15 <fantasai> ChrisL: *waves hand handwavily* 23:56:28 <fantasai> fantasai: Should we pipe all of the comments to a readonly mailing list? 23:56:45 <fantasai> ChrisL: Gives you the raw data. Not very usable form, but it's there. 23:56:58 <fantasai> ChrisL: We'd be screwed if GitHub shuts down, it is an issue. 23:57:03 <fantasai> TabAtkins: We can do that part today. 23:57:10 <fantasai> TabAtkins: Just need to create a new ML 23:57:27 <fantasai> Florian: Yes, everything that happens on Git should be sent somewhere, a subscribable place 23:58:03 <fantasai> fantasai: One of my main issues with switching systems is being able to work offline. 23:58:14 <fantasai> Florian: You can respond by mail, just can't open new issues. 23:58:51 <fantasai> Florian: Ability to file issues offline would be curtailed... everything else seems to be doable 23:59:30 <fantasai> Rossen: Trying to summarize... 23:59:38 <fantasai> Rossen: Hearing a lot of sympathy for moving to GitHub 23:59:54 <fantasai> Rossen: And one drawback is being able to work offline