2014-07-01 [17:10:07.0000] Apparently web-platform-tests differs with the HTML standard about whether input type="email" should be selectable? https://github.com/tmpvar/jsdom/pull/804#issuecomment-47602028 [18:20:57.0000] "a principled stance" is a fascinating phrase (assumes that the speaker's set of principles are the only valid ones) [21:02:09.0000] this whole TAG thing is pretty hilarious [21:02:23.0000] i love that all these people think they can only contribute if they're in the TAG [21:03:00.0000] /me suits up in his tag [22:36:26.0000] Hixie: TAG in general or did they make some statement? [00:11:52.0000] cabanier: see www-tag [00:33:18.0000] zewt: no it does not assume that [00:33:36.0000] zewt: I haven't read yet the context but in general it doesn't imply that at all [00:33:52.0000] zewt: in fact it often implies the opposite [00:35:29.0000] zewt: it's often used to acknowledge that while you disagree with someone else's argument, you respect the position they've taken on it as being one based on principles, though you may disagree with the priorities of those principles over other concerns, or with the principles themselves [00:36:56.0000] Domenic: if the tests differs from the spec then it should be raised as an wpt issue and/or as a PR [00:37:41.0000] Domenic: ah I see you already said as much in the issue thread [00:43:44.0000] MikeSmith: as in a "wow they're really sticking to their principles" type of thing? [00:57:58.0000] Domenic: If the spec and the tests disagree it's presumably a bug in the tests. [00:58:26.0000] Oh, MikeSmith just said that [00:58:47.0000] I should apparently not read a randomly selected subset of the scrollback [01:23:22.0000] MikeSmith: I opened https://github.com/masinter/multipart-form-data/issues/17 [01:23:39.0000] I'll also watch the repository for a bit [01:26:44.0000] SamB: Well, in fact chrome. I think it makes sense to develop more of the web platform in javascript. From low-level primitives given from the engine c++ land. [01:45:30.0000] annevk: gool [01:45:43.0000] erp cool [01:46:47.0000] Oh, I assumed that was an unlikely typo for "good". Although now it sounds like some sort of football celebration [02:01:53.0000] I thought it was a reference to https://twitter.com/hober/status/483296410108833793 & https://twitter.com/hober/status/483296772941283328 [02:40:04.0000] "Web Components as currently designed cannot explain the behavior of any built-in elements (except maybe those which can be explained with CSS alone)." [03:07:55.0000] annevk: body.asJSON - we decided they consume the stream rather than tee it, right? Was there a reason for that? Maybe it should tee. [03:21:12.0000] JakeA: as*allthethings don't tee [03:21:22.0000] JakeA: elaborate? [03:22:47.0000] annevk: If they tee, you can call them multiple times, or call asBlob then asText. I'm not sure it's intuitive that they're one-off at the moment. What's the advantage? [03:23:16.0000] JakeA: you don't have to keep the response around [03:24:54.0000] annevk: I can see that being an issue if the object is kept in reference long after calling asWhatever, not sure that's likely though [03:26:00.0000] The design of responseType / response on XMLHttpRequest was exactly because of this [03:26:38.0000] The original design of having both responseText and responseXML was a memory issue, and that's why we didn't add responseBlob [03:33:42.0000] annevk: adding responseBlob wouldn't have added extra memory overhead though, the blob would have been constructed as part of the getter right? [03:34:21.0000] JakeA: the problem was that you could never toss away the original bytes if someone e.g. had already asked for responseText [03:35:41.0000] JakeA: if streams support something like tee(), then subclasses of streams will too, and you could just do .body.tee().asText() [03:37:07.0000] annevk: Yeah, I get the original bytes thing, I didn't realise that'd be a huge problem as the object is likely to get gc'd shortly afterwards anyway. But yeah, body.tee().asText() seems fine. [03:39:55.0000] I think people are rightly concerned about memory usage. If we offer a low-level API such as this it seems good to make that usage explicit. [03:40:22.0000] We will need to support a tee operation, there's numerous places that require tee/copy [03:40:41.0000] slightlyoff: see above. [03:40:46.0000] E.g. the stream that is passed to fetch()'s Request object will need to be teed [03:40:47.0000] Yeah, makes sense [03:40:58.0000] tee'd? [03:42:32.0000] JakeA: we are going to rename navigate to "topframe" and "child" to "frame" most likely [03:42:35.0000] JakeA: see https://www.w3.org/Bugs/Public/show_bug.cgi?id=26247 [03:43:18.0000] jungkees: ^^ [03:46:12.0000] annevk: feels like we need a "navigate" helper to cover "topframe", "frame" and "popup" [03:47:02.0000] since navigates are the cases you'd want to provide a "no connection" fallback page, or something [03:47:14.0000] JakeA: https://github.com/slightlyoff/ServiceWorker/issues/345 [03:47:33.0000] JakeA: "client request" was that term [03:48:59.0000] JakeA: as you demonstrate, "navigate" makes you forget about workers [03:49:51.0000] annevk: that was deliberate, in this case [03:50:10.0000] annevk: I wouldn't want to serve up a "Sorry no connection" page in response to a sharedworker request [03:50:59.0000] annevk: But I understand why sharedworkers are in that grouping, as they can make requests themselves [03:51:23.0000] isNavigateRequest, isClientRequest could be on Request I suppose [03:51:44.0000] Or on FetchEvent, depending on where context/client end up [03:52:53.0000] We also haven't really dealt with yet [03:53:14.0000] annevk: - is this a client request? [03:53:22.0000] I guess not [03:53:33.0000] no [03:53:47.0000] but will requests triggered by whatever.svg go through the page's SW, and are we leaking by doing so? [03:53:59.0000] client requests and resource requests are mutually exclusive [03:54:01.0000] I guess it's the same as CSS at that point [03:54:07.0000] (except maybe for , which does both...) [03:54:41.0000] if you load an SVG as an image it cannot do any further fetches [03:54:41.0000] annevk: hopefully we can reuse a lot of appcache's mess when it comes to [03:54:53.0000] annevk: ah, phew, problem solved [03:55:10.0000] (at least not network fetches) [03:57:03.0000] is there a term to describe something that looks like trolling but may not be motivated by trolling intent? [03:58:25.0000] like appealing to the behavior of "newer browsers" when requesting a spec change and giving Emacs Web Wowser as an example of such a newer browser [03:58:45.0000] pedant [03:58:54.0000] Doesn't sound like pedantry [03:59:11.0000] Sounds like being divorced from the real world [04:00:55.0000] /me finds phantasmagoric [04:01:27.0000] That's some phantasmagoric shit right there [04:02:02.0000] JakeA: maybe we should just not do the weird thing appcache did and always route them through the SW? [04:02:48.0000] meh [04:02:50.0000] hard [04:06:32.0000] annevk: which SW? [04:07:12.0000] annevk, JakeA: please don't call it tee(), though [04:07:19.0000] annevk: the page's or the one that would be used if it were a navigation [04:08:43.0000] JakeA: the page [04:09:20.0000] JakeA: although I guess sometimes you do know upfront the page wants to navigate [04:09:46.0000] JakeA: well, does ... work? would need to test :/ [04:16:08.0000] annevk: thanks for the pointer. will keep an eye on it [04:24:30.0000] annevk: you might be interested in https://bugzilla.mozilla.org/show_bug.cgi?id=1003716 [04:24:54.0000] particularly, exposing menus that have items for both ISO-8859-1 and windows-1252 to the user [04:25:04.0000] even though both encode and decode the same [04:25:21.0000] so it's basically exposing the decision of which label to put in email headers to the user [04:25:26.0000] which is sad UI [04:25:44.0000] I'm not sure if I have the stamina to bikeshed that one anymore [04:27:08.0000] (Thunderbird has code that specifically picks the windows-1252 encoder even if the outgoing encoding is ISO-8859-1, which is a distinc encoding internally in Gecko, still) [04:31:14.0000] hsivonen: why do they even expose technical terms to end users? [04:46:28.0000] annevk: so the page SW would control the load of the document, but what about the subresources? Through the child document's SW? [05:17:11.0000] JakeA: hmm yeah, would have to do some more digging as to how that entire thing is setup [05:19:30.0000] hsivonen: fwiw, I do think that new software should use the Encoding Standard, otherwise we get into the situation where for each format there's a debate about whether the Encoding Standard can be a normative reference [05:19:49.0000] hsivonen: which would just suck and complicate everything for no good reason [05:59:31.0000] annevk: if all new software will use the Encoding Standard and non-UTF encodings will be allowed then you will loose interop with existing encoding libraries in JDK/.NET/iconv/... [06:03:53.0000] Jirka_: yes [06:06:08.0000] it's not really losing interop if they didn't have interop with each other in the first place [06:10:24.0000] annevk: What about spliting the Encoding Standard into two documents -- one will define only UTF-8 related stuff and JS APIs and second will define how to handle legacy web resources in non-UTF encodings. Any new software will be then built on top UTF-8-only Encoding Standard, no need to deal (and possibly create confusion) with legacy encodings [06:12:22.0000] yeah you can never have to many documents to not read! [06:12:32.0000] oh man, typo ruined sarcasm =( [06:12:34.0000] if people won't follow a simple "only use utf-8" instruction, breaking specs apart isn't going to help--and it's a pain in the ass to do, for everyone involved [06:13:48.0000] Jirka_: I don't really see what problem that solves [06:13:52.0000] Does this make sense: [06:13:56.0000]

To byte lowercase a byte sequence, means replacing any byte in the range [06:13:56.0000] 0x41 to 0x5A of the byte sequence with their corresponding byte in the range 0x61 to 0x7A. [06:14:05.0000] s/means replacing/replace/ [06:14:09.0000] also it seems like the entire point of "new software should use this spec" is exactly *for* legacy encodings ... interop on utf-8 itself isn't a problem [06:14:34.0000] there's some interop problems around utf-8, but yes [06:14:40.0000] annevk: makes sense but does require interpretation [06:15:02.0000] should I do s/their/the/? [06:15:11.0000] the only interop issue with utf-8 i've really seen is overlong sequences, and that's uncommon [06:15:46.0000] I'm not talking about 5/6 byte sequences, but amount of U+FFFD emitted during error handling [06:16:18.0000] annevk: s/their/the/ is what I was going to suggest [06:16:21.0000] could say something like "adding 0x20 to any byte of the byte sequence in the range 0x41 to 0x5A" [06:16:41.0000] that might be better [06:16:43.0000] thanks [06:17:09.0000] is it clear that it's an inclusive range [06:17:19.0000] (aside from "duh") [06:18:37.0000]

