| 00:10 | <Domenic> | Wheee OK nobody needs to install FreePascal anymore https://github.com/domenic/wattsi-server |
| 00:10 | <Domenic> | (Although I'm pretty sure as of this morning everyone already did, lol.) |
| 00:28 | MikeSmith | looks |
| 00:29 | <MikeSmith> | wow |
| 00:29 | <MikeSmith> | nice |
| 00:29 | <MikeSmith> | Domenic: you gonna work on a patch to make the build use this, or do you want me to? |
| 00:30 | <Domenic> | MikeSmith: already done :) https://github.com/whatwg/html-build/pull/10 |
| 00:30 | <MikeSmith> | dang |
| 00:30 | <Domenic> | MikeSmith: but error handling is annoying... https://superuser.com/questions/965558/get-curl-to-output-non-2xx-to-stderr-but-2xxs-to-a-file |
| 00:30 | MikeSmith | looks |
| 00:30 | <Domenic> | MikeSmith: still counting on you for the separate-directories patch though! |
| 00:31 | <MikeSmith> | OK yeah will do that |
| 00:32 | <MikeSmith> | Domenic: about that superuser question, we should talk to Daniel |
| 00:32 | <MikeSmith> | about curl |
| 00:32 | <MikeSmith> | he works a Mozilla now, right? |
| 00:32 | <MikeSmith> | Daniel Stenberg |
| 00:37 | <Domenic> | Yeah people on Twitter are referring me to him |
| 00:38 | <Domenic> | I feel kind of bad bugging the creator of a program on usage info though, especially for something that popular |
| 00:43 | <MikeSmith> | dunno, he seems to be pretty enthusiastic about helping people solve problems |
| 00:44 | <MikeSmith> | and if it were any easy problem you'd already have an answer |
| 00:46 | <Domenic> | well a couple people pinged him so we'll see what happens |
| 01:15 | <MikeSmith> | ok |
| 02:18 | <Domenic> | I think @WHATWG should retweet https://twitter.com/mnot/status/638532265388019712 |
| 02:19 | <Domenic> | Also MikeSmith I am 90% sure https://twitter.com/domenic/status/638531133274132481 will work, woo. |
| 02:22 | <MikeSmith> | Domenic: awesome |
| 02:25 | <MikeSmith> | Domenic: heh, that mnot tweet is nice too |
| 02:25 | <MikeSmith> | mnot, you have been assimilated |
| 04:07 | <SimonSapin> | hsivonen: http://w3techs.com/technologies/details/en-utf16/all/all sees less than 0.007% of websites using UTF-16. Do we have telemetry on this? Do we have a threshold for dropping support of things? |
| 04:08 | <annevk> | Domenic: retweeted |
| 04:36 | <Domenic> | There is still a lot of low-hanging fruit |
| 04:40 | <annevk> | Yeah, I was going to fix base URLs but that's harder than expected |
| 04:52 | <Domenic> | here is one minor tweak we made, https://github.com/tmpvar/jsdom/blob/master/lib/jsdom/living/helpers/document-base-url.js especially https://github.com/tmpvar/jsdom/blob/master/lib/jsdom/living/helpers/document-base-url.js#L34 |
| 05:35 | <Sebmaster> | annevk: i think i have another issue with the url spec :/ |
| 05:35 | <Sebmaster> | you have a minute? |
| 06:00 | <annevk> | Sebmaster: sure |
| 06:01 | <Sebmaster> | Awesome! |
| 06:02 | <Sebmaster> | Okay so, assume we have an object with mixed in urlutils. it calls set the input with some string as input, let's go with "example" |
| 06:03 | <annevk> | Sebmaster: hmm so URLUtils has open issues |
| 06:03 | <annevk> | but okay |
| 06:03 | <Sebmaster> | So set the input parses the stuff, calls get the base etc. and comes up with some resulting url: http://example.org/example |
| 06:04 | <Sebmaster> | so we have an object, its input is set to example, and its url is set to http://example.org/example |
| 06:05 | <annevk> | Sebmaster: yes |
| 06:05 | <Sebmaster> | we now call the hash attribute setter with a string "foobar", it does the whole parsing spiel again, we get a resulting object: input is "example", url is "http://example.org/example#foobar"; |
| 06:07 | <Sebmaster> | when we now call the href attribute getter, it calls reset the input, which in turn calls set the input with "example" and "http://example.org/example#foobar"; |
| 06:07 | <Sebmaster> | set the input then sets input and url, but since input is non-null, it then re-parses the url with input, resulting in #foobar being dropped |
| 06:10 | <Sebmaster> | and i really, really hope i didn't miss any part of the spec again :S |
| 06:13 | <annevk> | Sebmaster: no you didn't |
| 06:13 | <annevk> | Sebmaster: the problem is that once you set the hash attribute the input also needs to be updated |
| 06:14 | <annevk> | Sebmaster: I fixed URLUtils the wrong way and I haven't really worked on specifying it in the right way yet since I didn't have access to update HTML directly, where we should probably put some of the logic |
| 06:14 | <Sebmaster> | thank god, i was getting worried i'm constantly misreporting everything |
| 06:14 | <Sebmaster> | well then, I'll wait until you're done with the new changes |
| 06:20 | <annevk> | Sebmaster: https://github.com/whatwg/url/issues/62 and https://github.com/whatwg/url/issues/61 |
| 06:20 | <annevk> | Sebmaster: it's quite the mess :-( |
| 06:25 | <Sebmaster> | Oh right, those tie into the whole thing |
| 06:26 | <Sebmaster> | I assumed the spec would be in a working state without those reworks :( |
| 06:27 | <Sebmaster> | Means I can put it off again though, so that's fine for me for now :D |
| 06:27 | <annevk> | Maybe I should add a note to the API since it'll take me a couple of weeks before I'm going to get to that I think |
| 06:30 | <annevk> | Done |
| 06:47 | <annevk> | MikeSmith: I had it happen again that a link to source became source |
| 06:49 | <annevk> | Locally building is pretty much a must it seems, looking forward to somebody making it faster |
| 07:06 | <MikeSmith> | annevk: is it just the symlink to the `source` file that happens with? or others too? |
| 07:07 | <annevk> | MikeSmith: I haven't tested the others, they're mostly static so it doesn't matter |
| 07:07 | <MikeSmith> | ok |
| 07:09 | <MikeSmith> | well *grumble grumble* we wouldn't have a problem at all with that if we just moved the build tools into the html repo |
| 07:10 | <annevk> | MikeSmith: I think Domenic made some reasonable arguments against that |
| 07:10 | <annevk> | MikeSmith: I think the problem would be gone too if we had an input and output directory |
| 07:11 | <MikeSmith> | ok |
| 07:12 | <MikeSmith> | annevk: remind where we discussed how we wanted that to work? was it on IRC, or is there an open issue that details the proposal/requirement? |
| 07:14 | <mkwst> | MikeSmith: https://github.com/whatwg/html-build/issues/3 |
| 07:14 | <MikeSmith> | ah |
| 07:14 | <MikeSmith> | "Source repository history should not be intermingled with build tool revisions." |
| 07:14 | <MikeSmith> | I guess I actualy agree with that |
| 07:15 | <MikeSmith> | and I'm surprised/disappointed that I didn't think come to that conclusion on my own already |
| 07:15 | <MikeSmith> | I blame lack of sleep |
| 07:17 | <MikeSmith> | mkwst: anyway, thanks for the citation |
| 07:18 | MikeSmith | stares at the dozens of unread github notifications in his inbox |
| 07:18 | <mkwst> | As long as he's doing the work, I don't care. But it seems strange to pretend that these are really separate projects. *shrug* Whatever. I like green bikesheds! :) |
| 07:19 | <zcorpan> | MikeSmith: i checked the "Popular sites using UTF-16" and afaict they're not using utf-16 |
| 07:20 | <zcorpan> | e.g. Epoker.com has Content-Type:·text/html;·charset=utf-8 and then <meta·http-equiv="Content-Type"·content="text/html;·charset=utf-16"> |
| 07:21 | <zcorpan> | so i wouldn't give much weight to that statistic |
| 07:22 | <MikeSmith> | eh? |
| 07:22 | <zcorpan> | hmmm. sorry MikeSmith. i meant SimonSapin ^ |
| 07:22 | <MikeSmith> | ah |
| 07:22 | <MikeSmith> | wake up, SimonSapin! |
| 07:22 | <zcorpan> | hsivonen: ^ |
| 08:08 | <annevk> | mkwst: what is an endpoint origin? |
| 08:09 | <mkwst> | Given: `fetch("https://example.com/endpoint";, { body: fd })`, it would be `example.com`. |
| 08:10 | <mkwst> | Basically, I'd like to be able to lock submissions down to a certain origin. The previous draft did so by overriding `fetch(url)` with `send(url)`, processing the URL there, and then setting a bunch of flags which prevented redirects. |
| 08:11 | <mkwst> | So, my thought at the moment is that I could put some flags on the FormData object which would govern the ways in which Fetch can use it. |
| 08:11 | <annevk> | https://code.google.com/p/chromium/codesearch#chromium/src/net/base/mime_util.cc&rcl=1427945811&l=384 a curious reference to w3schools |
| 08:12 | <mkwst> | annevk: Yeah. No idea. Let's git blame that, shall we? :) |
| 08:12 | <annevk> | also, there used to be a list of JavaScript MIME types there per https://www.w3.org/Bugs/Public/show_bug.cgi?id=28397 but they are now gone |
| 08:12 | <mkwst> | https://codereview.chromium.org/3311016 *shrug* |
| 08:15 | <annevk> | more like *shudder* |
| 08:16 | <mkwst> | https://blink.lc/chromium/tree/components/mime_util/mime_util.cc#n59 |
| 08:16 | <mkwst> | which doesn't seem to match HTML, but also doesn't seem to have generated compatibility issues, since it hasn't changed in a long time, |
| 08:16 | <zcorpan> | Domenic: annevk: so what should i do differently to make PRs automatically close as merged? |
| 08:17 | <annevk> | zcorpan: I think the git push --force to the branch must have failed |
| 08:18 | <zcorpan> | $ git push --force |
| 08:18 | <zcorpan> | Everything up-to-date |
| 08:18 | <zcorpan> | it said |
| 08:23 | <annevk> | zcorpan: did you do git checkout branch-name too? |
| 08:24 | <zcorpan> | annevk: yes |
| 08:24 | <annevk> | and then git push --force and then git checkout master |
| 08:24 | <annevk> | hmm |
| 08:24 | <zcorpan> | yes |
| 08:24 | <annevk> | I haven't tried this new approach myself yet so I'm not a 100% that Domenic gave the correct instructions |
| 08:25 | <annevk> | but when you update the branch that should appear on the GitHub site |
| 08:26 | <zcorpan> | ok. yeah i didn't know what message to expect so i figured "Everything up-to-date" meant things were going a-OK |
| 08:36 | <annevk> | zcorpan: do you want to merge 69 or can I make an attempt? |
| 08:36 | <zcorpan> | annevk: do it |
| 08:38 | <annevk> | zcorpan: so yeah, I've had the same problem as you, I think Domenic's instructions are incomplete |
| 08:39 | <Ms2ger> | You probably want `git push --force origin <branch>` |
| 08:59 | <jgraham> | A more complete syntax is git push [options] <remote> <local_ref>:<remote_branch> |
| 09:00 | <jgraham> | the behaviour of bare git push depends on the defaults which depend on the version of git you are running |
| 09:00 | <jgraham> | (unless you changed them) |
| 09:19 | <annevk> | mkwst: e.g., you already forgot you can iterate FormData, see https://xhr.spec.whatwg.org/#formdata |
| 09:20 | <annevk> | mkwst: but you working through it SGTM |
| 09:20 | <mkwst> | annevk: s/forgot/didn't know/. But it's nice of you to assume competence. |
| 09:20 | <mkwst> | :) |
| 09:30 | <MikeSmith> | :-) >it's nice of you to assume competence |
| 09:32 | <MikeSmith> | one of the things that has always made me feel nice when hsivonen reviews code I write is that he always assumes I must have had a good rational reason for writing something in the way I did (instead of not actually having known the better way until he told me). |
| 09:50 | <beverloo> | MikeSmith, annevk: window.focus() works on Chrome as well. Thanks :) |
| 09:58 | <annevk> | MikeSmith: seems more folks are confused by the caniuse.com panel: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28709 |
| 09:58 | <annevk> | MikeSmith: I wonder if we can adjust the stylesheet or closing mechanism somewhat to make it easier |
| 09:59 | <annevk> | MikeSmith: another thing that happens to me in Firefox is that once the scrollbar appears it goes right over the thing that allows you to close the widget, making it particularly hard to close |
| 10:05 | <annevk> | Okay, changing that requires changing Wattsi |
| 10:27 | <mkwst> | annevk: Should `toX` methods return a `Promise<X>` or `X`? It seems like some APIs do the one and some the other. |
| 10:28 | <annevk> | mkwst: depends on whether IO is involved I guess |
| 10:28 | <mkwst> | Hrm. Ok. |
| 10:28 | <mkwst> | I guess it's safer, but more cumbersome, to return a Promise. |
| 10:29 | <mkwst> | safer == future proof. |
| 10:29 | <annevk> | mkwst: if this is for FormData synchronous is fine |
| 10:29 | <mkwst> | it is. |
| 10:29 | <mkwst> | ok. that's simpler then. |
| 10:30 | <annevk> | I wonder if I can get the HTML bug count to be <300 by the end of the week |
| 10:30 | <mkwst> | That's easy. WONTFIX, WONTFIX, WONTFIX. |
| 10:33 | <darobin> | nah, with WONTFIX it is considered etiquette to at least explain why; which takes time |
| 10:33 | <darobin> | INVALID, INVALID, INVALID is much more efficient |
| 10:33 | <mkwst> | :) |
| 10:35 | <annevk> | That is how we got from ~500 to <400 |
| 10:35 | <annevk> | It's a bit trickier now |
| 10:35 | <annevk> | As in, it involves work |
| 11:09 | <darobin> | MikeSmith: if you're around, can you please give me push access to w3c/gh-backup? |
| 11:10 | <MikeSmith> | yep |
| 11:10 | <MikeSmith> | gimme a minute, on from my mobile |
| 11:14 | <MikeSmith> | darobin: should be good to go now |
| 11:42 | <annevk> | mkwst: it seems like you can provide a PR for https://www.w3.org/Bugs/Public/show_bug.cgi?id=27852 right? It didn't break the web... |
| 11:43 | <mkwst> | I was looking at that yesterday. It's not clear to me where the sniffing is actually done in HTML. |
| 11:43 | <mkwst> | If you point me to the right spot, I'm happy to submit a PR. |
| 11:45 | <Ms2ger> | Somewhere around https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script ? |
| 11:46 | <annevk> | mkwst: <script> doesn't do any sniffing |
| 11:46 | <annevk> | mkwst: it just takes the response and executes it |
| 11:46 | <Ms2ger> | And things like importScripts? |
| 11:46 | <annevk> | mkwst: what you want is to prevent that |
| 11:47 | <annevk> | Ms2ger: it seems importScripts() also does some non-2xx check |
| 11:50 | <annevk> | mkwst: I guess it needs to be somewhere in https://html.spec.whatwg.org/multipage/scripting.html#execute-the-script-block but Ms2ger is correct that'd we also want to affect importScripts() and new Worker/new SharedWorker |
| 11:51 | <annevk> | So I guess a fix is not very straightforward |
| 11:51 | <Ms2ger> | I guess we'd need to start by factoring out "fetch a script source" or something |
| 11:51 | <annevk> | mkwst: doing it in Fetch might actually be easier, but I'm not sure if that's a good idea |
| 11:52 | <annevk> | Ms2ger: yeah, that kind of refactoring before doing the greater Fetch refactoring might be a good idea |
| 11:52 | <annevk> | I haven't really figured out how to best tackle Fetch refactoring yet |
| 11:52 | <annevk> | requires so many changes |
| 11:57 | <Ms2ger> | Yeah :/ |
| 11:57 | <mkwst> | Well, I'm happy to give you a PR. I'm even happier to wait until you've done a lot of work to make my PR easy. :) |
| 11:57 | <mkwst> | doing it in Fetch seems simple. just return a network error given a set of properties on the request and the response mime type. |
| 11:57 | <mkwst> | but it's probably the wrong layer. |
| 11:58 | <Ms2ger> | I think so, yes |
| 12:09 | <hsivonen> | SimonSapin, zcorpan: I think zcorpan has previously shown w3techs.com to be bogus, but browser-based telemetry would be interesting |
| 12:09 | <SimonSapin> | hsivonen: so we don’t have telemetry for that yet? |
| 12:09 | <hsivonen> | annevk: what's the recommended way to test non-UTF encoders without relying on a server and using Web-exposed functionality only? |
| 12:10 | <hsivonen> | SimonSapin: AFAIK, we don't |
| 12:10 | <mkwst> | annevk: philipj asked me to expose the `opaque` flag to the web so we can test it in layout tests (and, I suppose, so folks could construct excitingly opaque FormData objects). Before I do that, how strongly do you feel about changing from `FormData` with a flag to `CredentialFormData`? |
| 12:13 | <philipj> | mkwst: well I didn't ask you to expose it, just if it should be exposed :) |
| 12:13 | <mkwst> | well, that seems to be an implicit request to expose it, right? :) |
| 12:13 | <philipj> | surely something should cause it to become set, which isn't currently the case |
| 12:13 | <darobin> | thanks MikeSmith! |
| 12:13 | <mkwst> | philipj: right. that's the second patch I sent you. :) |
| 12:14 | <philipj> | mkwst: eh, well OK :) |
| 12:14 | <philipj> | ah there it is, fd->makeOpaque() |
| 12:15 | <mkwst> | yeah. basically, i don't mind exposing that. i can't think of much of a use case, other than transferring a FormData object to a new context via `postMessage()`. |
| 12:15 | <mkwst> | but not being able to think of a use case is probably just my small-mindedness. |
| 12:15 | <mkwst> | maybe exposing every flag ever is good! |
| 12:15 | <mkwst> | (note, though, that it needs to be a one-way operation; JS shouldn't be able to unopaqueify an opaque object) |
| 12:22 | <hsivonen> | annevk: is there something smarter than http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3609 for accessing encoders purely on the client and using public APIs only? |
| 12:28 | <mkwst> | *sigh* why is testharness so wrong about the ordering of expected and actual values? |
| 12:28 | <philipj> | ask jgraham :) |
| 12:28 | <philipj> | what is the right order, agin? |
| 12:28 | <yoav> | I get those wrong *every* time |
| 12:28 | <mkwst> | the right order is expected, actual. |
| 12:28 | <mkwst> | testharness's order is backwards. |
| 12:29 | <mkwst> | :) |
| 12:29 | <Ms2ger> | What? |
| 12:29 | <Ms2ger> | actual, expected is the only sensibler order |
| 12:30 | <philipj> | mkwst: incidentally I was confused about why gtest has the "wrong" order not long ago, being very used to testharness |
| 12:31 | <mkwst> | philipj: Does https://codereview.chromium.org/1323043002 do what you wanted? |
| 12:31 | <philipj> | let me see if it induces happiness |
| 12:32 | <jgraham> | mkwst: FWIW I agree as you will see if you examine presto-testo for the testharnesses I wrote before testharness.js. It just turns out that the rest of the world largely disagrees. |
| 12:32 | <mkwst> | jgraham: Ok! So let's sneakily change it back and see if anyone notices! |
| 12:33 | <jgraham> | mkwst: I see you haven't worked with Ms2ger for long enough |
| 12:35 | Ms2ger | wanders up to mkwst |
| 12:36 | <mkwst> | I haven't, actually, though I've gotten some good ms2ger feedback on various specs. :) |
| 12:37 | <Ms2ger> | Probably rather grumpy feedback :) |
| 12:37 | <annevk> | hsivonen: I don't think so, hadn't even thought of that approach, neat |
| 12:37 | <mkwst> | all feedback is good feedback. like, really. it's tough to get any feedback until something's shipping, and then it's somewhat late. :/ |
| 12:38 | <annevk> | mkwst: how do you envision changing the FormData constructor? |
| 12:38 | <mkwst> | annevk: I don't. |
| 12:38 | <mkwst> | https://w3c.github.io/webappsec/specs/credentialmanagement/#dom-formdata-makeopaque is my current thought. |
| 12:39 | <annevk> | mkwst: isn't that extremely fragile from a security perspective? |
| 12:39 | <mkwst> | if you pick up https://github.com/whatwg/html/issues/62, that would change the `FormData(HTMLFormElement)` constructor. |
| 12:40 | <mkwst> | yes? i don't think `makeOpaque()` has any security value; it has explanatory value. |
| 12:41 | <mkwst> | currently, opaque FormData objects only make sense in the context of the credential management API, or write-only form fields. |
| 12:41 | <annevk> | Ms2ger: I recommend not replying to the <keygen> issue |
| 12:41 | <jgraham> | " see if anyone notices" where Ms2ger ∈ anyone is always true |
| 12:41 | <Ms2ger> | annevk, but someone is wrong on the internet! |
| 12:41 | <mkwst> | there's no other case I know of in which they offer any value, as all the data's already available to JavaScript. |
| 12:41 | <Ms2ger> | (point taken) |
| 12:42 | <annevk> | mkwst: I think if we expose anything it should be part of the constructor |
| 12:42 | <mkwst> | annevk: how does that help? |
| 12:43 | <annevk> | mkwst: seems more robust |
| 12:43 | <mkwst> | that is, how is `FormData(form, { opaque: true })` better than `var fd = FormData(form); fd.makeOpaque();`? I suppose it's prettier? |
| 12:43 | <mkwst> | robust against what? :) |
| 12:44 | <annevk> | mkwst: e.g., you can use a different data structure for the internals then |
| 12:44 | <annevk> | mkwst: anyway, I don't think we should expose the slot for v1 |
| 12:44 | <annevk> | mkwst: seems like feature creep |
| 12:45 | <mkwst> | what do you mean? |
| 12:45 | <annevk> | mkwst: it adds complexity in the design process while not solving any problems |
| 12:45 | <mkwst> | I'm not following. We need to somehow expose the password to something, otherwise the user can't sign in with it. |
| 12:47 | <annevk> | What does the password have to do with exposing opaque to JavaScript? |
| 12:48 | <mkwst> | Oh, I see. You're calling the flag a slot. Got it. |
| 12:49 | <mkwst> | I don't think we need to expose opaque to JavaScript, but doing so make it possible to write DOM-based layout tests instead of just unit tests for the C++ code. |
| 12:49 | <mkwst> | Also: this was philipj's idea. :) |
| 12:49 | <mkwst> | See https://codereview.chromium.org/1323043002/#ps20001. |
| 13:02 | <philipj> | It's fine with me if it isn't web-exposed, should still be possible to test opaque-ness by using toFormData I think |
| 13:03 | <mkwst> | philipj: Yeah. It's a bit roundabout, but since that's the only thing that creates an opaque FormData object, it's a totally reasonable way of testing the feature. I'll drop it. Adding it back is trivial if annevk changes his mind. :) |
| 13:04 | <philipj> | annevk never changes his mind, he was born with all the right opinions |
| 13:04 | <mkwst> | lucky guy. |
| 13:04 | <MikeSmith> | agree it's a bad idea to feed that keygen troll |
| 13:15 | <mkwst> | So. Anyone have a thesaurus handy? I need a word that means "credential" but that isn't "credential". :) |
| 13:18 | <jgraham> | http://www.thesaurus.com/browse/credential |
| 14:05 | <johnme> | annevk: for notification actions (https://github.com/whatwg/notifications/pull/48), I've realised the event delivered to pages shouldn't inherit from ExtendableEvent. |
| 14:05 | <johnme> | annevk: Should I rename NotificationEvent to PersistentNotificationEvent, and introduce a new NonPersistentNotificationEvent? |
| 14:06 | <annevk> | johnme: interesting, does this feature even make sense for toast-like notifications? |
| 14:06 | <johnme> | might depend on the platform |
| 14:07 | <annevk> | johnme: provided you want to keep it, I suggest not renaming NotificationEvent, but only introducing NonPersistentNotificationEvent, or perhaps ToastNotificationEvent... |
| 14:08 | <johnme> | ok |
| 14:09 | <johnme> | (I checked github and could find almost zero mentions of NotificationEvent) |
| 14:13 | <annevk> | mkwst: johnme: do you know who does autocomplete in Chrome? https://www.w3.org/Bugs/Public/show_bug.cgi?id=28952 has a suggestion |
| 14:15 | <mkwst> | Wow. I thought Heidegger died. And I didn't know he built websites. |
| 14:16 | <mkwst> | Oh no. |
| 14:16 | <mkwst> | TBL on www-tag@. :( |
| 14:17 | <mkwst> | https://lists.w3.org/Archives/Public/www-tag/2015Sep/0000.html |
| 14:20 | <annevk> | Maybe someone should tell timbl that you need HTTPS for <keygen> |
| 14:20 | annevk | hides |
| 14:24 | <johnme> | annevk: mathp & thestig (both @chromium.org) are probably good people to talk to about autofill |
| 14:28 | <johnme> | annevk: after chatting to peter, I think I'll drop actions from non-persistent notifications for now (due to the uncertainty around moving to toast notifications) |
| 14:36 | <Workshiva> | I wonder if there are numbers on frequency of http vs https in keygen usage |
| 14:48 | <annevk> | johnme: thank you, pinged them |
| 15:23 | <wanderview> | JakeA: annevk: I don't support either of you have an opinion on this issue before we change our tests to do one or the other? https://github.com/slightlyoff/ServiceWorker/issues/742 |
| 15:27 | <annevk> | wanderview: so is scriptURL the final after redirects URL? |
| 15:28 | wanderview | looks |
| 15:29 | <wanderview> | annevk: it appears the scriptURL is set before fetching the script... so I would say before any redirects |
| 15:31 | <wanderview> | annevk: as far as I can tell the script URL is never updated based on the final redirected URL |
| 15:33 | <annevk> | wanderview: hmm |
| 15:33 | <annevk> | wanderview: so for Request it returns the URL without the fragment |
| 15:33 | <wanderview> | yes |
| 15:34 | <annevk> | wanderview: but there's also a dozen other APIs that will return it with |
| 15:34 | <annevk> | wanderview: so maybe Request is wrong |
| 15:34 | <wanderview> | I don't think this uses Request in the register() path |
| 15:34 | <wanderview> | annevk: you're making me sad right now |
| 15:34 | <wanderview> | we just fixed Request to strip the fragment :-\ |
| 15:34 | <annevk> | wanderview: that doesn't really matter when looking for consistency though |
| 15:35 | <annevk> | Yeah I don't know, the fragment is useless... |
| 15:36 | <wanderview> | annevk: I can't see a reason to keep the fragment... and it appears chrome strips it for the script URL |
| 16:27 | <ccardona-work> | Good morning/afternoon/evening WHATWG crew 😎 |
| 16:32 | <annevk> | Domenic: https://github.com/whatwg/dom/issues/61#issuecomment-136773368 |
| 16:32 | <annevk> | The base URL story changes yet again |
| 16:32 | <Domenic> | Yeah... |
| 16:33 | <Domenic> | annevk: couldn't in theory it still be lazy though? e.g. if selector matching just looked at .href? |
| 16:33 | <Domenic> | annevk: oh no i get it |
| 16:34 | <Domenic> | Sebmaster ^ |
| 16:38 | <Sebmaster> | oh :( |
| 16:38 | <Sebmaster> | well, could still do parsing lazily i guess |
| 16:39 | <Sebmaster> | i guess it depend how the pseudo-class is implemented, but I think it could be done lazily anyways |
| 16:41 | <Domenic> | I thought about that |
| 16:42 | <Domenic> | It would be very convoluted. You'd want to re-compute the pseudo class matching every frame for drawing. |
| 16:42 | <Domenic> | So, not really an option. |
| 16:42 | <Domenic> | (Plus you'd need to make sure it gets recomputed whenever someone does selector matching.) |
| 16:42 | <annevk> | Domenic: I found https://github.com/whatwg/html/commit/78f1994463a1f19685ea2ca5beb335ca2a91ca14 |
| 16:42 | <Domenic> | href can still be lazy |
| 16:43 | <annevk> | Domenic: what is the correct GitHub syntax to link that? |
| 16:43 | <Domenic> | annevk: 78f1994463a1f19685ea2ca5beb335ca2a91ca14 |
| 17:13 | <Yuhong> | Something where we actually care about W3C's patent policy: https://blog.mozilla.org/blog/2015/09/01/forging-an-alliance-for-royalty-free-video/ |
| 17:16 | <Yuhong> | It is not actually developed within W3C though. |
| 17:17 | <Domenic> | As far as I can tell the winning codec is the one that gets all the chipset manufacturers to build hardware decoders |
| 17:19 | <annevk> | Domenic: I can't figure out how to change the commit message |
| 17:20 | <Domenic> | annevk: git commit --amend -m "new message" should do the trick |
| 17:20 | <annevk> | Domenic: that will not change the title? |
| 17:20 | <Domenic> | annevk: title is a human concept... |
| 17:21 | <Domenic> | oh you mean of the PR itself? |
| 17:21 | <Domenic> | That doesn't end up mattering |
| 17:21 | <annevk> | Domenic: no I meant of the commit |
| 17:21 | <Domenic> | Yeah title just means first line of message |
| 17:21 | <annevk> | Domenic: how I handle newlines? Does \n work? |
| 17:21 | <Domenic> | Good question... |
| 17:21 | <Domenic> | oh |
| 17:21 | <Domenic> | just git commit --amend and then you'll get a text editor |
| 17:22 | <annevk> | Domenic: yeah not one I can use though... I guess I can try |
| 17:22 | <Domenic> | git config --global core.editor subl |
| 17:23 | <Domenic> | (I think subl = sublime text on macs...) |
| 17:23 | <annevk> | Ah, is that the command-line way to launch your editor? |
| 17:23 | <annevk> | Mine responds to "edit resource" |
| 17:23 | <annevk> | So would I use git config --global core.editor edit? |
| 17:24 | <annevk> | yes |
| 17:24 | <annevk> | cool |
| 17:26 | <annevk> | Hmm that didn't work |
| 17:28 | <annevk> | Domenic: so it opens the editor with .git/COMMIT_EDITMSG which I modify and save and then I run git push --force but nothing |
| 17:32 | <Domenic> | -_- |
| 17:33 | <Domenic> | http://stackoverflow.com/a/15008335/3191 |
| 17:33 | <Domenic> | Looks like this --wait option is important |
| 17:33 | <Domenic> | Want to give it a try? Otherwise I can do it. |
| 17:34 | <annevk> | Okay |
| 17:34 | <jamesr___> | git relies on the exit code from whatever editor it spawns |
| 17:37 | <Domenic> | \o/ |
| 17:37 | annevk | finds http://stackoverflow.com/questions/13257519/how-to-change-the-default-editor-for-git |
| 17:37 | <annevk> | Which seems to have worked, yay |
| 17:38 | <Domenic> | so currently your selectors-attribute-value is not on top of master |
| 17:40 | <annevk> | Okay, so that is what went wrong? |
| 17:41 | <annevk> | I guess I needed to amend and do git rebase then? |
| 17:42 | <Domenic> | yeah rebase is the trick |
| 17:42 | <Domenic> | rebase then push |
| 17:42 | <Domenic> | (force push) |
| 17:42 | <annevk> | Do you do the rebase before running pr? |
| 17:43 | <Domenic> | So the problem with pr is that it works in this other temporary branch, named pr/74 |
| 17:43 | <annevk> | We need to write down the explicit steps under merge policy I think |
| 17:43 | <Domenic> | that is mainly because when other people without access to the repo do PRs, there is no corresponding whatwg/selectors-attribute-values branch |
| 17:45 | <Domenic> | In your case what you could have done (but again this is all kind of silly) is manually done these three steps from pr(): https://gist.github.com/domenic/11371574#file-bashrc-L4-L6 |
| 17:45 | <Domenic> | just instead of `pr/$1` you'd do it with your local `selectors-attribute-values` |
| 17:46 | <Domenic> | i can make this easier with more scripts, let me see. |
| 17:46 | <annevk> | Would you mind adding both set of steps to the README? |
| 17:46 | <annevk> | For external branches and local branches? |
| 17:47 | <gsnedders> | Yet another person missing the "element refer to element in the HTML namespace" in the terminology section. I wonder if it's worthwhile revisiting that, given it causes so many bugs. |
| 17:49 | <Domenic> | yeah |
| 17:49 | <Domenic> | (to adding steps) |
| 17:51 | <annevk> | gsnedders: if you have suggestions or a PR :-) |
| 17:53 | <gsnedders> | annevk: well the only real option is to explicitly state "HTML element" everywhere, which seems pretty bad. It simultaneously reduces readibility and improves it (verbosing v. redefining common terms) |
| 17:53 | <annevk> | gsnedders: html:select |
| 17:54 | <annevk> | but no, let's not do that |
| 17:55 | <annevk> | gsnedders: perhaps we could have "select element" and have "element" here link to "HTML element" |
| 18:03 | <gsnedders> | annevk: it's caused enough bugs in enough things, though. like, the confusion from redefining the term is real, and is a problem. :| |
| 18:29 | <Sebmaster> | linking in the url spec was pretty sweet to differentiate between local vs state variables. I thought that was pretty nice |
| 20:12 | <aklein> | Domenic: more Map/Set fixes in cloining in https://github.com/whatwg/html/pull/82 |
| 20:19 | <Domenic> | aklein: great, will review by tomorrow at the latest; really gotta work on some other stuff today :P |
| 20:51 | <aklein> | Domenic: np, just feel bad that I didn't fix it properly the first time |
| 20:53 | <Stevef_> | annevk: hi, is it worth me opening issues for author conformance and advice differences between whatwg/w3c html? |
| 20:55 | <Stevef_> | annevk: for example, I filed this one https://github.com/whatwg/html/issues/83 |