| 09:46 | <Ms2ger> | I guess all the webperf stuff is not exposed in workers? |
| 10:58 | <Ms2ger> | Should one expose MouseEvent in workers? |
| 11:46 | <satazor> | hey guys |
| 11:46 | <satazor> | I'm having an issue with fs.utimes because it is messing with ctime |
| 11:47 | <satazor> | is it expected? Or was it expected to change only the mtime & atime as the documentation says? |
| 11:50 | <satazor> | oops |
| 11:50 | <satazor> | wrong channel |
| 11:50 | <satazor> | ahahz |
| 13:10 | <JakeA> | If the browser receives "<body>Hello w" is there any way to tell that's an incomplete response vs the server intending to send that? |
| 13:10 | <JakeA> | Assuming Content-Length is not to be trusted |
| 13:11 | <jgraham> | Content-Length has to be trusted |
| 13:12 | <jgraham> | At least in HTTP 1.1 |
| 13:12 | <jgraham> | In 1.0 you could theoretically rely on the server to close the connection I think |
| 13:12 | <JakeA> | So if we get a response longer/shorter than Content-Length, what happens? |
| 13:13 | <gsnedders> | shorter you just hang until you timeout |
| 13:14 | <gsnedders> | longer is more complex :P |
| 13:17 | <JakeA> | Then I shall build a test. Quick, to the local server! *nodejs logo zooms into the screen & back out again* |
| 13:17 | <jgraham> | You could build a test that you could submit to web-platform-test, you know |
| 13:17 | <jgraham> | Like http://w3c-test.org/http/ |
| 13:19 | <jgraham> | The test there is a simple "too long" test |
| 13:19 | <jgraham> | From when annevk was asking about the same things |
| 13:24 | <gsnedders> | JakeA: longer depends on things like whether pipelining support is enabled, IIRC |
| 13:26 | <JakeA> | jgraham: Is that documented somewhere, like how to get a local version running for development |
| 13:28 | <jgraham> | https://github.com/w3c/web-platform-tests has basic documentation |
| 13:28 | <jgraham> | http://wptserve.readthedocs.org/en/latest/ has more detailed server documentation |
| 13:29 | <jgraham> | 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 |
| 13:29 | <jgraham> | *Or someone else of course |
| 14:17 | <smaug____> | why do we need Fetch API? |
| 14:34 | <jgraham> | smaug____: I think it's fair to say we don't *need* it. We might want it though. |
| 14:34 | <smaug____> | ok, why do we want it |
| 14:34 | <smaug____> | XHR isn't too good, sure |
| 14:35 | <smaug____> | but so aren't many other APIs |
| 14:39 | <jgraham> | I believe "we have lots of crappy APIs therefore having crappy APIs is OK" isn't universially considered to be a winning argument |
| 14:46 | <annevk> | SimonSapin: sounds like those IPv4 tests are broken |
| 14:46 | <annevk> | SimonSapin: IPv4 is basically no different from a domain per the specification in terms of parsing |
| 14:46 | <annevk> | SimonSapin: resolving any other numeric sequence as IPv4 is bad for security |
| 14:47 | <SimonSapin> | annevk: looks like at least Firefox and Chrome do it |
| 14:47 | <annevk> | SimonSapin: I know, Safari doesn't |
| 14:49 | <JakeA> | smaug____: ServiceWorker needs Request/Response. Also opaque responses for corss-origin no-cors requests |
| 14:50 | <jgraham> | JakeA: In principle you could add Request/Response to XHR, so it doesn't fully justify Fetch |
| 14:50 | <jgraham> | And certainly not Fetch-in-document |
| 14:52 | <JakeA> | I suppose you could hack it on, but ugh |
| 14:52 | <jgraham> | 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? |
| 14:52 | <jgraham> | s/document/URL/ |
| 14:52 | <SimonSapin> | annevk: So Safary tries to resolves these addresses from DNS? |
| 14:52 | <SimonSapin> | Safari |
| 14:53 | <annevk> | SimonSapin: not sure exactly how the network layer deals with the address given |
| 14:54 | <annevk> | SimonSapin: file a bug if it's still unclear, I got some tea and chocolate to take care of |
| 14:54 | <JakeA> | jgraham: you could use fragment, but that can only be set at registration time |
| 14:54 | <SimonSapin> | annevk: I filed https://github.com/w3c/web-platform-tests/issues/1104 , should it be in the spec’s bugzilla instead? |
| 14:55 | <jgraham> | JakeA: I think that might be OK here? |
| 14:55 | <JakeA> | jgraham: What's the use-case? |
| 14:56 | <annevk> | SimonSapin: maybe, let's talk about it two weeks from now |
| 14:56 | <jgraham> | 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 |
| 14:56 | <jgraham> | So only being able to specify it in JS isn't very helpful |
| 14:56 | <SimonSapin> | annevk: who two weeks, are you gonna be in London? |
| 14:57 | <jgraham> | In the worst case, I guess I could use specially formatted comments or similar |
| 14:57 | <annevk> | SimonSapin: no, but I won't be on vacation |
| 14:57 | <SimonSapin> | eh, ok :) |
| 15:05 | <JakeA> | jgraham: Yeah, fragment or querystring would work then. |
| 15:12 | <smaug____> | JakeA: why does serviceworker even need Request/Response ? (but yes, those could be hacked into XHR) |
| 15:12 | smaug____ | is just trying to understand the reasoning behind Fetch API |
| 15:12 | smaug____ | doesn't have any opinion whether the API is a good or bad thing |
| 15:13 | <JakeA> | 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. |
| 15:33 | <Domenic> | JakeA: why do both Request and Response have a .body? |
| 15:34 | <JakeA> | Domenic: If I'm posting formdata to a server, that request has a body |
| 15:34 | <JakeA> | Domenic: if the server responds with "yay everything's great", that response has a body |
| 15:35 | <Domenic> | JakeA: OK, but why would you readAsJSON() the request body? |
| 15:36 | <JakeA> | Domenic: If the content type of the body is json & you want to read it |
| 15:36 | <Domenic> | JakeA: but you put the data there, so you shouldn't need to read it... |
| 15:36 | <Domenic> | 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 |
| 15:37 | <JakeA> | 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 |
| 15:37 | <JakeA> | Eg, convert formdata into JSON for another endpoint |
| 15:37 | <Domenic> | JakeA: then you should do that before writing it to the request |
| 15:38 | <Domenic> | JakeA: forcing buffering of all the data in memory that you write to the request is quite bad |
| 15:38 | <JakeA> | Domenic: Where is that being forced? |
| 15:38 | <Domenic> | JakeA: the fact that you can call readAsJSON() at any time on the request body stream forces that |
| 15:38 | <Domenic> | JakeA: it means you can't fire-and-forget bytes over the wire |
| 15:40 | <JakeA> | 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. |
| 15:40 | <JakeA> | Domenic: Same with responses |
| 15:41 | <Domenic> | 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 |
| 15:41 | <Domenic> | requestBody is not GCed |
| 15:41 | <jgraham> | That's true, but is it a problem? |
| 15:42 | <jgraham> | It *might* be |
| 15:42 | <JakeA> | Domenic: once the request is given to something like fetch(), its body stream is consumed |
| 15:42 | <Domenic> | JakeA: so calling readAsJSON() errors? |
| 15:42 | <JakeA> | Domenic: yes |
| 15:43 | <Domenic> | JakeA: so that means FetchBodyStream is a readable stream. So how do you write to it? |
| 15:43 | <JakeA> | Domenic: new Request(url, {body: stream}) |
| 15:43 | <Domenic> | JakeA: how do you write to stream? Since it is readable, not writable |
| 15:46 | <JakeA> | 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? |
| 15:46 | <Domenic> | JakeA: https://whatwg.github.io/streams/#rs-intro |
| 15:48 | <JakeA> | Domenic: start(enqueue, close, error) { - is that creating a "start" property on that object? |
| 15:50 | <JakeA> | Domenic: Assuming yes, you could create a readable stream like that & use it when constructing a Request object |
| 15:51 | <JakeA> | Domenic: You should be able to pipe a response body into a new request |
| 15:52 | <Domenic> | JakeA: that's the thing though. You pipe to writable streams, not to readable streams |
| 15:52 | <Domenic> | JakeA: see my latest email to whatwg@ |
| 15:53 | <Domenic> | you are proposing option 2 in my email, I guess. Which is kinda annoying and unidiomatic, from a streams point of view. |
| 15:53 | <JakeA> | 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) |
| 15:54 | <Domenic> | JakeA: yes, that is the problem, you can no longer pipe or write directly, you have to wrap things into readable streams |
| 15:55 | <Domenic> | JakeA: ideally things you can write to are represented as writable streams, not as functions accepting readable streams |
| 15:56 | <JakeA> | Domenic: ahh ok, understanding better now |
| 15:57 | <JakeA> | reading that thread… |
| 16:17 | <JakeA> | 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. |
| 16:17 | <Domenic> | JakeA: ah, the old client-request vs. server-request thing... |
| 16:18 | <Domenic> | fetch(request) should take a client-request |
| 16:18 | <Domenic> | service workers should get a server-request |
| 16:18 | <JakeA> | hmm, I should be able to do fetch(event.request) |
| 16:20 | <Domenic> | you should? |
| 16:20 | <Domenic> | from a server's point of view, a request contains data to read |
| 16:20 | <Domenic> | from a client's point of view, a request is something you write to |
| 16:20 | <Domenic> | i am not sure how you would reconcile that |
| 16:21 | <Domenic> | one is mutable, the other is immutable |
| 16:22 | <JakeA> | 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? |
| 16:24 | <Domenic> | 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 |
| 16:25 | <Domenic> | 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 |
| 16:27 | <Domenic> | JakeA: yeah, it is pretty much just copying, meh... http://stackoverflow.com/a/20354642/3191 |
| 16:31 | <Domenic> | JakeA: ends up looking like https://gist.github.com/domenic/1bbec0f341ae3cfb3a8f in service-worker land... |
| 16:32 | <Domenic> | JakeA: now I am thinking making it a writable stream is not worth the trouble... |
| 16:32 | <Domenic> | JakeA: or maybe we should make it a duplex stream |
| 16:32 | <Domenic> | (i.e. { input, output } pair, possibly { input, output, readAsJSON, ... }, or maybe put readAsJSON on output, at the cost of more typing...) |
| 16:33 | <JakeA> | Domenic: Would that be a different type to the request I get on the fetch event? |
| 16:34 | <Domenic> | JakeA: in the gist? yeah it should say ClientRequest; ev.request is a ServerRequest |
| 16:34 | <Domenic> | JakeA: the difference being that req.body is writable for ClientRequest, readable for ServerRequest |
| 16:34 | <JakeA> | Domenic: I mean your duplex idea |
| 16:35 | <Domenic> | JakeA: the duplex idea would be that both client and servers re-use the same Request class, but req.body = { WritableStream input, ReadableStream output } |
| 16:35 | <Domenic> | JakeA: conceptually, a client will start with an "empty" stream, and write things into input |
| 16:36 | <Domenic> | JakeA: whereas a server will start with a "full" stream and read things from output |
| 16:36 | <Domenic> | 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.) |
| 16:37 | <Domenic> | 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 |
| 16:38 | <JakeA> | 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}); |
| 16:40 | <Domenic> | 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. |
| 16:42 | <Domenic> | JakeA: the duplex idea was designed to avoid such shenanigans |
| 16:43 | <Domenic> | JakeA: since you could just pass the duplex stream from ev.request into fetch(), since fetch() reads from the output side |
| 16:55 | <JakeA> | 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 |
| 17:58 | <Hixie> | so what do people think cross-spec references should look like? |
| 17:58 | <Hixie> | should every link to "URL" in the URL spec have a [URL] reference? |
| 17:59 | <Hixie> | should i not bother with [FOO] references except where there's no direct link to the spec? |
| 17:59 | <Hixie> | should i drop [FOO]-style refs entirely? |
| 18:00 | <caitp> | 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 |
| 18:00 | <Hixie> | yeah that's a given |
| 18:00 | <Hixie> | assume that the links are now real cross-spec links |
| 18:59 | <jgraham> | Hixie: What do you mean by "[FOO]" references? i.e. what's the distinguishing feature that you have in mind? |
| 19:03 | <Hixie> | jgraham: so right now the spec says things like "The foobar is a blooberry. [FOO]" |
| 19:03 | <Hixie> | jgraham: which then links to the References section and describes the Foo spec |
| 19:03 | <Hixie> | so i'd like "foobar" here to link directly to the definition of "foobar" in the Foo spec |
| 19:04 | <Hixie> | but what about the next paragraph, which also has a "foobar" in it? Should it also say [FOO]? Should neither say [FOO]? |
| 19:04 | <Hixie> | the [FOO] right now is just included where i made an editorial decision to include it |
| 19:04 | <Hixie> | it's somewhat arbitrary |
| 19:05 | <Hixie> | 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]" |
| 19:05 | <Hixie> | basically i'm asking what you think cross-spec references should look like if we forget our legacy |
| 19:05 | <jgraham> | Well arguably in that case "XML" and "namespaces" should be linked |
| 19:06 | <Hixie> | to just the specs? |
| 19:06 | <jgraham> | Yeah |
| 19:06 | <caitp> | Hixie: from my perspective, in a single paragraph, you shouldn't have multiple links to the same section of a referenced spec |
| 19:06 | <caitp> | maybe in the same group of paragraphs |
| 19:06 | <Hixie> | caitp: well i want every reference to a term to link to the same place |
| 19:06 | <jgraham> | ink consistently linking terms defined elsewhere like you would terms defined in the spec makes much more sense |
| 19:07 | <jgraham> | *I think |
| 19:07 | <Hixie> | so drop the whole [FOO]-style refernece thing and the references section? |
| 19:08 | <caitp> | 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.` |
| 19:08 | <jgraham> | Well you could have a references section that would just be a list of other specs that get referenced |
| 19:08 | <jgraham> | But I don't know how useful it is |
| 19:08 | <caitp> | otherwise it just gets a bit link-spammy |
| 19:09 | <jgraham> | caitp: It shouldn't use a different style compared to internal references |
| 19:09 | <Hixie> | jgraham: but not link to it? |
| 19:09 | <caitp> | the notation is just indicating that it's a link to the foobar section of the FOO spec |
| 19:10 | <caitp> | not that it's a different style |
| 19:10 | <jgraham> | Hixie: I don't think linking to it is all that practical |
| 19:10 | <Hixie> | jgraham: k |
| 19:10 | <jgraham> | caitp: Right, I meant "style" in the sense of "how often it links" |
| 19:10 | <Hixie> | 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. |
| 19:10 | <jgraham> | i.e. my suggestion is "do what you already do and ignore the difference between internal and external references" |
| 19:11 | <caitp> | hmm, that's true |
| 19:11 | <Hixie> | caitp: i think with the current underline-less style, link-spamminess is much less of a problem |
| 19:11 | <caitp> | well you probably do want to clearly identify that it's a link to somewhere else |
| 19:11 | <jsbell> | 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. |
| 19:11 | <jgraham> | 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 |
| 19:12 | <Hixie> | jsbell: well we don't include the version or date anyway, since we're always linking to the latest revision |
| 19:12 | <jsbell> | Yep. |
| 19:13 | <Hixie> | 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. |
| 19:13 | <Hixie> | though kittens know how i figure out what reference to actually use |
| 19:13 | <Hixie> | but that's a separate issue |
| 19:14 | <Hixie> | one thing is that MikeSmith wanted the references section to link to all the sections that referenced the spec in question |
| 19:14 | <Hixie> | which would be harder if there's no marker to link back to... |
| 19:14 | <jgraham> | 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 |
| 19:14 | <jgraham> | e.g. if it's the whole XML spec |
| 19:14 | <Hixie> | jgraham: i just meant the title and editor names and so on |
| 19:15 | <Hixie> | 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 |
| 19:15 | <Hixie> | no magic to autoinsert the right [FOO]s when there's a cross-spec cross-ref or whatever |
| 19:22 | <astearns> | Hixie: FWIW, I use real cross-ref links everywhere, and only add a [FOO] to the first instance where a particular spec is linked |
| 19:22 | <Hixie> | that makes sense |
| 19:22 | <astearns> | mainly to build the reference index |
| 19:26 | <smaug____> | dglazkov_: ping |
| 19:31 | <Hixie> | man there sure are a lot of <dfn>s in the HTML spec that aren't used by anything in the spec |
| 20:53 | <awrbgh> | ŘŞŘذير |
| 20:53 | <awrbgh> | warning |
| 20:53 | <awrbgh> | you may be watched |
| 20:53 | <awrbgh> | do usa&israel use the internet(facebook,youtube,twitter, chat rooms ..ect)to spy?? |
| 20:53 | <awrbgh> | do usa&israel use the internet 2 collect informations,,can we call that spying?? |
| 21:08 | <Hixie> | not just usa&israel, i would imagine... |
| 21:09 | <caitp> | well that was interesting |
| 21:13 | <marcosc> | Thinking of standardizing Wake Locks. Use cases: https://w3c-webmob.github.io/wake-lock-use-cases/ |
| 21:13 | <marcosc> | would appreciate any feedback before proposing an API |
| 21:19 | <caitp> | 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 |
| 21:20 | <Hixie> | 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" |
| 21:21 | <caitp> | don't media elements offer an attribute or something to prevent sleep? I thought they did but can't recall |
| 21:22 | <Hixie> | marcosc: your document seems woefully short on abuse considerations |
| 21:22 | <caitp> | maybe it's just a default chosen by the implementation, I dunno |
| 21:22 | <Hixie> | 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" |
| 21:24 | <caitp> | 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 |
| 21:26 | <caitp> | 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 |
| 21:26 | <Hixie> | i don't see why Google Maps shouldn't support navigation on a phone |
| 21:26 | <Hixie> | i think that use case makes emminent sense |
| 21:27 | <Hixie> | i mean there's nothing really about the native Android Google Maps app that shouldn't be possible from a web app, imho |
| 21:28 | <caitp> | Hixie: you might use google maps on a phone, that would be fine |
| 21:29 | <caitp> | but you probably are using the android or ios app |
| 21:29 | <caitp> | which can keep the device awake natively |
| 21:29 | <Hixie> | but why should google need to make two or more navigation apps? instead of just a web app? |
| 21:29 | <caitp> | easier on the battery too, quite likely |
| 21:30 | <caitp> | well, google already does |
| 21:30 | <Hixie> | 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) |
| 21:30 | <caitp> | and if they didn't, someone else would |
| 21:30 | <caitp> | (and someone else does, actually) |
| 21:30 | <Hixie> | but why is that a good thing? |
| 21:30 | <caitp> | because it is |
| 21:30 | <Hixie> | ... |
| 21:30 | <Hixie> | game over: you have lost your argument |
| 21:30 | <caitp> | lol |
| 21:31 | <caitp> | 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 |
| 21:31 | <caitp> | and without being blocked on bugs in different implementations |
| 21:31 | <Hixie> | that arguments generalises to all features, and suggests the web shouldn't exist. |
| 21:31 | <caitp> | and that's really a logical conclusion, when you get down to it |
| 21:32 | <marcosc> | Hixie: true about abuse cases. Will add that. |
| 21:32 | <Hixie> | 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. |
| 21:32 | <Hixie> | caitp: that alone justifies its existence, imho |
| 21:32 | <caitp> | it's not really vendor-neutral, though |
| 21:32 | <caitp> | it's not |
| 21:32 | <caitp> | we try, we do try |
| 21:33 | <caitp> | but it's not |
| 21:33 | <caitp> | with simple documents we get pretty close |
| 21:33 | <marcosc> | caitp: did you read the document? |
| 21:33 | <Hixie> | caitp: by definition, anything that isn't interoperable across multiple vendors isn't part of the web. :-) |
| 21:34 | <caitp> | 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 |
| 21:35 | <caitp> | because of this, the web is not the single platform for all things |
| 21:35 | <Hixie> | that also describes every other platform, especially the old ones |
| 21:35 | <caitp> | it can't be, it's not possible :( |
| 21:35 | <caitp> | it would be cool if it were possible |
| 21:35 | <Hixie> | your argument is essentially "the web isn't perfect, therefore it's got no value" |
| 21:35 | <caitp> | I never said it had no value =) |
| 21:35 | <Hixie> | and things aren't that black and white |
| 21:36 | <caitp> | but it's got too many problems which will keep it from progressing in a meaningful way for some of these things |
| 21:36 | <caitp> | security issues, limitations of imperative languages, lack of imperative languages, etc |
| 21:36 | <caitp> | performance issues, energy cost issues |
| 21:36 | <marcosc> | caitp: about games, search for Magic the gathering. Also, see the first example in "other applications". |
| 21:36 | <caitp> | too many responsibilities -> never going to be good at everything you need it to be |
| 21:37 | <Hixie> | we're literally working on every single one of those |
| 21:37 | <caitp> | i know they're being worked on, but it's never really going to "work" |
| 21:37 | <caitp> | 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 |
| 21:38 | <Hixie> | caitp: https://www.youtube.com/watch?v=pWdd6_ZxX8c |
| 21:38 | <caitp> | this is a prime example of the web not doing a great job for all things |
| 21:38 | <caitp> | not that the web is bad |
| 21:38 | <caitp> | the web is awesome |
| 21:38 | <Hixie> | you realise that _no_ platform does "a great job for all things" right |
| 21:38 | <caitp> | but it's not the be-all-end-all solution for everything |
| 21:39 | <caitp> | no, but sometimes C# or ObjC or Java or C++ does a better job of solving a given problem |
| 21:39 | <caitp> | (easier than say, javascript + API bindings into someone elses C++) |
| 21:39 | <Hixie> | sure. there are multiple projects ongoing for providing ways to compile C++ to a form that runs on any browser. |
| 21:40 | <Hixie> | not to mention that many web apps are now written in Java using GWT, etc. |
| 21:40 | <caitp> | yeah but that's not really a solution :p |
| 21:40 | <caitp> | running in a browser isn't really any better than running in anything else |
| 21:40 | <Hixie> | well, again, https://www.youtube.com/watch?v=pWdd6_ZxX8c |
| 21:40 | <caitp> | there's nothing that makes an app that runs in IE any better than an app that runs in MS-DOS |
| 21:41 | <Hixie> | ... |
| 21:41 | <Hixie> | that's just objectively false |
| 21:41 | <caitp> | it could be the exact same application, running it in IE wouldn't be any better |
| 21:41 | <caitp> | it wouldn't necessarily be worse, but it wouldn't be better |
| 21:41 | <caitp> | running in a browser doesn't "improve" anything |
| 21:42 | <Hixie> | the browser is just the runtime |
| 21:42 | <marcosc> | hixie, adding the user opt-in requirement also. Thanks for the feedback. |
| 21:42 | <Hixie> | i don't care if it's IE or Chrome OS or whatever |
| 21:43 | <hober> | ISTM that wake lock shouldn't be API, but should simply be something UAs do themselves |
| 21:43 | <caitp> | yes, it's the runtime |
| 21:43 | <Hixie> | in fact the whole point is that it can be any of the browsers |
| 21:43 | <caitp> | and the runtime doesn't matter |
| 21:43 | <caitp> | the browser being a runtime isn't an improvement |
| 21:43 | <caitp> | it's not a detriment in all cases, but it's not an improvement |
| 21:43 | <Hixie> | the improvement is that there's multiple runtimes |
| 21:43 | <hober> | like, if i take a <video> full screen, a reasonable UA should wake lock while it's playing |
| 21:43 | <hober> | without the author doing anything |
| 21:43 | <Hixie> | hober: yeah but e.g. for a navigation web app, how does the browser know to wake lock? |
| 21:43 | <marcosc> | hober: yes |
| 21:44 | <caitp> | you're a website running in an airport kiosk |
| 21:44 | <hober> | Hixie: because the user activated a control in the UA chrome? :) |
| 21:44 | <caitp> | the sysadmin controlling the kiosk has disabled sleep |
| 21:44 | <caitp> | problem solved |
| 21:44 | <Hixie> | hober: Safari is going to have a "wake lock" button? :-) |
| 21:44 | <caitp> | sysadmin/IT grunt/whoever |
| 21:44 | <Hixie> | yeah kiosks aren't a good use case |
| 21:44 | <hober> | Hixie: you know us. we love adding lots of random ui buttons :) |
| 21:45 | <Hixie> | hober: i rest my case... :-P |
| 21:45 | <marcosc> | yeah, I didn't include them... though I do have a picture of one that we use at the office here. |
| 21:45 | <marcosc> | (we use an app for meeting rooms.... but the screen could shut off after hours) |
| 21:45 | <marcosc> | so they are not a terrible use case |
| 21:48 | <caitp> | there are cases where it's obvious you want to disable sleep, like videos |
| 21:48 | <caitp> | but I don't think the other cases are that obvious |
| 21:48 | <caitp> | that's all |
| 21:48 | <Hixie> | how is maps not obvious |
| 21:48 | <caitp> | because you're probably issuing inputs |
| 21:49 | <caitp> | I mean the only case where you'd ever do that is on your mobile phone, and your mobile phone isn't going to sleep, unless you leave it alone for a minute, and if it does, who cares |
| 21:49 | <caitp> | you could disable sleep if you need to use it as your car GPS or something |
| 21:49 | <caitp> | (which you shouldn't) |
| 21:49 | <Hixie> | uh |
| 21:50 | <Hixie> | let me tell you how i am NOT issuing inputs while driving... |
| 21:50 | <Hixie> | why "which you shouldn't" |
| 21:50 | <Hixie> | i don't get it |
| 21:50 | <caitp> | don't use your phone as a GPS while driving =) and if you can avoid it, don't use GPS at all |
| 21:50 | <caitp> | people grow overly dependent on these things, you know |
| 21:51 | <Hixie> | uh |
| 21:51 | <Hixie> | ok |
| 21:51 | Hixie | is going to keep using a navigation app until such time as his car drives itself, thanks |
| 21:52 | <caitp> | i'm sure it will only be a few years |
| 21:52 | <Hixie> | especially with google maps being so freaking awesome at it these days |
| 21:52 | <Hixie> | navigating around traffic dynamically and giving lane guidance and all that |
| 21:52 | <Hixie> | it's freaking fantastic |
| 21:52 | <caitp> | and then we'll forget all about reading paper maps, street signs and landmarks, and celestial navigation |
| 21:52 | <caitp> | and it will be terrible |
| 21:52 | <Hixie> | you'd have to be crazy to not use it |
| 21:53 | <caitp> | and more importantly, we'll start to forget to look away from the screen |
| 21:53 | <caitp> | wouldn't that be awful? |
| 21:53 | <caitp> | oh man |
| 21:53 | <Hixie> | oh man, yeah, how will we ever survive as a species if we forget how to use logarithm tables, slide rules, punch cards, pedal looms or how to ride a horse |
| 21:53 | <caitp> | yes |
| 21:53 | <caitp> | darned right |
| 21:53 | <caitp> | no sarcasm |
| 21:53 | <caitp> | it will be a sad day when that knowledge disappears =) |
| 21:54 | <Hixie> | luckily for us, that knowledge will forever live on since we now have near-infinite archival storage and no longer depend on flammable paper for our backups |
| 21:55 | <caitp> | archived knowledge is not necessarily living knowledge |
| 21:55 | <caitp> | anyway I think this got a bit sidetracked =) |
| 21:56 | <Hixie> | do you know how to use a slide rule? |
| 21:56 | <marcosc> | caitp: you didn't even read the document, did you? |
| 21:57 | <caitp> | in its entirety? heck no, I was in a meeting =) |
| 21:57 | <marcosc> | ok, most of the things you mentioned are addressed in the document |
| 21:57 | <caitp> | but I'm still not really buying it, I don't want any web app that wants to disabling sleep on my system, and I don't want to let a web app disable sleep |
| 21:58 | <marcosc> | caitp: that's fine. You can opt out |
| 21:58 | <marcosc> | but other people would want it |
| 21:58 | <caitp> | for obvious cases like videos, the UA can disable sleep, but otherwise I'd prefer to do that myself |
| 21:58 | <marcosc> | caitp: ok, that's fine. But do you acknowledge that other people might not want that? |
| 21:58 | <marcosc> | (i.e., a lot of people don't even know how to do that( |
| 21:59 | <marcosc> | ) |
| 21:59 | <caitp> | if someone doesn't know how to disable sleep, do you think they really know what they're doing allowing a random web app to disable sleep? |
| 21:59 | <marcosc> | caitp: again, see the document |
| 21:59 | <marcosc> | e.g., the app for cooking and the Brazil 2014 app |
| 21:59 | <caitp> | the document explains how it makes up for other peoples lack of knowledge? |
| 21:59 | <caitp> | o_o |
| 21:59 | <marcosc> | yes |
| 22:00 | <caitp> | which section would I find that snippet, is there another spec proposed for interfacing directly with a user's brain? |
| 22:00 | <marcosc> | I think that's called interaction design |
| 22:01 | <marcosc> | seems you are not really interested in actually providing constructive feedback. |
| 22:02 | <caitp> | it's not that it's not constructive, it's that it's not what you want to hear |
| 22:02 | <caitp> | which is fine, I can't stop ya |
| 22:02 | <Domenic> | no, this is pretty much the definition of non-constructive feedback right here |
| 22:02 | <caitp> | there's no way to make this work in a good way within the constraints of the platform, domenic, that would never be appropriate |
| 22:03 | <marcosc> | caitp: why is it then possible to do it effectively on Android and iOS? |
| 22:03 | <marcosc> | Or even in Firefox OS? |
| 22:03 | <caitp> | well, it's not as effective on the android store because the play store isn't policed as effectively |
| 22:04 | <caitp> | but certainly on the app store they take abuse a bit more seriously |
| 22:04 | <marcosc> | Wait, you are saying that we shouldn't standardize any new features because the web doesn't have an "app store"? |
| 22:05 | <caitp> | no |
| 22:05 | <caitp> | that's you fitting those words into my mouth =) |
| 22:05 | <caitp> | the trouble is, by asking users to opt-in, you're A) assuming they have a clue what they're opting into or how it affects them, and B) essentially giving a free-pass for people to take advantage of less-skilled computer users |
| 22:05 | <marcosc> | apologies, can we focus on the use cases and try to find an solution to the abuse cases? |
| 22:05 | <Hixie> | caitp: you're not explaining your position very well, fwiw |
| 22:06 | <caitp> | while at the same time imposing inconvenience on more experienced users |
| 22:08 | <marcosc> | if the application provides a wake lock and it's really useful (e.g., driving, using Google Cardboard, following a recipe) I don't see how that is a huge inconvenience for a significant gain. Once the user is done using the application, they just press the power button or open a different app. |
| 22:08 | <Hixie> | marcosc: on android i would expose it as a notification that said "This Web page would like to keep your phone from turning off. This can increase battery usage. (( Allow maps.google.com to control when the phone turns off ))" and if you dismiss it, the app is added to the blacklist so the notification doesn't come back. |
| 22:08 | <Hixie> | oh man, google cardboard is another great use case |
| 22:09 | <Domenic> | I want a Google cardboard, but am ironically too lazy to make one... |
| 22:10 | <marcosc> | heh |
| 22:10 | <Hixie> | Domenic: you can find prebuilt kits online |
| 22:10 | <Hixie> | Domenic: http://www.dodocase.com/products/google-cardboard-vr-goggle-toolkit http://www.unofficialcardboard.com/ |
| 22:11 | <caitp> | anyways I'm still not seeing where this draft is claiming to make up for a users inexperience marcosc :( do you have a link to the section/ |
| 22:11 | <caitp> | ? |
| 22:12 | <Domenic> | Hixie: awesome! |
| 22:12 | <marcosc> | No, it's implied throughout the whole document because there are many successful apps using wake locks. |
| 22:12 | <marcosc> | caitp: ^^ |
| 22:12 | <Domenic> | The "Handcrafted in San Francisco" banner is a nice touch. |
| 22:12 | <caitp> | that... isn't the issue though |
| 22:12 | <caitp> | there is any number of things that you could gain a marginal benefit from wakelocks for |
| 22:12 | Hixie | must admit to having no idea what issue caitp is currently having |
| 22:13 | <caitp> | the issue is how do you prevent abuse |
| 22:13 | <caitp> | because opt-in isn't enough |
| 22:13 | <caitp> | it just isn't |
| 22:13 | <Hixie> | it's isn't because...? |
| 22:13 | <caitp> | because people don't understand what they're opting into/out of, don't understand all of the implications, don't know how to undo their choices |
| 22:14 | <Domenic> | I guess people should not use phones then |
| 22:14 | <caitp> | and more importantly, people don't want to have to opt in |
| 22:14 | <Domenic> | Cuz the wakelock monster will get them |
| 22:14 | <Domenic> | and lock their phones awake |
| 22:14 | <Hixie> | we have much bigger issues that are currently opt-in without the world ending... |
| 22:14 | <Hixie> | for example, the geolocation api |
| 22:15 | <caitp> | well, it would take a lot for the world to end |
| 22:15 | <Hixie> | if opt-in is sufficient for the geolocation api, i'm very comfortable saying that it's sufficient for a wake lock |
| 22:16 | <Hixie> | and the industry seems to have concluded that it's sufficient for the geolocation api |
| 22:16 | <caitp> | you opted into gUM on website X on one day, on a different day you've opted into wakelock |
| 22:17 | <caitp> | now you've fallen asleep, wakelock and gUM are working simultaneously and you're being surveiled |
| 22:17 | <caitp> | that's creepy as hell! |
| 22:17 | <Hixie> | oh no! |
| 22:17 | <Hixie> | call the nsa! |
| 22:17 | <caitp> | but worse, it's also killing your ipad battery cycles and causing you to pay another 200$ for a replacement battery sooner! |
| 22:17 | <Hixie> | oh wait, they can already do this without any help from us |
| 22:17 | <Hixie> | since they can run software on the baseband |
| 22:17 | <caitp> | yes they can |
| 22:18 | <Hixie> | phew |
| 22:18 | <Hixie> | disaster averted |
| 22:18 | <caitp> | it's not averted, it's just ignored :p |
| 22:18 | <caitp> | just because you already have a problem doesn't mean that making it easier for people to abuse it is any better |
| 22:19 | <Hixie> | if you don't trust the site to not surveil you, then don't opt-in to gUM |
| 22:19 | <Hixie> | that's what the opt-in is _for_ |
| 22:19 | <caitp> | maybe you don't remember that you opted in |
| 22:19 | <caitp> | maybe you had a good reason to opt-in at one point, but no longer do |
| 22:20 | <caitp> | maybe you don't know that you don't have a good reason to suspect people on the internet because you're a 90 year old grandmother |
| 22:20 | <caitp> | I mean really, who can say |
| 22:21 | <caitp> | you could come up with lots of ways to abuse it, and you'd get like at least 3 out of every 12 people you tried it on |
| 22:21 | <caitp> | probably more |
| 22:21 | <Hixie> | i'm totally on board with the suggestion that we should make it clearer to users that a site has permissions to use your camera or whatever |
| 22:21 | <Hixie> | but that is not specific to the web, and not specific to wake locks. |
| 22:22 | <caitp> | maybe an app-store like system for the web would actually be a really good idea |
| 22:59 | <TabAtkins> | caitp: Maybe rethink that, given the travesty of App Store permissions (particularly on Android, but only because I'm not familiar enough with iTunes to know how bad it is). |
| 23:01 | <caitp> | no, I think it would be extraordinary if we could vette specific applications and grant them permissions because we know that they aren't acting abusinely. I'm not saying it would be even close to a simple thing to implement, and it would cost piles of money and will likely never happen |
| 23:01 | <caitp> | but that's the problem isn't it |
| 23:01 | <caitp> | we let people do whatever they want and keep giving them more tools to do it with and the only protection we offer is completely half-assed |
| 23:03 | <caitp> | not just specific applications but specific hashes computed from the source code of an application |
| 23:04 | <TabAtkins> | Oh, so you're saying "A system vaguely similar to an App Store, but actually quite different from every existing App Store in important ways". |
| 23:04 | <caitp> | well, somewhat similar to the apple store |
| 23:05 | <Hixie> | hm... making <dfn>s for terms that are defined in other specs actually turn into links that go to those other specs makes my dfn.js ui break... |
| 23:05 | <Hixie> | because you end up following the link rather than seeing the list os term usages... |
| 23:05 | <Hixie> | of |
| 23:06 | <TabAtkins> | Hixie: Dont' do that, then. Your local definitions will clash with the other spec's definitions, and will make Bikeshed unhappy. ;_; |
| 23:07 | <Hixie> | don't worry, they're easily detectable. Just ignore any <dfn> containing an <a> (or any <dfn> with a data-x-href, if you use my source file as input) |
| 23:07 | <TabAtkins> | (When you do want a local definition of a concept that is more fully defined elsewhere, Bikeshed has a concept of "unexported" definitions, which are local-only and don't get picked up by Shepherd's database.) |
| 23:07 | <gsnedders> | Hixie: what was the 3D printing place you were recommending? |
| 23:08 | <TabAtkins> | Hixie: No can do, all <dfn>s have an <a> in Bikeshedding specs (for the permalink). |
| 23:08 | <TabAtkins> | Hixie: You could put a data-noexport attribute on the definitions you don't want to show up globally, if you wanna be Bikeshed-friendly. |
| 23:08 | <Hixie> | TabAtkins: i'm sure we'll figure out some solution |
| 23:09 | <Hixie> | TabAtkins: i'm first trying to get something good for HTML before I worry about other specs :-) |
| 23:09 | <TabAtkins> | Sure, but I wanna make sure you don't do a lot of work, and then would have to do *more* work afterwards to make it play well with others. ^_^ |
| 23:10 | <TabAtkins> | So just in case it's something you'd have to do to your source file, knowing about it earlier rather than later is better. |
| 23:10 | <TabAtkins> | For example, typing your dfns would be *wonderful*. |
| 23:10 | <TabAtkins> | (Particularly your WebIDL ones.) |
| 23:11 | <Hixie> | my medium-term plan with webidl is to not have to type any, but just to have my pipeline parse the webidl directly. |
| 23:12 | <Hixie> | anyway. the HTML spec has a section on dependencies, where all the terms the spec uses from other specs are defined |
| 23:12 | <Hixie> | so what i'm doing is just using this as a way to also declare internally what all the terms should actually point to |
| 23:13 | <TabAtkins> | That also works, yes. That's what Bikeshed does. |
| 23:13 | <TabAtkins> | (re: parsing webidl automatically) |
| 23:14 | <TabAtkins> | So if you just add a data-noexport attribute to all of those definitions (because they're not "real" definitions, just local ones you're using for spec-specific purposes), that would be great. |
| 23:14 | <TabAtkins> | Then I won't have to constantly disambiguate HTML definitions from everything else. ^_^ |
| 23:15 | <Hixie> | file a bug to remind me (whatwg.org/newbug, whiteboard "tools") |
| 23:16 | <TabAtkins> | What's the whiteboard? |
| 23:16 | <TabAtkins> | Don't see that field anywhere. |
| 23:17 | <Hixie> | you have to edit it after filing the bug |
| 23:17 | <Hixie> | for some reason |
| 23:18 | <TabAtkins> | k, done |
| 23:29 | <marcosc> | caitp: I added the geolocation + wake lock abuse case to the document (haven't pushed yet). |
| 23:29 | <Hixie> | TabAtkins: thanks |
| 23:35 | <MikeSmith> | -there's also an early version of "Referer". It's called "Referree" [sic]. In a file from the very next day, it's called "Referee" [sic]. |
| 23:35 | <MikeSmith> | http://lists.w3.org/Archives/Public/public-webhistory/2014Jul/0002.html |
| 23:37 | <Hixie> | why is the second marked [sic]? |
| 23:38 | <Hixie> | oh because that word doesn't make sense there |
| 23:38 | <Hixie> | nevermind |