| 02:24 | roc | watches Sylvain and Tab go head to head |
| 02:47 | <TabAtkins> | roc: I'm *super* pissed about that. Totally done talking with Sylvain for a while. |
| 02:48 | <TabAtkins> | Happened before. I should know better by now. |
| 02:48 | <SamB> | what forum was this? |
| 02:48 | <TabAtkins> | Twitter. |
| 02:48 | <TabAtkins> | The moment he switches from arguing to snarking, I just need to block him for a while. |
| 02:49 | <TabAtkins> | Too fucking frustrating otherwise. |
| 02:49 | <SamB> | that does not sound like a good place to argue |
| 02:52 | <TabAtkins> | The smug subtweeting afterwards is the worst part (which is why I need to just block for a while). |
| 02:54 | <astearns_> | TabAtkins: FWIW, I think the main disconnect is between what you think (and continue to maintain) you said, and what everyone else in the room heard at the time |
| 02:55 | <TabAtkins> | I'm aware of what the disconnect is. Doesn't make it any less wrong, or any less annoying when people insist that I *really meant* something different and evil. |
| 02:55 | <TabAtkins> | I know what I actually said. What people heard is their business. |
| 02:56 | <astearns> | TabAtkins: I was in the room, and I heard something different than what you maintain you said. Yes, it is my business, but I'm not the only one |
| 02:56 | <astearns> | and I do expect that you really meant something different - what you're maintaining you said now |
| 02:58 | <TabAtkins> | And it certainly wasn't helped by a few people straight up saying during the discussion that I had previously said "Chrome would accept any changes the WG makes" and implying that I was now going against my word, when I was careful the entire time to say that it was "as long as it doesn't freeze due to usage". Which should be a matter of course, but some |
| 02:58 | <TabAtkins> | people like pretending that they can change reality by altering a spec. |
| 02:59 | <roc> | time for an emergency subject change |
| 02:59 | <TabAtkins> | I suspect that that (some people saying I had said something different in the past) probably had an effect on what other people "heard" me say. Memory is shitty, after all. |
| 02:59 | <TabAtkins> | roc: Kittens |
| 02:59 | <SamB> | it sounds like everyone should just agree that what TabAtkins meant to say and what other people though TabAtkins meant to say are not the same thing, and stop worrying about the details of whether he said either of those things |
| 03:00 | <TabAtkins> | SamB: It would be great if everyone did that, yes. |
| 03:00 | <TabAtkins> | roc: You're supposed to *deploy* the subject change when you say that. |
| 03:00 | <SamB> | I suspect that the the those two things are actually ideas, in any case, and what he said are words |
| 03:00 | <TabAtkins> | roc: Can't just expect the rest of the room to change itself. |
| 03:00 | <TabAtkins> | SamB: I communicate only through interpretative dance, so no. |
| 03:00 | <SamB> | lol |
| 03:01 | <SamB> | TabAtkins: no wonder nobody had a clue what you meant |
| 03:01 | <astearns> | it can be difficult at times :) |
| 03:01 | <TabAtkins> | SamB: Dance is the universal language. Not my fault the rest of the room hadn't learned it. |
| 03:01 | <TabAtkins> | Nor does that make it less universal, if that's what you're thinking. |
| 03:02 | <SamB> | obviously terrans are just rude |
| 03:02 | <astearns> | it does add a bit of savior-faire to the proceedings, though |
| 03:02 | <roc> | savoir |
| 03:02 | <astearns> | gah |
| 03:02 | <TabAtkins> | *Jesus Christ |
| 03:02 | <astearns> | no need for any more savior-faire |
| 03:02 | <TabAtkins> | That's the Christian ren-faire. |
| 03:03 | <SamB> | why didn't I ever get an invite? |
| 03:03 | <TabAtkins> | Not savory enough. |
| 03:03 | <roc> | TabAtkins: here's another subject for you. abarth said on www-style a while back that Chrome people were trying to find a script-based approach to generic scrolling effects (sticky, sliding panels, parallax scrolling, etc). What's happening with that? Is there a nascent API proposal anywhere? |
| 03:03 | <TabAtkins> | roc: brb |
| 03:05 | <astearns> | can't find the video of shirtless dancing at TPAC :( |
| 03:06 | <SamB> | 'computed COMEFROM' ... mind ... broken! |
| 03:08 | <TabAtkins> | roc: Not really, not yet. We're still not sure quite what to do. We have a few ideas, just not enough to put a proposal together yet. |
| 03:08 | <TabAtkins> | roc: We discussed it a bit at the Input meeting last week in Seattle. |
| 03:09 | <TabAtkins> | roc: Basically, we think that, while moving more effects to a scrolling thread is great for lots of things, it makes it impossible to simulate some existing effects (and thus to do your own effects of the same caliber). |
| 03:10 | <TabAtkins> | roc: So we think we'll need some way for pages to opt back into sync scrolling for elements or the page, along with well-designed timing for the scroll events and such, plus other main-thread improvements to make it easier to do the effects and hit every frame. |
| 03:10 | <roc> | I don't know if you're aware yet, but we're very interested in extending Web Animations to support scroll position as a timing source. Similar to your CSS-based proposal. |
| 03:10 | <TabAtkins> | roc: Pair that with continuing development of off-thread developments in the declarative realm. |
| 03:11 | <TabAtkins> | roc: Like, yes, custom timing sources such as scroll position in Web Anim. |
| 03:11 | <TabAtkins> | And yeah, the Web Anim approach is our preferred direction for that kind of thing right now, with possible a CSS layer afterwards. |
| 03:12 | <roc> | abarth rejected CSS snapping (and apparently position:sticky?). Any idea whether any declarative proposals will be accepted by Chrome in the medium term? |
| 03:13 | <roc> | do you think Web Animation with a scroll position timing source is above Adam's bar? |
| 03:13 | <roc> | or if you don't want to channel him, where's your bar? |
| 03:16 | <TabAtkins> | roc: Adam's on one side of the divide, I'm on the other, and I've been pulling the team a little more on the "we really do need to offer sugar for authors" side lately. |
| 03:16 | <roc> | ok good to know :-) |
| 03:16 | <TabAtkins> | So we're probably going to do at least a subset of snapping. As we figure it out, I'll send feedback. |
| 03:16 | <TabAtkins> | Sticky is going to happen, we just had a bad impl that didn't mesh well with our compositor. |
| 03:17 | <roc> | ok |
| 03:17 | <roc> | that's also good to know |
| 03:17 | <TabAtkins> | And it was making it hard to improve things in the meantime. |
| 03:17 | <roc> | for CSS snapping, I think we can actually do most of what we want using script. |
| 03:17 | <TabAtkins> | Doing a lot of revolution-not-evolution in our compositing pipeline lately, trying to fix a lot of latent bugs. |
| 03:17 | <TabAtkins> | roc: We don't think you can do high-fidelity snapping async. |
| 03:18 | <roc> | is there a short explanation? |
| 03:22 | <roc> | I agree you can't do perfect-fidelity snapping without telling the compositor enough information that it can execute a complete scrolling gesture plus snapping without any main-thread activity. |
| 03:24 | <TabAtkins> | Yeah, that's basically it. That's not something you can tell the compositor right now. |
| 03:25 | <roc> | but if the compositor sent an event to the main thread when the user scroll gesture ends, where the event contains the scroll position the compositor will settle on after fling momentum ends etc, then the main thread can compute a snapped position and tell the compositor, which would be responsible for landing at that position --- either by tacking on more animation or by adjusting the... |
| 03:25 | <roc> | ...in-progress animation. |
| 03:25 | <TabAtkins> | And we think that ultimately the set of things you might want to do will exceed what we choose to expose in "tell the compositor about X". |
| 03:26 | SamB | wonders if this is a bad time to mention how much he hates those pages with the background images that don't scroll with the rest of the page, thus requiring lots of needless recompositing ... |
| 03:26 | <roc> | the latency between the user scroll gesture ending and the compositor getting the snapped scroll position might not be so bad. After all, snapping generally requires scroll direction and/or velocity changes anyway. |
| 03:29 | <roc> | anyway, the impasse over CSS snapping specs means we'll probably have to try that approach for our existing snapping use-cases. Using ScrollOptions.behavior = "smooth" with scrollTo/scrolTop to tell the compositor to snap to a position. |
| 05:39 | <abarth> | roc: you can implement snap points today without help from the browser |
| 05:40 | <abarth> | roc: amazon has a nice implementation |
| 05:40 | <abarth> | the problem is more how to make it possible for folks to re-use implementations written by experts |
| 05:52 | <roc> | AFAIK shipping browsers lack two things |
| 05:52 | <roc> | 1) a way to reliably detect the end of a user scroll gesture |
| 05:53 | <SamB> | roc: how would that work exactly |
| 05:53 | <SamB> | what is this "end" |
| 05:53 | <roc> | 2) a way to tell the compositor to scroll smoothly to a destination in a way that dovetails nicely with momentum scrolling that carries on after the user scroll gesture has finished |
| 05:54 | <SamB> | if I grab the bar, whose to say where I'm going to release it? |
| 05:55 | <roc> | SamB: with a "fling gesture" on a touchscreen, the touch-up is the end of the user scroll gesture, but scrolling continues until it runs out of momentum |
| 05:56 | <SamB> | so, how would this thing work on a desktop with a scrollbar? |
| 05:56 | <roc> | for thumb dragging, we'd fire the "user scroll gesture ended" event when the user releases the thumb. |
| 05:57 | <SamB> | sounds kind of jarring |
| 05:57 | <SamB> | to snap AFTER the user releases the thumb |
| 05:57 | <SamB> | not that I've got a better idea |
| 05:58 | <roc> | that matches how most snapping works on touch devices |
| 05:58 | <abarth> | roc: amazon doesn't use scrolling to implement snap points |
| 05:59 | <abarth> | maybe I should study their code more, but I would be surprised if they did |
| 06:00 | <abarth> | roc: yes, we should add scrollstart and scrollend events |
| 06:00 | <roc> | if so, it doesn't work with async scrolling and touch panning, so it won't be a great experience |
| 06:00 | <abarth> | roc: the latter doesn't follow from the former |
| 06:00 | <abarth> | in fact, it's a great experience |
| 06:00 | <abarth> | try it |
| 06:00 | <roc> | on a really low end device? |
| 06:01 | <abarth> | roc: it works well on the devices I have |
| 06:01 | <abarth> | maybe I should try on lower end devices? |
| 06:01 | <abarth> | roc: what is the minimum latency to talk to the main thread on your target device? |
| 06:02 | <abarth> | meaning, under optimal conditions, how long does it take for the main thread to program data into the compositor |
| 06:05 | <roc> | less than 2x the vsync interval. |
| 06:06 | <roc> | but the real problem is that conditions are not always optimal :-) |
| 06:06 | <abarth> | so, if vsync is 16ms |
| 06:06 | <abarth> | it takes 8ms! |
| 06:06 | <abarth> | how hard have you tried to bring that number down? |
| 06:06 | <roc> | it's really easy to blow the 16ms frame budget with main-thread activity. You know that of course :-) |
| 06:07 | <abarth> | well, if your minimum latency is 8ms, I'm not surprised |
| 06:07 | <abarth> | we're getting more like 2ms |
| 06:07 | <abarth> | we're working on getting it down to 1ms |
| 06:08 | <roc> | I'm not worried about the best-case performance. |
| 06:08 | <roc> | I'm worried about the main thread getting blocked by a script or something outside our immediate control. |
| 06:08 | <abarth> | ok, then what's causing you not to get best-case performance when the user scrubbing a snap point widget? |
| 06:09 | <abarth> | who's control? |
| 06:09 | <roc> | the UA's control. |
| 06:09 | <abarth> | right, the UA is not in control |
| 06:09 | <abarth> | the web developer is in control |
| 06:11 | <abarth> | my experience discussing this topic is that when you push on the motivation for snap points |
| 06:12 | <abarth> | you eventually get down to the person who supports snap points saying that JavaScript developers aren't skilled developers |
| 06:12 | <abarth> | I think it's fair to say that some JavaScript developers are highly skilled and some are less highly skilled |
| 06:13 | <abarth> | which is why I wrote above that this problem is really about how to you get the less skilled developer to reuse work done by highly skilled developers |
| 06:13 | <abarth> | historically, we've done that by having the highly skilled developers hard-code behaviors into browsers |
| 06:14 | <abarth> | but another approach is to encourage highly skilled JavaScript developers to make their work reusable by less skilled developers |
| 06:14 | <roc> | BTW I completely misunderstood your earlier question about update latency... |
| 06:14 | <abarth> | oh good |
| 06:14 | <abarth> | you had me worried :) |
| 06:14 | <roc> | the problem is that to keep main-thread latency reliably low you have to prevent the "less skilled developer" from doing anything that could blow the latency budget |
| 06:15 | <abarth> | which is a scheduling problem |
| 06:15 | <abarth> | iOS does that by controling your event loop |
| 06:15 | <abarth> | when the finger is down on the glass |
| 06:15 | <roc> | so it's not just a matter of "use this library for scrolling", it's also "don't do anything else that could run too long", and there's a long list of things there |
| 06:15 | <abarth> | only certain events will come out of the event loop |
| 06:15 | <abarth> | the rest are delayed |
| 06:15 | <abarth> | we'll likely do something like that too |
| 06:16 | <abarth> | but we haven't studied that aspect of the problem in great detal yet |
| 06:16 | <abarth> | detail |
| 06:16 | <abarth> | roc: put another way, how did the less skill developer steal time from the snap points widget's time slice? |
| 06:18 | <roc> | lots of ways ... requestAnimationFrame, triggering a complex CSS restyle/reflow, setTimeout |
| 06:19 | <abarth> | can you see how those are scheduling problems? |
| 06:19 | <roc> | no, not really |
| 06:19 | <abarth> | why did the setTimeout fire during the touch interaction? |
| 06:19 | <roc> | I don't think you can get away with suppressing those entirely during a touch-pan |
| 06:19 | <abarth> | why not? |
| 06:20 | <abarth> | that's what iOS does |
| 06:20 | <abarth> | it's true that we haven't gone down that path you |
| 06:20 | <abarth> | s/you/yet/ |
| 06:21 | <roc> | do animations stop? |
| 06:21 | <abarth> | we're still working with folks fairly high up the skill curve |
| 06:21 | <abarth> | you shouldn't drive animations with setTimout |
| 06:21 | <abarth> | if you do that, I'm ok making your animations bad |
| 06:21 | <abarth> | it's an iterative process |
| 06:21 | <abarth> | whereby we're moving down the skill curve |
| 06:22 | <roc> | I didn't say that, I was just curious |
| 06:22 | <abarth> | maybe we'll get to a point where the developers aren't skilled enough |
| 06:22 | <abarth> | but we haven't reached that point yet |
| 06:22 | <abarth> | I don't think we can tile the space of all effects by hard-coding them into the browser |
| 06:22 | <roc> | I don't think so either |
| 06:23 | <abarth> | so, at some point, we need to decide "that's bespoke" |
| 06:23 | <roc> | so I wish you'd stop raising that straw man |
| 06:23 | <abarth> | then, it's just a question of where to draw the line |
| 06:23 | <abarth> | not whether to draw a line |
| 06:23 | <abarth> | how do you decide where to draw the line? |
| 06:23 | <abarth> | we're trying to figure that out by seeing how good we can make the platform for bespoke effects |
| 06:24 | <abarth> | maybe we'll fail |
| 06:24 | <abarth> | and bespoke effects won't work well |
| 06:24 | <abarth> | in which case, we'll need to add many tiles and draw the line to include more UA-provided effects |
| 06:24 | <abarth> | but maybe we'll succeed |
| 06:24 | <abarth> | in which case, many effects can be treated as bespoke by the platform |
| 06:24 | <roc> | I don't have a deterministic algorithm for drawing the line |
| 06:24 | <abarth> | and the UA provides a much smaller set |
| 06:25 | <abarth> | which is why I wrote the email I did about snap points |
| 06:25 | <abarth> | it's not that I think they're bad |
| 06:25 | <abarth> | it's just that we're not planning to implement them |
| 06:25 | <abarth> | that might change if we fail |
| 06:26 | <abarth> | and the web platform can't support high-quality bespoke effects |
| 06:26 | <roc> | in the FirefoxOS homescreen, touch panning is done by script setting CSS transforms, and we did a lot of optimizations to make that work well |
| 06:26 | <abarth> | its too bad you don't have web animations |
| 06:27 | <abarth> | that way script can talk directly to the animation engine |
| 06:27 | <abarth> | without involving CSS |
| 06:27 | <abarth> | e.g., you can program an animation curve |
| 06:27 | <abarth> | and all you need to do in your touch handler |
| 06:27 | <abarth> | is set the currentTime of the animation |
| 06:27 | <abarth> | the main thread has almost no work to do |
| 06:28 | <abarth> | that's why I'm interested in the idea of moving that touch handler into the compositor. it's such a powerful, basic primitive |
| 06:29 | <roc> | our existing script-driven panning solutions have some problems. One of them is that we have implemented a lot of heuristics and behaviors for async scrolling and touch scrolling in the platform. And they have to be reimplemented/emulated by our panning scripts. |
| 06:30 | <abarth> | so, Android solves this problem by writing them once in Java |
| 06:30 | <roc> | we are working on Web Animations, and are very interested in being able to make a Web Animation directly use the async scroll position as its timing source |
| 06:30 | <abarth> | in the context of a browser, that would mean writing them once in JavaScript |
| 06:30 | <abarth> | another approach would be to supply them to JS as a library |
| 06:31 | <abarth> | you can do that in Android too. They have a bunch of Java classes provided by the framework that do scrolling math for you |
| 06:31 | <abarth> | they don't move things around on the screen---they just tell you what the physics are |
| 06:33 | <roc> | if you have a lot of use-cases which can be implemented by having your touch handler just set the current time on a Web Animation, then adding an API to that automatically in the compositor seems like a no-brainer to me. |
| 06:33 | <roc> | it certainly satisfies most of our use-cases |
| 06:33 | <abarth> | I'm glad to hear that :) |
| 06:34 | <roc> | and you get a nice robust solution |
| 06:34 | <roc> | so are you on board with that? :-) |
| 06:34 | <abarth> | yes :) |
| 06:35 | <roc> | glad to hear it :-) |
| 06:35 | <abarth> | thanks for taking the time to talk this through |
| 06:35 | <abarth> | IRC can be a better medium than mailing lists sometimes |
| 06:46 | <sspi> | I send an email towards www-dom⊙wo yesterday (about 10 hours ago here), however haven't seen it in the archives yet. Do I need to do anything special besides saying it's okay to archive my email? which I did. |
| 08:42 | <annevk_> | "masinter added you to multipart-form-data" great work there MikeSmith |
| 08:46 | MikeSmith | pats himself on the back |
| 08:46 | <MikeSmith> | annevk: paving the road for you with my good intentions |
| 08:49 | <MikeSmith> | sspi: I'll check on it right now |
| 08:50 | <annevk> | jgraham: how easy would it be for you to set up test where Content-Length is set to 4 and body is set to "PASS (if you see this though, FAIL!)"? |
| 08:51 | MikeSmith | pushes some buttons |
| 08:51 | <MikeSmith> | sspi: should be on its way to the list no |
| 08:51 | <MikeSmith> | *now |
| 08:53 | <annevk> | Domenic: given https://code.google.com/p/chromium/issues/detail?id=389124#c10 it seems pretty clear he's not even willing to entertain the thought they might be wrong |
| 09:03 | <jgraham> | annevk: Very? |
| 09:05 | <jgraham> | annevk: If you were careful with byte counting you could even make it work as a scripted test |
| 09:06 | <annevk> | jgraham: could you do it and tell me what happens? |
| 09:06 | annevk | is trying to find the answer to https://www.w3.org/Bugs/Public/show_bug.cgi?id=26241#c6 |
| 09:14 | <jgraham> | annevk: The test I wrote seems to PASS in Chrome and Fx |
| 09:15 | <jgraham> | annevk: If you work out where this test should live I could even submit a PR for it :) |
| 09:16 | <annevk> | jgraham: can be part of XHR if you did it that way |
| 09:17 | <annevk> | jgraham: it's testing the HTTP layer though, so if we have a directory for HTTP |
| 09:18 | <jgraham> | We don't have a HTTP directory, and I just did it through a normal document |
| 09:18 | <annevk> | jgraham++ for having a better test framework than we had a couple years back |
| 09:18 | <jgraham> | No XHR |
| 09:19 | <annevk> | I guess you could make it a ref test in a new HTTP dir? |
| 09:20 | <annevk> | SamB: that draft was replaced by another draft which was also replaced, which eventually became http://tools.ietf.org/html/rfc6648 |
| 09:20 | <annevk> | SamB: unfortunately some of the linking went lost |
| 09:22 | <jgraham> | https://github.com/w3c/web-platform-tests/pull/1089 |
| 09:25 | <jgraham> | http://w3c-test.org/submissions/1089/http/content_length.html is the actual test |
| 09:30 | <annevk> | ta |
| 09:32 | <JakeA> | annevk: are you suggesting context="frame" for all navigations? Or would iframes get something different? |
| 09:32 | <annevk> | JakeA: yes |
| 09:33 | <annevk> | JakeA: "document" might be a better term since HTML calls them document environments |
| 09:33 | <JakeA> | annevk: much better |
| 09:33 | <JakeA> | I'll add that to the ticket |
| 10:31 | <pulse00> | hi all. i'm trying to find info on how browsers implement autocompletion of login credentials. we're having a loginpage example.com/login which has 2 input fields, one with type="password". when saving the password, the browser (chrome in this case) not only autofills example.com/login form fields, but also example.com, which holds a registration form. |
| 10:31 | <pulse00> | however, the registration form under example.com should not be autofilled with previous username/password values. |
| 10:31 | <pulse00> | i've already set <form autocomplete="off"/> on the registration page, but this is being ignored it seems. |
| 10:32 | <pulse00> | has anyone an idea if this feature is somewhere handled in the html specification? |
| 10:33 | <annevk> | pulse00: instead of setting autocomplete to off, set it to a value that describes the purpose |
| 10:34 | <annevk> | pulse00: per http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-autocomplete |
| 10:36 | <pulse00> | annevk: thanks a lot! |
| 10:40 | <pulse00> | what's still a mystery to me: why is the browser autocompleting a form with values from another url? i mean the login form lives on example.com/login, and the registration form on example.com, which are 2 different forms and urls... |
| 10:43 | <annevk> | pulse00: login forms can often be found on many URLs |
| 10:43 | <pulse00> | so because the form has an email/password input combination, the browser assumes it's the login form and autofills it? |
| 10:44 | <annevk> | yeah, heuristics for that are not really defined |
| 10:44 | <annevk> | browsers are slowly working on addressing that problem better now, part of the deal is the new design of the autocomplete attribute |
| 10:45 | <pulse00> | annevk: thanks a lot for the info |
| 11:35 | <Ms2ger> | If f is not one of "NFC", "NFD", "NFKC", or "NFKD", ... |
| 11:35 | <Ms2ger> | Yay ES |
| 11:42 | <sspi> | MikeSmith: just read your message, tnx for helping out :) |
| 12:41 | <MikeSmith> | sspi: chhers |
| 12:45 | <annevk> | Ms2ger: what's the problem? |
| 12:45 | <annevk> | JakeA: I'm not sure if checking MIME type was agreed or not, but it seems like it would be good |
| 12:46 | <JakeA> | annevk: I'm happy with your conclusion. Assume multipart unless it's a urlencoded mime type |
| 12:46 | <annevk> | JakeA: I meant re service worker MIME type |
| 12:47 | <annevk> | JakeA: for multipart apparently the MIME type has to be checked to get the boundary parameter |
| 12:51 | <JakeA> | annevk: oh, sorry. Yeah, I agree. 96.7% of urls ending in ".js" are served with one of application/x-javascript, text/javascript. application/javascript |
| 13:13 | <MikeSmith> | hsivonen: I've landed validator support for <picture> in the syntax repo. Any chance you might be able to deploy it to v.nu and h5.v.nu today? |
| 13:15 | <MikeSmith> | hsivonen: for this case (relatively big new addition) I'd prefer not deploying it at the w3c validator until you have time to also deploy it |
| 13:20 | darobin | wonders if annevk gets to spend as much time with his dog as he'd like |
| 13:21 | <annevk> | darobin: my dog is dead you ass |
| 13:21 | <darobin> | ow! |
| 13:21 | <darobin> | sorry about that |
| 13:21 | <darobin> | but seriously, is that a .nl expression? |
| 13:23 | <annevk> | I had a dog once, but my mother mostly took care of it, he died of old age, and above I was failing to be funny |
| 13:43 | <darobin> | annevk: I thought you were trying to be funny, but there was the odd chance you weren't and I didn't want to just torment your bereaved soul |
| 13:43 | <darobin> | well, I didn't want it too bad |
| 13:44 | <darobin> | anyway, loved that expression on www-tag; I'm definitely going to use it :) |
| 13:44 | <annevk> | heh |
| 14:03 | <annevk> | This whole blob reading things needs some more thinking... |
| 14:18 | <SamB> | annevk: yeah, I noticed, I just wish there was some kind of "report" functionality for such missing links between drafts ... |
| 14:18 | <annevk> | SamB: I reported it on Twitter, the editor passed it on |
| 14:18 | <SamB> | I guess that works |
| 14:19 | <SamB> | naturally, the original title was better ;-) |
| 14:30 | <annevk> | There's no place for humor in the IETF, except when it comes to their publishing format |
| 14:31 | <jcgregorio> | annevk +1 :-) |
| 14:35 | <SamB> | annevk: are you talking about the recent sad but true April 1 RFC? |
| 14:36 | <jgraham> | The IETF publishing format is dadaism at its finest. |
| 14:37 | <jgraham> | In a few years they'll have an original copy of RFC 2616 printed on a daisywheel printer in MoMA |
| 14:40 | <SamB> | oh, *that* ;-) |
| 14:40 | <MikeSmith> | you guys need to step up your game |
| 14:41 | <MikeSmith> | we need to have higher expectations for IETF trolling than what I'm seeing on display here today |
| 14:41 | <SamB> | I was thinking about the "realistic requirement keywords" RFC ;-) |
| 14:41 | <SamB> | that was a masterwork of sad, true, and funny all at once ... |
| 14:45 | <annevk> | I missed http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0123.html |
| 14:45 | <annevk> | Of course it is directly casually dismissed afterwards |
| 15:06 | <annevk> | SamB: https://twitter.com/stpeter/status/484352051645009922 |
| 16:37 | <annevk> | http://w3cmemes.tumblr.com/post/90566879702 <3 |
| 16:38 | <Domenic> | oooh w3cmemes stepped up its game |
| 16:38 | <Domenic> | i liked http://w3cmemes.tumblr.com/image/90566406597 |
| 16:49 | <hober> | that's not the first time slightlyoff's been represented by a dog |
| 16:49 | <hober> | i wonder what's up with that |
| 17:20 | <IZh> | Hi. Is it possible to select multiple Options from JS? |
| 17:20 | <IZh> | The select.value selects one. |
| 17:25 | <TabAtkins> | IZh: If you ahve a <select multiple>, then you can adjust selectedness on each option individually. |
| 17:25 | <TabAtkins> | I forget how. |
| 17:25 | <TabAtkins> | Probably opt.selected=true or something. |
| 17:30 | <Hixie> | you know your standards organisation is successful when the mailing list for your flagship spec has less than a third the volume of mail traffic as the mailing list for your process, two months in a row |
| 17:30 | <Hixie> | (http://lists.w3.org/Archives/Public/public-html/ vs http://lists.w3.org/Archives/Public/public-w3process/) |
| 17:31 | <SamB> | Hixie: does the WHATWG even *have* a process? |
| 17:31 | <SamB> | I guess they better have at least PID 1 and apache, huh |
| 17:35 | <tantek> | mailing lists are such good honeypots. especially process mailing lists. |
| 17:35 | <SamB> | you mean, they keep the bullshit away from ... ? |
| 17:40 | <jgraham> | SamB: Don't let tantek troll you. He has like a 4 hour spiel about how all mailing lists are failures, even ones that are successful, and how everything should be on wikis despite wikis having faults of their own. |
| 17:40 | <SamB> | I hear wikimedia-l is ... fun ;-) |
| 17:40 | <Hixie> | i'm not sure, i'm just guessing, but i think jgraham might disagree with tantek on this mailing list thing |
| 17:41 | <SamB> | but personally I don't think a wiki is a good place to review patches |
| 17:41 | <Hixie> | SamB: not in any meaningful sense, no (by design) |
| 17:41 | <jgraham> | A mailing list isn't a good place to review patches either |
| 17:41 | <SamB> | Hixie: lol |
| 17:41 | <jgraham> | a code review system is |
| 17:41 | <SamB> | jgraham: true, not particularly fantastic for that |
| 17:41 | <tantek> | SamB - they keep a lot of bullshit (in terms of volume of text) away from say, IRC, like here. |
| 17:41 | <SamB> | jgraham: but a wiki manages to do EVEN WORSE |
| 17:41 | <tantek> | jgraham, that's the spirit! ;) |
| 17:42 | <SamB> | and I'm not sure you couldn't integrate a code review system into a mailing-list workflow pretty well ... |
| 17:42 | <tantek> | SamB - who does code reviews on a wiki? I've never done that but I'm curious to see anyone who would try! |
| 17:43 | <SamB> | tantek: well, the way I was interpreting jgraham's statements, you were ;-P |
| 17:43 | <tantek> | github's UI flow for code submissions/reviews appears to have the best adoption to date of any such "system". so I'd start by studying theirs. |
| 17:43 | <jgraham> | At least code review on a wiki would give you some kind of diff between revisions of the patch |
| 17:43 | <SamB> | jgraham: hmm |
| 17:43 | <tantek> | (!!!) |
| 17:43 | <jgraham> | Oh man *I* have a four your rant about the failures of github for code review and patch submission |
| 17:43 | <jgraham> | *hour |
| 17:44 | <SamB> | jgraham: I was thinking of a Talk:-style thing though, which really wouldn't |
| 17:44 | tantek | looks forwared to reading jgraham's blog post about the failures of github for code review and patch submission. |
| 17:44 | <jgraham> | SamB: Yeah, the fact that you would have to mix comments and code would be a disaster |
| 17:44 | <tantek> | SamB, Talk: pages suck. Don't use them |
| 17:44 | rniwa | prefers Bugzilla code reviews over Github. |
| 17:45 | <SamB> | tantek: well, how would YOU discuss a Template on-wiki |
| 17:45 | <jgraham> | To be fair, the main problem with GH for submission is that their permissions model is broken so only the original author can update a patch |
| 17:45 | <SamB> | or, say, the content or formatting of a wikipedia article |
| 17:45 | <jgraham> | s/patch/PR/ |
| 17:45 | <SamB> | jgraham: mmm |
| 17:46 | <SamB> | jgraham: well, given that only the latest version of the PR is accessible from the CLI (afaik), I'm not sure that's totally stupid |
| 17:46 | <jgraham> | rniwa: Does webkit have some much better thing than mozilla for review in bugzilla? Because what we have is awful. |
| 17:46 | <SamB> | I guess it should be possible to have multiple PRs on one PR page ... |
| 17:46 | <tantek> | SamB - IRC for quick discussions |
| 17:46 | <SamB> | jgraham: I don't think so |
| 17:47 | <jgraham> | SamB: I don't understand what you mean. A PR is just a branch. It should be possible for multiple people to push to the same branch. |
| 17:47 | <SamB> | tantek: not always clear where to find anyone relevant to a specific topic on IRC, at least wrt WMF's wikis |
| 17:48 | <jgraham> | People certainly *shouldn't* keep squashing and force pushing if that's what you mean by "latest version" |
| 17:48 | <SamB> | it's not too bad wrt commons or enwikisource |
| 17:48 | <jgraham> | Once you do that you may as well use a mailing list again. |
| 17:48 | <SamB> | jgraham: I was just thinking that remote reflog access might be worth implementing |
| 17:49 | <SamB> | but yes, I see what you mean |
| 17:49 | <SamB> | forbidding force push to PR refs would work too, after a fashion |
| 17:50 | <caitp> | squashing and forcepushing is great, it's not like the old refs disappear |
| 17:50 | <SamB> | anyway, clearly we have very little clue what we're doing WRT patch review systems |
| 17:50 | <SamB> | caitp: huh? |
| 17:50 | <SamB> | are you talking about the web UI? |
| 17:50 | <caitp> | no |
| 17:50 | <jgraham> | You need to allow it but you either need the kind of magic that hg+changeset evolution has to keep track of the previous commits, or you need to strictly control when people squash so that the review system can keep track of it |
| 17:51 | <SamB> | caitp: or do you know how to get at the old PR tips from the CLI? |
| 17:51 | <SamB> | I haven't done much hg yet |
| 17:51 | <SamB> | at least it doesn't seem as stupid slow as bzr |
| 17:51 | <caitp> | if you have the sha of an old tip you should be able to cherrypick it back on if you want to restore it |
| 17:51 | <SamB> | and isn't dead upstream like bzr |
| 17:51 | <caitp> | getting the sha is the hard part |
| 17:52 | <SamB> | caitp: github allows you to do that? |
| 17:52 | <SamB> | but how would you find out the sha without hitting the web |
| 17:52 | <caitp> | i'm not sure why github would care |
| 17:52 | <jgraham> | I haven't actually used hg+evolve, but aiui when you rebase it stores a pointer to the old commits in the rebased tree, but marks them as "obsolete" or something |
| 17:52 | <caitp> | you can just make a note of shas, or put them in a temporary branch before rebasing |
| 17:53 | <SamB> | caitp: by default, git forbids access to commits that aren't found in refs |
| 17:53 | <caitp> | temp branch is safer :p |
| 17:53 | <SamB> | I mean, when you use the smart protocols |
| 17:53 | <SamB> | jgraham: nice |
| 17:53 | <rniwa> | jgraham: https://bugs.webkit.org/attachment.cgi?id=224930&action=review |
| 17:53 | <rniwa> | jgraham: ojan made a lot of improvements to our review tool |
| 17:53 | <rniwa> | jgraham: it supports inline comments, etc... |
| 17:54 | <jgraham> | rniwa: Well it allows context expansion at least. Can you get diffs between different versions of patches or track which issues have been addressed somehow? |
| 17:55 | <rniwa> | jgraham: diffs between different patches is still broken :( |
| 17:56 | <jgraham> | Moilla are supposed to be moving to reviewboard, but it remains to be seen whether that still sucks |
| 17:56 | <Philip`> | jgraham: Gerrit seems to work non-terribly at that - it stores every version of a patch that you've pushed for review, and the web UI lets you see diffs between any versions |
| 17:57 | <SamB> | Philip`: what happens if you change the subject line? |
| 17:57 | <jgraham> | Philip`: Yeah, AIUI Gerrit isn't terrible. Although I haven't actually used it so I couldn't say if it's good or not |
| 17:57 | <SamB> | and I hear gerrit doesn't handle series' well? |
| 17:58 | jgraham | is quite a fan of Opera Critic ofc |
| 17:58 | <Philip`> | SamB: There's a hook that puts a Change-Id field in your commit message, as a unique identifier for a patch |
| 17:58 | <rniwa> | Philip`, jgraham: the one used by chromium is horrible re: Gerrit |
| 17:58 | <jgraham> | Reitvald? |
| 17:58 | <Philip`> | so you can happily rewrite the commit message (but keep the Change-Id) and it'll recognise it |
| 17:59 | <SamB> | I think the cutest review tool I've seen involved GPG-signed votes of approval on a mailing list, and a bot that ran tests and merged if all was well after recieving enough "go ahead" votes |
| 17:59 | <rniwa> | jgraham: oh i guess I mixed the two |
| 17:59 | <SamB> | Philip`: how does the Change-Id get into your commit message? |
| 17:59 | <jgraham> | Isn't Gerrit a fork of Rietvald or something? |
| 17:59 | <caitp> | rietveld isn't really ideal, no :[ |
| 18:00 | <SamB> | is it telling that I've never heard of rietvald before? |
| 18:00 | <SamB> | probably not very |
| 18:00 | <caitp> | codereview.chromium.org etc, the UI still confuses me after over a year |
| 18:00 | <jgraham> | Well code review tools aren't exactly thrilling dinner party conversation |
| 18:01 | <jgraham> | It isn't the sort of thing they teach posh people to politely discuss at finishing school |
| 18:01 | <SamB> | what is finishing school? |
| 18:01 | <Philip`> | SamB: By a commit-msg hook that you have to download into your repository |
| 18:01 | <SamB> | do they teach you to finish things? |
| 18:01 | <SamB> | maybe I should sign up |
| 18:01 | <SamB> | Philip`: ah |
| 18:01 | <jgraham> | http://en.wikipedia.org/wiki/Finishing_school |
| 18:02 | <SamB> | Philip`: that actually sounds workable |
| 18:02 | <Philip`> | The best thing about Gerrit is that part of its configuration is in Prolog |
| 18:02 | <SamB> | but somehow I suspect it hasn't a clue how to handle it if you squash or split a change |
| 18:03 | <SamB> | er, well, not that you can squash one change by itself |
| 18:03 | <jgraham> | Philip`: See, that's what the channel lacks when you aren't around |
| 18:04 | <SamB> | Philip`: I'm assuming that it's not actually particularly useful that it's in prolog? |
| 18:04 | <SamB> | or you would be explaining how |
| 18:04 | <SamB> | hmm, did firefox drop SWI yet? |
| 18:04 | <SamB> | (how long ago?) |
| 18:04 | <jgraham> | What's SWI? |
| 18:04 | <Philip`> | SamB: It's your responsibility to keep the Change-Id in the appropriate commit that you want associated with your previous review, if you're doing some squashing etc |
| 18:04 | <SamB> | SWI Prolog |
| 18:05 | <Philip`> | If you're doing major reorganisation you might want to just abandon the old reviews and start a new set for your new patches, to reduce confusion |
| 18:06 | <SamB> | Philip`: is "review/change set" an actual concept of gerrit? |
| 18:06 | <Philip`> | SamB: It's not particularly useful if you don't already know Prolog |
| 18:06 | <SamB> | what sort of things does it configure? |
| 18:07 | <Hixie> | anyone want to help out with admin⊙wwo requests? (it's just creating wiki accounts for people who seem legit) |
| 18:09 | <Philip`> | SamB: The rules for when a patch is allowed to be submitted, e.g. https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html#_example_14_master_and_apprentice |
| 18:10 | <SamB> | Hixie: so basically you get to serve as glorified captcha? |
| 18:10 | <SamB> | anyway I'm terrible at handling my mail already, so not I! |
| 18:13 | <Ms2ger> | jgraham, Rietveld, btw |
| 18:14 | <jgraham> | Danm vowels |
| 18:16 | <Philip`> | They're evidently no worse than the consonants |
| 18:16 | <jgraham> | Cursed letters |
| 18:17 | <Domenic> | I hate Gerrit, largely because of the Change-Ids |
| 18:21 | <Hixie> | SamB: yeah |
| 18:25 | <Manishearth> | annevk: around? |
| 18:25 | <Manishearth> | I'd like to know exactly when CORS applies |
| 18:25 | <jgraham> | Manishearth: I don't think he is |
| 18:25 | <Manishearth> | :/ |
| 18:26 | <Manishearth> | apparently fetching an ftp:// page from an http:// page is a CORS violation. Wonder if the same is true for fetching ftp:// from ftp:// |
| 18:26 | <Hixie> | annevk: i'm not clear on what i'm supposed to be answering on https://github.com/slightlyoff/ServiceWorker/issues/352#issuecomment-47768718 |
| 18:28 | <SamB> | Manishearth: I'm not aware of a way to clear cross-origin requests with an FTPD |
| 18:28 | <SamB> | so, um, naturally you can't use CORS with ftp:// |
| 18:29 | <SamB> | I guess it's pointless to ask about nntp://, news://, etc. since, uh, well, browsers don't exactly support NNTP these days |
| 18:29 | <Manishearth> | SamB: strange, I tried ftp-ftp in Chrome's console and it worked |
| 18:30 | <Manishearth> | data-data doesn't work though |
| 18:30 | <SamB> | hmm |
| 18:30 | <SamB> | wait what |
| 18:30 | <SamB> | Manishearth: what exactly are you attempting to do? |
| 18:30 | <Manishearth> | and I think blob uris can be fetched ;p |
| 18:30 | <Manishearth> | SamB: implement CORS for Servo |
| 18:30 | <SamB> | I meant, what did you try between data: and data: that did not work? |
| 18:30 | <Manishearth> | or, more generically, implemet CORS in rst -- trying to make it reusable |
| 18:31 | <Manishearth> | *Rust |
| 18:32 | <Manishearth> | SamB: so data:text/html is a thing |
| 18:32 | <SamB> | hmm, I guess ftp has to count as cross-origin; someone's bound to have internal ftp servers with sensitive data on them ... |
| 18:33 | <SamB> | Manishearth: it just seems kind of dumb to prevent fetching a data URL when you could just as well get the content by parsing it yourself |
| 18:35 | <Manishearth> | SamB: exactly |
| 18:35 | <Manishearth> | So I was wondering if there was a table of sorts which specifies who can fetch ffrom where |
| 18:36 | <Manishearth> | this data uri doesn't work, for example: |
| 18:36 | <Manishearth> | data:text/html;charset=utf-8;base64,PGh0bWw+DQo8aGVhZD48L2hlYWQ+DQoNCjxib2R5Pg0KPHNjcmlwdD4NCnhocj1uZXcgWE1MSHR0cFJlcXVlc3QoKTsNCnhoci5vcGVuKCJHRVQiLCAiZGF0YTp0ZXh0L2h0bWw7Y2hhcnNldD11dGYtODtiYXNlNjQsUEdoMGJXdytEUW9OQ2p3dmFIUnRiRDQ9IikNCnhoci5zZW5kKCk7DQo8L3NjcmlwdD4NCjwvYm9keT4NCjwvaHRtbD4= |
| 18:36 | <SamB> | does curl implement data: ... |
| 18:36 | SamB | checks |
| 18:36 | <Manishearth> | hm |
| 18:36 | <Manishearth> | Note that here I'm talking about same-origin, but different *schemes* |
| 18:37 | <SamB> | Manishearth: ah |
| 18:38 | <SamB> | turns out curl doesn't support the data scheme |
| 18:38 | <Manishearth> | though it would also be interesting if ftp:// fetching http:// cross origin is considered unsupported |
| 18:39 | <SamB> | Manishearth: can't see any reason it shouldn't work besides lack of enthusiasm to bother |
| 18:39 | <Manishearth> | (even if the correct access-control headers are set) |
| 18:39 | <Manishearth> | true, bt it's all confusing ;) |
| 18:40 | <SamB> | annevk: perhaps there should be some kind of ... testsuite? |
| 18:40 | <Manishearth> | SamB: don't we have wpt? :) |
| 18:40 | <Manishearth> | but it doesnt cover thee strange cases |
| 18:40 | <SamB> | how would you test this stuff anyway |
| 18:41 | <Ms2ger> | Make jgraham write an ftp server |
| 18:41 | <SamB> | I mean, I'm thinking live testing is probably not workable here |
| 18:41 | <SamB> | but dry-running part of the algorithm maybe could be? |
| 18:41 | jgraham | hides |
| 18:42 | <Manishearth> | SamB: I'm creating data uris and using ftp servers and all ;p |
| 18:42 | <SamB> | hrmm, maybe it's not THAT hard |
| 18:43 | <SamB> | (does, say, twisted have an ftp server?) |
| 18:44 | <SamB> | Manishearth: what kind of harness are you using, and how much of the stack does it test? |
| 18:45 | <Manishearth> | SamB: me? I'm currently just testing locally |
| 18:45 | <Manishearth> | as in, entering stuff into the console |
| 18:45 | <SamB> | ah |
| 18:45 | <Manishearth> | we use wpt though |
| 18:45 | <SamB> | I'm not sure how you can do tests with different toplevel origins though |
| 18:45 | <Ms2ger> | Manishearth, you should move the dirs we run into an ini file, I want to start running FileAPI/ at some point |
| 18:46 | <SamB> | I mean, automatically |
| 18:46 | <SamB> | (I mean, this is the one time you would really want to be able to be able to totally ignore the same-origin rule, no?) |
| 18:47 | <Manishearth> | SamB: Okay, turns out that Blick doesn't like xhr in data uris, bt Gecko does |
| 18:47 | <Manishearth> | this is unspecced |
| 18:47 | <Manishearth> | implement at will ;p |
| 18:47 | <SamB> | gecko is right, clearly |
| 18:47 | <Manishearth> | Ms2ger: yeah, we shold. Will do that |
| 18:47 | <Manishearth> | *should |
| 18:47 | <Ms2ger> | Thanks :) |
| 18:47 | <SamB> | though, failing safe is better than failing dangerous |
| 18:50 | <Manishearth> | // This bit is probably more complicated. Fetching same origin data URIs from data URIs |
| 18:50 | <Manishearth> | // works in Gecko but not Blink. Fetching same origin ftp:// from ftp:// works in both |
| 18:50 | <Manishearth> | // Same origin blob URIs also work for both. Fetching same origin http from ftp works in gecko |
| 18:50 | <Manishearth> | // but not Blink. I give up. |
| 18:50 | <Manishearth> | screw it, I'll just leave a long comment ;p |
| 19:46 | <Hixie> | jgraham: any news on the attribute ordering thing? |
| 19:57 | <annevk> | Manishearth: see http://fetch.spec.whatwg.org/#concept-fetch |
| 19:58 | <annevk> | Manishearth: if you want to implement CORS, "just" implement Fetch |
| 19:59 | <annevk> | Hixie: just a heads up that your algorithms might be affected somehow by all this CSP / Fetch stuff; if you're not concerned, it's fine |
| 19:59 | <annevk> | SamB: testsuite for what? |
| 20:00 | <Hixie> | annevk: which algs? |
| 20:00 | <annevk> | Manishearth: implementing CORS without Fetch would be wrong |
| 20:00 | <annevk> | Hixie: navigate and things that invoke navigate |
| 20:00 | <Hixie> | ah |
| 20:00 | <SamB> | annevk: what should happen if URL foo tries to do X involving URL bar |
| 20:00 | <Hixie> | i kinda assumed they'd be affected eventually anyway |
| 20:01 | <SamB> | perhaps with more details about what bar's server has to say about that |
| 20:01 | <annevk> | The address bar is UI |
| 20:02 | <SamB> | annevk: sorry, "bar" was a poor choice of metasyntactic variable |
| 20:02 | <SamB> | s/bar/baz/ |
| 20:02 | <annevk> | SamB: oh, yes |
| 20:03 | <annevk> | SamB: there's some of that for XMLHttpRequest |
| 20:03 | <annevk> | SamB: are you volunteering? if so, I'll have more time to coordinate something like that in twelve hours, or you can talk to jgraham :-) |
| 20:04 | gsnedders | wonders if we should be writing more specs without testsuites, given how badly tested stuff is already... |
| 20:04 | <SamB> | annevk: hmm, I'll volunteer Manishearth to come up with the wierd corner cases to try |
| 20:05 | <annevk> | gsnedders: well, everything that is implemented gets tests, so there's tests for those specifications somewhere |
| 20:05 | <gsnedders> | somewhere doesn't necessarily mean reusable outside of that implementation, which is kinda harmful |
| 20:07 | <SamB> | annevk: note that when I said "testsuite", I didn't *necessarily* mean that they would have to be ready for any sort of automated use |
| 20:07 | <gsnedders> | manual tests are pretty useless though, nobody ever runs them |
| 20:08 | <SamB> | a table of examples with an indication of what the results should be would be better than what we have now |
| 20:10 | <SamB> | gsnedders: I mean, yes, ideally you'd have some kind of automatable tests, but it seems like the same-origin restriction would make it distinctly tricky to set up windows with all the wierd origins you'd need here |
| 20:12 | <SamB> | if you wanted a cross-browser harness, I mean |
| 20:12 | <gsnedders> | not really |
| 20:12 | <gsnedders> | the big problem is dealing with browsers that, e.g., don't support FTP |
| 20:12 | gsnedders | wonders if Fetch actually requires FTP support |
| 20:12 | <gsnedders> | it looks like it? |
| 20:12 | <SamB> | skip tests that involve ftp://, I assume! |
| 20:13 | <gsnedders> | it's detecting that FTP isn't supported that's hard :) |
| 20:13 | <SamB> | just like nobody is going to make gopher:// tests |
| 20:14 | <SamB> | is it? |
| 20:14 | <SamB> | gsnedders: couldn't you just load a script or an img over ftp:// ? |
| 20:14 | <gsnedders> | can you distinguish the different failure states? |
| 20:14 | <gsnedders> | (does anyone still support gopher? was IE not the last, and they dropped it several releases back) |
| 20:14 | <SamB> | or maybe you could just let the user tell you |
| 20:15 | <SamB> | gsnedders: yes, that's why nobody will write tests; the features involved don't all occur in the same browser |
| 20:15 | <SamB> | I mean, no, nobody still supports gopher |
| 20:16 | <SamB> | except if they don't support JS in the first place, in which case CORS doesn't seem likely to apply to much |
| 20:17 | <gsnedders> | IE7 IIRC supported Gopher and is still supported, no? ;P |
| 20:17 | <gsnedders> | Or maybe it was IE7 that dropped it? |
| 20:17 | <SamB> | oh, I have no idea |
| 20:18 | <SamB> | for all I know, it was dropped in a patch distributed over Windows Update |
| 20:23 | <gsnedders> | There are definitely browsers that support JS and gopher though, which is my point. Probably not worthwhile testing, though. :) |
| 20:25 | <SamB> | gsnedders: I don't think IE7 counts as "maintained" for the purposes of Fetch |
| 20:27 | <gsnedders> | SamB: As I said, "not worthwhile testing" |
| 20:27 | <SamB> | yeah |
| 20:28 | <SamB> | on the plus side, the likelyhood of anyone having any private information stored on a local gopher server approaches nil |
| 20:30 | <jgraham> | Hixie: No. I will have another look this evening. |
| 20:35 | <Hixie> | jgraham: cool, thanks |
| 20:35 | <Hixie> | jgraham: sorry for giving you work |
| 20:37 | <annevk> | gsnedders: yeah, you need all three |
| 21:58 | <mounir_> | Domenic, abarth: my understanding that you guys are still holding the position you had when the discussion started, is that right? |
| 21:59 | <abarth> | mounir_: I haven't changed my opinon |
| 22:02 | <mounir_> | it seems that you guys are the only persons who really care, it would be great if you could find some agreement... |
| 22:03 | <abarth> | mounir_: why don't we continue with the implementation |
| 22:05 | <mounir_> | eh... that's the problem |
| 22:05 | <abarth> | why is that a problem? |
| 22:05 | <mounir_> | if I land a patch going one way, let's be honest, I'm not going to write a spec going the other way |
| 22:05 | <abarth> | great |
| 22:05 | <abarth> | problem solved |
| 22:07 | <mounir_> | I wouldn't say that |
| 22:08 | <abarth> | what I'd probably do in your place is open an issue in the working groups tracker and move forward |
| 22:08 | <abarth> | eventually you'll need to resolve the issues in the tracker before advancing the spec to CR |
| 22:08 | <Ms2ger> | Meh, w3process |
| 22:08 | <abarth> | if you wait for everyone to agree before writing each line of code, you'll wait for a long time |
| 22:09 | <Hixie> | just ask whoever the spec editor is to make a decision |
| 22:09 | <Ms2ger> | Well, that's mounir_ |
| 22:09 | <Hixie> | hawkward |
| 22:09 | <Hixie> | ask another vendor to make a decision, and do whatever they say? |
| 22:09 | <jgraham> | Hixie: &alphabetical_attributes=on |
| 22:10 | <Hixie> | sweet |
| 22:10 | <jgraham> | Hixie: Seems past me had a very strange idea about what "defaults" meant |
| 22:10 | <Hixie> | heh |
| 22:10 | <Hixie> | i know that feeling |
| 22:10 | <jgraham> | In this case they seemed to mean "defaults, but only if a parameter value was actually supplied, which for booleans could only be true anyway" |
| 22:13 | <jgraham> | mounir_: Toss a coin, and if that doesn't help, toss a salad? At least that way you'll have some delicious salad (assuming you put delicious things in your salad. If you mainly put in iceberg lettuce you will have a soggy disappointment go go with your spec woes) |
| 22:14 | <mounir_> | abarth: what bothers me is that given that the Blink implementation will be blocked to a specific solution, I can't realisticly spec something different |
| 22:14 | <mounir_> | I would need to be slightly crazy to implement something and spec something else |
| 22:14 | <Hixie> | are there other implementations? |
| 22:14 | <abarth> | mounir_: sure, but you can log an issue and change both the spec and the implementation when the issue is resolved |
| 22:15 | <mounir_> | abarth: except that the issue will unlikely be resolved in another way than what you want to be implemented |
| 22:15 | <mounir_> | abarth: given that Blink will anyway not implement it the other way, right? |
| 22:15 | jgraham | doesn't know what the actual issue is |
| 22:15 | Hixie | either |
| 22:15 | <abarth> | mounir_: you're just making assumptions |
| 22:15 | <abarth> | mounir_: why do you assume that? |
| 22:16 | <mounir_> | abarth: there are two patches up there, one is blocked, the other one is ready to land |
| 22:16 | <abarth> | right |
| 22:16 | <abarth> | so land the CL that's ready to land |
| 22:16 | <abarth> | that doesn't foreclose changing the implementation later |
| 22:17 | Ms2ger | isn't sure of that in general |
| 22:17 | <abarth> | Ms2ger: this whole feature is experimental, which means we aren't shipping it |
| 22:17 | <Ms2ger> | Good good |
| 22:18 | <mounir_> | abarth: will do that |
| 22:18 | <caitp> | which feature? // curiousity |
| 22:18 | <abarth> | ScreenOrientation |
| 22:18 | <mounir_> | abarth: but I would be surprise that it doesn't ship for M38 |
| 22:18 | <caitp> | ah |
| 22:18 | <abarth> | mounir_: well, they'll be an intent-to-ship email |
| 22:18 | <abarth> | that folks are welcome to raise concerns in |
| 22:19 | <abarth> | presumably you're going to write that email. If you don't think the spec is mature enough, then we're not very likely to ship the feature |
| 22:19 | <abarth> | shipping is the gate that locks things in. implementation behind a flag doesn't |
| 22:24 | <Hixie> | jgraham: fwiw, getting 504s. i'll keep trying, it's probably intermittent. |
| 22:26 | <jgraham> | Hixie: OK, it worked for me |
| 22:26 | <Hixie> | it worked the third time |
| 22:26 | <Hixie> | looks perfect, attributes in order and everything |
| 22:26 | <Hixie> | thanks! |
| 22:35 | <Hixie> | jgraham: is there a flag for not omitting end tags, by any chance? |
| 22:38 | <jgraham> | Er, it omits end tags? |
| 22:40 | <jgraham> | Oh right maybe if you are passing omit_optional_tags |
| 22:41 | <jgraham> | So just removing that might help |
| 22:42 | <MikeSmith> | Hixie: a while back bz pointed out that the Navigation Timing spec is using the term "current document" and "previous document" but never defines them |
| 22:42 | <MikeSmith> | Hixie: e.g., https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#dom-performancetiming-navigationstart |
| 22:42 | <Hixie> | jgraham: ah, excellent |
| 22:42 | <MikeSmith> | Hixie: "This attribute must return the time immediately after the user agent finishes prompting to unload the previous document. If there is no previous document, this attribute must return the time the current document is created." |
| 22:42 | <Hixie> | MikeSmith: those terms would be easy to define |
| 22:42 | <Hixie> | MikeSmith: given the session history |
| 22:43 | <MikeSmith> | yeah? |
| 22:43 | <Hixie> | yeah |
| 22:43 | <Hixie> | current document is just "active document" |
| 22:43 | <MikeSmith> | can't they just use terminology that's all ready in the HTML spec? just reference terms |
| 22:43 | <MikeSmith> | ah |
| 22:43 | <MikeSmith> | yeah |
| 22:44 | <Hixie> | and "previous document" is something like "document for the entry before the first entry of the active document" or something |
| 22:44 | <MikeSmith> | OK that's what I thought for current document |
| 22:44 | <MikeSmith> | ok |
| 22:44 | <Hixie> | though exactly what they want depends on how they want to handle things like bfcache, bfcache eviction, fragmetn navigations, pushState, etc. |
| 22:45 | <Hixie> | not to mention history traversal |
| 22:45 | <MikeSmith> | well |
| 22:45 | <MikeSmith> | I think the spec doesn't go into details in those areas that maybe it should |
| 22:45 | <MikeSmith> | but I dunno I haven't looked too deeply and kinda don't want to |
| 22:46 | <MikeSmith> | I'm glad at least that bz has been taking the time |