| 06:06 | <zcorpan_> | should we sync animations in SVG in <img>? |
| 06:07 | <birtles> | I think they should have their own separate timelines |
| 06:07 | <birtles> | separate <svg> roots within a single <html> already do |
| 06:13 | <zcorpan> | gif is synced though |
| 07:34 | <Ms2ger> | Anyone got a spec for Last-Modified header parsing? |
| 07:56 | <zcorpan_> | Ms2ger: i checked some RFC when there was a related wpt PR but it doesn't define parsing |
| 07:57 | <zcorpan_> | also involved Date() parsing :-) |
| 08:00 | <Ms2ger> | Yeah, I saw |
| 08:00 | <Ms2ger> | That's Servo implementing document.lastModified ;) |
| 08:10 | <Ms2ger> | "W3C Invites Implementations of HTML Canvas 2D Context" |
| 08:10 | <Ms2ger> | Says funny |
| 08:16 | <MikeSmith> | it means W3C is inviting all the existing implementations of canvas to a party |
| 08:17 | <MikeSmith> | they just left that part out for brevity in the headline |
| 08:17 | <MikeSmith> | you need to read the full thing |
| 08:17 | <Ms2ger> | I see |
| 08:18 | <Ms2ger> | I think I've got blame for Servo's implementation :) |
| 08:18 | <MikeSmith> | in that case the rule is that your implementation has to buy all the beer for the other implementations |
| 08:19 | <Ms2ger> | :D |
| 08:20 | <jgraham> | Maybe W3C is talking directly to the servo team with this call to implementations stuff |
| 08:20 | <jgraham> | After all we're the only people a decade behind the state of the art |
| 08:21 | <jgraham> | Perhaps when HTML5 goes to Rec someone will finally decide to implement navigation in servo |
| 08:21 | <Ms2ger> | Yep |
| 08:21 | <Ms2ger> | You :) |
| 08:23 | <jgraham> | Well, at risk of going all "meme" I do sometimes seem tot be the only one around here that gives a shit about document loading ;) |
| 08:23 | <jgraham> | But you really don't want me implementing it :) |
| 08:24 | <Ms2ger> | It's more that you convinced me how much work it'd be :) |
| 08:25 | <smaug____> | Domenic: will you change the streams spec to some readable form at some point ? ;) |
| 08:52 | <MikeSmith> | smaug____: Don't worry I heard he's planning on rewriting it in the style of the ES spec |
| 09:02 | <smaug____> | iik |
| 09:02 | <smaug____> | and isn't it a bit like that already |
| 09:05 | <jgraham> | smaug____: I hope MikeSmith was joking |
| 09:06 | <jgraham> | Although I guess you never know… |
| 09:15 | <annevk> | zcorpan_: SVG in <img> should use the animation frame task |
| 09:16 | <zcorpan_> | annevk: what does that say about the timelines being in sync? |
| 09:19 | <annevk> | zcorpan_: not much I guess, sorry |
| 09:21 | <annevk> | Well this is something new http://www.operasoftware.com/press/releases/mobile/2014-08-21 |
| 09:31 | <zcorpan_> | why does xref have "the blockquote element" as a term rather than "blockquote"? |
| 09:42 | <annevk> | zcorpan_: feel free to fix things as you see fit |
| 09:42 | <annevk> | zcorpan_: most of the HTML element related references are for the document you are editing I think |
| 09:43 | <zcorpan_> | ok |
| 10:54 | <zcorpan_> | MikeSmith: can you create a bugzilla component "HTML - <script>alert('LOL')</script>" ? |
| 10:55 | <zcorpan_> | https://www.w3.org/Bugs/Public/query.cgi click WHATWG product |
| 10:59 | <MikeSmith> | zcorpan_: http://instagram.com/p/r0eJp3PW7G/ |
| 11:10 | <zcorpan_> | MikeSmith: i think it's showOptionInIE() in field.js doing optionNode.innerHTML = aNode.data; |
| 11:22 | <JakeA> | annevk: is there a collective name for things that can be controlled by a SW? |
| 11:23 | <JakeA> | There's ServiceWorkerClient, but is it defined outside of SW? |
| 11:40 | <annevk> | JakeA: clients was the idea I thought |
| 11:40 | <annevk> | JakeA: SW needs to define all this terminology |
| 11:40 | <annevk> | JakeA: and clients are global objects |
| 11:40 | <annevk> | JakeA: which is why I think a DedicatedWorker ought to be controlled |
| 11:41 | <annevk> | So far the spec does a pretty poor job of outlining the underlying model |
| 11:51 | <JakeA> | gotcha. Will make a ticket |
| 11:56 | <MikeSmith> | zcorpan_: https://www.w3.org/Bugs/Public/query.cgi |
| 11:57 | <zcorpan_> | MikeSmith: it was innerHTML which doesn't run script :-( |
| 11:57 | <MikeSmith> | ah |
| 11:57 | <zcorpan_> | MikeSmith: showOptionInIE() in field.js doing optionNode.innerHTML = aNode.data; |
| 11:59 | <JakeA> | annevk: Opened https://github.com/slightlyoff/ServiceWorker/issues/423 to decide whether DedicatedWorkers are a client |
| 12:01 | <MikeSmith> | zcorpan_: ah ok I see now you said that earlier |
| 12:13 | <annevk> | JakeA: we should also make sure that everything is backed by some concept |
| 12:13 | <annevk> | JakeA: e.g. how Request objects are backed by the request concept |
| 12:16 | <JakeA> | annevk: not familiar with this pattern, where's the request concept? |
| 12:24 | <annevk> | JakeA: http://fetch.spec.whatwg.org/#concept-request |
| 12:29 | <annevk> | foolip: let me know when I start blocking you |
| 12:29 | <annevk> | foolip: working on some other things, but I can make time |
| 12:31 | <JakeA> | annevk: basically a description of the underlying properties/flags? |
| 12:32 | <annevk> | JakeA: it's basically a definition of how the system works, and the API reflects parts of the system |
| 12:33 | <annevk> | JakeA: e.g. fetch() itself is not much, most of the actual meat is in #concept-fetch |
| 12:33 | <JakeA> | gotcha |
| 13:13 | <annevk> | why are registerContentHandler and registerProtocolHandler not on caniuse? |
| 13:15 | <MikeSmith> | foolip: has anybody implemented datacue? |
| 14:06 | <annevk> | http://annevankesteren.nl/2014/08/registerprotocolhandler anyone have pointers to more about this? |
| 14:06 | <annevk> | I'm planning on filing some bugs on Gecko to see if we can make some improvements to make it more attractive |
| 14:07 | <annevk> | Or should we just forget about it altogether? I'm a bit on the fence |
| 14:23 | <MikeSmith> | annevk: I think it's worth investing some work in UI ideas. I've always liked registerProtocolHandler since whenever I first found out about in 2006 is whatever. I've think others do too (even if we don't hear from them so much) |
| 14:28 | <MikeSmith> | (like as in, think it's a pretty useful feature to have in the platform) |
| 14:46 | <gsnedders> | odinho: me + some not entirely clear group of people are going to Mustard at 6:30; I guess you won't want food, but feel free to drop by later if you want to get a drink if you're free. |
| 14:47 | <jgraham> | gsnedders: Your friends are translucent? |
| 14:47 | <gsnedders> | jgraham: shut up you |
| 14:48 | <annevk> | gsnedders: in Oslo? |
| 14:48 | annevk | misses Nøgne Ø |
| 14:49 | <annevk> | (also friends :p) |
| 14:49 | <jgraham> | Also beer prices? |
| 14:50 | <gsnedders> | annevk: yeah |
| 14:50 | <gsnedders> | jgraham: don't mention the cost :'( |
| 14:50 | <annevk> | jgraham: well, Zürich ain't much better |
| 14:50 | <annevk> | although it is a bit, I guess |
| 14:50 | <Domenic> | irccloud uses registerProtocolHandler I think? It works pretty well, although I don't find too many irc:// links on the web to click on. |
| 14:50 | <gsnedders> | annevk: well yeah, you just seem to like spending time in expensive places |
| 14:51 | <odinho> | gsnedders: oh, nice! 18.30 you say. |
| 14:55 | <gsnedders> | odinho: yeah |
| 14:56 | <richt> | annevk: Always wondered if the process of registering new protocol handlers could be permissionless and browsers could instead provide a picker UI when registered protocol types are invoked... |
| 14:57 | <gsnedders> | do any mobile platforms support registerProtocolHandler at an OS level? |
| 14:57 | <gsnedders> | well I presume Fx OS does, but anything else? |
| 14:58 | <annevk> | richt: Firefox has both |
| 14:58 | <annevk> | richt: with a checkbox to select a default |
| 15:04 | <foolip> | annevk: I still have some non-spec issues to work out, but the sooner the spec changes are made the sooner I can find the next round of bugs :) |
| 15:05 | <foolip> | MikeSmith: WebKit has it actually |
| 15:06 | <MikeSmith> | foolip: ok |
| 15:06 | <MikeSmith> | wonder what's blocking it from landing in blink. I seem to remember there being a patch |
| 15:07 | <foolip> | don't know if it's enabled though |
| 15:07 | <MikeSmith> | ok |
| 15:07 | <foolip> | MikeSmith: the intent to implement never went anywhere |
| 15:07 | <MikeSmith> | I see |
| 15:08 | <MikeSmith> | as far as gecko, there's not even a bug open for datacue as far as I can see |
| 15:12 | <richt> | annevk: oh cool. |
| 15:13 | <richt> | annevk: has opt-out instead of opt-in been considered before? the browser says '[domain] has registered to open all [type] links?' with the option to 'Undo' that. |
| 15:13 | <richt> | + a picker UI on invocation of course. |
| 15:15 | <caitp> | one day, the wikipedia article for the world wide web is going to have an opening paragraph like "the world wide web is a vast collection of dialog boxes asking you to opt into or out of specific features, where the wrong selection will make your experience a complete waste of time" |
| 15:16 | <caitp> | and nobody will be able to read it before opting into or out of thousands of different features |
| 15:19 | <jgraham> | Much like the android article today, you mean? |
| 15:29 | <JakeA> | Domenic: just noticed https://dvcs.w3.org/hg/dap/raw-file/tip/battery/Overview.html#widl-Navigator-getBattery-Promise-BatteryManager |
| 15:29 | <JakeA> | Domenic: that should be a getter rather than a method right? It returns the same object each time |
| 15:35 | <caitp> | for the brief period before `await` is supported, all of these asynchronous apis are going to be really fun for people to deal with |
| 15:36 | <JakeA> | yeeep |
| 15:36 | <JakeA> | await should be fast-tracked IMO |
| 15:37 | <Domenic> | JakeA: I think the motivation for being a method was that it will likely have side effects, e.g. a permission prompt or booting up the battery-tracking mechanism or similar. |
| 15:39 | <JakeA> | Domenic: I don't think it requires permission, but fair point on the tracking mechanism |
| 15:40 | <Domenic> | JakeA: yeah, I guess not. The model in https://dvcs.w3.org/hg/dap/raw-file/tip/battery/Overview.html#security-and-privacy-considerations is more that the browser will give the website bogus data if it doesn't trust the website. |
| 15:46 | <Ms2ger> | Is there any spec for file:// sniffing? |
| 15:47 | <gsnedders> | Ms2ger: sniffing what? MIME? |
| 15:47 | <Ms2ger> | Yeah |
| 15:48 | <gsnedders> | Ms2ger: do they not use OS level stuff? isn't xdg-mime used on Linux, at least? |
| 15:49 | <Ms2ger> | Well, I don't know, that's why I ask :) |
| 15:49 | <Ms2ger> | Manishearth, ^ |
| 15:52 | <Manishearth> | Ms2ger: should we be doing that then? Shouldn't be hard to write bindings for xdg-mime, but then we need to get it done on OSX too |
| 16:00 | <annevk> | richt: I don't think it has, but that seems wrong to reuse that infobar for opt out |
| 16:12 | <Ms2ger> | Heh |
| 16:13 | <Ms2ger> | Running Aryeh's IDL-extraction code on HTML yields |
| 16:13 | <Ms2ger> | interface TextTrackCueReady for first implementationsLatest Internet Explorer beta: unknownLatest Firefox trunk nightly build: unknownLatest WebKit |
| 17:21 | <JakeA> | annevk: Any idea what Mozilla's opinion on the quota API is? We need something for cache |
| 17:24 | <annevk> | JakeA: I don't really like the concept of quotas for storage |
| 17:25 | <annevk> | JakeA: not sure if we have a general opinion, there's not enough research done I think to really show what works well |
| 17:28 | <JakeA> | annevk: is there an alternate proposal? |
| 17:29 | <annevk> | I think there's a proposal from Alex about telling apps when they need to free up space |
| 17:29 | <annevk> | not concrete |
| 17:29 | <annevk> | But something like that was my idea was, if users use an application a lot, we try to keep the space it uses in tact |
| 17:30 | <annevk> | if the app is not often used and not marked in some way (e.g. bookmarked) we'd trash it |
| 17:31 | <JakeA> | Worried about something like tripit, that gets infrequent use but it's very important that it retains info |
| 17:31 | <JakeA> | I guess something like add-to-homescreen would be a signal there |
| 17:31 | <annevk> | yeah things like that |
| 17:31 | <annevk> | or use of the password manager or whatever |
| 17:32 | <annevk> | asking users about storage seems like a really dumb idea to me |
| 17:33 | <JakeA> | hmm, but telling developers "yeah we might dump all the data you told the user you'd make-work-offline, depends on heuristics" |
| 17:34 | <JakeA> | doesn't build trust in the web as a platform |
| 17:34 | <JakeA> | "If you want the data stored reliably, build a native app" etc etc |
| 17:34 | <annevk> | PhistucK guy o_O |
| 17:36 | <annevk> | JakeA: well, Alex' proposal was to ask applications to free up data |
| 17:36 | <annevk> | JakeA: and note that we're talking about filling up the entire disk here |
| 17:36 | <annevk> | JakeA: native apps have that problem too |
| 17:37 | <annevk> | JakeA: just typically there's enough storage space, not sure why that'd be less true here for the things users care about |
| 17:38 | <smaug____> | JakeA: btw, "take" is used some times to indicate a resource isn't available for other stuff |
| 17:39 | <JakeA> | annevk: I suppose the OS could ask the user to prioritise what I want to keep. If I got into space issues, I wouldn't want the browser to dump the 4gb of movies I wanted to watch on plane, rather than the combined 4gb of dumb games that I didn't even know were that large |
| 17:39 | <smaug____> | so perhaps takeAsJSON or such |
| 17:39 | <annevk> | JakeA: yeah, the OS/browser could ask the user the moment you run into the problem |
| 17:40 | <annevk> | JakeA: prolly listing the largest origins at the top |
| 17:40 | <JakeA> | smaug____: doesn't feel streamy, but it is shorter, which I like. The amount of fingerskin I lose over querySelectorAll… |
| 17:40 | <annevk> | then the user can make an educated decision |
| 17:40 | <JakeA> | annevk: yeah, that makes sense |
| 17:40 | <annevk> | the user can't really make an educated decision about bytes |
| 17:41 | <annevk> | that's from the old days, like how large you want to make a certain partition |
| 17:41 | <annevk> | brr |
| 17:41 | <smaug____> | consume doesn't sounds streamy to me ;) |
| 17:41 | <smaug____> | consume sounds like going to shopping something useless |
| 17:42 | <JakeA> | annevk: in the Chrome impl I think it talks in terms of "small" … "very large amount of space" to the user when it comes to permission. The wording can be judged by bytes & space available |
| 17:42 | <caitp-> | probably an apt analogy really |
| 17:42 | <JakeA> | annevk: but I'm happy to go with the "just take the space" approach |
| 17:44 | <JakeA> | smaug____: If I heard "I'm consuming", I would assume eating/drinking first. Is that a British thing? |
| 17:44 | <caitp> | http://en.wikipedia.org/wiki/Consumer |
| 17:45 | smaug____ | is not a native English speaker and has been horrified about climate change recently, so 'consume' has certainly some negative associations to him |
| 17:45 | <smaug____> | JakeA: btw, 'take' has been used elsewhere in the platform, http://dom.spec.whatwg.org/#dom-mutationobserver-takerecords |
| 17:45 | annevk | only cares about "body" |
| 17:45 | <smaug____> | not sure about consume |
| 17:45 | <annevk> | takeBodyAsJSON() |
| 17:45 | <annevk> | wfm |
| 17:45 | <annevk> | isBodyTaken |
| 17:46 | <JakeA> | caitp: consumer means shopping to me. But not the verb "consume". |
| 17:46 | <TabAtkins> | gsnedders: vh and vw are relative to the page box in paged media. |
| 17:47 | <JakeA> | annevk: I prefer take to consume. |
| 17:47 | <annevk> | JakeA: reply to WHATWG list? |
| 17:47 | <annevk> | nobody else seems to care so far today |
| 17:47 | <annevk> | at least not about that thread |
| 17:48 | <caitp> | whichever word you go with, you're going to have people who get it, and people who just scratch their heads and wonder how the heck anyone ever came up with a name like that |
| 17:49 | <annevk> | well they can look it up in the archives |
| 17:49 | <smaug____> | and blame me |
| 17:49 | <smaug____> | which is fine |
| 17:51 | <annevk> | smaug____: hard to attack a dragon |
| 17:52 | <annevk> | JakeA: I'll reply |
| 17:52 | <JakeA> | annevk: Just sent |
| 17:52 | <annevk> | ah k |
| 17:53 | <annevk> | thanks |
| 18:28 | <Domenic> | smaug____: ya streams spec is going to become more readable later. Algorithms are still going to specified in ES style, but they will be surrounded with enough useful padding and text. https://whatwg.github.io/streams/ is the skeleton for that |
| 18:33 | <TabAtkins> | Domenic: Out of curiosity, would it be possible to just write the algos in JS, with the appropriate wordsmithing to ensure you have the initial versions of built-ins/etc? |
| 18:36 | <Domenic> | TabAtkins: well, sorta. I use a lot of internal slots, and a few promise "macros". |
| 18:37 | <Domenic> | Also, some common algorithms get factored out into common abstract operations, and saying that those operations are "JS functions" has unwanted implications. |
| 19:40 | <gsnedders> | TabAtkins: okay, that's what I thought, which makes the caniuse note wrong |
| 19:45 | <annevk> | JakeA: for your TLS efforts you might want to read up on https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c50 and earlier/later comments |
| 19:47 | <annevk> | JakeA: Netflix is not really willing to entertain TLS for content delivery it seems |
| 19:58 | <Hixie_> | annevk: what're the use cases for the getBodyAsX methods? |
| 20:00 | <annevk> | Hixie_: to get access to the body of a response or request |
| 20:00 | <annevk> | Hixie_: e.g. what we have xhr.response for |
| 20:04 | <Hixie_> | annevk: isn't xhr.response enough? |
| 20:05 | <Hixie_> | TabAtkins: what do you think of a feature like <div needs="foo bar"> <script id=foo src=...></script> <link rel=stylesheet id=bar href=...>, where the <div> doesn't render until the dependencies are met? |
| 20:06 | <Hixie_> | TabAtkins: maybe with :ready and :loaded pseudos? |
| 20:21 | <annevk> | Hixie: oh well, it's also if a service worker gets a request, that it can ready the form data |
| 20:21 | <Hixie> | ready the form data? |
| 20:22 | <Hixie> | why would the service worker be sending back form data |
| 20:23 | <caitp> | why not |
| 20:23 | <Hixie> | i don't understand |
| 20:24 | <caitp> | I make a FormData and create some task which passes it to the service worker, who later ships it off at some scheduled time |
| 20:24 | <caitp> | why not |
| 20:27 | <caitp> | maybe the form data is the contents of an email that I wrote, but can't send right now because I'm in a train underground, and the service worker will try to get rid of it when it can 〜(￣▽￣)〜 |
| 20:27 | <Hixie> | i don't understand the relevance of what you're saying to what annevk and i are talking about |
| 20:27 | <caitp> | it's impossible to have total relevance because there's context missing |
| 20:28 | <caitp> | but based on the words you're using, there is a relevance |
| 20:28 | <Hixie> | oh well if we're just free-associating... |
| 20:28 | Hixie | wonders if maybe anne meant "read" instead of "ready" |
| 20:29 | <caitp> | no no, we aren't replacing words or meanings, we're using the words and meanings as they're presented, but without your context |
| 20:34 | <annevk> | Hixie: document has <form>, service workers wants to know what the user filled in |
| 20:34 | <annevk> | Hixie: oh yeah, read |
| 20:34 | <annevk> | my bad |
| 20:34 | <Hixie> | annevk: ok, i get the use case for service worker seeing the body of the request |
| 20:34 | <Hixie> | annevk: is the response case just redundant with xhr? |
| 20:35 | <annevk> | yeah I suppose, although you can have responses for <img href=crossorigin> although obviously reading those is not going to work |
| 20:35 | <annevk> | well |
| 20:35 | <annevk> | you might get a response out of a cache |
| 20:36 | <annevk> | and then read it for templating purposes |
| 20:36 | <annevk> | so I guess they really need it even if we only had XHR, and then fetch() is really nice glue to have as well, and covers the <img href=crossorigin> case |
| 20:42 | <annevk> | Domenic: https://github.com/slightlyoff/ServiceWorker/issues/372#issuecomment-52922105 reply by email doesn't really work it seems |
| 20:42 | <Domenic> | annevk: thanks... usually I just have to clean up everything after my comment, but this time I tried interleaving :( |
| 20:42 | <Domenic> | I think it depends on there being a "sent from my iPhone" or something. |
| 20:57 | <TabAtkins> | Hixie: I think the idea is intriguing, and might help with some of the FOUC issues that Web Components have. |
| 20:57 | <Hixie> | TabAtkins: k. i think i'm gonna shelve it for v2 for now, but keep it in mind when you read my upcoming epic |
| 20:58 | <Hixie> | TabAtkins: as it is written with that expansion path in mind |
| 20:58 | <TabAtkins> | Sure. |
| 21:00 | <Hixie> | Domenic: if i have an array of promises, and want a promise that's done when all of them are done, what's the magic word? |
| 21:00 | <Hixie> | i want, like, new Promise(promiseArray).then(function () { ... }) |
| 21:00 | <Domenic> | Hixie: Promise.all (PromiseAll in spec language) will work, assuming that if any of them fail you want the new promise to fail |
| 21:01 | <Hixie> | Promise.all(promiseArray).then(function () { ... }) ? |
| 21:01 | <Domenic> | yep. |
| 21:01 | <Hixie> | k |
| 21:01 | <Domenic> | you can get even get an array of results |
| 21:01 | <Hixie> | don't care about results |
| 21:01 | <Hixie> | :-) |
| 21:01 | <Hixie> | the result is success/fail |
| 21:01 | <Domenic> | horse_#whatwg |
| 21:02 | <caitp> | that's not what you were saying the other day, I thought you were saying you just wanted the all promise to succeed, but without the rejected intermediate one |
| 21:02 | <caitp> | succeed/be fulfilled |
| 21:03 | <Hixie> | this may come as a surprise, but sometimes i want different things |
| 21:03 | <Hixie> | for example in the morning i want breakfast, but at night, dinner! |
| 21:07 | <TabAtkins> | I don't understand. With pizza on a bagel, you can have pizza anytime. Why would you want anything different based on time of day? |
| 21:07 | <Domenic> | ^ that |
| 21:12 | <caitp> | heh, I don't keep up with all of the different promise needs of different people, that would be too much! so when I see you talking about flow control concerns with Promise.all twice in the same week, my general assumption is that you're still talking about the same thing and thus want the same outcome |
| 21:13 | <caitp> | so yeah it's a bit surprising, if I had the ability to keep track of everyones issues simultaneously it would be easier ;) |
| 21:50 | <Hixie> | hmm, i wonder how exciting it will be to set document.currentScript correctly for modules |
| 21:53 | <Domenic> | modules aren't scripts, so no need? :) |
| 21:54 | <Hixie> | it'd be unfortunate if you couldn't do: |
| 21:54 | <Hixie> | <div> |
| 21:54 | <Hixie> | <script type=module> |
| 21:54 | <Hixie> | import "myrelevantmodule"; |
| 21:54 | <Hixie> | document.currentScript.parentNode.className = 'ready'; |
| 21:54 | <Hixie> | </script> |
| 21:54 | <Hixie> | ...and so on |
| 21:54 | <Domenic> | i really don't think that'd be unfortunate. |
| 22:08 | <Hixie> | Domenic: why not? |
| 22:08 | <Hixie> | Domenic: how else would you get at the <div>? |
| 22:08 | <Hixie> | Domenic: the only thing that distinguishes it from all the other dics is that this is the one that contains your specific <script> |
| 22:09 | <Hixie> | divs |
| 22:09 | <Domenic> | Hixie: yes, in general, if you don't add identifiers to a thing, then you can't get to it. Just because this one happens to contain your script doesn't make it special. |
| 22:09 | <Philip`> | <div id=theonethatcontainsmyscript>? |
| 22:10 | <Hixie> | having to use globally-unique IDs is an order of magnitude more annoying than just being able to refer to the current script block |
| 22:10 | <Hixie> | you have to start worrying about ID collisions, about poluting the ID namespace, etc |
| 22:12 | <Domenic> | If it's actually important to refer to the current script block, then you'll do it. |
| 22:12 | <Domenic> | Just like if it's important to refer to any other element. |
| 22:13 | <Hixie> | i don't understand the problem with currentScript |
| 22:13 | <Hixie> | it seems like a net win to the engineering environment |
| 22:14 | <jgraham> | Is it a thing that currently exists and that people use? |
| 22:14 | <Ms2ger> | I believe it exists in Gecko |
| 22:17 | <Hixie> | currentScript? yeah |
| 22:18 | <jgraham> | On an entirely different subject I am rather against the name consimeAsJSON(). I think it falls into the API design flaw where you have a design choice to make in the API, which therefore seems important to you, and you signal in the name of the API functions the choice that you made. But to a user of the API it's unimportant noise because you made a consistent choice so it's just making you type out something "obvious" |
| 22:18 | <jgraham> | *consumeAsJSON() |
| 22:19 | <jgraham> | Like if you has a language with immutable strings and you added a method appendAsNewString() |
| 22:21 | <Hixie> | you mean as opposed to just .asJSON() ? |
| 22:24 | <jgraham> | Yes |
| 22:24 | <Hixie> | the problem with .asJSON() is that it already means something in the platform. It means, "copy this into a JSON form". |
| 22:26 | <Hixie> | hm i guess that's toJSON() |
| 22:27 | <jgraham> | Honestly I would prefer response.body.json() if possible |
| 22:28 | <Hixie> | i don't really understand why we're not using xhr |
| 22:28 | <jgraham> | response.body.json(), response.body.text(), response.body.consumed |
| 22:47 | <Yuhong> | msg NickServ identify asdasd |
| 22:58 | <TabAtkins> | The NickServ identification method is not very safe. :/ |
| 23:05 | <slightlyoff> | My proposal was to ask and *then* evict if you don't get enough back |
| 23:11 | <TabAtkins> | slightlyoff: ????? |
| 23:13 | jgraham | resolves to avoid becoming slightlyoff's tenant |
| 23:14 | <jamesr__> | jgraham: thankfully slightlyoff lives in a place where eviction is basically illegal |