| 01:26 | <Domenic> | TabAtkins: best practices for abbreviated <dfn>s in bikeshed specs/specs in general? I am thinking "A <dfn>exclusive stream reader</dfn> or <dfn>reader</dfn> is..." but maybe the second one shouldn't be <dfn>ed? |
| 01:39 | <TabAtkins> | Domenic: Use a long enough name that it stands a good chance of being globally unique; makes everyone's lives easier. If you want to use a shorter term within your spec, use the local-title='' attribute, which'll create linking text solely for local autolinks, without exporting. |
| 01:40 | <TabAtkins> | So <dfn export local-title="reader">exclusive stream reader</dfn> will give you the long term for autolinking from elsewhere, and the short term locally for convenience. |
| 01:40 | <Domenic> | OK. And just remove the <dfn> around the word "reader" later in the sentence? |
| 01:42 | <TabAtkins> | yeah. |
| 01:42 | <Domenic> | sgtm |
| 01:43 | <Domenic> | all of my stuff is <dfn>s so at some point I need to go change them into <dfn export>s |
| 01:43 | <TabAtkins> | Alternately, keep the <dfn> around reader, just don't export it. It'll only be autolinkable if people specify they want it from the spec. |
| 01:43 | <TabAtkins> | Yeah. |
| 09:43 | <Ms2ger> | zcorpan, http://dev.w3.org/csswg/cssom/#dom-cssstyledeclaration-item doesn't say what happens for out-of-range arguments |
| 09:47 | <zcorpan> | Ms2ger: can you file a bug? |
| 09:47 | <Ms2ger> | Sure |
| 09:48 | <Ms2ger> | I see https://www.w3.org/Bugs/Public/show_bug.cgi?id=27590 already exists for the other thing that confused me :) |
| 09:48 | <zcorpan> | thx |
| 09:51 | <Ms2ger> | annevk, r? https://critic.hoppipolla.co.uk/r/3473 |
| 09:57 | <annevk> | oh shit, I didn't realize you were just moving things |
| 09:57 | <annevk> | oh well |
| 10:19 | <Ms2ger> | annevk, well, not sure if anyone's reviewed it before :) |
| 10:25 | <Ms2ger> | annevk, trying to figure out where the normative requirement is exactly... |
| 10:25 | <Ms2ger> | Is it "If the CORS flag is set and a CORS check for request and response returns failure, return a network error." in Fetch? |
| 10:32 | <annevk> | Ms2ger: actually, I wonder whether that test is correct at all |
| 10:32 | <annevk> | Ms2ger: it looks bogus |
| 10:33 | <Ms2ger> | Hrm |
| 10:33 | <annevk> | Ms2ger: at the time XHR does send(); it should issue a CORS-with-forced-preflight |
| 10:33 | <annevk> | Ms2ger: due to event listeners being attached |
| 10:33 | <annevk> | Ms2ger: which would make progress events work |
| 10:33 | <Ms2ger> | Isn't that only with event listeners on xhr.upload? |
| 10:34 | <annevk> | Ms2ger: oh good point |
| 10:34 | <annevk> | Ms2ger: okay so yeah, this is about failing before any progress tasks would be queued |
| 10:40 | <Ms2ger> | annevk, so is that covered by the bit I quoted? |
| 10:40 | Ms2ger | still doesn't know his way around Fetch |
| 10:55 | smaug____ | has still no idea how Fetch works |
| 10:56 | <smaug____> | goal for the next year, try to understand what Fetch is about :) |
| 11:31 | <annevk> | Ms2ger: yeah |
| 11:41 | <Ms2ger> | annevk, okay, thanks |
| 12:15 | <ondras> | https://www.ups-scs.com/contact/technical_support_questions.html |
| 12:15 | <ondras> | nice Browser Type options |
| 12:27 | <annevk> | Anyone here familiar with bikeshed? |
| 12:27 | <annevk> | I'm getting "FATAL ERROR: Functions/methods must end with () in their linking text, got 'href'." and I've no idea what is wrong |
| 12:32 | <zcorpan_> | annevk: it's expecting <dfn>href()</dfn>. maybe change the dfn type (don't remember which attribute to change the type) |
| 12:32 | <annevk> | I don't even know how that can happen since I'm not changing any of that |
| 12:33 | <annevk> | I think rubys must be using a different version of bikeshed |
| 12:33 | <annevk> | *sigh* |
| 12:34 | <annevk> | Okay so something is wrong with "stringifier" |
| 12:50 | <annevk> | I pushed a PR against whatwg/url... Hopefully this gets fixed somehow |
| 13:36 | <rubys> | fdd7aa2dfce7b2ed8b8f00c7dc628aeada61fad6 is the first bad commit |
| 13:36 | <rubys> | commit fdd7aa2dfce7b2ed8b8f00c7dc628aeada61fad6 |
| 13:36 | <rubys> | Author: Tab Atkins <jackalmage⊙gc> |
| 13:36 | <rubys> | Date: Wed Dec 3 11:24:08 2014 -0800 |
| 13:36 | <rubys> | Add stringifier to the functionish types. Use construct.methodName, per plinss recommendation. |
| 13:36 | <rubys> | :040000 040000 cad74a9ec249d4cd7f358bb2b26a651e49f711c2 9bd6d22e2d39f6393c90f4be02d684c2e05a299c M bikeshed |
| 13:36 | <rubys> | bisect run success |
| 13:44 | <annevk> | Maybe bikeshed should have a pre/postcommit hook to make sure it doesn't actually break any specs |
| 13:46 | <JakeA> | annevk: is there a collective term for requests that may potentially create a new client? |
| 13:46 | <annevk> | potentially? |
| 13:47 | <JakeA> | annevk: I guess the only potential is embed |
| 13:47 | <JakeA> | (and object) |
| 13:47 | <annevk> | Commented out I have this: |
| 13:47 | <JakeA> | And we ignore those in ServiceWorker at the moment |
| 13:47 | <annevk> | <p>A <dfn>client request</dfn> is a <span title=concept-request>request</span> whose |
| 13:47 | <annevk> | <span title=concept-request-context>context</span> is one of <i title>child</i>, |
| 13:47 | <annevk> | <i title>navigate</i>, <i title>popup</i>, and <i title>sharedworker</i>. |
| 13:48 | <annevk> | but that seems out of date with the contexts we have |
| 13:48 | <JakeA> | Yeah, needs to include form, anchor etc |
| 13:48 | <annevk> | And the opposite was "resource request" |
| 13:48 | <JakeA> | Client request works for me |
| 13:48 | <JakeA> | I'll write up a ticket |
| 13:49 | <JakeA> | (with the complete list of contexts) |
| 13:50 | <rubys> | got a minimal test case for the bikeshed breakage, will open an issue. I don't see a workaround as being possible. |
| 13:54 | <JakeA> | annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27595 |
| 13:55 | <rubys> | https://github.com/tabatkins/bikeshed/issues/307 |
| 13:59 | <annevk> | rubys++ |
| 13:59 | <annevk> | JakeA: yeah, I'm not sure about your open question |
| 14:00 | <JakeA> | embed/object? They could be "potentially client requests" |
| 14:00 | <JakeA> | A different collection |
| 14:00 | <annevk> | I think plugin is fetches from a plugin |
| 14:01 | <annevk> | If the plugin uses the browser's network stack |
| 14:01 | <JakeA> | …then it's a resource |
| 14:01 | <JakeA> | cool |
| 14:01 | <annevk> | Would need to check with Mike to be sure, but I think that's correct, yes |
| 14:01 | <annevk> | "annoying requests" for object/embed |
| 14:02 | <annevk> | clientcurious |
| 14:02 | <JakeA> | haha |
| 14:06 | <annevk> | JakeA: oh btw, per some feedback from Domenic and TabAtkins I might end up renaming all the /context/ things to "context" so prose and enums match |
| 14:08 | <JakeA> | annevk: I don't follow, give me an example |
| 14:11 | <annevk> | JakeA: currently the spec has /form/, it'll become "form" |
| 14:11 | <annevk> | JakeA: I guess serviceworker as client request makes sense, it will just never have an associated service worker |
| 14:13 | <JakeA> | annevk: Yeah, I was thinking what new Request().client would be within a ServiceWorker |
| 14:14 | <annevk> | JakeA: I thought .client was on FetchEvent? |
| 14:17 | <JakeA> | annevk: yeah, but https://github.com/slightlyoff/ServiceWorker/issues/318 suggests request is better? |
| 14:18 | <annevk> | Ah right, so if client as a thing is only ever going to be useful in the context of a service worker, perhaps putting it on FetchEvent is not too bad |
| 14:19 | <annevk> | And if we decide that it is useful outside of SW, we could always make FetchEvent.prototype.client's getter forward |
| 14:21 | <JakeA> | Yeah, I'm fine with that |
| 14:22 | <annevk> | JakeA: actually, I thought we would not have .client there and maybe at some point have a handle back to the fetcher |
| 14:22 | <annevk> | JakeA: and only have clients exposed on the global |
| 14:23 | <JakeA> | annevk: true https://github.com/slightlyoff/ServiceWorker/issues/575 |
| 14:24 | <JakeA> | annevk: hah, I was hovered over the "Comment" button there when yours appeared |
| 14:24 | <annevk> | heh |
| 14:25 | <annevk> | Is the subscribe feature in GitHub new? Seems useful |
| 14:30 | <annevk> | rubys: so some other things that broke are links to URLSearchParams, they would normally be #urlsearchparams whereas #dom-urlsearchparams would be a link to its constructor definition |
| 14:31 | <annevk> | rubys: it seems #url also no longer links to the URL interface |
| 14:31 | <annevk> | rubys: and the URL constructor is now #dom-url-url... |
| 14:32 | <rubys> | annevk: I've got some things I need to attend to today (for wife not work), so bug reports would be helpful. |
| 14:33 | <annevk> | rubys: sure |
| 15:31 | <TabAtkins> | annevk: More people use Bikeshed than I even know about, so not breaking "any" specs as I update and tweak is likely impossible. ^_^ |
| 15:31 | <TabAtkins> | annevk: But I do run Web Animations regularly, as it tends to use more complex things. I might add url to that regimen. |
| 15:33 | <TabAtkins> | annevk: The #dom-foo pattern for interface names is standard practice (though obviously it can be overridden by you). Dunno what standard practice is for constructor IDs, but it's currently treated as a method of the same name as the interface, thus the ID you see. |
| 15:33 | <Ms2ger> | TabAtkins, it's not standard practice in specs that define interfaces |
| 15:34 | <TabAtkins> | Ms2ger: Yes, it is? |
| 15:35 | <Ms2ger> | https://wiki.whatwg.org/wiki/Specs/howto#Definitions |
| 15:36 | <TabAtkins> | Hm, ok. |
| 15:36 | <TabAtkins> | Wonder why I was told to implement it this way originally. |
| 15:38 | <TabAtkins> | annevk: Remember that I try hard to make sure that Bikeshed recovers gracefully from fatal errors, so if something is erroring wrongly, you can always do a force-generate until I fix the issue. |
| 15:45 | <annevk> | TabAtkins: make force-generate? |
| 15:46 | <TabAtkins> | annevk: Your makefile is something y'all did on your own, I have no idea what options y'all have there. |
| 15:46 | <annevk> | I see |
| 15:46 | <TabAtkins> | But it's just passing the -f flag right after the command, `bikeshed -f spec` |
| 15:46 | <annevk> | Okay |
| 15:46 | <TabAtkins> | (Your makefile should probably force-generate by default.) |
| 15:47 | <annevk> | TabAtkins: the convention I know is #interfacename (interface) and #dom-interfacename (constructor), #dom-interfacename-member (member) |
| 15:47 | <TabAtkins> | Yeah, Ms2ger pointed me to the wiki page. |
| 15:48 | <TabAtkins> | For some reason I was instructed differently when I was first putting together ID generation for IDL stuff. |
| 15:48 | <annevk> | :-( |
| 15:49 | <rubys> | I'd prefer not to pass the -f flag. Bikeshed detected errors should be fixed. 99% of the time, the right fix is to change the spec. |
| 15:50 | <rubys> | as to definitions, my preference is that the url standard not be an exception. If that means that there is a one time cost to move to what others have agreed to, I think we should do that. |
| 15:50 | <TabAtkins> | rubys: I dunno make. Is it possible to add some way to force-generate via make? |
| 15:50 | <TabAtkins> | rubys: yeah, moving IDs is no problem. |
| 15:50 | <rubys> | I can always do a force generate "manually" when I need to debug a problem. |
| 15:50 | <TabAtkins> | rubys: But annevk doesn't know how to do that. |
| 15:50 | <rubys> | s/doesn't/didn't/ :-) |
| 15:51 | <annevk> | rubys: define "others" and see the above page |
| 15:52 | <rubys> | annevk: I'm not going to define others. :) If the right fix is that bikeshed should change, then that's ok with me too. |
| 15:53 | <annevk> | Pretty sure the conventions used by URL predate bikeshed |
| 15:53 | <TabAtkins> | the only other big user of IDL so far is Web Animations. It's fine to move Bikeshed. |
| 15:53 | <TabAtkins> | There's not a ton of cross-linking of IDL between specs yet, so it's a good time to nail these down. |
| 15:53 | <rubys> | +1 |
| 15:53 | <TabAtkins> | And fixing is just a matter of regenning if any links do break. |
| 16:43 | <TabAtkins> | What in the hell? Why does github use flash somewhere on the page, and why is it suddenly crashing in my Chrome and preventing me from interacting with the page? |
| 16:44 | <Domenic> | TabAtkins: uses flash to make clipboard copy buttons work |
| 16:44 | <TabAtkins> | Ah, kk. Well, for some reason it's crashing in my ubuntu chrome. >_< |
| 16:48 | <rubys> | fwiw, github works fine here (ubuntu 14.04, 64-bit intel desktop) |
| 17:23 | <TabAtkins> | Annoyingly, that stringifier error was hitting codepaths that *didn't* fail gracefully when you forced the generation. That's fixed now. ^_^ |
| 17:23 | <TabAtkins> | rubys: Sorry about not testing the stringifier-attribute form. I don't recall ever seeing it in real life before. |
| 17:35 | <jgraham> | You know I would be more sympathetic to web crypo going through the process too fast if I hadn't sat in a room where everyone agreed that a testsuite was needed but refused to actually commit any resources to creating one. |
| 17:35 | <boogyman> | haha |
| 17:36 | <boogyman> | :( |
| 17:59 | <Domenic> | there's an anandtech expose waiting to be written about specs being pushed through the process too fast |
| 18:02 | <annevk> | From what I gather from tweets from sleevi it was not just things being pushed fast |
| 18:02 | <annevk> | That WG seemed rather broken |
| 18:03 | <TabAtkins> | Yeah, there seemed to be a lot of "okay, we know this is broken, but we want to implement it anyway, so it needs to be in the spec". |
| 18:05 | <annevk> | And a lot of spurious arguments around crypto algorithms |
| 18:10 | <TabAtkins> | Basically it appeared there were several people in the group who didn't care about security, but rather about matching some existing crypto impl, or something like that. |
| 18:10 | <TabAtkins> | And the chair didn't suppress them sufficiently. |
| 18:15 | <annevk> | For anyone interested in searchParams and URLSearchParams: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27596 |
| 18:59 | <Domenic> | annevk: ugh why can't we have nice things |
| 19:00 | <boogyman> | um, 1:1 ? that sounds bad |
| 19:02 | <Domenic> | annevk: I don't understand why your solution of replacing hte object upon navigation doens't work |
| 19:57 | <annevk> | boogyman: why? |
| 19:58 | <annevk> | Domenic: Location is associated with a document's browsing context's active document; we could tie URLSearchParams to document, but what happens if you hold a reference to an older URLSearchParams object before you navigated and start to mutate it? |
| 19:59 | <annevk> | Domenic: that is why I came up with the idea of having an immutable variant |
| 20:00 | <Domenic> | annevk: is there something wrong the answer "the location object's other properties update, but otherwise nothing happens"? |
| 20:00 | <Domenic> | s/the location object/the old location object/ |
| 20:04 | <annevk> | Domenic: there's no old Location object |
| 20:07 | <Domenic> | well, presumably someone could have saved it somewhere? |
| 20:07 | <Domenic> | or is there really only one window.location across navigations |
| 20:07 | <annevk> | Domenic: it doesn't change identity afaik |
| 20:07 | <Domenic> | ah |
| 20:07 | <Domenic> | well i guess then i'd say disassociate the old one so that mutating it does nothing to the location |
| 20:08 | <annevk> | Domenic: we really need some diagrams for this set of objects at some point |
| 20:08 | <Domenic> | kind of strange but it is explicable |
| 20:08 | <Domenic> | +Infinity |
| 20:08 | <annevk> | Domenic: I'm hoping to make some once I learn about a good tool since I keep messing up even the basics such as Window vs WindowProxy |
| 20:09 | <Domenic> | I used http://gliffy.com/ for streams but their SVG support got worse recently so I had to re-code it all by hand |
| 20:09 | <annevk> | Yeah, I guess disassociation is what's needed, but that breaks "fast back" (or whatever it's called) in browsers that support such a thing |
| 20:10 | <Domenic> | They used data: URL images for arrows :(. Whereas you can just use <path marker-end> in SVG. https://github.com/whatwg/streams/blob/master/readable-stream.svg?short_path=48eff29#L56 |
| 20:10 | <Domenic> | hmmmmm |
| 20:10 | <boogyman> | annevk: because so many languages already have support for domain.tld/?a=foo&a=bar&a=baz unless I am mistaken about that ticket. |
| 20:10 | <annevk> | boogyman: 1:1 is about the URL object and the URLSearchParams object |
| 20:10 | <Domenic> | i don't really understand fast back and how it impacts standards |
| 20:10 | <Domenic> | i guess html has a bfcache in the spec? |
| 20:10 | <annevk> | boogyman: not about how many parameters you can have |
| 20:10 | <annevk> | Domenic: yup |
| 20:11 | <Domenic> | i don't really feel like reading up on all that today :P |
| 20:11 | <annevk> | Domenic: I guess you could restore the association, but that seems really sketchy |
| 20:11 | <Domenic> | it's all pretty explicable I think in JS terms. (With internal slots/weak maps) |
| 20:12 | <Domenic> | Would want to write it out to be sure but if that's what you mean by sketchy, seems ok |
| 20:13 | <boogyman> | annevk: if the URL object is a hashmap, when would the various components ever not be 1:1 ? |
| 20:30 | <rubys> | TabAtkins: I'm still seeing the problem: |
| 20:30 | <rubys> | FATAL ERROR: Functions/methods must end with () in their linking text, got 'href'. |
| 20:31 | <TabAtkins> | Yeah, it ain't fixed yet. |
| 20:31 | <TabAtkins> | Been traveling all morning |
| 20:32 | <TabAtkins> | I just fixed the part where it crashed if you forced it. |
| 20:32 | <rubys> | oh, nevermind. I saw closed and thought it was fixed. It was referenced by another issue, and that issue is closed. |
| 20:33 | <TabAtkins> | Yeah, I can fix it now that the other issue is fixed. |
| 20:34 | <rubys> | I'm not rushing you; I honestly misunderstood. |
| 20:35 | <TabAtkins> | Good, because I'm busy doing my nails right now and won't be able to type for an hour. ^_^ |
| 20:39 | <Domenic> | Has anyone created a Firefox OpenSearch thing that restricts to html.spec.whatwg.org? I realized I'm appending "site:html.spec.whatwg.org" to many of my searches now |
| 20:40 | <Domenic> | I guess it doesn't look very hard https://developer.mozilla.org/en-US/Add-ons/Creating_OpenSearch_plugins_for_Firefox |
| 22:02 | <annevk> | The relationship between URL and URLSearchParams is currently N:1 |