To byte lowercase a byte sequence, increase each byte it contains in the range 0x41 to 0x5A by 0x20. [06:18:40.0000] annevk: current reading of the Encoding Standards and legacy encodings seems to cover all usages of legacy encodings and not only those on the web. [06:18:59.0000] zewt: yeah, I need to clarify that at some point, that's a bigger issue though :/ [06:19:13.0000] Jirka_: yes that is intended [06:20:00.0000] Jirka_: it would be weird to allow some CSS or XML to be interpreted in different ways [06:20:02.0000] i imagine there are many encodings that exist but which aren't used on the web, in which case they wouldn't be in the encoding spec (but I guess if that's a problem for some cases they could write a spec for just those encodings) [06:20:29.0000] (that are used, not just exist) [06:22:43.0000] It would be a problem if they leak, which is why I think protocols and formats ought to be based on the Encoding Standard or only allow utf-8 [06:22:45.0000] heh i think ircd does case-insensitive comparisons with just chr | 0x20, since iirc it treats { and } as equal to [ and ] for nicks [06:22:52.0000] (and then the flavor of utf-8 defined by the Encoding Standard) [06:23:03.0000] annevk: IMHO legacy encoding in CSS could (and should be) handled in the same way as in HTML. However for legacy encodings XML parsers in browsers are not interoperable -- neither between some browsers not with non-browser implementations [06:23:20.0000] (not aware of there being multiple "flavors" of utf-8) [06:23:33.0000] Jirka_: browsers are not always interoperable either when it comes to encodings, I would consider all that to be a bug [06:23:45.0000] zewt: error handling issue mentioned above [06:30:22.0000] zewt: iirc there are bits reserved for application-specific purposes which might be accidentally transmitted and understood differently by different agents --- I can't recall what that's called, though. so you could think of that as "different flavours" [06:30:35.0000] i'd call that "not utf-8 at all" [06:30:55.0000] well, it's not meant to be exposed to anyone outside of the application, that's for sure =) [06:31:22.0000] just think of it as utf8 with some extra bonus garbage [06:31:23.0000] I'm not talking about CESU-8 or variants of that [06:31:24.0000] not aware of any "reserved bits" in utf-8, either [06:31:34.0000] CESU-8, that sounds like what I'm thinking of [06:33:52.0000] i wonder if it's possible to satisfy the FFFE definition (efficiently) while seeking backwards in utf-8 [06:34:03.0000] guessing not [06:36:00.0000] actually you probably could... that is, generate FFFEs without having to seek backwards without bound to figure out how many to generate (but you don't actually need to know how many, only whether you should be generating one more or not) [06:39:27.0000] zewt: (JNI has its own special UTF-8 - http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/types.html#wp16542) [06:39:52.0000] that's also just Not UTF-8(tm) [06:39:58.0000] /me has no idea how likely that is to leak out in the external world [06:41:42.0000] it's not the greatest encoding in the world, it's just a tribute [06:54:24.0000] annevk: In APIs like thingOfThings.create(newThingName), if newThingName already exists, do we generally throw or return the existing thing? [06:54:36.0000] In idb it throws. Any other cases? [06:55:25.0000] annevk: Going to change the caches API. Rather than caches.add(name, new Cache(...)) it'll be caches.create(name).then(function(cache) {}) [06:55:46.0000] Trying to work out what's best if the cache already exists [06:55:52.0000] Create not creating seems pretty confusing [06:57:30.0000] (if you called it "set" it would be less confusing) [06:57:36.0000] I guess if you want the get-or-create behaviour it's caches.get(name).catch(e => caches.create(name)) [06:58:23.0000] Actually I guess it wouldn't [06:58:29.0000] JakeA: well e.g. createElement() would always succeed [06:59:08.0000] annevk: yeah, but what about where the name is unique (like caches or idb databases) [06:59:17.0000] JakeA: throwing or overwriting seems expected from maps? [06:59:23.0000] Yeah, there isn't much precedent on the platform for having this kind of datastructure [07:00:06.0000] Right, I was assuming that overwriting wasn't sensible for some reason [07:00:30.0000] if it is, then I would really expect that [07:01:41.0000] Yeah, that works pretty well. So caches.create(name) would replace 'name' with an empty cache even if one existed [07:02:20.0000] JakeA: if it's a map, maybe just name it set then [07:02:31.0000] JakeA: although at that point you're back at add() :p [07:02:48.0000] It's an async map, right? [07:03:25.0000] Only not quite [07:03:25.0000] jgraham: Sorta, but we're not defining an async map type [07:03:35.0000] It's an async default map [07:03:59.0000] JakeA: Well you are, just in DOM rather than ES [07:04:03.0000] Which is fine [07:04:34.0000] Here's the pattern I'm looking at https://gist.github.com/jakearchibald/69bdd0c49d205717963e [07:06:02.0000] "set" doesn't feel right. I'd expect "set" to take two args, key & value. [07:07:52.0000] Yeah, I agree [07:08:21.0000] This is doing special magic with the key to implicitly create a value [07:08:37.0000] Or maybe not with the key [07:08:55.0000] I don't think there's any magic [07:08:58.0000] it's just the key [07:09:05.0000] it's not like createElement [07:09:29.0000] caches.create(name) caches.get(name) caches.delete(name) [07:09:41.0000] it's most similar to idb's create database method [07:10:19.0000] (which throws if a database of that name already exists, so we could do the same as that, but I'm not convinced idb is a great thing to copy) [07:10:21.0000] Sure. I just mean that it's not a generic operation, it's specific to this particular type of object [07:10:38.0000] yeah [07:12:09.0000] (or, I guess, it is probably something that *could* be applicable to many types of objects, but you would need some kind of protocol for specifying the code that create() runs to generate a value. Which doesn't seem worth abstracting out) [07:14:18.0000] JakeA: so is it a map or a set of caches? [07:16:08.0000] annevk: IAFAICT it's an (async) map of caches [07:16:14.0000] *AFAICT [07:16:24.0000] oh right, name -> cache [07:16:33.0000] sorry [07:16:52.0000] so yeah, create makes sense [07:17:10.0000] annevk: What jgraham said, although all values are forced to be caches, all keys are forced to be strings, uniqueness is enforced in values [07:17:42.0000] I think following IDB and throwing is fine for duplicates, provided there's has() [07:17:56.0000] You probably don't want to accidentally erase a bunch of resources [07:18:11.0000] JakeA: please do respond to the various issues open against this API btw [07:18:14.0000] annevk: Problems with the current API: var myCache = new Cache(); caches.add('foo', myCache); caches.add('bar', myCache); [07:18:20.0000] JakeA: especially the one about it having the wrong name [07:18:59.0000] JakeA: what if instead you did it as new Cache(name) [07:19:07.0000] JakeA: and then cache.add(myCache) [07:19:14.0000] and then cache.getByName(name) [07:19:32.0000] so it's a set with identifiers on the objects [07:20:14.0000] and add() would simply throw if either cache or name was already present [07:21:29.0000] annevk: Yeah, aware of the wrong name one. Not convinced "cache" is bad, but not strongly opposed to changing it. [07:21:58.0000] I think the argument from Brendan about Cache not being persistent is quite persuasive [07:22:10.0000] yeah [07:25:27.0000] annevk: So, var myCache = new Cache("static-v1"); caches.add(myCache); caches.getByName("static-v1")? That solves the unique issue, but feels weird being able to create these cache things without them being part of the thing that persists them. [07:26:19.0000] Although I suppose that's true of blobs & idb too, but I don't think a cache is useful outside of caches [07:32:19.0000] annevk: just saw https://twitter.com/annevk/status/483974642336825344 [07:32:35.0000] ugh [07:32:41.0000] heh, that's what I said [07:33:33.0000] I'm not aware of the consensus here [07:33:33.0000] JakeA: so with this you could imagine transferring the Cache() between apps [07:33:54.0000] JakeA: you can transfer it between domains even if we support cloning on it [07:34:40.0000] annevk: Transferring between apps? Something like caches.copy(name, otherName)? [07:34:49.0000] It seems like you need Cache to exist as an object either way [07:35:08.0000] now like otherapp.postMessage(cache) [07:35:11.0000] s/now/no/ [07:35:28.0000] potentially otherapp.postMessage(cache, [cache]) if we support transfering [07:36:25.0000] caches.get(name).then(function(cache) { otherap.postMessage(cache); }) [07:37:48.0000] yeah [07:39:48.0000] annevk: That's already possible in the .create & .get model, but if you got a cache via postmessage you wouldn't be able to get it back into caches. Hmm. [07:41:18.0000] I kind of like what I proposed above [07:41:57.0000] var files = new Cache(files); caches.add(files, ...) [07:42:37.0000] new Cache("files"); right? [07:47:17.0000] i agree that that is a bit weird ... not horrible though [07:47:40.0000] Domenic: what is? [07:47:41.0000] what is the problem with caches.set('name1', c); caches.set('name2', c) ? [07:48:00.0000] JakeA: var c = new Cache('name'); caches.add(c); seems a bit weird, but not horrible. [07:48:29.0000] JakeA: yes [07:49:20.0000] Domenic: having some caches be === feels complicated and unuseful [07:49:48.0000] JakeA: that's not my mental model. My mental model is there's still only one cache object, but it got put in two entries in the cache-map [07:50:09.0000] JakeA: the same as `var x = {}; var m = new Map(); m.set('key1', x); m.set('key2', x);` [07:50:22.0000] is that the wrong mental model? [07:50:43.0000] Domenic: No, but is there anywhere else we do that with permanent storage? [07:51:17.0000] JakeA: I dunno, but, is caches really a permanent storage model, or is it an async map? [07:51:34.0000] that is, when you store something in caches, do you serialize it? [07:51:48.0000] i think serialization is what draws the line for "permanent storage" vs. "async map" for me [07:52:05.0000] annevk: it seems with |var files = new Cache(files); caches.add(files, ...)|, we would still might want to store stuff to disk even if it hasn't been added to caches yet [07:52:22.0000] annevk: otherwise someone could add many large resources to the cache and we would have to maintain them all in memory [07:52:54.0000] Yes, wanderview makes a good point... at what point do things get put into disk vs. in-memory? [07:53:35.0000] I could see that as a common footgun too... new Cache, add all my resources, put in caches at the end [07:53:55.0000] well, until it gets GC'ed, I can't imagine ever being able to evict them from memory... [07:54:06.0000] just saying that you put it on disk doesn't mean it can move out of memory [07:55:16.0000] Domenic: can't we stream the resources to disk and only read into memory if there is an outstanding Promise? [07:55:33.0000] At the moment, in the current API: var cache = new Cache(); cache.add(things...); [07:55:45.0000] I'd expect stuff to be written to disk because of the memory issue [07:56:03.0000] but if that isn't added to `caches`, it'd be deleted when `cache` is gc'd [07:56:15.0000] JakeA: yea, I think thats possible, but its a bit of a complication to clean up the filesystem on GC I think [07:56:41.0000] The caches.create('name').then(c => c.add(things...)) model prevents that [07:56:49.0000] wanderview: if the things you add to the cache are accessible as local variables in JS anyway (including temporary ones), you can't remove them from memory until they get GCed ... right? [07:57:37.0000] Domenic: I guess I was thinking of the cache.add(requests...) case... where content is pre-loading the cache and not explicitly waiting for the response [07:57:39.0000] JakeA: OK, that is helpful. So we are saying in-memory caches are not useful? Or are we saying that new Cache() would still work, but caches.create('name') is a way of getting one that is synced to storage [07:57:51.0000] Although there's still cache.get('name').then(function(cache) { caches.delete('name'); }) [07:58:07.0000] So deleting from disk on gc is still needed [07:58:18.0000] JakeA: for testability if nothing else I would think in-memory caches are useful. [07:58:27.0000] unless we can put cache objects in some kind of "disabled" state [07:58:33.0000] this is going down a dark path [07:58:51.0000] JakeA: or we replace caches.delete() with cache.deleteFromCaches() or something... but thats kind of ugly :-( [07:59:30.0000] wanderview: that doesn't help, cache still exists in memory. [07:59:44.0000] wanderview: unless deleteFromCaches() also puts it in some sort of disabled state [07:59:54.0000] the disabled state thing feels ugh [08:00:00.0000] wanderview: hmm, don't we have an equivalent problem with new File() or new Blob()? [08:00:01.0000] yes please don't, if possible [08:00:12.0000] I think dealing with the GC file eviction is required [08:00:24.0000] annevk: yea, maybe its not the problem I think it is [08:00:34.0000] (brb, meeting) [08:00:42.0000] its a complication, but probably a solved one [08:01:16.0000] why is it caches.each() instead of caches.forEach() O_O [08:01:54.0000] Domenic: the browser might serialize it [08:02:13.0000] annevk: can't tell what that's in response to [08:02:14.0000] question... var c = new Cache(); c.add(requests...); without putting in caches count against the origin's disk quota? [08:02:19.0000] Domenic: or try to keep it alive in some other way [08:02:43.0000] I think it must as we will want the flexibility to save to disk at any time... just wanted to clarify since we were talking about "memory only" cache objects [08:02:46.0000] Domenic: the cache API is a permanent storage model (and therefore has the wrong name) [08:03:09.0000] annevk: is the cache API permanent, or is the caches API permanent? [08:03:31.0000] well only caches is something that survives a reboot [08:03:41.0000] wanderview: I think that makes sense, as long as the programmer's mental model is that it's entirely in-memory until explicitly saved? [08:04:28.0000] each vs. forEach filed https://github.com/slightlyoff/ServiceWorker/issues/351 [08:05:31.0000] Domenic: hmm... I guess I was trying to say I will want to write to disk immediately to allow us to GC memory when possible, so not sure we are on the same page... what is the "explicit save" step in your view? [08:05:46.0000] wanderview: well from my perspective that's what's being discussed in this chat :) [08:06:04.0000] wanderview: so e.g. in the existing `var c = new Cache(); caches.set('name', c)` API, the `caches.set()` step saves to disk [08:06:20.0000] wanderview: whereas in the `caches.create('name').then(c => ...)` API, it is created-and-saved in the same step [08:06:26.0000] although "saved" is the wrong word [08:06:39.0000] more like... "made into something that is backed by persistent storage" [08:07:01.0000] versus in-memory only (from the programmer's point of view, even if the implementation puts some stuff on disk for its own reasons) [08:07:24.0000] the `var c = new Cache(); /* never store it in caches */` usage would be "in memory only" and useful for testing and such. [08:07:36.0000] Domenic: hmm, so in that case it would *not* count against quota until the caches.set() [08:08:00.0000] I think so, yeah... if that works from a disallowing-abuse POV [08:08:10.0000] or maybe there are separate temporary and persistent quotas [08:08:29.0000] Cache should use the same quota as Blob I suppose [08:08:43.0000] but I can see how it all gets rather tricky :/ [08:09:04.0000] Domenic: I guess I just worry about people waiting to call caches.set() at the end in order to avoid a partial cache object [08:09:40.0000] annevk: agreed, same as Blob makes a lot of sense... [08:09:44.0000] I'm sure we can make it work [08:09:54.0000] wanderview: well, I think a caches.create('name') API would mitigate that [08:10:03.0000] the constructor could be a lower-level API used by unit tests and such [08:10:19.0000] whereas the best practice if you want a persistent cache would be caches.create [08:10:24.0000] Domenic: yea, I guess its an education issue (although at some point those become footguns) [08:10:58.0000] At this point it all makes sense in my head; curious what JakeA thinks :) [08:11:23.0000] Domenic: what is the advantage of memory-only for testing vs. what we recommend for production use? [08:11:40.0000] Domenic: will read through when this meeting is done (yey for meetings) [08:12:51.0000] wanderview: if you are not very careful, you will fill up your persistent storage with repeated unit-test data [08:13:15.0000] good point [08:37:03.0000] I emailed the HTTP WG about an issue... but why? *cries* [08:39:02.0000] it's going to be okay anne [08:41:36.0000] caitp: that's what they said last time [08:56:55.0000] Domenic: so this "save" is kind of like migrating stuff from /tmp or /var/cache to /var/lib ? [08:57:22.0000] SamB: from my perspective as a JS developer /tmp is an implementation detail of the browser [08:57:28.0000] SamB: it could be in-memory for all I care [08:57:41.0000] /tmp CAN be in-memory [08:57:47.0000] anyway this is a metaphor [08:57:48.0000] yes, well, there you go [08:57:56.0000] the only observable thing (as far as I can tell) is whether the data survives a reboot [08:59:10.0000] and naturally, JS apps don't really get to complain if data turns out to survive that they wouldn't have expected to survive, right? [08:59:25.0000] well, it should not observably survive [08:59:29.0000] hmm [08:59:42.0000] Domenic: is there a document that explains why we don't want to expose promise state? [09:00:05.0000] so maybe not the /var/cache part then; that can only *theoretically* get nuked, afaict [09:00:27.0000] I mean, stuff is still supposed to work if you nuke it, but I've not heard of any automatic process which would nuke it [09:01:15.0000] annevk: hmm. we don't want to expose, or we don't want to allow external modification of? [09:01:51.0000] Domenic: don't expose I guess [09:02:36.0000] annevk: I don't think exposing is bad. Several promises libraries have promise.inspect() that returns e.g. { state: "fulfilled", value: [whatever] } [09:02:50.0000] the use cases are dubious however [09:03:03.0000] i guess it kind of encourages zalgo code? [09:03:28.0000] if (promise.inspect().state === "fulfilled") { runUserCodeWith(promise.inspect().value); } else { promise.then(runUserCodeWith); } [09:03:36.0000] zalgo in action [09:14:33.0000] ta [09:47:45.0000] Domenic: re each vs forEach, we didn't want to use a name that may be taken by asyncmap, as the behaviour of cache.each may differ [09:48:04.0000] Oh you made a ticket [09:53:13.0000] annevk: Domenic: exposing promise state would have helped in this case https://github.com/jakearchibald/trained-to-thrill/blob/master/www/static/js/app.js#L64-74 - means I wouldn't need showingLiveData. [09:54:22.0000] Domenic: Done the read-back. Are you suggesting `caches.create('name')` work, but also `new Cache()`? [11:05:32.0000] JakeA: yes, I think so, at least. new Cache() is in memory; caches.set('name', c) and/or c.makePersistentVia(caches) makes c persistent; caches.create('name') combines the two at once as a sugar layer [11:06:39.0000] JakeA: maybe file a bug on the promise spec? [11:06:49.0000] Domenic: we need to start thinking about ES7-promises [11:07:06.0000] Domenic: at least finally, we should add finally [11:07:11.0000] annevk: agreed on that one [11:07:35.0000] annevk: I can have an extension spec written up as an "ES7 track proposal" for next TC39; if everyone likes it then everyone can implement it ASAP. [11:07:47.0000] (ES is a living standard; they just don't know it yet.) [11:08:09.0000] Domenic: sgtm (is that enough? :p) [11:08:17.0000] :P [11:08:41.0000] JakeA: I'm not sure the code would look *that* much better. I dunno, it's pretty rare. Perhaps more common than Promise.race, I'll grant you. [11:26:14.0000] http://annevankesteren.nl/2014/06/vats now with analogies [11:27:40.0000] _win 30 [11:34:47.0000] "ES is a living standard; they just don't know it yet" <- i wish it was that simple :-) [11:38:07.0000] From the perspective of implementers, it's pretty close. [11:38:14.0000] the messaging is all screwed up [11:38:34.0000] but there are "ES7" things that are shipping, and "ES6" things that are nowhere near done or even started on implemnetatios [11:38:47.0000] and those ES7 things are locked whereas the ES6 things change all the time [11:39:01.0000] So stability is directly proportional to shipping or not [11:39:16.0000] and people are starting to realize this [11:41:22.0000] Domenic, people *here* know that ;) [11:42:27.0000] annevk: those are good analogies [11:42:38.0000] it's definitely not a living standard in the HTML sense from the perspective of implementors, in my experience [11:42:57.0000] i've asked implementors "how about we add foo to ES" and they say "we can'd do that now, because ES is frozen" [11:42:57.0000] I feel like implementers are coming around. I might be over-optimistic.\ [11:43:06.0000] O_O [11:43:07.0000] Domenic: I love talking to Allen [13:04:04.0000] How do I create WebIDL "mixins" that don't appear in proto chains or on the global? Is it just [NoInterfaceObject] + always use implements, not : ? [13:06:51.0000] Correct [13:07:16.0000] The former for "on the global", the latter for "in proto chains" [13:10:42.0000] annevk: I know Dominic Clooney well enough to know that he wasn't trying to be contemptuous or dismissive in that bug comment [13:10:54.0000] https://code.google.com/p/chromium/issues/detail?id=389124#c8 [13:15:01.0000] annevk: I think he should have used different words there but I don't think his comments are indicative of trying to blow anything off [13:17:52.0000] MikeSmith - sorry I don't buy that. The very phrase "the consensus within Google" should NEVER be used to justify anything standards related. [13:18:03.0000] such a phrase is *political* not technical and is not helpful [13:18:35.0000] I got a bit pissed because various times I have heard about Google discussing things internally about service workers / fetch that are relevant to everyone in the community [13:18:49.0000] it also implies that there is a "internal standards process" at Google that happens before they send someone to "litigating" their work outside. Also a very poor choice of word. [13:19:05.0000] that kind of delayed open behavior is unacceptable [13:19:15.0000] so it's right for annevk to call them out on it [13:19:30.0000] annevk - you're right to be pissed. [13:19:49.0000] those that behave that way at Google have a cultural problem that is antithetical to open standards development. [13:20:02.0000] it's fine to "vet" or "double-check" ideas privately, with colleagues, co-workers etc. [13:20:15.0000] but any kind of "consensus" discussion should happen in an open space [13:21:10.0000] MikeSmith - I accept that there is no ill will. That's not the problem. The problem is one where individuals like in that thread don't even realize that their behavior (perhaps learned from internal culture) is antithetical to open standards development [13:44:38.0000] tantek: yeah like I said, I think he could have used some better words there. And yeah I think what he describes is probably not the process that's likely to produce the best results [13:45:19.0000] yeah. it however seems to shed light on what may be standard procecdure behind Google's walls. that's the larger concern [13:46:21.0000] I think it's somewhat OK to put the job of interfacing with the wider world on one person's shoulders [13:46:37.0000] Some people are intimidated by standards lists etc. [13:49:44.0000] position: sticky is gone from Blink? Bad for mobile perf? [13:51:26.0000] Domenic: I think most people are intimidated by standards lists. The ones who aren't are the odd exceptions [13:51:54.0000] That does seem like something we should improve [13:52:28.0000] Specifiction seems unintimidating. Although not entirely useful (yet?). [13:52:42.0000] Never heard of it [13:53:02.0000] Ms2ger: it's something Robin set up [13:53:17.0000] Ms2ger: so that automatically means you'll love it [13:53:39.0000] Ha [13:54:16.0000] Ms2ger: discourse.specifiction.org [13:54:47.0000] So what is it? [13:58:09.0000] Ms2ger: it’s an on topic chat room, slowed down. [13:58:21.0000] Aha [13:58:23.0000] I think of it as a prototype for replacing mailman [13:58:35.0000] But right now everything is in one big forum so it's pretty unfocuse [13:58:46.0000] So it's moving discussion away from where people expect it to be, without telling them? [13:58:58.0000] That seems like somewhat poor form [13:59:22.0000] Perhaps. It's an experiment, is the somewhat-buyable excuse. [14:05:28.0000] I like that posts are more thought out than chat and easier to create than a full blog. I fear it might develop an aggressive mob mentality as I’ve seen in GitHub issues, Twitter threads, and the beccapurple Specifiction. [14:09:02.0000] I would also recommend it for all of the creative ideas that appear there, and the notable contributors to the web who chime in with their own responses. [14:10:41.0000] The issue (aside from the now there are two things problem Ms2ger alludes to) is that it's not focused around any particular technology implementers care about. It's kind of like whatwg⊙wo in that way, if more people knew about it. [14:11:24.0000] Except unlike whatwg@, you don't get a guarantee of a personal response from Hixie, so a lot of threads can just become developers saying "I'd like this" or "here's my bikeshed color" with no driving toward a solution. [14:12:16.0000] "I think it's somewhat OK to put the job of interfacing with the wider world on one person's shoulders" <- that's not the problem, the problem is that this job should come _before_ making decisions, not after [14:20:45.0000] well, that's where we get into charitable vs. uncharitable interpretations. Charitable: we want it, and we hope Alex can argue for it successfully, so we're implementing now on that assumption. Uncharitable: we're doing it no matter what; Alex's job is to make other people fall in line. [14:22:44.0000] What Hixie said about "this job should come _before_ making decisions, not after" [14:22:47.0000] that. [14:23:18.0000] Domenic, care to explain how you're interpreting anything charitable from "consensus within Google" ? [14:23:34.0000] which sounds awfully like "done deal within Google" [14:24:06.0000] and "litigating" sounds like force. I mean at least say something like "negotiating" but even that is bad as it sounds antagonistic. [14:24:14.0000] tantek: I am trying, and possibly failing to combat I'm-a-Googler-now bias. But to me it sounds like "after talking with our security folks, this is the solution we thought would work." [14:24:38.0000] And yes, litigating sounds very bad. Perhaps a word someone who is scared of standards bodies would use. [14:25:19.0000] who said that word? [14:26:17.0000] and I thought it was more like "now there are 17 competing specs" [14:26:28.0000] Domenic - I can understand people disliking (whether for fear or other reasons) standards bodies, or in particular standards mailing lists. [14:26:40.0000] SamB talking about https://code.google.com/p/chromium/issues/detail?id=389124#c8 [14:26:43.0000] though actually that didn't work out so bad for "menu" [14:27:26.0000] I mean, it's kind of dying now that .desktop has come along, but before that it was pretty darn useful [14:27:40.0000] oooh i wonder how the Blink

implementation is coming along [14:27:54.0000] will be so exciting to have that be more than just a Firefox-only feature [14:28:21.0000] /me still likes most of the stuff Hixie has come up with, even in our brave new web components world where everyone builds their own [14:28:34.0000] "menu" being the debian package that let other packages ship menu entries in *one* format for all WMs [14:28:46.0000] even though they all had their own menu formats [14:31:26.0000] "world where everyone builds their own" is merely XML "2.0" (in contrast to actual "XML 2.0") [14:31:39.0000] I'm going to grab a big bag of popcorn to watch that show [14:39:31.0000] hmm, if the idea is to prevent trouble with sites that DON'T WANT service workers, how is a new header on the REQUEST going to help AT ALL? [14:54:50.0000] hmm, I guess it could help when a site becomes AWARE of the rogue SW during the 24-hour window [15:05:09.0000] https://datatracker.ietf.org/doc/draft-saintandre-xdash-considered-harmful/ expired :-( [15:06:27.0000] Welp, that's it, I guess we all have to add X- back to our headers now [15:08:00.0000] lol [15:08:24.0000] /me really isn't sure the automatic expiry thing is at all useful [15:10:30.0000] oh, the tracker is just dumb [15:10:35.0000] it didn't really get dropped [15:13:13.0000] isn't automatic expiry the complete opposite of living standard? [15:13:59.0000] well it would hardly happen to HTML [15:14:38.0000] since HTML gets edited way more often than every 6 months [15:16:12.0000] when i was editing an I-D [15:16:15.0000] anyway, I really wish there was an obvious place to point out that a draft appears to be an ancestor of another draft, so that someone could make the IETF tools aware of this fact ... [15:16:19.0000] i published every edit as a new version [15:16:26.0000] and they literally complained that this was generating too much work for them [15:16:38.0000] because apparently someone has to manually do something every time you send an update (!) [15:16:43.0000] hahaha [15:16:51.0000] did you tell them to automate it? [15:17:06.0000] it ended up being a non-issue since i quit editing the spec shortly after [15:17:27.0000] "someone has to manually do something every time" - hey that sounds like W3C publication! [15:17:39.0000] tantek: yeah, but this was about DRAFTS [15:17:48.0000] SamB - same thing - WORKING DRAFTS [15:18:28.0000] well, I mean, they don't have like dev.ietf.org or anything [15:19:28.0000] Hixie: I suppose, if nothing else, it would tend to spam the mail archive [15:20:13.0000] the idea that one can update a spec too fast was so foreign to me i was baffled [15:20:22.0000] anyway evidently that draft somehow ended up as this is RFC 6648/BCP 178 [15:20:23.0000] "please don't fix the errors that quickly" [15:21:30.0000] Hixie: maybe what they really meant was "put it up somewhere else if you're gonna fix things that quickly, then just send us a snapshot every week or so" [15:22:07.0000] who knows [15:22:12.0000] seems pretty dumb eitherr way [15:22:40.0000] i mean, either they have the canonical copy, in which case it better have all known bugs fixed, or they don't, in which case, what's the point in theirs existing [15:26:55.0000] Hixie as the Mozart of spec editing. "There's just too many edits, make fewer" [15:27:36.0000] http://www.toomanynotes.com/Amadeus.htm [15:31:21.0000] Hixie: so yeah, maybe they should offer to host ED repos like w3 does ... [15:32:32.0000] lol [15:33:00.0000] "Which few did you have in mind, Majesty?" 2014-07-02 [19:24:25.0000] /me watches Sylvain and Tab go head to head [19:47:55.0000] roc: I'm *super* pissed about that. Totally done talking with Sylvain for a while. [19:48:09.0000] Happened before. I should know better by now. [19:48:20.0000] what forum was this? [19:48:24.0000] Twitter. [19:48:53.0000] The moment he switches from arguing to snarking, I just need to block him for a while. [19:49:00.0000] Too fucking frustrating otherwise. [19:49:01.0000] that does not sound like a good place to argue [19:52:13.0000] The smug subtweeting afterwards is the worst part (which is why I need to just block for a while). [19:54:59.0000] 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 [19:55:29.0000] 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. [19:55:44.0000] I know what I actually said. What people heard is their business. [19:56:32.0000] 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 [19:56:54.0000] and I do expect that you really meant something different - what you're maintaining you said now [19:58:53.0000] 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 [19:58:53.0000] people like pretending that they can change reality by altering a spec. [19:59:31.0000] time for an emergency subject change [19:59:34.0000] 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. [19:59:37.0000] roc: Kittens [19:59:52.0000] 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 [20:00:06.0000] SamB: It would be great if everyone did that, yes. [20:00:32.0000] roc: You're supposed to *deploy* the subject change when you say that. [20:00:37.0000] I suspect that the the those two things are actually ideas, in any case, and what he said are words [20:00:41.0000] roc: Can't just expect the rest of the room to change itself. [20:00:53.0000] SamB: I communicate only through interpretative dance, so no. [20:00:58.0000] lol [20:01:08.0000] TabAtkins: no wonder nobody had a clue what you meant [20:01:20.0000] it can be difficult at times :) [20:01:26.0000] SamB: Dance is the universal language. Not my fault the rest of the room hadn't learned it. [20:01:35.0000] Nor does that make it less universal, if that's what you're thinking. [20:02:05.0000] obviously terrans are just rude [20:02:07.0000] it does add a bit of savior-faire to the proceedings, though [20:02:19.0000] savoir [20:02:27.0000] gah [20:02:31.0000] *Jesus Christ [20:02:41.0000] no need for any more savior-faire [20:02:55.0000] That's the Christian ren-faire. [20:03:23.0000] why didn't I ever get an invite? [20:03:32.0000] Not savory enough. [20:03:48.0000] 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? [20:03:58.0000] roc: brb [20:05:57.0000] can't find the video of shirtless dancing at TPAC :( [20:06:57.0000] 'computed COMEFROM' ... mind ... broken! [20:08:32.0000] 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. [20:08:44.0000] roc: We discussed it a bit at the Input meeting last week in Seattle. [20:09:37.0000] 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). [20:10:28.0000] 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. [20:10:39.0000] 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. [20:10:50.0000] roc: Pair that with continuing development of off-thread developments in the declarative realm. [20:11:05.0000] roc: Like, yes, custom timing sources such as scroll position in Web Anim. [20:11:23.0000] And yeah, the Web Anim approach is our preferred direction for that kind of thing right now, with possible a CSS layer afterwards. [20:12:06.0000] abarth rejected CSS snapping (and apparently position:sticky?). Any idea whether any declarative proposals will be accepted by Chrome in the medium term? [20:13:02.0000] do you think Web Animation with a scroll position timing source is above Adam's bar? [20:13:22.0000] or if you don't want to channel him, where's your bar? [20:16:19.0000] 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. [20:16:32.0000] ok good to know :-) [20:16:45.0000] So we're probably going to do at least a subset of snapping. As we figure it out, I'll send feedback. [20:16:58.0000] Sticky is going to happen, we just had a bad impl that didn't mesh well with our compositor. [20:17:12.0000] ok [20:17:14.0000] that's also good to know [20:17:16.0000] And it was making it hard to improve things in the meantime. [20:17:37.0000] for CSS snapping, I think we can actually do most of what we want using script. [20:17:42.0000] Doing a lot of revolution-not-evolution in our compositing pipeline lately, trying to fix a lot of latent bugs. [20:17:58.0000] roc: We don't think you can do high-fidelity snapping async. [20:18:41.0000] is there a short explanation? [20:22:00.0000] 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. [20:24:35.0000] Yeah, that's basically it. That's not something you can tell the compositor right now. [20:25:19.0000] 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... [20:25:21.0000] ...in-progress animation. [20:25:22.0000] 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". [20:26:20.0000] /me 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 ... [20:26:59.0000] 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. [20:29:52.0000] 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. [22:39:54.0000] roc: you can implement snap points today without help from the browser [22:40:01.0000] roc: amazon has a nice implementation [22:40:35.0000] the problem is more how to make it possible for folks to re-use implementations written by experts [22:52:28.0000] AFAIK shipping browsers lack two things [22:52:42.0000] 1) a way to reliably detect the end of a user scroll gesture [22:53:36.0000] roc: how would that work exactly [22:53:41.0000] what is this "end" [22:53:52.0000] 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 [22:54:04.0000] if I grab the bar, whose to say where I'm going to release it? [22:55:42.0000] 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 [22:56:10.0000] so, how would this thing work on a desktop with a scrollbar? [22:56:56.0000] for thumb dragging, we'd fire the "user scroll gesture ended" event when the user releases the thumb. [22:57:06.0000] sounds kind of jarring [22:57:15.0000] to snap AFTER the user releases the thumb [22:57:51.0000] not that I've got a better idea [22:58:04.0000] that matches how most snapping works on touch devices [22:58:46.0000] roc: amazon doesn't use scrolling to implement snap points [22:59:27.0000] maybe I should study their code more, but I would be surprised if they did [23:00:28.0000] roc: yes, we should add scrollstart and scrollend events [23:00:31.0000] if so, it doesn't work with async scrolling and touch panning, so it won't be a great experience [23:00:45.0000] roc: the latter doesn't follow from the former [23:00:52.0000] in fact, it's a great experience [23:00:57.0000] try it [23:00:59.0000] on a really low end device? [23:01:19.0000] roc: it works well on the devices I have [23:01:33.0000] maybe I should try on lower end devices? [23:01:53.0000] roc: what is the minimum latency to talk to the main thread on your target device? [23:02:18.0000] meaning, under optimal conditions, how long does it take for the main thread to program data into the compositor [23:05:48.0000] less than 2x the vsync interval. [23:06:03.0000] but the real problem is that conditions are not always optimal :-) [23:06:21.0000] so, if vsync is 16ms [23:06:24.0000] it takes 8ms! [23:06:36.0000] how hard have you tried to bring that number down? [23:06:42.0000] it's really easy to blow the 16ms frame budget with main-thread activity. You know that of course :-) [23:07:22.0000] well, if your minimum latency is 8ms, I'm not surprised [23:07:29.0000] we're getting more like 2ms [23:07:41.0000] we're working on getting it down to 1ms [23:08:13.0000] I'm not worried about the best-case performance. [23:08:52.0000] I'm worried about the main thread getting blocked by a script or something outside our immediate control. [23:08:53.0000] ok, then what's causing you not to get best-case performance when the user scrubbing a snap point widget? [23:09:03.0000] who's control? [23:09:44.0000] the UA's control. [23:09:50.0000] right, the UA is not in control [23:09:57.0000] the web developer is in control [23:11:53.0000] my experience discussing this topic is that when you push on the motivation for snap points [23:12:14.0000] you eventually get down to the person who supports snap points saying that JavaScript developers aren't skilled developers [23:12:45.0000] I think it's fair to say that some JavaScript developers are highly skilled and some are less highly skilled [23:13:15.0000] 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 [23:13:42.0000] historically, we've done that by having the highly skilled developers hard-code behaviors into browsers [23:14:26.0000] but another approach is to encourage highly skilled JavaScript developers to make their work reusable by less skilled developers [23:14:34.0000] BTW I completely misunderstood your earlier question about update latency... [23:14:49.0000] oh good [23:14:53.0000] you had me worried :) [23:14:54.0000] 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 [23:15:14.0000] which is a scheduling problem [23:15:24.0000] iOS does that by controling your event loop [23:15:33.0000] when the finger is down on the glass [23:15:37.0000] 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 [23:15:39.0000] only certain events will come out of the event loop [23:15:41.0000] the rest are delayed [23:15:51.0000] we'll likely do something like that too [23:16:05.0000] but we haven't studied that aspect of the problem in great detal yet [23:16:08.0000] detail [23:16:45.0000] roc: put another way, how did the less skill developer steal time from the snap points widget's time slice? [23:18:44.0000] lots of ways ... requestAnimationFrame, triggering a complex CSS restyle/reflow, setTimeout [23:19:19.0000] can you see how those are scheduling problems? [23:19:33.0000] no, not really [23:19:49.0000] why did the setTimeout fire during the touch interaction? [23:19:49.0000] I don't think you can get away with suppressing those entirely during a touch-pan [23:19:56.0000] why not? [23:20:17.0000] that's what iOS does [23:20:54.0000] it's true that we haven't gone down that path you [23:20:56.0000] s/you/yet/ [23:21:00.0000] do animations stop? [23:21:15.0000] we're still working with folks fairly high up the skill curve [23:21:24.0000] you shouldn't drive animations with setTimout [23:21:33.0000] if you do that, I'm ok making your animations bad [23:21:43.0000] it's an iterative process [23:21:53.0000] whereby we're moving down the skill curve [23:22:05.0000] I didn't say that, I was just curious [23:22:06.0000] maybe we'll get to a point where the developers aren't skilled enough [23:22:15.0000] but we haven't reached that point yet [23:22:42.0000] I don't think we can tile the space of all effects by hard-coding them into the browser [23:22:53.0000] I don't think so either [23:23:06.0000] so, at some point, we need to decide "that's bespoke" [23:23:07.0000] so I wish you'd stop raising that straw man [23:23:18.0000] then, it's just a question of where to draw the line [23:23:22.0000] not whether to draw a line [23:23:37.0000] how do you decide where to draw the line? [23:23:55.0000] we're trying to figure that out by seeing how good we can make the platform for bespoke effects [23:24:01.0000] maybe we'll fail [23:24:07.0000] and bespoke effects won't work well [23:24:26.0000] in which case, we'll need to add many tiles and draw the line to include more UA-provided effects [23:24:32.0000] but maybe we'll succeed [23:24:42.0000] in which case, many effects can be treated as bespoke by the platform [23:24:51.0000] I don't have a deterministic algorithm for drawing the line [23:24:54.0000] and the UA provides a much smaller set [23:25:16.0000] which is why I wrote the email I did about snap points [23:25:25.0000] it's not that I think they're bad [23:25:35.0000] it's just that we're not planning to implement them [23:25:51.0000] that might change if we fail [23:26:00.0000] and the web platform can't support high-quality bespoke effects [23:26:20.0000] 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 [23:26:49.0000] its too bad you don't have web animations [23:27:08.0000] that way script can talk directly to the animation engine [23:27:13.0000] without involving CSS [23:27:24.0000] e.g., you can program an animation curve [23:27:33.0000] and all you need to do in your touch handler [23:27:38.0000] is set the currentTime of the animation [23:27:59.0000] the main thread has almost no work to do [23:28:33.0000] that's why I'm interested in the idea of moving that touch handler into the compositor. it's such a powerful, basic primitive [23:29:18.0000] 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. [23:30:01.0000] so, Android solves this problem by writing them once in Java [23:30:12.0000] 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 [23:30:15.0000] in the context of a browser, that would mean writing them once in JavaScript [23:30:47.0000] another approach would be to supply them to JS as a library [23:31:04.0000] you can do that in Android too. They have a bunch of Java classes provided by the framework that do scrolling math for you [23:31:21.0000] they don't move things around on the screen---they just tell you what the physics are [23:33:19.0000] 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. [23:33:43.0000] it certainly satisfies most of our use-cases [23:33:46.0000] I'm glad to hear that :) [23:34:02.0000] and you get a nice robust solution [23:34:07.0000] so are you on board with that? :-) [23:34:34.0000] yes :) [23:35:18.0000] glad to hear it :-) [23:35:32.0000] thanks for taking the time to talk this through [23:35:43.0000] IRC can be a better medium than mailing lists sometimes [23:46:34.0000] 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. [01:42:51.0000] "masinter added you to multipart-form-data" great work there MikeSmith [01:46:10.0000] /me pats himself on the back [01:46:51.0000] annevk: paving the road for you with my good intentions [01:49:16.0000] sspi: I'll check on it right now [01:50:59.0000] 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!)"? [01:51:09.0000] /me pushes some buttons [01:51:22.0000] sspi: should be on its way to the list no [01:51:25.0000] *now [01:53:26.0000] 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 [02:03:56.0000] annevk: Very? [02:05:11.0000] annevk: If you were careful with byte counting you could even make it work as a scripted test [02:06:16.0000] jgraham: could you do it and tell me what happens? [02:06:28.0000] /me is trying to find the answer to https://www.w3.org/Bugs/Public/show_bug.cgi?id=26241#c6 [02:14:38.0000] annevk: The test I wrote seems to PASS in Chrome and Fx [02:15:38.0000] annevk: If you work out where this test should live I could even submit a PR for it :) [02:16:54.0000] jgraham: can be part of XHR if you did it that way [02:17:17.0000] jgraham: it's testing the HTTP layer though, so if we have a directory for HTTP [02:18:31.0000] We don't have a HTTP directory, and I just did it through a normal document [02:18:34.0000] jgraham++ for having a better test framework than we had a couple years back [02:18:34.0000] No XHR [02:19:04.0000] I guess you could make it a ref test in a new HTTP dir? [02:20:02.0000] SamB: that draft was replaced by another draft which was also replaced, which eventually became http://tools.ietf.org/html/rfc6648 [02:20:09.0000] SamB: unfortunately some of the linking went lost [02:22:38.0000] https://github.com/w3c/web-platform-tests/pull/1089 [02:25:02.0000] http://w3c-test.org/submissions/1089/http/content_length.html is the actual test [02:30:08.0000] ta [02:32:34.0000] annevk: are you suggesting context="frame" for all navigations? Or would iframes get something different? [02:32:59.0000] JakeA: yes [02:33:24.0000] JakeA: "document" might be a better term since HTML calls them document environments [02:33:36.0000] annevk: much better [02:33:48.0000] I'll add that to the ticket [03:31:12.0000] 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. [03:31:31.0000] however, the registration form under example.com should not be autofilled with previous username/password values. [03:31:51.0000] i've already set
on the registration page, but this is being ignored it seems. [03:32:24.0000] has anyone an idea if this feature is somewhere handled in the html specification? [03:33:45.0000] pulse00: instead of setting autocomplete to off, set it to a value that describes the purpose [03:34:19.0000] pulse00: per http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-autocomplete [03:36:15.0000] annevk: thanks a lot! [03:40:54.0000] 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... [03:43:10.0000] pulse00: login forms can often be found on many URLs [03:43:53.0000] so because the form has an email/password input combination, the browser assumes it's the login form and autofills it? [03:44:15.0000] yeah, heuristics for that are not really defined [03:44:46.0000] browsers are slowly working on addressing that problem better now, part of the deal is the new design of the autocomplete attribute [03:45:30.0000] annevk: thanks a lot for the info [04:35:23.0000] If f is not one of "NFC", "NFD", "NFKC", or "NFKD", ... [04:35:25.0000] Yay ES [04:42:36.0000] MikeSmith: just read your message, tnx for helping out :) [05:41:32.0000] sspi: chhers [05:45:19.0000] Ms2ger: what's the problem? [05:45:37.0000] JakeA: I'm not sure if checking MIME type was agreed or not, but it seems like it would be good [05:46:33.0000] annevk: I'm happy with your conclusion. Assume multipart unless it's a urlencoded mime type [05:46:50.0000] JakeA: I meant re service worker MIME type [05:47:05.0000] JakeA: for multipart apparently the MIME type has to be checked to get the boundary parameter [05:51:38.0000] 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 [06:13:47.0000] hsivonen: I've landed validator support for in the syntax repo. Any chance you might be able to deploy it to v.nu and h5.v.nu today? [06:15:28.0000] 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 [06:20:40.0000] /me wonders if annevk gets to spend as much time with his dog as he'd like [06:21:08.0000] darobin: my dog is dead you ass [06:21:19.0000] ow! [06:21:32.0000] sorry about that [06:21:41.0000] but seriously, is that a .nl expression? [06:23:06.0000] 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 [06:43:44.0000] 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 [06:43:51.0000] well, I didn't want it too bad [06:44:04.0000] anyway, loved that expression on www-tag; I'm definitely going to use it :) [06:44:44.0000] heh [07:03:23.0000] This whole blob reading things needs some more thinking... [07:18:11.0000] annevk: yeah, I noticed, I just wish there was some kind of "report" functionality for such missing links between drafts ... [07:18:44.0000] SamB: I reported it on Twitter, the editor passed it on [07:18:58.0000] I guess that works [07:19:48.0000] naturally, the original title was better ;-) [07:30:57.0000] There's no place for humor in the IETF, except when it comes to their publishing format [07:31:18.0000] annevk +1 :-) [07:35:25.0000] annevk: are you talking about the recent sad but true April 1 RFC? [07:36:10.0000] The IETF publishing format is dadaism at its finest. [07:37:38.0000] In a few years they'll have an original copy of RFC 2616 printed on a daisywheel printer in MoMA [07:40:50.0000] oh, *that* ;-) [07:40:54.0000] you guys need to step up your game [07:41:23.0000] we need to have higher expectations for IETF trolling than what I'm seeing on display here today [07:41:25.0000] I was thinking about the "realistic requirement keywords" RFC ;-) [07:41:51.0000] that was a masterwork of sad, true, and funny all at once ... [07:45:45.0000] I missed http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0123.html [07:45:58.0000] Of course it is directly casually dismissed afterwards [08:06:43.0000] SamB: https://twitter.com/stpeter/status/484352051645009922 [09:37:17.0000] http://w3cmemes.tumblr.com/post/90566879702 <3 [09:38:56.0000] oooh w3cmemes stepped up its game [09:38:58.0000] i liked http://w3cmemes.tumblr.com/image/90566406597 [09:49:50.0000] that's not the first time slightlyoff's been represented by a dog [09:49:53.0000] i wonder what's up with that [10:20:13.0000] Hi. Is it possible to select multiple Options from JS? [10:20:56.0000] The select.value selects one. [10:25:15.0000] IZh: If you ahve a [08:10:54.0000] that is, with extensions like ".doc" in there -- not just mime types [08:11:09.0000] Do UAs actually support that? [08:11:26.0000] TabAtkins, alphabetizes as J, clearly ;) [08:13:28.0000] Ms2ger: This spec alphabetizes by family name, so I'm just matching convention. [08:21:08.0000] hsivonen: dunno if you're still around any longer today, but if you are, please let me know if it's OK with you to downgrade galimatias do the previous version -- 0.0.4. I'd go ahead and just do it, but I don't want to further muff things up with you trying to deploy right now. [08:21:54.0000] hsivonen: anyway I don't think the 0.1.0 version of galimatias is going to work for us in production until we update our ICU4J version [10:14:40.0000] Manishearth: yeah, i need to update HTML to point to fetch.spec.whatwg.org [12:38:04.0000] jgraham: i removed omit_optional_tags=on but i'm still getting some end tags omitted, any idea what's up? [12:39:08.0000] mathiasbynens: hmm. i see "The latest plan is to land the showModalDialog removal in Chromium 36. " [12:50:14.0000] MikeSmith: where? [13:07:42.0000] Why is nothing outputted when I resize the window? document.addEventListener("resize", function() { console.log("a"); }); [13:07:56.0000] Also, is there better documentation than MozDev? I find it to suck. [13:27:43.0000] montecfel: because you’re resizing the `window`, like you said, not the `document` [13:31:12.0000] gsnedders: dude in what order does anolis number IDs? [13:31:24.0000] gsnedders: i just noticed that id=history-0 is after id=history-1 in the HTML spec [13:31:51.0000] is it like dfns before headings or some such? [13:35:48.0000] looks like that's exactly what it is [13:35:49.0000] oh man [16:59:51.0000] Hixie: bugwards compatibility ftw man 2014-07-08 [21:07:38.0000] marcosc_: you around? (not sure what time zone you're in) [23:20:55.0000] zcorpan: ah the correct URL is http://dev.opera.com/blog/showmodaldialog/, but apparently we didn’t have a redirect set up. fixed [02:09:48.0000] Hixie: Oh, I forgot to say "no" [02:56:52.0000] MikeSmith, I dunno what the advantage is of closing old wpt PRs [02:58:16.0000] Ms2ger: I don't know what the advantage is to keeping around old long-stale PRs that nobody's planning to actually ever review or take any more action on. [02:58:44.0000] they're just noise, accumulating [02:59:05.0000] I'm planning to deal with them at some point [02:59:59.0000] that's fine then, for those. I agree there's not point in closing those [03:00:30.0000] I'd just like to be able to identify the ones that nobody is actually planning to ever do anything more about [03:07:56.0000] Ms2ger: thanks for closing that WebGL one, anyway [03:08:51.0000] I thought I'd commented on it before [03:21:52.0000] Ms2ger: not as far as I can see [03:22:02.0000] Yeah [03:22:11.0000] Must've been a dream [03:23:10.0000] Ms2ger: you dream big, man [03:24:46.0000] Dammit [03:24:53.0000] Oh, there it is [03:56:35.0000] Hmm, I guess I need to read my GH mail [03:56:55.0000] I'm not generally a fan of dropping PRs unless we did enough work to figure out that the PR has no value [03:57:07.0000] If you did that work, I'm all in favour of dropping them [04:00:58.0000] MikeSmith: I don't know enough about galimatias to have an informed opition either way [04:01:35.0000] MikeSmith: any reason not to update ICU4J? [04:03:49.0000] hsivonen: No reason except it'd need at least minimal testing. But I could do it and run it through the TestRunner + test suite and if that doesn't cause any exceptions or other code issues then I think we're good to go and I can push it [04:04:14.0000] hsivonen: so gimme a few minutes to try that now, and I'll ping you [04:06:00.0000] jgraham: a number of those PRs I commented on today are more than a year old, with zero review. If nobody's reviewed than in a year than I'd say nobody sees enough value in having them to even take time to review them. [04:06:45.0000] MikeSmith: I think that's a totally invalid inference [04:08:00.0000] We have missed various important things before simply because there aren't enough people spending time doing review [04:08:36.0000] jgraham: well that's why I'm taking time to comment on them [04:08:45.0000] jgraham: I've not closed any myself [04:09:16.0000] I think the pinging is nice. [04:09:19.0000] jgraham: I'm commenting to basically say, we need to take a look at this [04:09:35.0000] But it should be done at a low enough frequency that it doesn't feel like too big a task to look through. [04:09:55.0000] Like last time, I was pinged on a million things, and did nothing. This time only one PR, so I could take a look and close it. [04:10:08.0000] without doing some kind of gardening we just end up with a tail of stale PRs just growing without any bound [04:10:50.0000] odinho: well last time I did it was the first time and then I basically went through every open issue that was more than a couple months old [04:11:20.0000] going forward if we do it more regularly it'll be a lot less noisy [04:11:43.0000] anyway, I reckon it'd be good to be doing it once a month or so [04:11:53.0000] gardening I mean (for lack of a better word) [04:13:50.0000] MikeSmith: Oh, OK, that seems reasonable [04:14:20.0000] /me wonders how rude it is to put headphones on in the WebDriver meeting for the bits where I don't plan to contribute ;) [04:19:16.0000] jgraham: that WG's chair is kind of a hardass so you're probably risking an official reprimand [05:03:50.0000] hsivonen: OK I updated to ICU4J 53.1 (the latest stable) and tested it from a fresh checkout and it builds and runs, and runs the test suite without any crashes in the test harness or unexpected test failures [05:04:30.0000] hsivonen: so you could pull and build and deploy from that [05:26:28.0000] jgraham: how do remote devtools/debugging protocols relate to WebDriver? [05:27:08.0000] Not, I think [05:27:17.0000] out of scope? [05:33:37.0000] SimonSapin: Yeah, unrelated more or less [05:34:59.0000] Sometimes the remote debug protocol is used to implement webdriver, but that's an implementation detail [05:36:51.0000] Does http://remotedebug.org/ sounds worth pursuing? It was mentioned on the Servo list [05:37:46.0000] I think it sounds like a bad idea. I think that devtools is moving too fast and support is too vendor-specific to standardise [05:38:26.0000] I think I have heard somewhere that particular spec basically takes all the design mistakes of all the current protocols and standardises the union of them [05:38:39.0000] But I haven't actually looked at it myself [05:39:37.0000] (there might be something really useless that you could standardise for devtools like a wire protocol where all the actual features would basically be optional) [05:40:47.0000] I sort of expect that the pressure here is coming from webdevs who want to run their favourite devtools against some other browser without considering the fact that each feature also needs backend work [05:41:44.0000] At the moment we can break back-compat with impunity which allows adding new features more easilly (I assume) [05:56:10.0000] /me I mean registration for the TPAC f2f meeting of the Browser Testing WG in Santa Clara in October/November [06:03:54.0000] jgraham: How rude! You'll definitely be reprimanded. [06:07:58.0000] Hixie: I have absolutely no idea how Anolis numbers stuff. It's been too long since I looked at it! [06:08:00.0000] SimonSapin: It's in our charter to work on if we want to. But we have no spec and no editor. (c: [06:08:38.0000] ohai, London. [06:09:02.0000] gsnedders: IIRC it generates IDs whenever it needs to, so if it looks at a certain element type first then it will number that, then the others (and not in document order) [06:09:14.0000] darobin: this is what I would guess [06:09:25.0000] darobin: and yes, it definitely only generates ids when it needs to [09:38:06.0000] fyi MIT's having some kind of network problem, so you'll find most w3c services inaccessible right now probably [09:38:10.0000] including bugzilla [09:38:24.0000] Hixie: ↑ [10:14:24.0000] MikeSmith: luckily i'm not really looking at bugzilla these days [10:14:33.0000] nearly got my anolis replacement done though [10:14:41.0000] (just the replacement) [10:14:44.0000] (not the new features) [11:13:35.0000] anyone know of any good data visualization channels? [11:20:18.0000] /me imagines a cable channel meeting that description [11:20:42.0000] cryptic: what sort of data? [11:25:16.0000] SamB: I have temperature data from various sensors on many floors of an office building [11:25:23.0000] temps are time-series data [11:25:32.0000] I'm plotting it against occupancy and time [11:26:13.0000] It's a typical 4d projection [11:28:26.0000] I dunno, maybe #latex could send you somewhere good? [11:28:28.0000] an isometric projection of stacked area charts with color gradients should work [11:29:43.0000] #d3.js might be better [11:29:46.0000] didn't even know it existed [11:30:17.0000] oh, you want it on the web? [13:24:07.0000] Hixie: So the webdriver people were discussing having something in the "Navigate" algorithm that give the UA the ability to opt out of performing a navigation even if it's a supported scheme (e.g. refusing to load file:// for whatever reason). Is that already somewhere in the spec that I missed, or does it sound sensible? [13:24:27.0000] seems likely to already be there, let me check [13:25:35.0000] step 10 is pretty open-ended [13:25:52.0000] assuming you're ok with still supporting fragment navigation [13:27:06.0000] Yeah, i think that would do it [15:13:33.0000] it's sad that when i try to update my pipeline, all the problems i get are due to the parts of the pipeline i haven't yet replaced... [15:14:03.0000] yeah, why didn't you get those problems before? [15:15:38.0000] i did, it's part of why i'm replacing it [15:49:18.0000] great kittens. [15:49:20.0000] what a mess. [15:54:04.0000] ok! [15:54:07.0000] i'm no longer using anolis. [15:54:41.0000] (no new features yet though) [16:09:15.0000] who here can answer a question about SVG in html5 us, for the benefit of that glorious front-end framework that is Angular [16:09:37.0000] /me wishes other browsers started to warn about use of sync XHR in main thread [16:09:50.0000] caitp, what is html5 us [16:10:10.0000] good question, I think ti's a typo =) [16:10:15.0000] google hangouts is setting my laptop on fire [16:10:24.0000] ah :) I can probably answer your question. What's up? [16:10:51.0000] ojan: any chance Chrome could start warn about use of sync XHR ? [16:11:37.0000] smaug____, I think ojan is on a plane. Can you file a bug at crbug.com? [16:11:42.0000] pdr, someone had filed an issue on angular a while ago about this, https://github.com/angular/angular.js/issues/7538, where we get different behaviour between chrome and safari/firefox [16:12:04.0000] pdr: I think that requires logging to some google account [16:12:09.0000] so I'd prefer not to [16:12:27.0000] i will try to boil that down to a simpler reproduction I think [16:12:31.0000] smaug____, as you wish, but irc is a black hole for feature requests. [16:13:22.0000] I can always hope googlers file the bugs I mention here ;) 2014-07-09 [17:47:31.0000] ok i made some pretty risky changes, please let me know if anything broke with the spec [17:56:26.0000] heh [17:57:07.0000] Hixie: browsing the diff, seems like the web dev edition might be broken by removal of some of the s? [18:02:34.0000] http://jsfiddle.net/8cQGe/ reproduction is a bit clearer in this case if anyone wants to clarify that [18:20:16.0000] Domenic: yeah, i mailed ben about it. i need to figure out what he needs. [21:05:20.0000] Hixie: I guess https://code.google.com/p/chromium/issues/detail?id=377581 is the fix for the 408s problem in Chrome [21:06:41.0000] Hixie: and I think the w3c systems team is also looking at making a HAProxy to deal with it http://blog.haproxy.com/2014/05/26/haproxy-and-http-errors-408-in-chrome/ [21:11:57.0000] *HAProxy change [21:51:55.0000] Can somebody tell me if it's yet possible to change the colors around of a canvas? That is, fast. Not loading all the pixel data in an array, looping through it all and changing the values, but actual fast manipulation of the existing pixels on a canvas? [21:52:13.0000] Also, I do not mean putting a rectangle on top of the image that is transparent. That doesn't change the color in the manner I wish. [21:52:28.0000] montecfel: what, you want pallette cycling??? [21:52:35.0000] SamB: Not really that. [21:52:51.0000] This would not be limited to the 256 color palette of olden times. [21:52:58.0000] Which was damn annoying trying to squeeze in all necessary shades. [21:53:10.0000] I need to gradually make it more nightely in my tile-based game. [21:53:24.0000] Without drawing 100 copies of each sprite with slightly different colors on it. [21:53:32.0000] Or pre-calculating this at the start of the game. [21:53:41.0000] Which would take up insane amounts of RAM and CPU. [21:55:33.0000] You catch my drift? [22:10:43.0000] WebGL [22:11:20.0000] yeah, WebGL shaders would presumably work [22:11:25.0000] never run on this system though [22:59:24.0000] SamB: Huh? [22:59:32.0000] roc and SamB: Well, I use Canvas 2D. [22:59:37.0000] Not Canvas WebGL. [22:59:49.0000] Because it's 2D graphics. [22:59:52.0000] my system doesn't appear to support WebGL [23:00:01.0000] WebGL is the best way to do fast 2D graphics too. [23:00:02.0000] Many systems don't. [23:00:05.0000] and OpenGL has been put to quite good use for 2D graphics for quite some time [23:00:22.0000] Why on Earth would they have completely separate APIs where one isn't accelerated? [23:00:24.0000] Doesn't add up. [23:00:39.0000] 2D is hard to accelerate [23:00:49.0000] WebGL gives you much more direct access to the GPU. [23:00:55.0000] That doesn't really answer my question, though. [23:01:04.0000] Why not do acceleration under the hood? [23:01:10.0000] In fact, I thought they were accelrated. [23:01:18.0000] MS IE 9+ sure as hell are. [23:01:20.0000] at least, nobody has bothered to do 2D-specific hardware acceleration for a LOOONG TIME [23:01:21.0000] yeah [23:01:25.0000] everybody does [23:01:26.0000] Ultra-fast 2D drawing. [23:01:34.0000] but it's still not as good [23:01:38.0000] not saying canvas doesn't use accelaration, mind [23:01:59.0000] Well, it's slow like a freaking heck to read and change pixels. [23:02:14.0000] I bet there is some well-hidden way to do exactly what I want, in a super nice and fast way. [23:02:21.0000] ironically that's actually slower with GPU-accelerated canvas, because you have to get the pixels back from VRAM [23:02:24.0000] Which doesn't involve reading in the pixel data and awkwardly looping through it and whatnot. [23:02:28.0000] montecfel: shaders are basically the way to do it [23:02:36.0000] montecfel: depending on your effect, you may be able to do what you want with fancy operators [23:02:43.0000] roc: don't suppose there's a way to ask for a not-accelerated canvas? [23:02:43.0000] But I have zero experience in WebGL, and it's different from Canvas 2D, and it's poorly supported? [23:03:01.0000] Possibly with typed arrays, but they don't seem much faster than general JS arrays. [23:03:49.0000] It feels criminal to, upon load, make 100 copies of each sprite/tile in my game, and keep them all in RAM, just to be able to shade in/out from night and day. [23:04:51.0000] What does WebGL code even look like for 2D stuff? [23:04:56.0000] And shaders... ugh... [23:05:03.0000] /me does not like the idea of diving into that. [23:06:21.0000] montecfel: maybe you can use the "lighten" or "darken" operators [23:06:26.0000] with globalCompositeOperation [23:07:05.0000] Hmm... [23:07:20.0000] Well, I need to set the R, G and B separately. [23:21:39.0000] +1 webgl shaders [23:21:53.0000] used them to great affect in a hackathon to make a nightvision filter [23:27:10.0000] Does anything specify javascript: URLs? cf. https://github.com/tmpvar/jsdom/issues/823. annevk? [23:29:49.0000] I don't understand how to use WebGL. [23:31:07.0000] ImageData.data [23:31:07.0000] Is a Uint8ClampedArray representing a one-dimensional array containing the data in the RGBA order, with integer values between 0 and 255 (included). [23:31:15.0000] Oh. It's a typed array. [23:31:19.0000] And still so damn slow. [23:31:22.0000] MikeSmith: wow, that's a dumb protocol design. totally racy. [23:31:27.0000] "Clamped" is a weird term. [02:47:14.0000] anybody know if there are people from Nashorn on TC39 [02:49:11.0000] Jim Laskey? [09:27:40.0000] MikeSmith: I located the build.py bug that prevented me from launching re-deploying validator.nu the other day [09:28:03.0000] hsivonen: glad for that [09:28:07.0000] there's now a command line parameter with a space in it and the shell script generation option doesn't deal [09:28:15.0000] oh.. [09:28:23.0000] sorry about that [09:28:36.0000] did I add that param? [09:28:40.0000] I must have [09:28:42.0000] what's the pythonic way to say "take this array of strings and give me an array where each item has been surrounded by single quotes"? [09:28:53.0000] I'm pretty sure I didn't :-) [09:29:33.0000] as far as your question, I'm not an idiomatic pyton coder [09:30:07.0000] but we could change that param to have an equals sign between the name of the switch and the value [09:30:31.0000] /me looks back to see what switches he added [09:32:34.0000] hsivonen: ["'%s' % x for x in foo] is what I'd claim is Pythonic [09:34:24.0000] gsnedders: I'd claim that's a SyntaxError :p [09:35:25.0000] hsivonen: the value for the "--user-agent" switch I guess. So ignore what I said before about the equals-sign thing. That won't make any difference of course [09:36:58.0000] jgraham: shut up you [09:45:10.0000] wtf is http://blog.udn.com/bbuqt56/13228080 and why is it linking to my blog [09:47:32.0000] linkback spam? [09:47:45.0000] (which now made it into archives ;) ) [09:49:15.0000] why would someone link-back spam to a random page on my blog with bogus arguments? [09:51:09.0000] hsivonen: Alternately, map("'{0}'".format, arr) [09:51:15.0000] /me has used that before. [09:51:34.0000] But the list comprehension works just as well. [09:54:26.0000] /me would claim that's less idiomatic [09:56:49.0000] Hixie, on the web, spam is the simplest (Occam's razor) explanation for many behaviors. [09:57:10.0000] granted [09:57:17.0000] but i don't understand what they hoped to achieve here [09:57:58.0000] get you to post a link in the channel? [09:57:58.0000] tantek: I thought broken code was the simplest explanation [09:58:36.0000] MikeSmith - true - and of that, databases are the biggest subset. spam is second to broken code. [10:02:24.0000] tantek: that's some convoluted spam operation [10:02:43.0000] tantek: also, i'm probably a poor target, given that i work at google, in the knowledge department... [10:03:30.0000] and for that we can go with MikeSmith's explanation - broken code - why your link was picked - no idea [10:03:44.0000] or lazy code [10:03:55.0000] yeah that too [10:05:54.0000] in other news, it's absurd how many RSS readers are still crawling my RSS feed [10:06:05.0000] it hasn't changed since 2011 [10:06:17.0000] time to 410 it, i guess [10:06:20.0000] maybe they're optimists [10:06:49.0000] Hixie - do it - then we can point out that you're killing RSS! [10:07:00.0000] rss is dumb and should have died long ago :-P [10:07:41.0000] it is dying, slowly: http://indiewebcamp.com/feed#Shutdowns [10:08:47.0000] also i love the crawlers that clearly lie in their referrer field [10:09:22.0000] Hixie, I for one see most of my bandwidth go to bots lying that they're IE5.5 [10:09:40.0000] i just had one claiming to be firefox on windows 3.1. [10:10:55.0000] nice [10:17:18.0000] some non-browser but non-bot stuff make up referer, I think lftp puts the url itself in [10:17:59.0000] useful when pasting in a file url to download since it convinces a lot of dumb sites to work [10:31:20.0000] I still <3 RSS... not as a format, but as a user experience. [11:27:30.0000] RSS (and Atom) is just a poor but sometimes pretty reinvention of NNTP. Fixing/evolving NNTP would be so much better. [11:28:51.0000] Why? What practical benefits would that give over RSS? [11:37:18.0000] TallTed: NNTP is rather different imho [11:37:33.0000] fundamentally the problem with RSS or Atom is that they're poll-based [11:37:36.0000] which is just a broken model [11:37:59.0000] Hixie, what do you think of Atom via PuSH? [11:38:10.0000] can scripts change a Document's quirks mode? can the quirks mode change during parsing other than by action of the parser? [11:38:20.0000] well atom's pretty horrible in and of itself, as a separate issue [11:38:23.0000] Hixie: NNTP is poll-based too, no? [11:38:33.0000] i'm not advocating nntp either [11:38:42.0000] though at least you poll, like, two servers instead of zillions [11:40:07.0000] tantek: i think PuSH is definitely the better model [11:40:24.0000] tantek: though i can't help but wonder why it seems that for most purposes, there just isn't that much demand for this kind of thing. [11:41:12.0000] at the client end, i mean [11:41:34.0000] Hixie: Well, you're already familiar with one push-based protocol in common use, yes? Oh, but not usually on the client end ... [11:41:36.0000] podcast readers and feed readers are the only real end-user usage of RSS/Atom, and they're pretty low in usage [11:41:57.0000] Hixie, ironically, there is from a user level AKA "push notifications" but that has yet to translate into decent simple reliable protocols for that at the server level. PuSH is a step but by no means a very good answer. [11:41:59.0000] are there any good feed readers now? [11:42:14.0000] um, hey, what's the lowercase u [11:42:36.0000] SamB: http://indiewebcamp.com/PuSH [11:43:01.0000] i would have linked to https://code.google.com/p/pubsubhubbub/ :-) [11:43:34.0000] tantek: the push notifications that users seem to want are things like instant messaging and calendar appointments and incoming phone calls and the like [11:43:47.0000] tantek: all of which have their own proprietary or dedicated protocols [11:43:51.0000] Hixie - that page is less up to date unfortunately - as a nearly all such project/corporate pages that don't have some wiki-ness to them. [11:43:59.0000] It's like the TR problem [11:44:13.0000] code.google.com has wikiness [11:44:14.0000] but sure [11:44:37.0000] Hixie - right " have their own proprietary or dedicated protocols" - we're still at that phase in the technology curve for user/web scale notifications [11:44:47.0000] code.google.com often has incomplete wikiness [11:45:11.0000] "web scale" is a buzzword, you know that right? [11:45:25.0000] SamB - I kind of assume all projects there are dead now, either abandoned or moved to github [11:45:35.0000] tantek: well it's not clear to me what the user desire is at the end of the day [11:45:46.0000] tantek: most people don't seem to care for web sites to push them notifications of new content. [11:45:54.0000] Hixie, sure, there are probably several different use-cases to unpack [11:45:57.0000] tantek: I think I've seen one project that was for some reason using google code for issues but github for pull requests [11:46:00.0000] libarchive, iirc [11:46:05.0000] tantek: at least, not in the indiscriminate ways that RSS/Atom/PuSH do [11:46:22.0000] Hixie "web sites" can be calendar, or even IM/IRC, and with WebRTC, phone calls too [11:46:24.0000] SamB: "web scale" is actually a pretty important concept that a lot of people don't get [11:46:36.0000] Hixie: that's almost the same as a buzzword [11:46:47.0000] it's jargon, not the same as a buzzword [11:46:58.0000] tantek: right [11:47:02.0000] I mean, um, people seem to use it without actually meaning anything in particular a lot of the time [11:47:16.0000] SamB, your skepticism is reasonable. [11:47:35.0000] tantek: it's messages about application state, not messages about all new site content, though. [11:47:50.0000] SamB: a lot of jargon is used by many people as if it was a buzzword [11:47:53.0000] if a what was jargon gets too much buzz, it can lose value as jargon [11:48:08.0000] SamB: but when tantek (or I, or most people in #whatwg) say "web scale", it isn't empty of meaning [11:48:11.0000] or, maybe, it's just that I personally am confused by the buzz [11:48:13.0000] Hixie - simple example: txt messages - they're all new (site) content [11:48:13.0000] dunno ;-) [11:48:45.0000] tantek: i guess the distinction i'm making is between user-specific content and public content [11:48:57.0000] so like Amber Alert txt messages then? [11:49:23.0000] tantek: those are an interesting case [11:49:41.0000] tantek: not sure they generalise, though [11:49:45.0000] Hixie - another: weather alerts: http://www.nws.noaa.gov/com/weatherreadynation/wea.html [11:49:57.0000] for cities, transit system alerts [11:50:21.0000] all of these are somewhat user-specific, in that they're geographically scoped [11:50:26.0000] but yeah [11:50:44.0000] they're public-ish [11:50:48.0000] sure [11:50:56.0000] oh yeah, it'd certainly be handy to know about impending weather or SEPTA service interruptions ;-) [11:51:07.0000] but you'd want your system to automatically provide you with alerts about the transit problems near you, you wouldn't want to subscribe to them manually [11:51:14.0000] Hixie, another more recent *global* example: World Cup scores [11:51:23.0000] (as they happen - as in individual goals) [11:51:38.0000] why do I keep thinking of twitter [11:51:54.0000] yeah, but how many users would want to manually subscribe to those? as opposed to just being told them if they've shown interest? [11:52:07.0000] Hixie - yes, many "subscriptions" you'd want to be automatic on/off rather than manually curating - we've come to that conclusion in the #indiewebcamp community as well. [11:52:10.0000] i mean, people aren't subscribing to Atom feeds for goals en-masse [11:52:14.0000] Hixie: the latter sounds kind of creepy [11:52:29.0000] creepy how? [11:52:36.0000] It's one of the reasons feed readers died [11:52:37.0000] too much curating [11:52:41.0000] tantek: right [11:52:45.0000] tantek: that's kind of my point [11:52:47.0000] it's also going to doom the silos, Twitter, FB, G+ etc. because you need to do too much curating of who/what you follow [11:53:07.0000] creepy like Facebook crossed with Amazon? [11:53:15.0000] Facezon! [11:53:25.0000] tantek: i assume that's why G+ and FB are working so hard on automatic curation [11:53:34.0000] SamB: i don't understand what you mean by "creepy" here [11:53:50.0000] Hixie - in FB's case, they're also doing it for academic studies of emotional manipulation / propation. [11:54:00.0000] yeah, that was a fascinating study [11:54:02.0000] some of us like to pretend we've got something resembling privacy [11:54:10.0000] SamB: ? [11:54:14.0000] SamB: what's privacy got to do with this [11:54:22.0000] is the automation meant to be client-side? [11:54:34.0000] in terms of figuring out what feeds to follow? [11:54:38.0000] SamB: what do you mean by "client-side"? [11:54:45.0000] Hixie - agreed, automatic curation is a very hard problem [11:54:54.0000] SamB: i don't understand what you mean by "privacy" in this context [11:55:25.0000] i don't see anything in what we've discussed that would imply anyone else being able to see anything about you [11:56:15.0000] tantek: as you say, though, it's pretty much going to be a requirement. [11:56:22.0000] tantek: cos people hate to do manual curation. [11:56:25.0000] Hixie: who is meant to do the automatic curation? [11:56:34.0000] or rather, what? [11:56:40.0000] SamB: some software somewhere. [11:57:53.0000] and what is the nature of the information on which it will base its choices? [11:58:59.0000] whatever you've provided the software, e.g. if it's twitter, who you follow, what you've tweeted, etc [11:59:31.0000] ideally, every action you've ever taken and every thought you've ever had [11:59:45.0000] though i doubt we'll get there any time soon, the tech isn't there yet :-) [12:00:21.0000] Hixie: and you're confused about why I'm bringing up privacy *why*? [12:00:25.0000] HIxie, I don't think you're helping with not creeping out SamB ;) [12:00:40.0000] SamB: privacy is about what other people see. there's no other people in this discussion. [12:01:01.0000] well, I guess my concern is basically with how vague "somewhere" is [12:01:52.0000] well given the volume of data and the processing requirements to handle it, probably some datacenter. [12:02:35.0000] Hixie, put another way, manual curation doesn't scale, not even to "average" friend group sizes these days [12:02:37.0000] nevermind all the more public-ish things you want to be notified about [12:02:47.0000] so will this data center be run by the NSA directly, or ... [12:03:02.0000] SamB - no they just get their copy as usual [12:03:29.0000] so it gets used for advertising purposes *and* policing then? [12:04:03.0000] SamB: let me assure you than the NSA can far more easily slurp data off your personal hardware than it can out of the datacenter of a company which pays teams of the world's security experts to specifically secure the data against agencies like the NSA [12:04:31.0000] _faaaar_ more easily [12:04:32.0000] Hixie: I believe it [12:04:52.0000] so you brought up the NSA because...? [12:06:29.0000] well, what company did you have in mind exactly? [12:07:12.0000] it doesn't really matter, since the NSA can get to your hardware as easily or more easily than any company's. [12:07:59.0000] yes but I think someone would notice if they actually got to my hardware [12:08:00.0000] even if you used the NSA itself as your curation provider, your data would still be no less secure than if you used your own hardware. [12:08:05.0000] lol no [12:08:23.0000] see the stuff snowden leaked. [12:08:28.0000] Hell, I'd be kinda worried just going over any border crossing [12:09:00.0000] /me imagines trying to carry a desktop across a border ... [12:09:00.0000] they intercept hardware delivers and replace the hardware with identical-looking hardware with built-in wifi hotspots that they can connect to. [12:09:08.0000] deliveries. [12:09:21.0000] including, e.g. USB cables [12:09:45.0000] if your threat model includes the NSA, then the only way you're going to be able to come close to thinking you're secure is if you have the resources of a small nation state. [12:09:59.0000] (like, for example, some large companies do) [12:10:33.0000] but do you trust the SoC? [12:10:58.0000] which SoC? [12:11:13.0000] any [12:11:27.0000] i don't understand your question [12:11:39.0000] if you designed and built it, then sure [12:11:50.0000] are you sure the built product is what you designed? [12:11:50.0000] you think they can squeeze a wifi hotspot into an SoC? [12:12:05.0000] SamB: um, every phone has a wifi hotspot on an SoC [12:12:34.0000] the antenna are a fair bit larger, but I'm sure you can work around that somehow [12:12:40.0000] gsnedders: if you took the data from your design to fab and so forth, sure [12:12:57.0000] technically not just the SoC, but I see your point [12:12:57.0000] if the hardware the wifi hotspot is being put into is a USB cable, you have a gigantic antenna to work with. [12:13:16.0000] no need to add much if the hardware was already going to be provided anyway [12:13:33.0000] i mean, the victim in the scenario here literally provides the antenna _as the product they're trying to get_ [12:13:58.0000] anyway [12:14:00.0000] as i said [12:14:41.0000] if the NSA is in your threat model, then your only real choices are: 1. no computer data at all, 2. be a nation state or large company, 3. employ the services of a nation state or large company. [12:14:44.0000] so do they really do this to the general public? [12:14:53.0000] I mean, as a whole? [12:15:04.0000] no, of course not. not in any way that matters to you. [12:15:22.0000] unless you're the girlfriend of an NSA agent, or are two or three steps removed from a terrorist suspect [12:15:49.0000] or make phone calls [12:15:51.0000] or send texts [12:16:47.0000] btw, if you're worried about the NSA seeing your automatically curated feeds, it's going to blow your mind when you realise that your credit card company sees everything you buy and your ISP sees everything you do online, and both of those are probably sharing that data with the NSA too [12:16:52.0000] well, I can be fairly certain they aren't responsible for the *design* of my phone; if they were, surely the piece of junk they call a "browser" would actually function, no? [12:18:53.0000] Hixie: well, somehow having all that preferences information already distilled just makes it worse ... [12:19:02.0000] I mean, in my mind, not in reality [12:19:19.0000] anyway I should probably go do something useful rather than worrying about the fiction of privacy ... [12:19:26.0000] yeah, god forbid the NSA know what football team you're rooting for [12:19:38.0000] your privacy is unaffected by what we're talking about [12:19:45.0000] (unless you care about the NSA) [12:20:02.0000] (but even then, your privacy isn't any _more_ affected by what we're talking about than it already is.) [12:21:49.0000] /me is beginning to feel like the NSA could have intentionally not reported heartbleed so that it could later serve as a convenient distraction from their ACTUAL methods of attack ... [12:22:38.0000] maybe they did intentionally not report heartbleed [12:22:49.0000] maybe martians have landed in DC [12:23:50.0000] the NSA claim that they didn't know about that OpenSSL bug, and people who claim to have looked through logs claim to not have seen any evidence that anyone was exploiting that bug early [12:24:04.0000] I mean, maybe that's the kind of thing it would have made sense for them to do, given knowledge of the existance of heartbleed. Not to say that I believe that they knew about it. [12:24:19.0000] but that bug's an interesting example of precisely what i meant by large companies having large security teams whose job it is to secure their users' data from the NSA [12:24:45.0000] on the other hand, the large companies are probably larger targets [12:24:59.0000] The idea being that they actually would do nothing with it, saving it for later when it would cause a huge stir [12:25:46.0000] (but don't ask me how they would arrange for it to be discovered) [12:27:03.0000] they have a specific word for revealing security vulnerabilities in the least helpful and most harmful way possible [12:27:05.0000] SamB: given how much of the US gov't depends on OpenSSL, I _highly_ doubt that they would be that reckless [12:27:29.0000] Hixie: point [12:27:56.0000] maybe a bug that was less bad, but not clearly so, would work better for such a purpose [12:28:02.0000] > implying agencies of government necessarily care if they step on another agencies toes [12:28:58.0000] the NSA's mission includes defence against sigint [12:29:24.0000] well, most of my programs will exit upon recieving sigint, so I think they've failed miserably [12:30:06.0000] heh [12:30:07.0000] is there a variant of Godwin's law like Snowden's law that says that every conversation online ends up being about the NSA? E.g. scrollback and see how fast we got from RSS to NSA. [12:30:13.0000] high quality puns [12:31:37.0000] I mean, I guess it's silly for me to worry so much more when you talk about actually *using* information that I've not hesitated to let e.g. google have in the past to actually make the product work better [12:31:57.0000] I mean I used reader for a while, was rather sad to see it go ... [12:32:48.0000] (especially since most sites have terrrible, uh, "retention" on their feeds) [12:33:12.0000] SamB - another reason why separate feed files were a bad idea [12:33:31.0000] modern approaches now just markup the visible content in the HTML [12:33:36.0000] hmm [12:34:15.0000] I think what was happening was they didn't want stupid clients to download the entire history of the world at every poll [12:34:25.0000] more on feed files (problems, superseded by) http://indiewebcamp.com/feed_file [12:35:09.0000] how would you pull in the entire history of everything using these modern approaches? [12:35:51.0000] SamB - is that a use case for anyone other than a search engine like google? [12:35:56.0000] and why am I suddenly wishing for a tag to put inside
;-P [12:36:00.0000] thus: web spider [12:36:33.0000] SamB - see previous debate about a tag - pretty sure that's in an FAQ somewhere (why we don't need one) [12:36:40.0000] tantek: well, it used to be nice and convenient to read all of that stuff in reader, especially before it started auto-marking everything as read before a certain date ... [12:37:03.0000] content doesn't really have much of a semantic meaning does it [12:37:05.0000] tantek: but ... comments ... aren't ... content ... of the ... article! [12:37:08.0000] "there is stuff here" [12:37:34.0000] section[for=comments] ? [12:37:49.0000] SamB - sure. are you publishing or parsing? [12:39:38.0000] well, it sounds like these "modern approaches" involve scraping the site, but you might want to see just the main content without all the trappings/comments ... [12:39:46.0000] no scraping - all parsing [12:40:08.0000] I'm not sure I follow the distinction ;-) [12:40:11.0000] yup - content of a post (vs. comments, faves, reposts, reply-context etc.) has been solved [12:40:39.0000] parsing has a spec that publishers conform to, scraping is one-off per site. not unlike site-specific APIs. which break when sites change. [12:40:45.0000] big difference [12:40:56.0000] tantek: okay, fine, I meant "parsing" [12:41:39.0000] cool - yeah if you want to chat modern approaches for distinguishing post content vs. comments, faves, reposts, reply-context etc. come on by #indiewebcamp [12:41:45.0000] tantek: got a blog that implements it? [12:42:02.0000] SamB - several! depends on what you're looking for [12:43:12.0000] i don't know why I ever bother with debug builds when a release clobber build just sails through so much faster [12:44:47.0000] caitp: a what now? [12:45:05.0000] don't mind me I'm yappin [12:45:08.0000] I hope you always build with -g [12:46:18.0000] have you ever seen a lithium ion battery explode? [12:47:30.0000] that's the main reason not to compile/link with symbols and debug info, that's frankly terrifying [13:50:54.0000] this is probably a question for annevk, but does anyone remember why fetch Headers require maintaining ordering? what use case requires controlling the ordering of headers? [14:49:05.0000] wanderview_: Perhaps for when duplicate headers overwrite each other? (Just guessing.) [14:52:24.0000] oops [14:52:29.0000] /me accidentally clobbers the spec [14:53:31.0000] does that mean we can rewrite HTML from the beginning? horray! [14:54:01.0000] Unfortunately it's only the spec, not all the legacy :( [14:54:12.0000] :'( [15:03:13.0000] Domenic: ping [15:03:33.0000] cabanier: pong [15:03:56.0000] Domenic: about the DOMRectReadonly object, why can't we treat it as just an interface? [15:04:14.0000] cabanier: what is an interface? WebIDL interface === JavaScript class [15:04:16.0000] Domenic: it seems you're going out of your way to make it the same object. [15:04:49.0000] cabanier: I agree, but that is roc's requirement, so that you can monkeypatch a common prototype class. My suggestion was just to have a DOMRectUtils mixin. [15:04:49.0000] Domenic: even if it has no constructor? [15:05:10.0000] cabanier: yes; remember there is no such thing as "no constructor" in JS, just "constructor which throws unless you pass it a secret" [15:05:44.0000] Domenic: but there are a lot of objects like that in the web platform. You can't new a canvas element for instance [15:06:03.0000] cabanier: EXCEPT that WebIDL has a special exception for interfaces that are [NoInterfaceObject] and only ever used with `inherits` instead of `:`; those are called "supplemental interfaces" [15:06:06.0000] Domenic: maybe domrectreadonly should be a dictionary [15:06:07.0000] cabanier: yes, and we are trying to fix those [15:06:26.0000] cabanier: well, that might be OK, but what about the left/right/top/bottom :-/ [15:06:52.0000] Domenic: var c = new HTMLCanvasElement(); ? [15:07:27.0000] Domenic: too bad that those attributes already shipped.... [15:08:24.0000] Domenic: can't they be implemented with JS? I agree it's failry magical [15:08:32.0000] cabanier: I think they are useful... either separate DOMQuadBounds and DOMRect classes, or DOMRectReadOnly and DOMRect classes, seem OK. [15:08:35.0000] s/failry/fairly [15:08:53.0000] cabanier: sorry, can't what be implemented with JS? [15:09:26.0000] left/right/top/bottom as attribute getter functions that do the calculation [15:09:36.0000] why not? [15:10:00.0000] they could be, but then there would be separate getters for every instance... classes are nice since they let you reuse getters (or methods) across multiple instances [15:10:39.0000] Domenic: but a dictionary defines everything new every time so that would be consistent [15:11:05.0000] cabanier: yeah, it'd be consistent, agreed. A little wasteful I guess, but not horrible. [15:17:17.0000] Domenic: then DOMRectReadOnly would just be an Object and DOMQuad would keep a reference to that object [15:34:38.0000] cabanier: that seems to kind of contradict the stated design goals, e.g. then people can modify quad.bounds.x and it'll be inconsistent with the quad itself. But I know a lot of people would argue that's more JavaScriptey anyway---the reflection of the object in the API can be messed with, even if the quad itself is not impacted. [15:35:51.0000] Domenic: can 'x' not be readonly in the dictionary? [15:36:49.0000] cabanier: well, I guess it could be a "dictionary" full of getters? E.g. `{ get x() { return 5; }, get y() { return 10; } }` [15:37:55.0000] Domenic: yes, for a quad they would pull it out of the quad. [15:42:45.0000] cabanier: I guess I don't see the advantage over a DOMQuadBounds class? [15:43:59.0000] cabanier: you end up writing a (browser-internal) factory function that is e.g. createRectDictionaryFromDomQuad(quad) { return { get x() { ... }, ... } } [15:44:31.0000] cabanier: which doesn't seem any better than creating a (user-exposed) constructor function DOMQuadBounds(quad) { ... } [15:44:49.0000] both are better than a throw-without-secret constructor, definitely [15:45:46.0000] (note that you can't hide constructors in JS, since they are always accessible via the .constructor property on instances. Whereas factory functions that return simple objects can be hidden.) [15:46:12.0000] Domenic: you avoid exposing another object to the global namespace [15:46:54.0000] Domenic: and avoid type checking when you pass in a DOMRectReadOnly [15:47:32.0000] cabanier: I think you can accomplish both of those though. The type checking definitely; input should never be a DOMRectReadOnly, just a DOMRectInit or something [15:48:11.0000] Domenic: yes. [15:48:13.0000] cabanier: the avoiding-exposing-an-object thing is a bit trickier since we'd need to fix WebIDL. But there is no reason in JS you cannot both (a) have a constructor; (b) decide not to make a global variable pointing to that constructor. [15:48:29.0000] The fact that having a constructor means it must be on the global in WebIDL is just a bug in WebIDL. [15:48:50.0000] it'll be a very bad bug once browsers start shipping modules :P [15:49:10.0000] Domenic: it might be a fundamental browser feature [15:49:31.0000] Domenic: so fixing it might take a while, if you can even convince them to do so [15:49:49.0000] s/feature/design flaw/ [15:50:16.0000] cabanier: that's fair. But we could have a spec that's slightly ahead of the browsers here. And browsers could either expose an extra global (risky), or have a throwing constructor. But as long as the throwing constructor is spec-uncompliant, I am happy. [15:53:43.0000] Domenic: thanks! I'm going to ponder this a bit (it's time to go to sleep :-)) [15:55:28.0000] cabanier: sounds good! glad I could help :) [15:55:56.0000] Domenic: yes, the spec will definitely get better [16:45:23.0000] dreamhost is moving the whatwg.org server to a different back-end to see if that improves performance [16:45:30.0000] site will be down until dns propagates [16:47:08.0000] Hixie: why can't they propagate DNS first :-( [16:47:31.0000] because that would just mean the site was down earlier? [16:48:24.0000] I mean, er, set up new backend, then wait for dns to propagate, then take down old one. I guess it would be important to flip the wiki to read-only though ... [16:52:24.0000] SamB: not just the wiki [16:52:47.0000] anyway, dns has propagated [16:52:49.0000] oh okay [16:53:20.0000] I guess a big name like them *would* remeber the "lower TTL first" step 2014-07-10 [17:27:23.0000] some aws stuff is designed around expecting low ttl always (on the order of ~60s) [17:27:57.0000] it's a bit bizarre that apparently firefox still ignores TTL, even though it breaks anything hosted on amazon ELB [17:33:22.0000] sounds like good material for a bug [17:34:21.0000] https://bugzilla.mozilla.org/show_bug.cgi?id=151929 filed 12 years ago [17:34:51.0000] nice [17:36:54.0000] well, 12 years and no attachments shows some commitment :s [17:36:55.0000] certainly a bigger bug today than it was then [18:58:17.0000] how do other browsers honour ttl if the OS doesn't expose it? [19:08:29.0000] the OS DNS does handle ttl, but iirc firefox has its own caching layer that doesn't [19:08:58.0000] if they're using the OS to do the underlying DNS and it doesn't expose TTL, then they either need to 1: not use the OS resolver at all to get the info or 2: lose the extra caching layer [19:10:56.0000] zewt: might not be *totally* insane to cache for, say, a minute despite not knowing TTL [19:11:48.0000] afaik they're caching for longer than that (five minutes or something) [19:12:39.0000] amazon ELB instances have a ttl of around 45-60 seconds [23:10:17.0000] what's with all of the asm.js hate? [23:11:00.0000] why did everybody decide to put their head in the ground at exactly the same time? [23:12:05.0000] Why can't I put my MacDraw picture in the cloud? [23:12:21.0000] Why can't I put my HyperCard stack in the cloud? [23:15:39.0000] dbpokorny: asm.js hate? [23:15:59.0000] and what's this about not being able to store those files in the cloud ... ? [23:18:24.0000] For example "assembly is inherently incompatible with the web". This is the ultimate source of what is and is not web. [23:18:50.0000] asm.js is probably not what they think [23:19:56.0000] I bring up MacDraw and HyperCard because they currently require pce.js to run, which requires asm.js. [23:52:06.0000] *sigh* so stuff like this "image decoding *can't* be done efficiently in script" [23:52:25.0000] I mean, it is being done in script. That train has left [23:53:50.0000] Are compiler writers so scarce that people simply believe language translation is not possible? [23:53:53.0000] it is better if you can let the browser do it rather than insisting on wasting memory in every ... single ... tab [23:54:24.0000] I agree [23:54:49.0000] okay, so no lecture about sharing code pages necessary then ;-) [23:56:22.0000] sharing code pages is very apt to this discussion [23:57:33.0000] yes, but *you* already know about it so *I* don't need to bore you with the details that you already know [23:57:54.0000] Basically, I want to run libhfs.c in my browser [00:01:28.0000] The whole, "it hasn't been invented yet, it will never be invented" attitude is just...so early 90s [00:01:52.0000] "(People have been trying unsuccessfully to do that since day one of MMX, so it's irrelevant until the day it actually happens.)" [00:02:14.0000] what, only since then? [00:02:39.0000] and I thought MMX was late 90s ;-P [00:02:51.0000] lol you're right [00:16:31.0000] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-May/296960.html [00:17:01.0000] "platform-independent code with performance competitive with native SIMD assembly is a thing of myth" [00:19:01.0000] it does sound kind of grail-ish [00:20:00.0000] yeah, but if you just turn over the coin, you see that all you have to do is define the algorithm namespace, check which algorithms/libraries you want, and hand the thing over to a compiler from 2050 [00:20:31.0000] everyone implements the same algorithms on new SIMD hardware [00:21:08.0000] unless, you know, you're IBM Almaden [00:21:39.0000] the compiler from 2050 still has good sheduling support for the hardware of 2014 ? [00:25:29.0000] I don't follow. The image compression issue is latency-oriented [00:40:50.0000] but the greater issue is that there are only so many ways to design different scheduling schemes for hardware. With the web, it will be easier to share them, and then design compilers for historical SIMD hardware the same way we ask students to come up with proofs that every nonempty perfect complete metric space is uncountable [05:30:08.0000] jgraham: I would like opinions from you on the Jython PR for html5lib. [08:14:09.0000] slightlyoff: you around? [08:20:10.0000] Ish. In a cab. Whaddup? [12:54:23.0000] Domenic, you realize that breach.cc is basically Firefox, right? [12:54:40.0000] Ms2ger: Firefox has a Node.js core? [12:54:53.0000] The UI being in HTML/JS is not the interesting part [12:55:07.0000] The core is Chromium, afaict [12:56:45.0000] see "layer 3" and http://breach.cc/hack/ [12:59:00.0000] what, firefox UI is in HTML now? [13:00:39.0000] XUL and bits of HTML [13:11:49.0000] it's sort of neat how FF's view for directly viewing an image is just a built-in html page, I was able to attach a greasemonkey script to it to add better zooming support [13:17:45.0000] zewt: doesn't everyone do that nowadays? [13:18:59.0000] gsnedders: hasn't mozilla been doing that since before most of the other engines were even born? [14:26:29.0000] jorendorff: yt? [14:26:46.0000] jorendorff: any idea why the sticky headers on http://people.mozilla.org/~jorendorff/es6-draft.html no longer appear on chrome? [14:27:46.0000] maybe chrome dropped position:sticky? [14:29:38.0000] I think that may be correct [14:29:53.0000] Hixie: Does it work for you here? http://html5-demos.appspot.com/static/css/sticky.html [14:29:54.0000] [14:30:14.0000] jorendorff: it does not [14:30:23.0000] jorendorff: you didn't use to use js or anything i take it [14:30:45.0000] Hixie: no, just position:sticky [14:31:31.0000] it says here "Support: Chromium 23.0.1247.0 with the --enable-experimental-webkit-features flag enabled via about:flags." [14:32:17.0000] ah maybe that's it [15:26:01.0000] gsnedders: chrome's can't be affected by user scripts, as far as i could tell [15:26:16.0000] though chrome basically removed support for user scripts (which forced me back to firefox) [15:29:44.0000] Hixie, jorendorff: the experimental sticky support in chrome was ripped out recently [15:30:00.0000] ah [15:30:01.0000] k [15:30:03.0000] it'll be added back when somebody (1) writes down what it is supposed to do and then (2) writes code that does that [15:30:14.0000] (1)'s never really happened so it's pretty hard to have good code around [15:30:22.0000] /me nods [15:31:03.0000] i think a mozilla intern was starting on it but didn't make it all the way. it's a worthwhile thing in a very long list of worthwhile things to pursue 2014-07-11 [00:44:47.0000] "Revive E4X as EXQO with extended SAX as Methods!!!!!" [00:53:20.0000] /me worries for Ms2ger's sanity [00:53:44.0000] You and me both [02:55:40.0000] SAX is so good it doesn'T need to be extended [02:56:54.0000] /me wonders if MikeSmith is being held hostage by XML terrorists [02:57:15.0000] tee hhee [02:57:31.0000] stockholm syndrome [02:59:43.0000] http://instagram.com/p/JzmkwQCr7y/ [03:02:24.0000] MikeSmith, not sure that's a think one'd like to be called [03:08:28.0000] yeah that's what makes it even better [03:10:16.0000] A think? [03:10:24.0000] /me blames XML [03:11:32.0000] if it'd been HTML it would have error-recovered from that for you automatically [03:16:43.0000] I really can't work out if "the ascii of the future" is supposed to be a compliment or not [03:37:26.0000] MikeSmith: I've redeployed validator.nu, despite it being a bad idea right before heading out of office for a couple of weeks [03:40:49.0000] TabAtkins: thanks for Python map() advice [03:41:22.0000] MikeSmith: I landed a quick map/lambda hack to paper over the shell script generation bug without correctly fixing all possible future cases [03:41:26.0000] (bad, I know) [03:41:59.0000] MikeSmith: if in the future we want a command line switch that both contains a space and requires shell variable expansions, things will break again [03:43:52.0000] hsivonen: thanks much man [03:44:24.0000] hsivonen: I'll try not to add any new switches to the script at all. We got plenty already [03:47:00.0000] hsivonen: the ones I've added are of marginal benefit anyway. They're mostly just there to allow some things for the W3C service to be slightly different. e.g., the space thing was caused by me adding a switch to allow the UA string to contain a URL for page that explains what the validator is [03:48:17.0000] hsivonen: some sites admins, otherwise not knowing what the validator is, send us complaints about it violating robots.txt and things, or even blocking it [03:49:25.0000] hsivonen: anyway, thanks again -- I appreciate it [07:09:27.0000] what does "Let form document be the form's Document." mean ? [07:09:37.0000] is that ownerDocument? [07:19:15.0000] Hixie: am I interpreting the spec correctly, and that means ownerDocument ? [07:19:40.0000] "The Document of a Node (such as an element) is the Document that the Node's ownerDocument IDL attribute returns." [07:29:15.0000] Yep [07:34:15.0000] and browsers behave differently there [08:49:02.0000] smaug____: yeah [08:51:31.0000] Hixie: what about "the Document object with which subject in question is associated." [08:51:39.0000] in hyperlink handling [08:51:49.0000] that Document is also ownerDocument? [08:51:53.0000] associated usually means something else [08:51:56.0000] let me see [08:52:53.0000] looks like in this case it's just ownerDocument, yeah [08:52:59.0000] that could probably be phrased more obviously [08:53:06.0000] actually all of this stuff probably could be better phrased now [08:53:15.0000] at the time it was written, ownerDocument wasn't formally specced [08:53:27.0000] but now we have anne's dom spec, it might be easier to reference it [08:53:50.0000] ah, yeah, the dom spec now defines "the node document" [08:53:57.0000] looks like browsers handle this kind of cases in different ways [08:54:13.0000] blink doesn't care whether element is in doc, but gecko and trident do [08:54:15.0000] i should just change all of this stuff to just refer directly to "node document" instead of the round-about way i had to use before [08:55:00.0000] the spec doesn't care, does it? whether the element is in a doc or not? [08:55:15.0000] for following hyperlinks, i mean [08:55:23.0000] what I'm starting to do is to go through this stuff and think how it should work in shadow dom [08:55:36.0000] Hixie: right. and I think that is probably wrong [08:55:42.0000] why? [08:55:52.0000] security, compat? [08:55:55.0000] something else? [08:56:00.0000] something else [08:56:13.0000] saner behavior [08:56:32.0000] but probably doesn't matter much [08:58:01.0000] Hixie: You around? [08:58:07.0000] /me grumbles [08:58:32.0000] smaug____: i think for some things (form submission in particular, also audio playback, img loading) we have a compat need to handle it while it's not actually in a doc, so for consistency we probably shouldn't artificially check it elsewhere [08:58:36.0000] bkardell__: 'sup [08:58:52.0000] form submission doesn't work in Gecko and Trident when not in doc [08:58:53.0000] smaug____: (i filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26310 btw) [08:58:56.0000] so no compat [08:58:58.0000] Hixie: Trying to figure out which list to even send this question to man... [08:59:05.0000] Hixie: Have a look at this https://gist.githubusercontent.com/bkardell/7da8ba03e690f2c24503/raw/ccbd20fc406f3158b0c616770e4bed1e956ce019/mutationobserverquestion.html [08:59:15.0000] smaug____: really? i thought we just found there was a compat need for something like that, when doing the rAc stuff. [08:59:35.0000] Hixie: Whoops, running with mime type https://rawgit.com/bkardell/7da8ba03e690f2c24503/raw/ccbd20fc406f3158b0c616770e4bed1e956ce019/mutationobserverquestion.html [09:00:14.0000] http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLFormElement.cpp#1595 [09:00:15.0000] Hixie: The question is - a) shouldn't that output the same in all browsers b) what is under-specified or buggy in existing if do [09:00:26.0000] s/do/so [09:00:47.0000] smaug____: huh [09:00:58.0000] smaug____: well anyway, the other cases stand [09:01:42.0000] I could buy that consistency argument [09:02:12.0000] bkardell__: if it's a mutation observer question, probably whatwg⊙wo, cc anne [09:02:56.0000] Hixie: yeah, anne was suggesting maybe it was about pasing... maybe still best to send to the list [09:03:09.0000] Hixie: just trying to shortcut list confusion [09:03:20.0000] bkardell__: pasing? [09:03:31.0000] s/pasing/parsing :) [09:03:35.0000] bkardell__: note, Gecko's behavior changed recently [09:03:37.0000] bkardell__: oh [09:03:45.0000] bkardell__: /me looks closer [09:03:58.0000] bkardell__: though, I assume you're testing with latest versions [09:04:03.0000] not release versions [09:04:15.0000] bkardell__: oh if you're getting mutation observers during parsing, you can't guarantee that you'll get the same thing even in the same browser [09:04:20.0000] smaug___: Checking in release versions [09:04:24.0000] bkardell__: it depends on TCP packet boundaries, amongst other things [09:04:29.0000] bkardell__: not useful [09:04:54.0000] Hixie: why not? The way the test is constructed, there shouldn't be major variation, right? [09:05:17.0000] but yeah, packet boundaries may affect to characterData records [09:06:18.0000] bkardell__: e.g. at the simplest level, if one load gets an event loop spin (e.g. because the data was split into two packets and it only got the first packet) half way through the being parsed, and a second load does it all as one task, then the first will fire the mutation observers as two microtasks (at least), and the second will fire them as one. [09:06:52.0000] TIL: treatment of img@hspace is not interoperable [09:07:12.0000] Hixie: Ok, I'll buy that for character data, but for element nodes they should be the same, yes? [09:07:52.0000] smaug___: what do you see for type 1 nodes in latest FF? [09:07:59.0000] bkardell__: well at the very minimum they'll be fired with different microtask timings [09:08:39.0000] Hixie__: the test doesn't really involve timings though, right? I mean, ignore text nodes in the output... [09:09:35.0000] bkardell__: FF has one characterData which chromium apparently doesn't have [09:09:37.0000] bkardell__: i don't really understand the test output [09:09:52.0000] (I don't understand those numbers under childList, but they are the same in FF and Chr) [09:11:06.0000] childlist contains a count of nodeType for each addedNode [09:11:09.0000] bkardell__: the parser can result in observably different results because of timings, but the end result DOM should be the same. If the question is about timings, then the parser might be relevant. If the question is about the end-result, then that's probably a DOM question, not a parser question. [09:11:15.0000] the source is pretty simple, fits on a visible screen [09:12:23.0000] hsivonen: MikeSmith: validator.nu/?doc=http%3A%2F%2Fscottjehl.github.io%2Fpicturefill%2F&showsource=yes gives an internal error [09:12:23.0000] smaug___: Let me check nightly [09:12:27.0000] bkardell__: you're assuming one understands the mutation observer API enough to understand the test :-) [09:12:41.0000] zcorpan: yeah checking on it now [09:16:26.0000] smaug___: excellent, right! nightly is matching! [09:16:36.0000] /me does a happy dance [09:17:34.0000] I'm being such a stereotypical PL guy. "Let's just use SML!" [09:20:05.0000] smaug___: any thoughts on why safari works fine for me with that test only if devtools are open? ever heard of that? [09:20:41.0000] well bummer [09:20:58.0000] no idea. I haven't used Safari for ages [09:21:02.0000] i added some checks to catch cases where the dev version of the spec referenced terms not defined in the dev version of the spec [09:21:31.0000] i fixed one, then made it tell me the total count, not just one at a time, and it found 3999 more occurrences. [09:21:39.0000] hober: You here? [09:32:24.0000] zcorpan: found the cause but not going to get it fixed until another hour or so at least. Hope hsivonen will be able to re-redeploy before he needs to head away [09:34:19.0000] Hm [09:34:40.0000] If I do margin-top: 50%, what is that based off? Width? [09:34:53.0000] yes [09:35:39.0000] Ta [09:36:31.0000] Do I need a link if my reftest files are called foo.html/foo-ref.html in wpt? [09:36:57.0000] Ms2ger: In theory, no [09:37:08.0000] In practice? [09:37:26.0000] But if the ref is reusable it's encouraged to use to a standard file rather than -ref [09:37:32.0000] Not really [09:37:38.0000] smaug___: When is that stuff supposed to land in release? [09:37:47.0000] Ms2ger: Can you make it reusable? [09:38:36.0000] Hmm, maybe I could reuse it [09:38:39.0000] Alright [09:39:10.0000] Or not really, actually [10:55:26.0000] hsivonen: I just pushed a fix to the build repo. Without it, the checker will fail with a non-document "Oops" internal error. If you have time to re-reploy before you have to head away, great. If not, it can wait til you're back. [10:55:51.0000] hsivonen: sorry for not having been more careful [10:58:49.0000] zcorpan: thanks for the heads-up. I fixed the cause and http://qa-dev.w3.org:8888/?doc=http%3A%2F%2Fw3c-test.org%2Fconformance-checkers%2Fhtml%2Felements%2Fpicture%2Fpicture-isvalid.html is built and running from the source trunk [10:59:57.0000] zcorpan: But for now the support is currently broken at both v.nu & h5.v.nu and the W3C validator in the same way [11:01:25.0000] zcorpan: and I'm going to leave it that way at the W3C validator until hsivonen is able to re-deploy too. Which may not be until 2 weeks from now [11:02:27.0000] and now I need to board yet another plane without wifi [11:02:47.0000] back around in 15 or so hours [12:29:41.0000] MikeSmit1: k [12:35:44.0000] dglazkov_: what does "Window object named properties [HTML] must access the nodes in the document tree." mean in shadow dom spec [12:35:54.0000] doesn't seem to belong to that spec at all [13:45:25.0000] jgraham: wow, you appeared around html5lib, I am amaze ;P [13:50:27.0000] gsnedders: Well it wasn't an insanly complex PR [14:49:52.0000] dglazkov_: is iframe supposed to work in shadow dom ? [14:50:13.0000] jgraham: I dunno, it's not the most elegent of code, but that's Py2 as it's defined, le sigh [14:53:26.0000] per spec no [14:53:40.0000] interestingly chrome actually loads the iframe content but doesn't render it [14:54:03.0000] h, hmm [14:54:22.0000] ah, yes, it does render it [14:54:25.0000] but that is a bug [14:55:11.0000] Hixie: "the furthest ancestor element node" doesn't mean anything cross shadom-DOM boundaries, right? [15:02:12.0000] smaug____: Do you mean "how does iframe work when it has a shadow root"? [15:02:53.0000] smaug____: And I believe any algorithm that look at the ancestor list should cross shadow boundaries and walk up the composed tree automatically. [15:03:14.0000] why? [15:03:21.0000] I mean per what spec? [15:04:29.0000] (I could agree iframe should load, but so far I haven't found any spec which says that) [15:10:16.0000] smaug____: no idea [15:10:27.0000] smaug____: i haven't updated any of my specs to handle shadow trees yet [15:10:53.0000] right, so what is implemented in blink is somewhat random [15:11:15.0000] smaug____: Unsure which of my comments your question is in response to. [15:11:51.0000] TabAtkins: to your comment "And I believe any algorithm that look at the ancestor list should cross shadow boundaries and walk up the composed tree automatically." [15:12:45.0000] Ah, kk. That's my personal belief, not one based on a spec ref. ^_^ But if the Shadow DOM spec doesn't define that, it should; for example, form elements inside of shadow DOM should be submitted when placed in an external . [15:12:47.0000] hmm, how should session history work in case there are iframes in shadow dom (assuming those actually load something) [15:13:20.0000] TabAtkins: whaat? form elements should be submitted in that case? [15:14:20.0000] that is surprising [15:15:13.0000] if one just used radio buttons in shadow dom for some UI stuff, their value might get submitted accidentally [15:15:52.0000] yeah i don't think it's as simple as just everything should work like if it was one tree [15:15:53.0000] it should definitely be opt-in behavior to let data to leak out from the shadow dom in such case [15:15:59.0000] i think it probably needs to depend on the binding [15:27:18.0000] smaug____: Hm, valid point. [15:28:07.0000] Domenic: I've got a super-class that's not meant to be used; it's just a holder for default implementations of methods, as it's designed to be extended. Should I have its constructor throw, or produce a valid-but-useless object? [15:28:55.0000] Domenic: (Specifically, I'm defining a set of XXXColor classes for CSS, and have a CSSColor superclass over them. If the constructor should really work, it'll just return an object that represents transparent black, with no way to manipulate it.) [15:30:44.0000] Also, I'm using WebIDL to define the shape of these interfaces, but defining most of the methods by just saying "here's the JS implementation", which is interesting. [15:32:42.0000] i'd just not define a constructor [15:32:53.0000] Gotta have something there. [15:33:15.0000] I forget what happens if you don't define a constructor. [15:33:35.0000] in webidl, if you don't set a [Constructor], you just don't get one [15:33:39.0000] It defines a throwing constructor [15:34:53.0000] TabAtkins: if you can make the throwing constructor work in a JS polyfill without mega-hacks, then that might be best... but I think that breaks inheritance [15:35:24.0000] (by mega-hacks, I mean a constructor that doesn't throw when you pass it an unguessable secret, which all the subclasses know) [15:35:35.0000] Domenic: Why is that necessary? [15:35:44.0000] TabAtkins: why is what necessary? [15:35:59.0000] Allowing the subclasses to construct an instance of the superclass? [15:36:21.0000] TabAtkins: if the superclass has any internal state at all, then you need to call super() in the subclass constructor to initialize it [15:36:32.0000] not necessarily [15:36:39.0000] you could call an internal init() method, e.g. [15:36:45.0000] It doesn't have any. The interface is just some methods, and some static stuff hanging off of it. [15:37:00.0000] TabAtkins: nice, then I think throwing constructor is pretty sound [15:37:09.0000] Okay, cool. [15:37:50.0000] (It has a semi-constructor that takes a string and returns one of its subclasses, but that's exposed as a static method on the interface instead.) [15:38:09.0000] (i mean, Object has some internal state, and yet it's still fine for subclasses to throw even if they then have further subclasses that don't throw) [15:38:11.0000] TabAtkins: as long as it can be JS polyfilled I am happy, even if it's a bit unusual. [15:38:17.0000] Hixie: Object has no internal state [15:38:30.0000] Hixie: but I think you are right that an internal init() method would probably work [15:38:30.0000] Object has quite a lot of internal state :-) [15:38:44.0000] Usually when I use a useless superclass, I just give its constructor an empty body and don't worry about it, becasue I know I'm not going to try and construct it. ^_^ [15:38:59.0000] But I gotta handle authors doing weird stuff. [15:39:08.0000] It would be nice if we had mixins in some first-class way [15:39:10.0000] So I was just wondering which style is more idiomatic - throwing, or dumb object. [15:39:15.0000] Yes. Yes it would be. [15:39:29.0000] That's all I'm using the stupid thing for, after all. [15:39:46.0000] WebIDL implements/ES7 Object.mixin would not allow monkeypatching the mixin and getting those changes shared by all mix-targets [15:39:57.0000] Yeah. [15:40:42.0000] And allowing monkeypatching is precisely why I'm structuring these things the way I am. [15:41:26.0000] (the problem i usually have with throwing constructors is that instances of them somehow exist. but that is not what is going on here.) [15:42:06.0000] Right. [15:42:27.0000] Unless there's some voodoo I'm not thinking of, there's no way to actually get a CSSColor object. [15:42:44.0000] Reflection wouldn't allow that, would it? [15:43:04.0000] Nah, I can't see how [15:43:18.0000] Oh wait, damnit, this isn't the name I wanted. I was going to go with RGBACompatibleColor. [15:43:21.0000] They would have to be exposed through APIs in your specs [15:44:14.0000] Wait... OK this is just a thought experiment, but... [15:44:26.0000] You could define RGBACCPrototype = { ...methods... } [15:44:35.0000] then inherit from that object directly [15:44:58.0000] Instead of defining function RGBACC () { throw new TypeError; }; RGBACC.prototype = { ... methods ... } [15:45:03.0000] Ah, you lose static methods though [15:45:05.0000] I need an RGBACC itself, though, to hang some static methods off of. [15:45:06.0000] Yeah. [15:45:39.0000] And... that pattern (proto-only) is getting very far from idiomatic. [15:47:01.0000] Might be interesting to make this pattern more explicit in IDL with "abstract interface ...", which fails syntax checking if there are any non-static attributes, or any constructors, and which is prohibited to be constructed by specs. [15:47:31.0000] (You'd still be able to use it in IDL itself, to denote an attribute/method that takes/returns any subclass of the interface.) [15:48:15.0000] (Or maybe prohibit it from being used directly, and add another syntax construct like "subclass" that must be used by attributes/methods.) [15:48:34.0000] (Where subclass is only valid when XXX is an abstract interface.) [15:49:01.0000] Unsure if worthwhile, but capturing relatively complex idioms that we want to use consistently is what WebIDL is for. [15:49:20.0000] why would non-static attributes be not ok in an abstract interface? [15:49:37.0000] Because that implies there's state on an instance, but there are no instances, by definition. [15:49:52.0000] i mean, fundamentally, "interface" really means "abstract class". WebIDL doesn't have a "class" concept. [15:49:59.0000] And putting data attributes on a prototype is bad practice. [15:50:10.0000] Node has plenty of attributes [15:50:12.0000] WebIDL's "interface" is JS's "class". [15:50:14.0000] i don't think that's bad practice [15:50:18.0000] I know. It's bad practice. ^_^ [15:50:29.0000] i find distinguishing "interface" from "class with virtual methods" to be a meaningless java-ism [15:50:42.0000] nah, Node isn't bad practice [15:50:49.0000] at least, not that part of it [15:50:55.0000] it's a quite sensible API [15:51:01.0000] If a data property is on a prototype, setting the property actually sets it on the prototype, changing it for *every instance*. That's almost never what you want. [15:51:05.0000] an attribute is fundamentally no different than a method [15:51:08.0000] i think the underlying reason java has it is to avoid issues like diamond inheritance, but there are better solutions to that [15:51:13.0000] And if it is, you can explicitly say so with a getter/setter pair. [15:51:25.0000] there's no difference between getter/setter pairs and data attributes in webidl [15:51:30.0000] Hixie: The "fundamental" difference is that you don't set methods regularly. [15:51:47.0000] setFoo()/getFoo() is equivalent to "attribute foo" [15:51:56.0000] Hixie: Technically, sure, but that's just because the getter/setter pair handle typechecking for you. [15:53:12.0000] Hm, I guess they always set the value on the instance, though. (Or set hidden state on the instance, which is the same thing here.) [15:53:21.0000] So maybe it's not actually terrible. [15:54:28.0000] But still, making the constructor automatically throw with a standard message, and preventing accidentally using the interface directly in other things (thus making it less likely the spec author absentmindedly constructs an instance in prose) might be helpful. [15:56:32.0000] [NoInterfaceObject] is the usual way to prevent that kind of mistake [15:56:47.0000] That prevents you from hanging static things off the interface. [15:57:09.0000] And doesn't prevent the mistake at all - prose can still construct a [NoInterfaceObject] object. [15:57:26.0000] The constructor just isn't present on the global. [15:57:53.0000] oh, from prose [15:58:09.0000] yeah, dunno what's a good way to prevent that kind of mistake [15:58:23.0000] whatever you put in the spec, other spec writers have a tendency to think their case is special :-) [15:58:27.0000] (i include myself in this!) [16:00:01.0000] TabAtkins: seems like a reasonable thing, although I'd like a couple more use cases first. [16:00:18.0000] Domenic: Yeah, it's a use-case-count of 1 right now, which is too small to generalize from safely. [16:00:26.0000] Gotta hit 3 before it's reasonable. ^_^ [16:06:30.0000] putting empty blocks on top of images to break copy image location is the modern-day equivalent of alert("right click is not supported") [16:20:04.0000] oooh, that's evil, i've never seen it before [16:21:30.0000] others put images in css background-images for the same reason [16:22:02.0000] (there are valid reasons to do that, but often it's just to make it harder to get the image url) 2014-07-12 [19:46:16.0000] Hm.. where is the spec for document.cookie / HTMLDocument#cookie ? [19:46:28.0000] MDN links to an old version in the HTML 2 spec on w3.org but can't find much else [19:46:33.0000] http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-8747038 [19:46:51.0000] seems neither html/c nor dom.spec contains any reference to it [19:47:59.0000] github search brought up https://github.com/whatwg/html-differences/blob/1f8778b1e26d98ae1de62ca7e99201c1d90a6a44/Overview.src.html#L3129 [22:39:05.0000] Krinkle|detached: http://www.whatwg.org/html#dom-document-cookie [22:49:59.0000] Someone needs to scrub MDN hard… [02:50:48.0000] /win 17 [03:37:48.0000] Hixie: thanks [03:47:32.0000] Domenic, you could be the MDN scrubber [10:29:43.0000] something that never gets old: squinting at a page for five minutes to figure out where some mysterious 4 pixels of padding is coming from [11:56:42.0000] hmm, http://amjith.blogspot.com/2007/07/visual-diff-tools-in-linux.html does not contain any actual content [11:57:21.0000] just a bunch of divs and some CSS (I think there was some actual CSS in there somewhere) and some scripts ... [11:58:11.0000] and even when I turn on JS, I still don't get to the entry in question [11:58:34.0000] /me wonders if they did the same thing to his blog; if so, he thinks it's time to move it elsewhere ... [11:58:35.0000] using what, netsurf? [11:58:55.0000] caitp: I had noscript on to start with [11:59:16.0000] also I *hate* endless scrolling [11:59:18.0000] but after enabling scripts you still can't see content? huh [11:59:37.0000] there's content, but I did not land at the content I would expect for that URL [12:00:59.0000] but I really hate gratuitously web-1.0-incompatible sites as well as (mandatory) endless scrolling [12:03:16.0000] thankfully, the wayback machine is working :-) [12:03:43.0000] (and broken links, I hate broken links too) [12:06:42.0000] /me edits the link on unix.SE to point at a web.archive.org snapshot ... [12:09:38.0000] you should put the "bad" one in rubytext or something [12:45:54.0000] Hi! What is the subdfn attribute of . There are lots of in in the spec now. A validator complains. [12:53:30.0000] The HTML spec? [12:53:37.0000] Probably a bug in Hixie's new pipeline [12:53:56.0000] Ms2ger: Yes. [12:54:37.0000] And what is the w-nodev attribute of the spans and links? [12:54:47.0000] Same [12:55:12.0000] There are about hundred of them. [12:55:32.0000] one hundred happy accidents is better than zero happy accidents [16:13:57.0000] hm, there shouldn't be any w-nodev attributes, i thought i filtered those out [16:14:06.0000] i did forget to filter out the subdfn ones though... 2014-07-13 [00:12:14.0000] Hi [10:11:49.0000] zcorpan: ping [11:04:02.0000] Hixie: pong [11:32:17.0000] The accessKeyLabel specification does not explicitly state that the node needs to be attached in the document root for the property to resolve. [11:32:19.0000] It seems in Firefox it remains an empty string until attached. [11:32:21.0000] http://jsfiddle.net/R3fNY/ [11:32:23.0000] Does that seem sensible? I'd like to have it changed. [11:32:27.0000] So that e.g. a library using this doesn't have to special-case anything that uses this to after insertion of the widget. [11:32:40.0000] Wikipedia software embeds this (when available) in the title attribute like "caption [ctrl-e]" [11:33:12.0000] We're hoping to phase out the ugly logic that currently infers the keyboard shortcut for accesskeys on all browsers using essentially UA sniffing. [11:36:08.0000] Down stream : https://bugzilla.wikimedia.org/show_bug.cgi?id=67946 ; Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=583533 [11:36:28.0000] I can file a proper bug but would be nice to know whether It'll be backed up by whatwg. [11:40:09.0000] CC me on the Mozilla bug, please. Ms2ger⊙gc [11:41:22.0000] Krinkle: looking... [11:42:55.0000] Krinkle: yeah, it does indeed appear that accesskey="" is defined to be assigned regardless of the element being in the doc [11:43:06.0000] Krinkle: i could go either way on this, fwiw, if the browsers disagree [11:43:18.0000] Firefox is the first one to have implemented it [11:43:29.0000] I've been waiting for WebKit for years [11:43:33.0000] I filed a Chromium ticket today [11:43:58.0000] I'm checking Aurora just in case, and will file a mozilla bug after with you two on CC? [11:48:38.0000] Hixie: https://bugzilla.mozilla.org/show_bug.cgi?id=1037990 [11:51:05.0000] Krinkle: k [11:51:23.0000] Krinkle: keep me posted, especially if the browser vendors have a reason for not wanting to pre-assign the access keys before the element is in the document [11:51:33.0000] Yeah [11:51:52.0000] Seems to be going really slow though. [11:52:46.0000] I mean, Wikipedia editors use accesskeys so much and while you tend to know them once you're used to them, I really want to get rid of this code [11:52:47.0000] https://github.com/wikimedia/mediawiki-core/blob/bc725806ac301baa92b7ff61d958be577e514a0b/resources/src/jquery/jquery.accessKeyLabel.js#L27-L74 [13:36:43.0000] When a test https://github.com/w3c/web-platform-tests does not seem to match the spec, should I file a bug on that repo or on the spec? (The bug could be in the spec as well as in the test) [13:36:59.0000] jgraham: ^ [13:42:05.0000] depends [13:42:18.0000] sometimes the test is wrong, sometimes the spec isn't clear, sometimes both [13:42:32.0000] probably quite often both [13:46:01.0000] SimonSapin: I'd file a bug on the test first [13:46:10.0000] and see if anyone claims the test is right :P [13:48:26.0000] There are test for IPv4 normalization (from octal or hex, with less than four pieces) but the spec does not mention that. https://github.com/w3c/web-platform-tests/issues/1104 [13:48:35.0000] … in URL parsing [13:54:11.0000] SimonSapin: Ask zcorpan I guess [13:54:20.0000] But file a bug on the test [13:55:19.0000] jgraham: that’s on https://github.com/w3c/web-platform-tests/issues/ , right? [13:59:10.0000] from what I've seen, a lot of the tests (for older specs in particular) seem to have either been ported directly from browser tests, or have been heavily influenced by a particular browser's implementation, and don't necessarily assert anything specified anywhere normative [14:00:53.0000] maybe "a lot" is too strong, but a few [14:14:26.0000] SimonSapin: Yeah [14:14:30.0000] caitp: Examples? [14:15:53.0000] jgraham: https://github.com/w3c/web-platform-tests/pull/771/files comes from webkit [14:16:34.0000] and tests behavior that’s not in the spec [14:25:32.0000] jgraham, some of the xhr tests, I raised an issue about one of them which I'm not sure has been resolved yet [14:26:02.0000] basically asserting something which isn't said anywhere in the IETF or WHATWG, far as I can tell [14:26:59.0000] i'm sure there are other examples, but i've only spent any time poking through the XHR tests so far [14:37:32.0000] Well you mainly need to talk to hallvors about that [14:38:07.0000] But actually XHR has an unusually large number of tests that were written especially for the testsuite [14:40:12.0000] https://github.com/w3c/web-platform-tests/issues/980 is interesting, because Chromium (along with webkit/safari and IE) will send a content-length of 0 for HEAD requests, for a reason which is explained in a comment in chrome's source, so I think Firefox is the only mainstream browser that actually passes that test [14:40:50.0000] but none of the HTTP rfcs or anything from the XHR spec say anything about this whatsoever, I spent a good while looking =P [14:41:08.0000] and, it's only the only such case, there are a few others I ran into a while ago [14:42:07.0000] so from my perspective it seems like someone either copy/pasted a test from gecko, or was just looking at the gecko implementation and writing tests based on that, rather than based on the spec itself [14:51:42.0000] SimonSapin: yeah I think all those PR #771 tests came from webkit. I guess I wrongly assumed they were actually testing requirements in a spec. [14:53:26.0000] SimonSapin: Santiago Mola uses them as part of the test suite for galimatias, so I assume galimatias pass those tests. But I don't know whether that's because he implemented something according a particular spec, or whether he implemented something in order to pass those tests. [15:05:00.0000] caitp: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13 seems pretty specific. I haven't checked the updates. [15:06:14.0000] there's nothing in any of those RFCs which says anything like "a client MUST not send an entity body if the request method is HEAD or GET" [15:06:40.0000] at best there's a "should not", or "probably not a good idea" [15:06:42.0000] I thought one the httpbis things changed that? [15:07:14.0000] but if it weren't a good idea, the big 3 browsers would probably be thoroughly broken any time anyone ever wanted to send a HEAD request [15:09:21.0000] basically http just doesn't care if there's a payload or not [15:09:37.0000] http doesn't care, and xhr doesn't care, so it's not clear why we're making any assertion in the first place [15:10:36.0000] caitp: Anyway what zcorpan says in that bug is right [15:10:46.0000] The goal is to get interop [15:10:55.0000] yes, I agree with that [15:11:07.0000] but my position is still that we should be testing compliance with the spec [15:11:18.0000] not with a particular implementation [15:11:19.0000] In this case it seems like specs are half-assing things and we should just agree what the right behaviour is and get everyone to implement it [15:11:44.0000] caitp: We're not [15:12:01.0000] You are assuming some sort of malice here when there is none [15:12:08.0000] oh no no no [15:12:14.0000] i'm not assuming malice [15:12:36.0000] it's not "malice", it seems like an honest mistake, like maybe it's testing something that _should_ be specified but isn't [15:12:57.0000] but regardless, no implementation that I've seen (not tested netsurf, does netsurf even have XHR yet?) passes that test, apart from gecko [15:14:06.0000] the comment which explains this reasoning for this behaviour in chromium is interesting, I linked to it in either the issue or PR [15:14:34.0000] http://mxr.mozilla.org/chromium/source/src/net/http/http_network_transaction.cc#866 [15:15:19.0000] when you word the reasoning like that, it's almost a "feature" to send the header [15:15:21.0000] Presto passes [15:15:39.0000] okay, opera might still pass without opera, since it's not blink which breaks this [15:15:42.0000] er [15:15:46.0000] opera might still pass without presto* [15:16:17.0000] not sure if modern opera shares more of the chromium tree or if it's just blink [15:16:27.0000] it's the chromium content api [15:16:36.0000] ah [15:16:59.0000] (which was why when Blink happened there was no practical choice) [15:17:43.0000] interesting =) [15:21:00.0000] Anyway, I don't think it's reasonable to assume that Blink behaviour is somehow more authorative than Gecko. The only relevant question is "what will everyone agree to implement". If you think gecko should change, file a bug. Or if you think that Blink+etc. should, file bugs there. It seems like there can't be a strong compat. argument either way, so there ought not to be too much resistance to changing. Reality might not be so straightforward. [15:21:24.0000] Also yell at the IETF for not specifying anything clear and unambiguous here [15:21:43.0000] that's not it, per se, i am just not sure it's right to assert things which aren't specified anywhere [15:22:03.0000] i agree that changing the test to assert for just a falsy content-length request header isn't right [15:22:44.0000] hmm webkit nightly and ie11 still fail that test, so I guess it's still true [15:23:20.0000] I think it's better to have tests and argue about what the result should be than weaken the test just because people have failed to achieve interop [15:24:03.0000] caitp: webkit doesn't have a single network layer, FWIW, depends on port [15:25:14.0000] if one line of code was changed in a fork of chromium, "chromium would pass", too :p [15:25:32.0000] but yeah you're right [15:26:03.0000] primarily referring to http://nightly.webkit.org/, which is basically safari afaict [15:26:55.0000] IIRC it uses the system Safari with a bit of magic [15:27:02.0000] so yeah, that uses NSURL [15:28:28.0000] MikeSmith: Galimatias does have code for parsing IPv4, but seems to handle none of the funny cases I mentioned in the bug [15:28:56.0000] anyhow, in the case of that particular issue, I'm not sure it matters a whole lot if browsers behave identically or not. like, the web doesn't care [15:29:06.0000] so it's just a weird assertion to make [15:29:25.0000] anyways, time to drop it and make dinner, fun chat \o [15:30:48.0000] Every time we decide that poor interop is OK, the web gets a little bit harder to author content for, and other platforms get a little more compelling [15:31:05.0000] So it's not a great position to take [15:33:03.0000] SimonSapin: ok, so yeah, would be good to hear back from smola 2014-07-14 [02:46:58.0000] I guess all the webperf stuff is not exposed in workers? [03:58:44.0000] Should one expose MouseEvent in workers? [04:46:03.0000] hey guys [04:46:41.0000] I'm having an issue with fs.utimes because it is messing with ctime [04:47:00.0000] is it expected? Or was it expected to change only the mtime & atime as the documentation says? [04:50:09.0000] oops [04:50:11.0000] wrong channel [04:50:13.0000] ahahz [06:10:44.0000] If the browser receives "Hello w" is there any way to tell that's an incomplete response vs the server intending to send that? [06:10:56.0000] Assuming Content-Length is not to be trusted [06:11:28.0000] Content-Length has to be trusted [06:12:02.0000] At least in HTTP 1.1 [06:12:20.0000] In 1.0 you could theoretically rely on the server to close the connection I think [06:12:35.0000] So if we get a response longer/shorter than Content-Length, what happens? [06:13:18.0000] shorter you just hang until you timeout [06:14:17.0000] longer is more complex :P [06:17:13.0000] Then I shall build a test. Quick, to the local server! *nodejs logo zooms into the screen & back out again* [06:17:41.0000] You could build a test that you could submit to web-platform-test, you know [06:17:56.0000] Like http://w3c-test.org/http/ [06:19:28.0000] The test there is a simple "too long" test [06:19:44.0000] From when annevk was asking about the same things [06:24:30.0000] JakeA: longer depends on things like whether pipelining support is enabled, IIRC [06:26:54.0000] jgraham: Is that documented somewhere, like how to get a local version running for development [06:28:10.0000] https://github.com/w3c/web-platform-tests has basic documentation [06:28:51.0000] http://wptserve.readthedocs.org/en/latest/ has more detailed server documentation [06:29:28.0000] It should all end up on testthewebforward.org, but unfortunately I* need to do quite a bit of infrastructure work on the site to make that happen [06:29:34.0000] *Or someone else of course [07:17:01.0000] why do we need Fetch API? [07:34:09.0000] smaug____: I think it's fair to say we don't *need* it. We might want it though. [07:34:43.0000] ok, why do we want it [07:34:48.0000] XHR isn't too good, sure [07:35:07.0000] but so aren't many other APIs [07:39:01.0000] I believe "we have lots of crappy APIs therefore having crappy APIs is OK" isn't universially considered to be a winning argument [07:46:09.0000] SimonSapin: sounds like those IPv4 tests are broken [07:46:28.0000] SimonSapin: IPv4 is basically no different from a domain per the specification in terms of parsing [07:46:43.0000] SimonSapin: resolving any other numeric sequence as IPv4 is bad for security [07:47:31.0000] annevk: looks like at least Firefox and Chrome do it [07:47:54.0000] SimonSapin: I know, Safari doesn't [07:49:39.0000] smaug____: ServiceWorker needs Request/Response. Also opaque responses for corss-origin no-cors requests [07:50:22.0000] JakeA: In principle you could add Request/Response to XHR, so it doesn't fully justify Fetch [07:50:35.0000] And certainly not Fetch-in-document [07:52:16.0000] I suppose you could hack it on, but ugh [07:52:17.0000] Speaking of Service Worker, is there a mechanism for communicating from the main thread to a service worker when it is launched? e.g. could you use the document fragment? [07:52:27.0000] s/document/URL/ [07:52:51.0000] annevk: So Safary tries to resolves these addresses from DNS? [07:52:57.0000] Safari [07:53:23.0000] SimonSapin: not sure exactly how the network layer deals with the address given [07:54:10.0000] SimonSapin: file a bug if it's still unclear, I got some tea and chocolate to take care of [07:54:39.0000] jgraham: you could use fragment, but that can only be set at registration time [07:54:49.0000] annevk: I filed https://github.com/w3c/web-platform-tests/issues/1104 , should it be in the spec’s bugzilla instead? [07:55:19.0000] JakeA: I think that might be OK here? [07:55:44.0000] jgraham: What's the use-case? [07:56:17.0000] SimonSapin: maybe, let's talk about it two weeks from now [07:56:28.0000] The context is a mechanism to pass harness configuration parameters in to testcases. In particular the timeout. For normal tests this is set in a meta element in the HTML document so that it can be read by the manifest generation stuff [07:56:47.0000] So only being able to specify it in JS isn't very helpful [07:56:52.0000] annevk: who two weeks, are you gonna be in London? [07:57:17.0000] In the worst case, I guess I could use specially formatted comments or similar [07:57:20.0000] SimonSapin: no, but I won't be on vacation [07:57:27.0000] eh, ok :) [08:05:47.0000] jgraham: Yeah, fragment or querystring would work then. [08:12:02.0000] JakeA: why does serviceworker even need Request/Response ? (but yes, those could be hacked into XHR) [08:12:12.0000] /me is just trying to understand the reasoning behind Fetch API [08:12:31.0000] /me doesn't have any opinion whether the API is a good or bad thing [08:13:46.0000] smaug____: the fetch event of the serviceworker allows developers to hijack a request and respond differently. Request lets them get information about the intended request, Response lets them construct their own. [08:33:59.0000] JakeA: why do both Request and Response have a .body? [08:34:35.0000] Domenic: If I'm posting formdata to a server, that request has a body [08:34:55.0000] Domenic: if the server responds with "yay everything's great", that response has a body [08:35:04.0000] JakeA: OK, but why would you readAsJSON() the request body? [08:36:01.0000] Domenic: If the content type of the body is json & you want to read it [08:36:16.0000] JakeA: but you put the data there, so you shouldn't need to read it... [08:36:32.0000] JakeA: and in fact having the ability to read it means that you must buffer it all in memory in case someone does read it [08:37:27.0000] Domenic: The page may have put it there, but you still may want to read it, or pipe it into another request with a transform in the middle [08:37:40.0000] Eg, convert formdata into JSON for another endpoint [08:37:49.0000] JakeA: then you should do that before writing it to the request [08:38:02.0000] JakeA: forcing buffering of all the data in memory that you write to the request is quite bad [08:38:31.0000] Domenic: Where is that being forced? [08:38:43.0000] JakeA: the fact that you can call readAsJSON() at any time on the request body stream forces that [08:38:52.0000] JakeA: it means you can't fire-and-forget bytes over the wire [08:40:08.0000] Domenic: if you call asJSON you're consuming the stream & yes you'll have to read it into memory. If you don't call that, you don't. [08:40:21.0000] Domenic: Same with responses [08:41:11.0000] JakeA: that doesn't make sense. The fact that someone *could* call readAsJSON() means that the socket can never consume data from the request body directly. You need to copy all the buffers that are written to the request body somewhere temporary in case someone calls requestBody.readAsJSON() later, even after the HTTP connection is closed, as long as [08:41:11.0000] requestBody is not GCed [08:41:57.0000] That's true, but is it a problem? [08:42:06.0000] It *might* be [08:42:12.0000] Domenic: once the request is given to something like fetch(), its body stream is consumed [08:42:31.0000] JakeA: so calling readAsJSON() errors? [08:42:44.0000] Domenic: yes [08:43:00.0000] JakeA: so that means FetchBodyStream is a readable stream. So how do you write to it? [08:43:45.0000] Domenic: new Request(url, {body: stream}) [08:43:55.0000] JakeA: how do you write to stream? Since it is readable, not writable [08:46:18.0000] Domenic: I'm not up-to-date on the plans for the streaming API. If I wanted to create my own readable stream, how would I do that? [08:46:42.0000] JakeA: https://whatwg.github.io/streams/#rs-intro [08:48:34.0000] Domenic: start(enqueue, close, error) { - is that creating a "start" property on that object? [08:50:39.0000] Domenic: Assuming yes, you could create a readable stream like that & use it when constructing a Request object [08:51:39.0000] Domenic: You should be able to pipe a response body into a new request [08:52:26.0000] JakeA: that's the thing though. You pipe to writable streams, not to readable streams [08:52:34.0000] JakeA: see my latest email to whatwg@ [08:53:00.0000] you are proposing option 2 in my email, I guess. Which is kinda annoying and unidiomatic, from a streams point of view. [08:53:35.0000] Domenic: you're not piping to a readable stream, you're passing a stream into the constructor (which will also take a blob, arraybuffer etc) [08:54:31.0000] JakeA: yes, that is the problem, you can no longer pipe or write directly, you have to wrap things into readable streams [08:55:21.0000] JakeA: ideally things you can write to are represented as writable streams, not as functions accepting readable streams [08:56:34.0000] Domenic: ahh ok, understanding better now [08:57:08.0000] reading that thread… [09:17:13.0000] Domenic: If a request comes into a serviceworker, you don't want that to have a writable stream. Its data is already being provided by something else. [09:17:58.0000] JakeA: ah, the old client-request vs. server-request thing... [09:18:08.0000] fetch(request) should take a client-request [09:18:16.0000] service workers should get a server-request [09:18:31.0000] hmm, I should be able to do fetch(event.request) [09:20:12.0000] you should? [09:20:40.0000] from a server's point of view, a request contains data to read [09:20:47.0000] from a client's point of view, a request is something you write to [09:20:56.0000] i am not sure how you would reconcile that [09:21:04.0000] one is mutable, the other is immutable [09:22:29.0000] Domenic: Say I get a fetch event, which gives me a request object, how should I then fetch it so I can look at headers before doing something with the response? [09:24:27.0000] JakeA: well, yeah, I see the use case. My only answer is a bad one... essentially copying over the relevant info (URL, headers, body, ...) from the request-to-the-service-worker into a new request-to-the-remote-server [09:25:21.0000] Let me see if I can recall how/if Node does this... it might be just copying though, which is bad, in which case we'll have to think of something else [09:27:39.0000] JakeA: yeah, it is pretty much just copying, meh... http://stackoverflow.com/a/20354642/3191 [09:31:00.0000] JakeA: ends up looking like https://gist.github.com/domenic/1bbec0f341ae3cfb3a8f in service-worker land... [09:32:03.0000] JakeA: now I am thinking making it a writable stream is not worth the trouble... [09:32:20.0000] JakeA: or maybe we should make it a duplex stream [09:32:55.0000] (i.e. { input, output } pair, possibly { input, output, readAsJSON, ... }, or maybe put readAsJSON on output, at the cost of more typing...) [09:33:52.0000] Domenic: Would that be a different type to the request I get on the fetch event? [09:34:20.0000] JakeA: in the gist? yeah it should say ClientRequest; ev.request is a ServerRequest [09:34:39.0000] JakeA: the difference being that req.body is writable for ClientRequest, readable for ServerRequest [09:34:41.0000] Domenic: I mean your duplex idea [09:35:14.0000] JakeA: the duplex idea would be that both client and servers re-use the same Request class, but req.body = { WritableStream input, ReadableStream output } [09:35:54.0000] JakeA: conceptually, a client will start with an "empty" stream, and write things into input [09:36:07.0000] JakeA: whereas a server will start with a "full" stream and read things from output [09:36:36.0000] JakeA: for a client, once they write things into input, the computer then reads from output to consume the data. (Or, they could muck things up by consuming from output themselves, ensuring the network never sees that data.) [09:37:14.0000] JakeA: similarly for a server, the computer is writing things into input---or they could do so themselves, creating some chaos by mixing up computer-generated stream data with their own [09:38:46.0000] Domenic: I'm trying to get my head around why var req = new Request(url, {method: "POST"}); stream.pipeTo(req.body); is better than var req = new Request(url, {method: "POST", body: stream}); [09:40:35.0000] JakeA: in the simplest case, it is not any better. But if you want to allow the full flexibility of a writable stream---it's own buffer, potentially combining input from multiple sources, setting up a pipe chain through several transforms, ... then having a writable destination is nice. [09:42:54.0000] JakeA: the duplex idea was designed to avoid such shenanigans [09:43:20.0000] JakeA: since you could just pass the duplex stream from ev.request into fetch(), since fetch() reads from the output side [09:55:57.0000] Domenic: still want to support setting the body as a blob, but I guess you'd still have an input, it'd just mess things up in new & interesting ways if you tried to use it [10:58:34.0000] so what do people think cross-spec references should look like? [10:58:48.0000] should every link to "URL" in the URL spec have a [URL] reference? [10:59:12.0000] should i not bother with [FOO] references except where there's no direct link to the spec? [10:59:17.0000] should i drop [FOO]-style refs entirely? [11:00:03.0000] cross-spec references should: not require you to scroll to the end of the (likely very, very long document) to find links to the specs [11:00:22.0000] yeah that's a given [11:00:44.0000] assume that the links are now real cross-spec links [11:59:20.0000] Hixie: What do you mean by "[FOO]" references? i.e. what's the distinguishing feature that you have in mind? [12:03:23.0000] jgraham: so right now the spec says things like "The foobar is a blooberry. [FOO]" [12:03:38.0000] jgraham: which then links to the References section and describes the Foo spec [12:03:51.0000] so i'd like "foobar" here to link directly to the definition of "foobar" in the Foo spec [12:04:12.0000] but what about the next paragraph, which also has a "foobar" in it? Should it also say [FOO]? Should neither say [FOO]? [12:04:22.0000] the [FOO] right now is just included where i made an editorial decision to include it [12:04:28.0000] it's somewhat arbitrary [12:05:06.0000] also, what about cases where there's no specific term, but still a reference to another spec, e.g.: "Implementations that support the XHTML syntax must support some version of XML, as well as its corresponding namespaces specification, because that syntax uses an XML serialisation with namespaces. [XML] [XMLNS]" [12:05:50.0000] basically i'm asking what you think cross-spec references should look like if we forget our legacy [12:05:55.0000] Well arguably in that case "XML" and "namespaces" should be linked [12:06:04.0000] to just the specs? [12:06:09.0000] Yeah [12:06:18.0000] Hixie: from my perspective, in a single paragraph, you shouldn't have multiple links to the same section of a referenced spec [12:06:25.0000] maybe in the same group of paragraphs [12:06:48.0000] caitp: well i want every reference to a term to link to the same place [12:06:53.0000] ink consistently linking terms defined elsewhere like you would terms defined in the spec makes much more sense [12:07:00.0000] *I think [12:07:18.0000] so drop the whole [FOO]-style refernece thing and the references section? [12:08:35.0000] what I mean is, `The foobar is a blooberry. The foobar makes a delicious pie.` should end up as `The [FOO#foobar] is a blooberry. the foobar makes a delicious pie.` and not The [FOO#foobar] is a blooberry. the [FOO#foobar] makes a delicious pie.` [12:08:38.0000] Well you could have a references section that would just be a list of other specs that get referenced [12:08:44.0000] But I don't know how useful it is [12:08:48.0000] otherwise it just gets a bit link-spammy [12:09:29.0000] caitp: It shouldn't use a different style compared to internal references [12:09:38.0000] jgraham: but not link to it? [12:09:55.0000] the notation is just indicating that it's a link to the foobar section of the FOO spec [12:10:01.0000] not that it's a different style [12:10:07.0000] Hixie: I don't think linking to it is all that practical [12:10:15.0000] jgraham: k [12:10:34.0000] caitp: Right, I meant "style" in the sense of "how often it links" [12:10:48.0000] caitp: the problem is that if different occurences of the term look different (e.g. one is a link, one is not) then it's confusing. [12:10:59.0000] i.e. my suggestion is "do what you already do and ignore the difference between internal and external references" [12:11:01.0000] hmm, that's true [12:11:04.0000] caitp: i think with the current underline-less style, link-spamminess is much less of a problem [12:11:30.0000] well you probably do want to clearly identify that it's a link to somewhere else [12:11:33.0000] The reasons I can think of to maintain [FOO]-style links to a references section are (1) use of the spec when printed and (2) adding additional metadata, such as a specific version/date. Neither of which seem to be worth the visual noise and maintenance burden, but YMMV. [12:11:38.0000] In terms of visual style a small marker to indicate an external link might be nice. Maybe *that* could link to the references section, if you want such a thing [12:12:32.0000] jsbell: well we don't include the version or date anyway, since we're always linking to the latest revision [12:12:41.0000] Yep. [12:13:22.0000] jgraham: it's been suggested that links to terms should have a popup that inline the definition and text around it. i figured for external links this would include the reference or something. [12:13:36.0000] though kittens know how i figure out what reference to actually use [12:13:45.0000] but that's a separate issue [12:14:05.0000] one thing is that MikeSmith wanted the references section to link to all the sections that referenced the spec in question [12:14:11.0000] which would be harder if there's no marker to link back to... [12:14:16.0000] Hixie: Oh well if you are going fancy, that could work. But it's not clear to me that inlining the reference is at all practical [12:14:27.0000] e.g. if it's the whole XML spec [12:14:37.0000] jgraham: i just meant the title and editor names and so on [12:15:26.0000] ok i guess for now i'm going to leave the [FOO] links alone and think about it some more, and i'll make the cross-spec links completely independent of this [12:15:45.0000] no magic to autoinsert the right [FOO]s when there's a cross-spec cross-ref or whatever [12:22:02.0000] Hixie: FWIW, I use real cross-ref links everywhere, and only add a [FOO] to the first instance where a particular spec is linked [12:22:14.0000] that makes sense [12:22:36.0000] mainly to build the reference index [12:26:37.0000] dglazkov_: ping [12:31:06.0000] man there sure are a lot of s in the HTML spec that aren't used by anything in the spec [13:53:58.0000] تحذير [13:53:59.0000] warning [13:53:59.0000] you may be watched [13:53:59.0000] do usa&israel use the internet(facebook,youtube,twitter, chat rooms ..ect)to spy?? [13:53:59.0000] do usa&israel use the internet 2 collect informations,,can we call that spying?? [14:08:00.0000] not just usa&israel, i would imagine... [14:09:01.0000] well that was interesting [14:13:08.0000] Thinking of standardizing Wake Locks. Use cases: https://w3c-webmob.github.io/wake-lock-use-cases/ [14:13:26.0000] would appreciate any feedback before proposing an API [14:19:34.0000] books doesn't seem like a good use case, you don't want to fall asleep reading a book on your ipad and have the system prevented from going to sleep o_o [14:20:36.0000] marcosc: my immediate reaction to the first sentence ("The web platform currently lacks a means to prevent a device from entering a power-saving state (i.e., some means that prevents an aspect of the system from "going to sleep").") was "and that's why i love the web" [14:21:13.0000] don't media elements offer an attribute or something to prevent sleep? I thought they did but can't recall [14:22:30.0000] marcosc: your document seems woefully short on abuse considerations [14:22:30.0000] maybe it's just a default chosen by the implementation, I dunno [14:22:53.0000] marcosc: i would have an additional requirement, namely "the page must not be able to get any kind of wake lock without user opt-in" [14:24:35.0000] really video elements seem like the only legitimate use case where you're going to leave the browser running for a specific use in the platform [14:26:10.0000] otherwise, if you're a kiosk, you're disabling sleep on the system itself, if you're a videogame you're getting user input periodically, if you're a book you're turning pages, if you're a map/gps you're probably not a web browser unless someone is just printing directions out or something [14:26:48.0000] i don't see why Google Maps shouldn't support navigation on a phone [14:26:53.0000] i think that use case makes emminent sense [14:27:24.0000] i mean there's nothing really about the native Android Google Maps app that shouldn't be possible from a web app, imho [14:28:56.0000] Hixie: you might use google maps on a phone, that would be fine [14:29:13.0000] but you probably are using the android or ios app [14:29:19.0000] which can keep the device awake natively [14:29:33.0000] but why should google need to make two or more navigation apps? instead of just a web app? [14:29:34.0000] easier on the battery too, quite likely [14:30:05.0000] well, google already does [14:30:09.0000] i see no reason why a web app shouldn't be able to do everything a native maps app can do, with no compromises (e.g. no worse battery usage) [14:30:09.0000] and if they didn't, someone else would [14:30:17.0000] (and someone else does, actually) [14:30:22.0000] but why is that a good thing? [14:30:29.0000] because it is [14:30:32.0000] ... [14:30:42.0000] game over: you have lost your argument [14:30:46.0000] lol [14:31:13.0000] it's a good thing because other platforms do more than the web platform without going through the process of needing to get other implementations working the same way [14:31:20.0000] and without being blocked on bugs in different implementations [14:31:41.0000] that arguments generalises to all features, and suggests the web shouldn't exist. [14:31:52.0000] and that's really a logical conclusion, when you get down to it [14:32:10.0000] Hixie: true about abuse cases. Will add that. [14:32:41.0000] caitp: the web provides a key feature that none of the other platforms provides: it's vendor-neutral. the same app can work on any platform. [14:32:46.0000] caitp: that alone justifies its existence, imho [14:32:50.0000] it's not really vendor-neutral, though [14:32:53.0000] it's not [14:32:58.0000] we try, we do try [14:33:00.0000] but it's not [14:33:16.0000] with simple documents we get pretty close [14:33:25.0000] caitp: did you read the document? [14:33:32.0000] caitp: by definition, anything that isn't interoperable across multiple vendors isn't part of the web. :-) [14:34:52.0000] Hixie, when you add things to the web platform, you have this huge pile of constraints which aren't related whatsoever to the problem you're actually trying to solve [14:35:11.0000] because of this, the web is not the single platform for all things [14:35:15.0000] that also describes every other platform, especially the old ones [14:35:16.0000] it can't be, it's not possible :( [14:35:43.0000] it would be cool if it were possible [14:35:45.0000] your argument is essentially "the web isn't perfect, therefore it's got no value" [14:35:54.0000] I never said it had no value =) [14:35:58.0000] and things aren't that black and white [14:36:07.0000] but it's got too many problems which will keep it from progressing in a meaningful way for some of these things [14:36:23.0000] security issues, limitations of imperative languages, lack of imperative languages, etc [14:36:41.0000] performance issues, energy cost issues [14:36:55.0000] caitp: about games, search for Magic the gathering. Also, see the first example in "other applications". [14:36:58.0000] too many responsibilities -> never going to be good at everything you need it to be [14:37:08.0000] we're literally working on every single one of those [14:37:23.0000] i know they're being worked on, but it's never really going to "work" [14:37:59.0000] right now I'm risking a chemical and electrical fire because a web application is heating my laptop to 160F while I'm sitting in a meeting [14:38:16.0000] caitp: https://www.youtube.com/watch?v=pWdd6_ZxX8c [14:38:23.0000] this is a prime example of the web not doing a great job for all things [14:38:31.0000] not that the web is bad [14:38:33.0000] the web is awesome [14:38:40.0000] you realise that _no_ platform does "a great job for all things" right [14:38:42.0000] but it's not the be-all-end-all solution for everything [14:39:08.0000] no, but sometimes C# or ObjC or Java or C++ does a better job of solving a given problem [14:39:22.0000] (easier than say, javascript + API bindings into someone elses C++) [14:39:48.0000] sure. there are multiple projects ongoing for providing ways to compile C++ to a form that runs on any browser. [14:40:02.0000] not to mention that many web apps are now written in Java using GWT, etc. [14:40:03.0000] yeah but that's not really a solution :p [14:40:14.0000] running in a browser isn't really any better than running in anything else [14:40:18.0000] well, again, https://www.youtube.com/watch?v=pWdd6_ZxX8c [14:40:46.0000] there's nothing that makes an app that runs in IE any better than an app that runs in MS-DOS [14:41:05.0000] ... [14:41:16.0000] that's just objectively false [14:41:19.0000] it could be the exact same application, running it in IE wouldn't be any better [14:41:27.0000] it wouldn't necessarily be worse, but it wouldn't be better [14:41:36.0000] running in a browser doesn't "improve" anything [14:42:21.0000] the browser is just the runtime [14:42:22.0000] hixie, adding the user opt-in requirement also. Thanks for the feedback. [14:42:59.0000] i don't care if it's IE or Chrome OS or whatever [14:43:08.0000] ISTM that wake lock shouldn't be API, but should simply be something UAs do themselves [14:43:09.0000] yes, it's the runtime [14:43:10.0000] in fact the whole point is that it can be any of the browsers [14:43:11.0000] and the runtime doesn't matter [14:43:22.0000] the browser being a runtime isn't an improvement [14:43:31.0000] it's not a detriment in all cases, but it's not an improvement [14:43:32.0000] the improvement is that there's multiple runtimes [14:43:35.0000] like, if i take a