| 00:00 | <SamB> | that's a fairly randomly chosen piece of documentation, but you can probably see that it's long enough that one might want to use something like fragmentions there |
| 00:01 | <KevinMarks_> | http://indiewebcamp.com/Special:Preferences##ಇ-ಅಂಚೆ |
| 00:02 | <SamB> | hmm, maybe that isn't the best example though because I guess the hash part of the URL is not terribly interesting ... |
| 00:03 | <zewt> | apple doc urls are a nightmare |
| 00:03 | <SamB> | yeah |
| 00:03 | <SamB> | but not seemingly a good example of the problem :-( |
| 00:03 | <KevinMarks_> | at least they stopped using the webobjects ones with colons in |
| 00:05 | <KevinMarks_> | hm, actually the chrome fragmention plugin seems to work OK in that doc |
| 00:06 | <SamB> | yeah, I remembered the fragments being more important there |
| 00:06 | <SamB> | obviously I misremembered |
| 00:07 | <KevinMarks_> | it certainly doesn't break their links |
| 00:18 | <SamB> | (Oh, how would you link to something on the Beta tab on, say, mediawiki.org -- without knowing the UI language?) |
| 00:19 | <MikeSmith> | is there a downloadable version of Presto-based Opera still available? |
| 00:24 | <MikeSmith> | nm |
| 00:24 | <MikeSmith> | Opera 12 I guess |
| 00:32 | <KevinMarks_> | SamB linking across languages is a tough usecase |
| 00:32 | <KevinMarks_> | the person at the annotations mtg who knew most about ti was a biblical concordance speciallist |
| 00:33 | <KevinMarks_> | and they have relatively well-defined cross-language anchors |
| 00:33 | <SamB> | well, the easy way is to use the ID, isn't it? |
| 00:33 | <KevinMarks_> | no, they have Matthew 12:18 type anchors |
| 00:34 | <KevinMarks_> | the 12:18 is in the text, and the lookup the Book name, iirc |
| 00:34 | SamB | meant for the MW preferences thing |
| 00:36 | <SamB> | or, if we actualyl want stuff like what fragmentions is actually meant for, try using them on https://groups.google.com/forum/#!topic/linux.debian.project/LBCAsdfl_ws maybe? |
| 00:39 | <SamB> | (nevermind that you can't read that in elinks, despite there not really being any content there that it couldn't handle tolerably ...) |
| 00:42 | <KevinMarks_> | is that an example of the hashbang antipattern? |
| 00:54 | <zewt> | "antipattern" is what people call things they don't like that they want to make sound bad, not something necessarily actually bad, so better not to call something an "antipattern" if you're not even sure if it is something or not :P |
| 00:54 | <tantek> | yup that's just #! hashbang anti-pattern. Google Groups needs to fix that. |
| 00:54 | <SamB> | KevinMarks_: it's an example of AJAX taken too far, period |
| 00:55 | <zewt> | (nothing wrong with that url, though the "!" seems a bit pointless) |
| 00:55 | <SamB> | #! might actually mitigate it somewhat for clients who have any idea what that means |
| 00:56 | <SamB> | I've seen other pages that had several tabs which I think a non-JS browser would just render all of |
| 00:56 | <zewt> | non-JS browsers are pretty irrelevant to the real world |
| 00:56 | <SamB> | that's not quite as bad, but it'd still be a problem for fragmentions |
| 00:58 | <SamB> | not so irrelevant that gmail doesn't support them ... |
| 00:58 | <SamB> | ... though admittedly actually *getting* into basic HTML mode has had problems lately |
| 00:58 | <zewt> | html in email isn't a browser |
| 01:03 | <KevinMarks_> | now here's another variant: https://dl.dropboxusercontent.com/u/18852638/draft/silly/test.html##Brennan+Novak(Brennan+is+bnvk+on+#indieweb+and+#mailpile) |
| 01:12 | <MikeSmith> | TabAtkins: when you have a few minutes please let me know what should be added to the "CSS features" part of http://platform.html5.org/ |
| 01:14 | <MikeSmith> | and what if anything should be removed |
| 02:06 | <MikeSmith> | Hixie: colors look nice |
| 02:09 | <Hixie> | :-) |
| 02:46 | <Hixie> | i'm amused that chrome just can't handle the gradient on the html spec and gives up |
| 02:46 | <Hixie> | firefox can't handle it well either, it turns into into four bands |
| 02:47 | <Hixie> | which actually kinda looks cool |
| 02:47 | <Hixie> | tempting to actually switch to that intentionally :-) |
| 04:56 | <JonathanNeal> | Will Chrome get HTML5 context menus? http://davidwalsh.name/html5-context-menu |
| 05:01 | <Hixie> | looks like the spec splitter is broken |
| 05:20 | <TabAtkins> | Hixie: The gradient works just fine on Chrome for me. |
| 05:36 | <Hixie> | TabAtkins: on teh single-page copy? |
| 05:37 | <TabAtkins> | Oh, haven't looked. |
| 05:37 | <Hixie> | works fine for me elsewhere |
| 06:54 | <zcorpan> | Hixie: that gradient is horrible :-P |
| 07:33 | <JakeA> | Domenic_: response.body will be a readable stream in SW. However, we need something akin to responseText from XHR |
| 07:34 | <JakeA> | Domenic_: async of course |
| 07:34 | <JakeA> | Domenic_: Are you planning on adding helpers like this to streams? |
| 07:35 | <JakeA> | Domenic_: Otherwise we'll just add them to our Response objects |
| 07:57 | <mathiasbynens> | Hixie: http://validators.whatwg.org/ still doesn’t resolve for me – sure that fix worked? |
| 08:06 | <JakeA> | http://www.downforeveryoneorjustme.com/http://validators.whatwg.org/ |
| 08:07 | <JakeA> | It's down for me too |
| 08:32 | <JakeA> | https://twitter.com/bug_facts/status/457712371616608256 |
| 08:35 | <JakeA> | Sooooo, posted THAT in the wrong channel |
| 08:36 | <JakeA> | Enjoy it anyway |
| 08:47 | <annevk> | When is someone going to take ownership of IDL? |
| 08:47 | <annevk> | We really need the array issues and such resolved |
| 08:48 | <Ms2ger> | When you do |
| 08:50 | <annevk> | JakeA: I think we should have helpers on streams |
| 08:50 | <annevk> | JakeA: e.g. a TransformStream of sorts that converts bytes to text |
| 08:51 | <annevk> | JakeA: although we probably need helpers on Response as well given that the decoding depends heavily on other properties of the Response object |
| 08:52 | <JakeA> | annevk: yeah, I guess you couldn't toBlob a stream because there's no content-type |
| 08:53 | <JakeA> | annevk: I think SW Response will need a getBodyText helper too, although we can deprecate it when streams land |
| 08:53 | <JakeA> | annevk: filed https://github.com/slightlyoff/ServiceWorker/issues/251 |
| 08:53 | <annevk> | JakeA: you can't just add / remove methods... |
| 08:53 | <annevk> | JakeA: getBodyText() sounds a lot like Java |
| 08:54 | <JakeA> | annevk: open to other names. Needs to return a promise. Problem is, toString() is taken :D |
| 08:55 | <annevk> | JakeA: don't really have great suggestions either |
| 08:56 | <JakeA> | asText() |
| 08:56 | <annevk> | JakeA: <canvas> has toBlob iirc |
| 08:56 | <JakeA> | Sounds like Aztecs |
| 08:56 | <annevk> | asString might be okay |
| 08:56 | <JakeA> | annevk: toBlob and asString? |
| 08:56 | <annevk> | or bodyToString() hmm |
| 08:59 | <JakeA> | annevk: to(type).then() |
| 08:59 | <annevk> | JakeA: similar to responseType? |
| 08:59 | <annevk> | JakeA: not half bad |
| 09:00 | <JakeA> | annevk: that's what I'm thinking |
| 09:03 | <smaug____> | annevk: how is nobody not maintaining idl? |
| 09:03 | <smaug____> | s/not// |
| 09:03 | <annevk> | smaug____: I don't know, it's just not happening |
| 09:04 | <annevk> | smaug____: I think getting it up to speed would be at least several months of fulltime work and nobody has taken the time |
| 09:04 | <JakeA> | more like ID-hell amirite? *holds hand up waiting for high-five* |
| 09:04 | <smaug____> | hmm, I thought it has been updated when needed |
| 09:05 | <annevk> | https://www.w3.org/Bugs/Public/buglist.cgi?component=WebIDL&product=WebAppsWG&resolution=--- lists 84 bugs and quite a few are larger issues |
| 09:09 | <smaug____> | is there annotation for read only array |
| 09:09 | <smaug____> | since I guess that is what we want for event.path |
| 09:09 | <smaug____> | or Gecko's [frozen] |
| 09:09 | <annevk> | It seems what people argue for is that we should simply return a mutable array |
| 09:10 | <annevk> | A JavaScript Array object |
| 09:13 | <smaug____> | well, for event.path is should be frozen Array |
| 09:13 | <smaug____> | that is just a JS thing |
| 09:13 | <annevk> | Again, Domenic_, dherman, et al, argue it should not be frozen |
| 09:51 | <jgraham> | annevk: If you want those input tests fixed your should review https://critic.hoppipolla.co.uk/r/1370 |
| 09:51 | <jgraham> | I'm not sure it's right |
| 09:53 | <annevk> | jgraham: looks legit, but https://github.com/w3c/web-platform-tests/pull/928#discussion_r11965914 |
| 09:55 | <jgraham> | Yeah, I wondered about that |
| 09:55 | <annevk> | jgraham: I think per spec you can make it dirty by input.value = input.value |
| 09:56 | <jgraham> | I guess I should find a way to sort the few useful messages from the torent of spam I get from GitHub |
| 09:56 | <annevk> | I just found out I missed pull requests going back six months |
| 09:56 | <jgraham> | annevk: Doing input.value += "a"; input.value = input.value.slice(0, input.value.length - 1) or something seems better |
| 09:57 | <jgraham> | In the sense that I don't really trust browsers to get this right in the first case |
| 09:57 | <annevk> | jgraham: because? |
| 09:57 | <annevk> | I guess it depends on what you want to test |
| 09:58 | <annevk> | But in that case I'd just do temp = input.value; input.value = "x"; input.value = temp |
| 09:58 | <annevk> | As the slice trickery makes it look complicated |
| 09:59 | <jgraham> | annevk: Curiously that was almost exactly what I had just written :) |
| 10:00 | <jgraham> | Pushed to the review |
| 10:02 | <annevk> | reviewed |
| 10:04 | <jgraham> | Thanks |
| 10:04 | <annevk> | I wonder what the deal with the gradient is |
| 10:16 | <jgraham> | Where is this gradient? |
| 10:17 | <Ms2ger> | Down |
| 10:17 | <jgraham> | Oh wait, I wasn't getting the new stylesheets |
| 10:18 | <jgraham> | Well this seems to be exposing bugs in Gecko in a way that make the spec more or less unusuable |
| 10:19 | <Ms2ger> | jgraham, oh? |
| 10:20 | <Ms2ger> | Oh wow, that's ugly |
| 10:21 | <jgraham> | http://imgur.com/NkwmZz3 |
| 10:22 | <jgraham> | On the multipage spec it works OK |
| 10:22 | <Ms2ger> | Ah |
| 10:22 | <jgraham> | But I really wish it didn't |
| 10:22 | <annevk> | hsivonen: whenever I hear you talk about crypto, it kind of sounds like we need a "Crypto Standard" |
| 10:23 | <jgraham> | Also most of the text in the boxes at the top overflows |
| 10:25 | <annevk> | hsivonen: I'm not volunteering btw |
| 10:25 | <zcorpan> | Hixie: i don't know if you're done with the review script, but currently it seems somewhat broken to me. if i click "more..." all that happens is that that button is replaced with a "hide" button, and clicking that makes the whole thing non-functional and no way to get it back without deleting the cookie |
| 10:59 | <smaug____> | why w3c bugzilla doesn't send all the bugmail it should :/ |
| 11:00 | <annevk> | smaug____: what are you missing out on? |
| 11:01 | <smaug____> | comments from bug 25412 |
| 11:01 | <smaug____> | but reading those now |
| 11:02 | <annevk> | :/ |
| 11:04 | <Ms2ger> | MikeSmith, ^ |
| 11:04 | <annevk> | so JakeA under http/https in http://fetch.spec.whatwg.org/#concept-basic-fetch we alternate on service worker / no service worker |
| 11:05 | <annevk> | JakeA: a response from the service worker will still have all the checks a HTTP response has too |
| 11:05 | <annevk> | JakeA: e.g. 301, 401 |
| 11:06 | <annevk> | JakeA: service worker only intercepts http/https traffic |
| 11:06 | <annevk> | JakeA: not data or blob URLs |
| 11:07 | <JakeA> | annevk: would SW branch at step 7 of the http(s) steps? |
| 11:08 | <annevk> | JakeA: of the initial set of steps, something like that |
| 11:09 | <annevk> | JakeA: we haven't really detailed how uploading works |
| 11:09 | <annevk> | JakeA: presumably the request would arrive before all the data gets there |
| 11:10 | <annevk> | JakeA: I've been thinking of factoring out "upgrading a request to a proper HTTP request", "making an http request", "creating a response from an http response", etc. |
| 11:10 | <JakeA> | annevk: the request body in SW would be a stream. Need to get my head around what we can & can't do, and which things should tee automatically |
| 11:10 | <annevk> | JakeA: to make the flow a bit more apparant |
| 11:10 | <MikeSmith> | smaug____: dunno why it wouldn't be sending you bugmail as expected |
| 11:11 | <annevk> | JakeA: currently it's a bunch of paragraphs intertwined with steps, not the best |
| 11:11 | <JakeA> | annevk: Good to have that flow there though |
| 11:11 | <JakeA> | annevk: It's like… this SW thing might actually happen |
| 11:11 | <MikeSmith> | smaug____: I'm receiving bugmail from bug 25412 fine |
| 11:12 | <MikeSmith> | about 6 messages from the last two days |
| 11:13 | <annevk> | JakeA: yeah, took me a while to realize how badly SW needs Fetch, glad I wrote it |
| 11:13 | <MikeSmith> | ーMy main criterion is "A C++ implementation of this algorithm will not crash" |
| 11:14 | <annevk> | MikeSmith: for a tombstone |
| 11:14 | <MikeSmith> | heh |
| 11:16 | <MikeSmith> | in other news for some bizarre reason my Opera 12 won't connect to whatwg.org nor google.com |
| 11:19 | <jgraham> | Opera has good taste in gradients and so won't let you see whatwg specs, or other properties with which Hixie has a professional association |
| 11:20 | <MikeSmith> | haha |
| 11:20 | <MikeSmith> | I like that gradient |
| 11:45 | <smaug____> | MikeSmith: I _think_ the same issue with w3 bugmail has happened before |
| 11:45 | <smaug____> | oh well |
| 12:20 | <tobie__> | slightlyoff: hey, what are you using to write the service-worker spec? It's totally screwing up my toolchain. :( |
| 12:48 | <zcorpan> | yay errata... https://www.w3.org/Bugs/Public/show_bug.cgi?id=25290 |
| 13:04 | <annevk> | tobie__: all the goo.gl URLs also... |
| 13:04 | <annevk> | not sure what is going on there |
| 13:05 | <zcorpan> | google, try switching it off and on again |
| 13:16 | <Domenic_> | JakeA: you plan to buffer the entire response body in memory? O_O that defeats the purpose of streaming it. |
| 13:17 | <zcorpan> | MikeSmith: looks like v.nu never implemented the "xml" restriction for <embed> |
| 13:17 | <annevk> | Domenic_: I think sometimes getting the response as a single string is fine |
| 13:17 | <Domenic_> | annevk: JakeA: yes definitely a TransformStream converting ArrayBuffer to text is in the plan |
| 13:17 | <annevk> | Domenic_: e.g. if you know it's small |
| 13:17 | <JakeA> | Domenic_: Yes, the response may be json for instance |
| 13:18 | <zcorpan> | MikeSmith: but it only gives a warning for foo:bar foo,bar etc, rather than an error |
| 13:18 | <Domenic_> | JakeA: annevk: OK, but ... if you're going to buffer the full thing anyway, then don't bother making it a stream |
| 13:18 | <JakeA> | Domenic_: This would be developer choice |
| 13:18 | <JakeA> | Domenic_: We give them a response object with a stream for the body |
| 13:18 | <Domenic_> | JakeA: no it's not. If the computer is buffering it all, then having it as a stream is pointless. |
| 13:18 | <annevk> | Domenic_: there's a big problem with Response.prototype.body and a TransformStream |
| 13:19 | <annevk> | Domenic_: you need other data from the Response to properly do it |
| 13:19 | <JakeA> | Domenic_: But we want to make it non-trivial for them to get the whole response body, if that's what they want |
| 13:19 | <annevk> | JakeA: there's a point to be made that as with XMLHttpRequest, the choice for what datatype you want is to be made upfront |
| 13:19 | <tobie__> | Agree with annevk. |
| 13:20 | <Domenic_> | JakeA: that's easy. readToEnd(Response.prototype.body) |
| 13:20 | <tobie__> | + consistency |
| 13:20 | <Domenic_> | readToEnd is a reusable function that works with *all* streams |
| 13:20 | <Domenic_> | err, readToEnd(response.body) |
| 13:20 | <JakeA> | Where does that method live? |
| 13:20 | <Domenic_> | npm? |
| 13:21 | <JakeA> | :( |
| 13:21 | <Domenic_> | I dunno, we could add a global.streamHelpers namespace |
| 13:21 | <JakeA> | annevk: Maybe response.body shouldn't be a stream at all, and you'd get one via .to('stream') |
| 13:21 | <Domenic_> | annevk: you need headers, sure. but the body stream and the headers are separate |
| 13:22 | <annevk> | brb |
| 13:22 | <Domenic_> | annevk: In Node: var request = getThingy(); request.on('response', function (response) { console.log(response.headers); response.body.pipe(process.stdout); }) |
| 13:23 | <Domenic_> | Now I understand if there's a sequencing problem here |
| 13:23 | <Domenic_> | i.e. if streams will be done/implemented after service workers (which seems possible, perhaps probable) |
| 13:23 | <Domenic_> | and you need something to hold you over in the meantime |
| 13:23 | <Domenic_> | but it will be redundant after streams land |
| 13:23 | <JakeA> | Domenic_: We've already got .toBlob, probably going to switch that to .to(type) |
| 13:24 | <Domenic_> | because nobody is going to want to use service worker's idiosyncratic way of buffering a whole stream and converting it to text |
| 13:24 | <Domenic_> | what does .to(type) return |
| 13:24 | <JakeA> | promise |
| 13:24 | <Domenic_> | for? |
| 13:24 | <JakeA> | depends on type |
| 13:25 | <Domenic_> | so promise for stream for example? |
| 13:25 | <Domenic_> | seems bad |
| 13:25 | <Domenic_> | here would be my vision |
| 13:25 | <JakeA> | Could be, although I think it's still better to reserve .body for the stream |
| 13:25 | <Domenic_> | nobody uses blobs ever |
| 13:25 | <zewt> | (what) |
| 13:26 | <Domenic_> | .body is a stream, when streams land |
| 13:26 | <Domenic_> | .to('arraybuffer') is conceptually readToEnd(response.body).then(concatAllArrayBufferSegmentsIntoOneGiantArrayBuffer) |
| 13:26 | <JakeA> | Domenic_: "nobody is going to want to use sw's way of buffering a whole stream to text" Really, so if I want to get some JSON from a request, people won't want to do response.to('text').then(function(text) {}), they'd rather have to npm install something to do the same thing? |
| 13:27 | <zewt> | the to(type) thing is ugly, don't do that |
| 13:27 | <Domenic_> | .to('string') is conceptually readToEnd(response.body.pipeThrough(new TextDecoderStream('utf8'))).then(concatAllStrings) |
| 13:27 | <Domenic_> | JakeA: yes, because the thing they install from npm will work with *any* stream |
| 13:28 | <JakeA> | "People won't use querySelectorAll, because they can just import Sizzle" |
| 13:28 | <Domenic_> | False analogy |
| 13:28 | <Domenic_> | It would be as if you had a QSA that only worked on SVG |
| 13:28 | <Domenic_> | and Sizzle worked on any DOM |
| 13:30 | <Domenic_> | oh and implicit in that vision was that response.body is a stream of arraybuffers because that is the primitive |
| 13:30 | <JakeA> | Well in this case, Sizzle works in more browsers than QSA |
| 13:30 | <Domenic_> | we're talking about the far-future |
| 13:30 | <Domenic_> | where both streams and SW are there |
| 13:30 | <Domenic_> | so people are now faced with a choice |
| 13:30 | <Domenic_> | something that they have to remember to look up for SW |
| 13:30 | <Domenic_> | or something that works for every stream in the same way |
| 13:31 | <Domenic_> | and that they already use for lots of other things in their code |
| 13:32 | <JakeA> | Hmm, this is a lot of future-prediction. Aside from that, SW is likely to land before streams, and we need to offer a way for people to get at response/request bodies |
| 13:33 | <JakeA> | We've reserved .body for a readable stream |
| 13:33 | <Domenic_> | yes, as i said, that's fine. there is a sequencing problem. but they will be conceptually vestigal after streams land, and---i predict---perceived as legacy vestiges. |
| 13:33 | <Domenic_> | yay :) |
| 13:33 | <JakeA> | I'm not confident in that prediction, but it doesn't matter |
| 13:34 | <Domenic_> | agreed |
| 13:34 | <Domenic_> | i would urge you to not have any blobs in new APIs and just use ArrayBuffers |
| 13:34 | <Domenic_> | i might be missing something. but ArrayBuffers are JS's binary type. |
| 13:35 | <zewt> | not a good suggestion; both Blobs and ArrayBuffers are useful and serve different purposes |
| 13:35 | <Domenic_> | and blobs have lots of problems regarding racy weak-ref sematnics |
| 13:35 | <zewt> | no they don't... |
| 13:35 | <Domenic_> | zewt: educate me. what purpose do Blobs serve that ArrayBuffers do not serve. |
| 13:35 | <JakeA> | zewt: What's wrong with .to(type)? The intention is to offer something like .responseType and .response in XHR, but not that awful |
| 13:35 | <Domenic_> | yes, they do. we were just going over them in TAG. |
| 13:36 | <Domenic_> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=25081 |
| 13:36 | <zewt> | being able to represent data that's stored on disk, which can't be accessed synchronously, and (as a corrolary to that) being able to represent large blocks of data which need to be splashed to disk |
| 13:36 | <Domenic_> | The former is Promise<ArrayBuffer> |
| 13:37 | <Domenic_> | the latter is arrayBuffer |
| 13:37 | <zewt> | blob reading is underdefined, but that's not an inherent problem with blobs themselves (and it's being worked on) |
| 13:37 | <zewt> | that doesn't make sense at all |
| 13:38 | <tobie__> | JakeA: why `to("type")` instead of `toType`? |
| 13:38 | <zewt> | if you get a File from a user via <input>, you don't want a callback system wrapping ArrayBuffer, you want a File (a Blob) |
| 13:38 | <Domenic_> | what purposes does a File serve that an ArrayBuffer does not. |
| 13:39 | <Ms2ger> | .name |
| 13:39 | <Domenic_> | { name, data } done |
| 13:39 | <zewt> | structured clone wouldn't work, which things like postMessage and IndexedDB depend on |
| 13:39 | <Domenic_> | structured clone works fine with ArrayBuffers |
| 13:39 | <Domenic_> | and works fine with shallow objects containing arraybuffers |
| 13:39 | <zewt> | it seems like you don't have a basic understanding of what Blob is if you think it can be replaced with a callback to ArrayBuffer |
| 13:40 | <Domenic_> | that's possible, but nobody here is saying anything otherwise |
| 13:40 | <Domenic_> | it appears to be a binary data type with strictly less features than arraybuffer |
| 13:41 | <zewt> | if you have a File pointing to a user-space file, you can stash the File object in History API (via structured clone), and reload it later after the session is restored, regaining access to the file (as long as it hasn't changed), without the UA having to make a deep copy of the file |
| 13:41 | <JakeA> | tobie__: That's the other option, but if they're going to be legacy (as Domenic_) suggests, I'd rather have one method than more than one. Also, naming the function that gives you a string is tough :D |
| 13:41 | <zewt> | i don't begin to see how that could map to a callback to a bunch of ArrayBuffers |
| 13:42 | <zewt> | you can seek into a Blob to read an arbitrary subset, without reading unwanted stuff from disk; same |
| 13:42 | <Domenic_> | zewt: ArrayBuffers and blobs are both things that can be transferred without making deep copies. What about blobs gives them this capability that you claim array buffers don't have? |
| 13:43 | <Domenic_> | hmm, seeking is interesting. thanks, that is compelling. although it sounds like the concept of "file handle" and "binary data" have been conflated into the blob concept. |
| 13:44 | <zewt> | if you store a File pointing to a user's document, the UA can simply internally store something like { type: "File", path: "c:/Documents/resume.txt", mtime: 12345 /* don't allow access if the mtime changes */ }, and later restore the File from that |
| 13:44 | <Domenic_> | ok, so *File*s have special capabilities |
| 13:44 | <Domenic_> | *Blob*s do not |
| 13:44 | <zewt> | no, File == Blob, except for a bit of extra data (the filename) |
| 13:44 | <Domenic_> | And that's still an optimization |
| 13:44 | <zewt> | (i think they should be the same type) |
| 13:45 | <Domenic_> | You could do the same with a file-backed arraybuffer |
| 13:45 | <zewt> | not preemptively reading or making a copy of a 500 GB file from disk is not an optimization in any practical sense |
| 13:45 | <Domenic_> | file handles as a use case is interesting, i agree |
| 13:46 | <zewt> | (okay, too many zeroes in that example) |
| 13:46 | <Domenic_> | if i think of the only use case for blobs as being to represent seekable file handles, that's fine |
| 13:46 | <Domenic_> | but e.g. using them to represent http responses is just weird |
| 13:46 | <zewt> | depends on the case |
| 13:47 | <zewt> | i agree there are fewer cases where it's optimal for that |
| 13:47 | <Domenic_> | (i appreciate you being willing to stick with me until i got it.) |
| 13:47 | <zewt> | only a few more minutes before I have to head to work, so I have a time cap :) |
| 13:48 | <zewt> | there are probably better examples, but: reading a 100 MB archive from the server (say, game data), then reading data out of it (loading textures for the game) |
| 13:49 | <zewt> | with Blob, the UA can read the big file to disk (it may not even have enough memory to store all that live); when you slice out the pieces you need it reads just the data you ask for |
| 13:49 | <zewt> | ArrayBuffer can never stash data on disk, because it can be accessed synchronously |
| 13:50 | <Domenic_> | with streams, you get to choose explicitly ;) |
| 13:50 | <zewt> | one other thing Blob allows is shallow copies when posting to Workers, since it's immutable (ArrayBuffer *might* be able to do that, if there was a way to mark it read-only...) |
| 13:50 | <zewt> | choosing that should be up to the UA (which knows how much memory it has, etc) |
| 13:50 | <Domenic_> | ArrayBuffers are transferable already |
| 13:51 | <zewt> | transferable isn't a shallow copy, it's moving the data outright |
| 13:51 | <Domenic_> | Ah I see |
| 13:51 | <zewt> | you can post a Blob to 10 workers, say to give a copy of data to a bunch of helpers without making 10 full copies |
| 13:53 | <Domenic_> | frozen arraybuffers are a thing, yeah. but i doubt UAs do the shallow copy today |
| 13:54 | <Domenic_> | plus lots of people hate freeze because it only works in certain specific cases. ArrayBuffers happen to be one of those cases, but the distaste remains. |
| 13:55 | <annevk> | Domenic_: what I meant was that the headers influence the processing of the body |
| 13:55 | <annevk> | Domenic_: so if you just pipe the body, you lose things such as encoding, MIME type |
| 13:59 | <Domenic_> | annevk: that's a good point. there are workarounds of course but you would ideally want `res.body.pipeThrough(new AutoTextDecoder())` to be able to consult the headers. Instead of e.g. `res.body.pipeThrough(new TextDecoder(res.headers.get('Content-Encoding')))` (and I assume that the defaulting logic for that if no header is supplied is some horrendeous |
| 13:59 | <Domenic_> | encoding-spec thing.) |
| 13:59 | <zewt> | cringe |
| 14:02 | <annevk> | Domenic_: yeah, a Blob has that advantage over a stream or ArrayBuffer |
| 14:03 | <annevk> | Domenic_: it carries a MIME type with an optional charset parameter |
| 14:03 | <zewt> | annevk: strictly speaking, ArrayBuffer could carry any of the metadata that Blob and File do |
| 14:03 | <annevk> | Yeah, a Blob could be a promise for an ArrayBuffer I suppose, except for the readonly aspect |
| 14:03 | <zewt> | (which might not be a bad idea, to bring the data models closer together) |
| 14:04 | <zewt> | (though I'd really try to merge File down into Blob first) |
| 14:05 | <Domenic_> | It sounds like promise for ArrayBuffer doesn't have seeking. |
| 14:06 | <zewt> | also compositing blobs together is easy and efficient |
| 14:08 | <annevk> | A blob sucks though |
| 14:08 | <annevk> | The biggest problem is the fixed size |
| 14:09 | <zcorpan> | aaargh. i spent so long debugging why there were 0 tests run. turned out i forgot setup({explicit_done:true}) and created my tests onload :-( |
| 14:09 | <annevk> | And synchronous availability of that size |
| 14:09 | <zewt> | blobs represent immutable data, so it's fine that it's fixed, but yes, it's lame that the property is sync |
| 14:12 | <jgraham> | zcorpan: :( |
| 14:13 | <jgraham> | Maybe if there were no tests it should give some helpful hints |
| 14:13 | <zcorpan> | or if it tries to create tests after the harness thinks it's done? |
| 14:14 | <annevk> | JakeA: maybe we should not use fetch() for the API where you need to read the response |
| 14:15 | <annevk> | JakeA: but instead something like fetchJSON() |
| 14:15 | <annevk> | JakeA: or fetchString() |
| 14:16 | <annevk> | JakeA: and those would take care of doing the proper decoding and just hand you back a promise with the JSON object or string (or maybe something slightly more complicated that also exposes some other data from the response) |
| 14:16 | <JakeA> | annevk: Do those methods mask the status etc of the request? |
| 14:17 | <annevk> | JakeA: response? |
| 14:17 | <annevk> | JakeA: depends on what we want |
| 14:17 | <JakeA> | yes, sorry |
| 14:17 | <Domenic_> | annevk: that makes a decent amount of sense to me given that it encapsulates a lot of encoding-spec and fetch-spec complexity |
| 14:18 | <Domenic_> | e.g. i assume fetchString() is actually quite a lot of code on top of raw fetchArrayBufferSegments() |
| 14:19 | <annevk> | It might not be that much as I'd force it to be utf-8 |
| 14:19 | <Domenic_> | haha |
| 14:20 | <Domenic_> | General comment: I don't mean to push streams too much as the panacea. I think they will solve lots of problems because they have done so in Node pretty well. But I realize I'm all talk at this point, and so am totally fine with skepticism and "interim" solutions until I can convert that talk into actual results. |
| 14:25 | <JakeA> | Domenic_: I'm not skeptic about streams at all. My concerns are around saying "Hey devs, this new fetch method is way better than XHR. If you want to get some JSON, just call fetch('yourjson.json').then(… then import some libraries from NPM…" |
| 14:26 | <annevk> | JakeA: I think we should offer things like fetchJSON if we want to compete with libraries |
| 14:26 | <Domenic_> | Why do you want to compete with libraries? |
| 14:27 | <annevk> | Domenic_: less to reason about what is going amiss |
| 14:27 | <zewt> | developers should never need libraries for common things (like "get some JSON") |
| 14:27 | <annevk> | Domenic_: I actually wanted to ask you if you're still thinking of developing JSIDL or IDL or some such |
| 14:28 | <annevk> | Domenic_: as IDL not being maintained is a pain and "just describe it in prose" is massive ugh |
| 14:28 | <JakeA> | annevk: branching at that point seems weird to me, response processing feels separate to making the request |
| 14:29 | <JakeA> | It's less about competing with libraries & more about making the common stuff easier. We're not doing this with SW, because we don't know what the common things are, but we do know people like to fetch json |
| 14:29 | <annevk> | JakeA: XMLHttpRequest and many libraries do the same though |
| 14:30 | <JakeA> | annevk: I thought you saw XHR as legacy? (I thought you said that when I asked for .send to return a promise) |
| 14:30 | <JakeA> | So the new thing, fetch() shouldn't regress on the old thing in terms of ease-of-use |
| 14:31 | <jgraham> | JakeA++ |
| 14:31 | <annevk> | JakeA: yes, however, I don't think overloading the new thing for many different scenarios is the best solution |
| 14:32 | <annevk> | JakeA: if you look at libraries they offer different fetch methods for the common cases |
| 14:32 | <jgraham> | It's not clear to me that there are many different scenarios |
| 14:32 | <Domenic_> | not regressing is a pretty good line to draw |
| 14:32 | <annevk> | jgraham: euh |
| 14:32 | <jgraham> | annevk: Depends which libraries. |
| 14:33 | <JakeA> | annevk: The libraries also fail on 404 |
| 14:35 | <Domenic_> | that's an interesting usability question |
| 14:35 | <annevk> | JakeA: ugh |
| 14:35 | <JakeA> | (btw, I don't think fetch() should fail on 404) |
| 14:35 | <Domenic_> | should it fail on 500? |
| 14:36 | <annevk> | JakeA: to go back a few steps; there was a case made when .responseType was introduced, that it was supposed to be settled before the response body came streaming in |
| 14:36 | <Domenic_> | people will have to install something from npm to get fail on 404... ;) |
| 14:36 | <annevk> | JakeA: to allow for UA optimizations |
| 14:36 | <annevk> | JakeA: is that no longer needed? |
| 14:36 | <Domenic_> | ^ key question |
| 14:36 | <JakeA> | Domenic_: if (r.status != 200) throw Error("Nah") |
| 14:36 | <annevk> | Domenic_: it fails on "network error", see Fetch |
| 14:37 | <annevk> | Domenic_: anything else is a successful fetch, but might be failure on the protocol level |
| 14:37 | <Domenic_> | i was being kind of silly. let's talk about the UA optimizations. that's more interesting. |
| 14:38 | <Domenic_> | IN THEORY the UA shouldn't be able to optimize any better than giving the raw data to JS and letting JS optimzie |
| 14:38 | <annevk> | I think it mostly came down to being able to decide what kind of object was going to be used as output before the output arrived |
| 14:38 | <JakeA> | annevk: I'm unaware of the optimisation thing. I'd assumed it was because .response would change type as new formats were added, and that would be baaaad |
| 14:38 | <Domenic_> | I feel that if the UA can optimize better then either (a) it's a matter of raw language primitives that JS is lacking; or (b) the API is not good enough. |
| 14:38 | <Domenic_> | (i.e. the API does not expose enough of the lower-level things JS code needs to be able to do things fast.) |
| 14:39 | <Domenic_> | (a) is worrying but i imagine maybe you can't get any faster than blitting response data into an ArrayBuffer backing store? |
| 14:40 | <annevk> | JakeA: well, say if you do to(x) |
| 14:41 | <annevk> | JakeA: first I do to("json") and then I do to("text") on the same response, that would not allow for said optimizations |
| 14:41 | <JakeA> | annevk: yeah, I'm seeing issues with the enum thing. Although to('unknown type') could reject |
| 14:41 | <JakeA> | annevk: Oh I see, true |
| 14:41 | <annevk> | The optimization being that you directly parse into JSON upon getting the bits and lose the original data |
| 14:42 | <JakeA> | annevk: I'm absolutely knowledgeless about the optimisation history of responseType |
| 14:42 | <Domenic_> | but. is parsing json from a C++/Rust buffer faster than parsing it in JS from an ArrayBuffer? |
| 14:42 | <Domenic_> | Seems probable :-/ |
| 14:42 | <annevk> | JakeA: we designed responseType, because responseXML, responseText, et al was such a mess |
| 14:43 | <annevk> | JakeA: and only allowed for lazy optimization, and you'd still have to keep enough data around |
| 14:43 | <annevk> | Domenic_: JSON.parse() exists |
| 14:44 | <Domenic_> | annevk: I think that's at a whole different level than a byte-by-byte parser... |
| 14:44 | <JakeA> | annevk: Would need to define if to ends or tees the stream |
| 14:44 | <JakeA> | if `to` |
| 14:44 | <annevk> | JakeA: we could do that to() only works the first time you invoke it |
| 14:45 | <annevk> | JakeA: which kinda allows for most of the desired optimizations |
| 14:45 | <Domenic_> | this seems good |
| 14:45 | <annevk> | JakeA: it's not very promise-y maybe |
| 14:45 | <Domenic_> | it's stream-ey though |
| 14:45 | <annevk> | promis-ey? |
| 14:45 | <annevk> | hmm |
| 14:45 | <Domenic_> | if you desugar that to streams the most natural way it would indeed consume the stream |
| 14:45 | <JakeA> | Well, it'd be streamy the other way too, it'd be teeing it right? |
| 14:46 | <JakeA> | (am I using the right terminology?) |
| 14:46 | <Domenic_> | yeah it would be, and yeah you are |
| 14:46 | <Domenic_> | but introducing a tee is an extra step |
| 14:46 | <annevk> | JakeA: we could further say that if you invoke .to .body is set to null |
| 14:46 | <Domenic_> | no |
| 14:46 | <annevk> | that might not mean much |
| 14:46 | <JakeA> | annevk: Nah, it's just an exhausted stream |
| 14:46 | <Domenic_> | .body will be an in-the-process-of-being-read stream |
| 14:46 | <JakeA> | or that |
| 14:46 | <Domenic_> | it will be exhausted when the promise fulfills |
| 14:47 | <annevk> | what if you read from .body and the invoke .to? |
| 14:47 | <JakeA> | to would reject |
| 14:47 | <Domenic_> | no |
| 14:47 | <annevk> | or invoke .to and read from body? |
| 14:47 | <Domenic_> | it would give you the JSON representation of the rest of the body |
| 14:47 | <Domenic_> | which would probably be a SyntaxError |
| 14:47 | <JakeA> | oh I see |
| 14:47 | <Domenic_> | if you invoke .to and .read() from the body they're going to interfere with each other pretty badly |
| 14:47 | <JakeA> | Is there a way to tell if you're getting the first bytes of a stream? |
| 14:47 | <Domenic_> | but think of this in terms of desugaring |
| 14:48 | <JakeA> | like a current position, or something |
| 14:48 | <JakeA> | because to() could throw if that isn't zero |
| 14:48 | <annevk> | Domenic_: normally we defend somewhat against such errors |
| 14:48 | <Domenic_> | annevk: OK, as long as it's thought of in terms of defense, that makes sense to me. |
| 14:48 | <JakeA> | (by throw I mean reject) |
| 14:49 | <Domenic_> | JakeA: not in the base stream interface (since bytes are not necessarily a concept at that level). But byte streams could easily add such a property. |
| 14:49 | <annevk> | Domenic_: if someone has a use case we could allow it I suppose |
| 14:49 | <Domenic_> | annevk: I feel like .read() + .to() might have a use case, but the reverse I can't think of one. |
| 14:49 | <annevk> | Domenic_: so the only thing that remains then is how to pass additional info along with a stream |
| 14:50 | <annevk> | Domenic_: so you have bytes + encoding for instance which a TransformStream can use if needed |
| 14:50 | <Domenic_> | annevk: yeah, I am thinking on that. will open an issue. |
| 14:50 | <Domenic_> | the model right now is that the destination doesn't know about what's being piped to it. the pipe just writes into it like anyone else |
| 14:51 | <Domenic_> | but this is a clear use case motivating the ability to either tell the destination metadata first, or have the destination query the source |
| 14:52 | <Domenic_> | in node this is handled fairly jankily. source does dest.emit('pipe', source) when piping begins. |
| 14:52 | <annevk> | great |
| 14:53 | <annevk> | I feel like we made some progress on this API |
| 14:56 | <JakeA> | People who leave writing talks late: I do not know how you survive |
| 15:04 | <Domenic_> | not all of us have fancy explosions in our talks jake ;) |
| 15:04 | <JakeA> | I'm using that joke again. I leaned how to do repeats at the BBC |
| 15:05 | <annevk> | I wonder if we can turn JakeA into some kind of media element |
| 15:06 | <annevk> | Play, pause, repeat |
| 15:06 | <JakeA> | As long as I inherit from stream, I get exhausted a lot |
| 15:07 | <JakeA> | especially after a small amount of exercise |
| 15:08 | <annevk> | pub.pipe(jake).pipe(bed).pipe(talk).repeat() |
| 15:08 | <JakeA> | haha |
| 15:08 | <annevk> | (Obvious disclaimer: I have no idea what I'm doing) |
| 15:09 | <JakeA> | I need a t-shirt with that. Or "cheerfully incompetent" |
| 15:11 | <jgraham> | TypeError: sessionStorage is null |
| 15:11 | <jgraham> | WTF? |
| 15:11 | <JakeA> | that in "private browsing"? |
| 15:11 | <jgraham> | No |
| 15:11 | <jgraham> | http://w3c-test.org/websockets/unload-a-document/001.html |
| 15:12 | <jgraham> | In gecko |
| 15:15 | <Domenic_> | wow the new html spec buttons look like shit at 2560x1440. they looked great at 1600x900 on my work computer. |
| 15:16 | <jgraham> | They look like shit at 1600x900 on my computer |
| 15:17 | <jgraham> | So much for device independence! |
| 17:30 | <Hixie> | mathiasbynens: the fix was to fix the link to point to the right url :-) |
| 17:32 | <Hixie> | Domenic_: send me a screenshot showing the "looks like shit"? (i made them all smaller, maybe that's the difference?) |
| 17:32 | <Hixie> | jgraham: if you have a better idea, let me know! i'm scraping the bottom of the barrel for ideas for making the top of the spec more approachable |
| 17:33 | <Domenic_> | Hixie: it's the way they spread wayyy across the window instead of being a 3x3 grid |
| 17:33 | <Hixie> | yeah that's intentional |
| 17:33 | <Hixie> | the 3x3 grid was making weird optical artefacts and taking way too much room |
| 17:36 | <jgraham> | Hixie: It's hard to imagine how it could look worse than http://i.imgur.com/NkwmZz3.png |
| 17:36 | <jgraham> | Which is the single page spec on my computer |
| 17:36 | <jgraham> | (after a bit of scrolling and hovering) |
| 17:36 | <Hixie> | well that's just a bug |
| 17:37 | <jgraham> | No |
| 17:37 | <jgraham> | It's a bug |
| 17:37 | <Hixie> | i mean it's a bug with the browser, not the page |
| 17:37 | <jgraham> | (that we can easilly avoid by not having the gradient) |
| 17:37 | <jgraham> | and it's bad design of the boxes |
| 17:37 | <jgraham> | (the overflowing text) |
| 17:37 | <Hixie> | ooh, the overflowing text is interesting |
| 17:37 | <Hixie> | i guess you don't have Helvetica Neue |
| 17:38 | <Hixie> | what's a good font on your system that's sans-serif and narrow? |
| 17:38 | <jgraham> | And bad design in general (the use of underline at least, possibly the choice of colours, the drop shadow) |
| 17:39 | <jgraham> | (I am not a designer, so that might not be a useful critique, but those elements seem bad to me) |
| 17:40 | <jgraham> | I have no idea. Surely the boxes should make sure they are wide enough for the contained text |
| 17:41 | <Hixie> | obviously opinions differ on whether the general approach is ugly, but since i'm out of other ideas, the only way i can make progress on that is if someone gives a better idea |
| 17:42 | <Hixie> | the boxes are fixed-width so that they line up in a grid |
| 17:42 | <Hixie> | CSS doesn't to my knowledge give me a way to set all of them to the max of their needed widths |
| 17:42 | <Hixie> | though that certainly would be nice |
| 17:42 | <jgraham> | Well then I guess you need a script |
| 17:43 | <Hixie> | (note that the general style here is very similar to what whatwg.org has had for years) |
| 17:43 | <jgraham> | But I think I have given concrete suggestions (remove the gradient, the drop shadow, and the underline) |
| 17:43 | <Hixie> | the gradient is cool, the drop shadow is cool, and the underline is needed to show it's a link :-P |
| 17:43 | <jgraham> | no, no, no |
| 17:44 | <Hixie> | i mean, this is all aethetics, so it's hard to really argue one way or the other |
| 17:44 | <Hixie> | i actually prefer the gradient that firefox does on the single-page spec |
| 17:44 | <Hixie> | just four bands |
| 17:44 | <Hixie> | might switch to that intentionally |
| 17:47 | <zewt> | Hixie: google's search results suddenly stopped underlining the main link ... drives me crazy |
| 17:47 | <Hixie> | agreed |
| 17:47 | <zewt> | hard to read |
| 18:01 | <Hixie> | man, gradients in blink are all kinds of buggy |
| 18:03 | <jsbell> | Has anyone made (spec, implementation) headway on "replace DOMError with DOMException" ? |
| 18:29 | <smaug____> | what has happened to the html spec |
| 18:30 | <smaug____> | uh, dom spec has the same odd background |
| 18:30 | <smaug____> | green text with dark gray background isn't too easy to read |
| 18:30 | <Hixie> | i'm playing with the spec style sheet. i'm not finding something i like, though. so if you have any ideas, do let me know :-) |
| 18:30 | <Hixie> | it shouldn't be a dark grat background |
| 18:31 | <Hixie> | can you send me a screenshot? |
| 18:31 | <Hixie> | gray |
| 18:31 | <smaug____> | not too dark |
| 18:31 | <Hixie> | (if you're using chrome, chrome has all kinds of bugs with this) |
| 18:32 | <smaug____> | oh, it looks totally different in chrome |
| 18:32 | <smaug____> | are you perhaps using some old blink/webkit only gradient syntax? |
| 18:32 | <Hixie> | no |
| 18:32 | <Hixie> | firefox renders it right |
| 18:32 | <Hixie> | chrome gets it all wrong |
| 18:33 | <smaug____> | anyhow, what is wrong with the old background? |
| 18:33 | <Hixie> | nothing, particularly. |
| 18:33 | <smaug____> | or are you just making the test case harder to load in browsers |
| 18:33 | <Hixie> | just seeing if i can find something better. |
| 18:33 | <smaug____> | s/harder/slower/ |
| 18:33 | <smaug____> | :) |
| 18:33 | <KevinMarks_> | did the spec just turn into an acid test? |
| 18:33 | <Hixie> | the initial reason for playing with the background was that i was trying to find a way to remove the weird artefacts between the buttons on the html spec |
| 18:34 | <smaug____> | KevinMarks_: it has never been an acid test, but something more useful |
| 18:34 | <Hixie> | but those are gone by just making the buttons smaller, now |
| 18:34 | Hixie | goes back to the smooth gradient |
| 18:34 | <smaug____> | in chrome I see a smooth gradient |
| 18:34 | <smaug____> | but oddly slow scrolling speed |
| 18:35 | <Hixie> | chrome's a disaster |
| 18:35 | <Hixie> | trying zooming in and out |
| 18:35 | <Hixie> | or selecting text |
| 18:36 | <Hixie> | and the bands are the wrong widths |
| 18:36 | <Hixie> | and sometiems it's at the wrong angle |
| 18:36 | <Hixie> | and it repaints badly |
| 18:37 | <smaug____> | Hixie: so I was going to look at the spec and what it says about img elements and img loading in case the element is from a document which isn't in any current/active browsing context |
| 18:37 | <smaug____> | looks like blink just doesn't let one to load a new image using such img element |
| 18:37 | <smaug____> | gecko doesn't have such limitation |
| 18:37 | <Hixie> | this is an img that's in a browsing context but not active? |
| 18:38 | <smaug____> | right |
| 18:38 | <smaug____> | say, img element from an iframe |
| 18:38 | <smaug____> | and then iframe is removed from its parent doc |
| 18:38 | <Hixie> | the iframe in that case loses its browsing context, no? |
| 18:38 | <smaug____> | or a new page is loaded to the iframe or so |
| 18:39 | <smaug____> | Hixie: right |
| 18:39 | <Hixie> | "When an iframe element is removed from a document, the user agent must discard the nested browsing context." |
| 18:39 | <Hixie> | so there the img wouldn't have a browsing context at all |
| 18:39 | <Hixie> | not just not an active document in a browsing context |
| 18:40 | <smaug____> | well, what about the case when a new page is loaded to the iframe |
| 18:41 | <Hixie> | looks like the spec is unclear on all this |
| 18:41 | <Hixie> | if there's no browsing context, "fetch" doesn't do anything. if there's a browsing context and it's not active, "fetch" queues up the tasks but they don't do anything until the document is active. |
| 18:42 | <Hixie> | so the img would suddenly update when you navigate back to that page in the session history, in theory |
| 18:42 | <Hixie> | which seems unlikely to match browsers |
| 18:42 | <Hixie> | but who knows |
| 18:42 | <Hixie> | i haven't tested it |
| 18:43 | <smaug____> | blink say something like "request cancelled" or some such in the console |
| 18:44 | <smaug____> | hmm, but ok, queuing makes sense, possibly |
| 18:50 | <Hixie> | i'm soon going to be rewriting the img loading section, so if this needs to be adjusted, now's a good time to do it |
| 18:58 | <jgraham> | Hixie: In the interests of being constructive, I think http://imgur.com/zhxdXcC is an improvement |
| 18:59 | <jgraham> | Although that brown is still particularly ugly |
| 19:19 | <KevinMarks_> | you could just make it a 2048 clone and use their colours |
| 19:26 | <Hixie> | jgraham: that's too big, though. takes up so much room that you can hardly see any of the ToC on anything but a big screen. |
| 19:26 | <Hixie> | jgraham: (it's more or less what we had yesterday) |
| 19:26 | <Hixie> | jgraham: (also i can't tell that those are links) |
| 19:27 | <Hixie> | jgraham: (and it suffers from the intersection optical illusion problem that i was trying to get rid of with the gradient) |
| 19:29 | <Hixie> | jgraham: (also, the green isn't whatwg green and the other colours are a bit bright... we were trying to make them darker yesterday because people complained about it being too in your face) |
| 19:35 | <jgraham> | Hixie: Being able to see the ToC isn't very useful anyway. The brightness is intentional because your colours are really ugly and muddy. There's a reason that no one makes UIs in dark colours. Also I think it is quite easy to guess that they are links. I mean at least as easy as it is to guess that the android/iOS/windows UI elements for launching applications are clickable |
| 19:36 | <jgraham> | the green is the same hue/saturation but 50% brighter |
| 19:36 | <Hixie> | lots of UIs are dark |
| 19:37 | <jgraham> | Pretty sure the lat time I saw that teal colour in a UI was a non-default windows 3.1 theme |
| 19:37 | <Hixie> | the launcher on Android uses icons, with a pictures and a label, which has a long history of being clickable. Here we're making things look just like labels. |
| 19:37 | <Hixie> | i don't think there's a parallel. |
| 19:38 | <Hixie> | my mail client, my irc client, and my editor all have black backgrounds. Can't get much darker than that. |
| 19:39 | <Hixie> | the buttons at the top of http://www.apple.com/ are dark |
| 19:39 | <Hixie> | (and don't look clickable, but that's another story) |
| 19:39 | <jgraham> | OK, let me rephrase |
| 19:39 | <jgraham> | Those colours are ugly |
| 19:39 | <jgraham> | Brighter colours are less ugly |
| 19:39 | <Hixie> | yesterday jcgregorio argued the opposite. |
| 19:39 | <jgraham> | Your boxes don't look clickable |
| 19:40 | <Hixie> | no, the boxes don't. but the text is underlined, so the text is obviously a link. |
| 19:40 | <IZh> | Hi all. Is it possible to make SVG elements to have relative coordinates (to previous element). I want to implement collapsible tree control (where you can expand items by clicking on [+]). I consider html+canvas and svg. In html it's not easy to draw. But in svg it's hard to make simething to collapse like in html (display: none). In svg it's possible to make things like display:hidden. |
| 19:40 | <jgraham> | No |
| 19:40 | <jgraham> | There is nothing about your text that says link to me |
| 19:40 | <Hixie> | ok |
| 19:40 | <Hixie> | if underline doesn't mean "link" to you, i don't know what to say |
| 19:41 | <jgraham> | Huge amounts of the web doesn't use underline for links anymore |
| 19:41 | <Hixie> | anyway, i'm not a fan of this whole box approach |
| 19:41 | <Hixie> | huge amounts of the web suck :-) |
| 19:41 | <IZh> | +1 |
| 19:41 | <jgraham> | Because it's ugly and makes the text hard to read |
| 19:42 | <jgraham> | Despite this people still manage to figure out which things are links |
| 19:44 | <Hixie> | anyway. as i said before, what i'd really like is some better solution that gets away from this whole block paradigm |
| 19:45 | <jgraham> | Sure |
| 19:45 | <Hixie> | some sites use a similar grid approach but with icons, but i'd rather not have to link in a bunch of images |
| 19:45 | <Hixie> | (not to mention having to get the artwork) |
| 19:46 | <jgraham> | In the meantime, can we have something that isn't going to actively make me add a user stylesheet if it doesn't change? |
| 19:46 | <Hixie> | give me a break, the current style isn't that bad |
| 19:46 | <Hixie> | it's way better than what we had before |
| 19:47 | <Hixie> | and it's not like you're gonna spend any time actually looking at the top of the spec |
| 19:47 | <jgraham> | I don't know what to say. I actually am going to turn it off if it stays like this. That's just a fact |
| 19:47 | <Hixie> | ok |
| 19:48 | <Hixie> | i mean, these links aren't useful to either you or me anyway |
| 19:48 | <Hixie> | so making them display:none would be an improvement for both of us |
| 19:48 | <Hixie> | but what i'm going for is trying to get new readers to see that there's useful things they could look at |
| 19:50 | <jgraham> | Sure, I appreciate the idea |
| 19:52 | <KevinMarks_> | it could be more annoying, you could steal http://leaverou.github.io/animatable/ |
| 20:03 | <Hixie> | jgraham: i played with it some more |
| 20:07 | <MikeSmith> | wondering what zcorpan meant by the "xml" restriction for <embed>, and "it only gives a warning for foo:bar foo,bar etc, rather than an error" |
| 20:08 | <MikeSmith> | I guess he meant "Any namespace-less attribute other than name, align, hspace, and vspace may be specified on the embed element, so long as its name is XML-compatible and contains no uppercase ASCII letters" |
| 20:08 | <IZh> | How to make part of SVG to collapse? |
| 20:08 | <MikeSmith> | and the warning in that case comes from the parser |
| 20:09 | <Hixie> | MikeSmith: "Attribute names are said to be XML-compatible if they match the Name production defined in XML, they contain no U+003A COLON characters (:), and their first three characters are not an ASCII case-insensitive match for the string "xml"." |
| 20:09 | <Hixie> | IZh: it seems there's not many people here who know svg well enough to help you :-( |
| 20:12 | <IZh> | I'm not sure that I need SVG. I want to visualize processes CPU consumption. For each process I have a plot that shows CPU utilization over the time. And for each process I know its children. So I want to show a process tree with the ability to collapse unneded subtree. |
| 20:13 | <MikeSmith> | Hixie: yeah so as far as the validator goes, the HTML parser already checks for XML-compatibility of attribute names now, and emits a warning if they're not XML-compatible. But in the case of embed, I guess it needs to be an error to conform to the spec. I guess we could have the parser check to see what element it has open at the point when it emits the current warning message, and if it's embed, change to emitting it as an error instead |
| 20:13 | <IZh> | HTML works better for collapsion. But SVG works better for plot drawing... |
| 20:14 | <Hixie> | MikeSmith: well note that the i expect zcorpan to file a bug (if he hasn't already) asking for this to change |
| 20:14 | <Hixie> | MikeSmith: since apparently the very stable XML 1.0, fifth edition, has errata that removes this reservation. |
| 20:14 | <Hixie> | or something. |
| 20:14 | <Hixie> | but don't worry! TR/ drafts are STABLE. |
| 20:15 | <MikeSmith> | hah |
| 20:15 | <MikeSmith> | yeah |
| 20:20 | <KevinMarks_> | IZh you could look at d3.js - that makes interactive SVG easier |
| 20:20 | <KevinMarks_> | IZh: or put multiple SVG charts inline in HTML and use the HTML to collapse them |
| 20:23 | <IZh> | KevinMarks_: I thought about it. May be lots of svgs is better (although it will be hundreds or thousand). But it was strange to me that there are no more easy ways. |
| 20:24 | <KevinMarks_> | if they're individually linkable, that may be more generally useful - then you can share one weird one |
| 20:24 | <TabAtkins> | IZh: By "collapse", what do you mean? Hide them? |
| 20:24 | <IZh> | Not only hide, but move all elements below it up. |
| 20:25 | <IZh> | Like in html when you remove a paragraph, all subsequent paragraphs will be shifted up. |
| 20:25 | <TabAtkins> | Oh, if you're doing SVG, you have to handle all layout yourslef. |
| 20:25 | <TabAtkins> | SVG is like using HTML with "* { position: absolute !important; }" applied. |
| 20:26 | <TabAtkins> | It's for drawing, not for documents. |
| 20:26 | <IZh> | But in svg I didn' find a way to provide relative coordinates. It seems, they are all absolute. |
| 20:26 | <TabAtkins> | Correct. |
| 20:26 | <IZh> | So hiding the element doesn't move up next elements. |
| 20:27 | <TabAtkins> | Yes, that's what I'm saying. |
| 20:27 | <IZh> | But why they don't have relative coords? :-) |
| 20:28 | <IZh> | Of course, all could be done with the help of js |
| 20:28 | <IZh> | But I first tried to find a way without it. |
| 20:30 | <TabAtkins> | Because it's a drawing language, not a document language. (Also, because the WG has traditionally been dominated by tool vendors, who don't care about hand-authoring, rather than people representing authors.) |
| 20:30 | <TabAtkins> | Either use HTML for your document structure, using SVG for the actual drawings when you need it, or do the whole thing in SVG with a bunch of JS to handle layout. |
| 20:30 | <TabAtkins> | I recommend the former. |
| 20:34 | <IZh> | I tried to avoid thousand svgs in one document. But it seems, I have no choice. :-) |
| 20:35 | <TabAtkins> | There's no difference between 1k <svg> diagrams and a giant <svg> containing 1k diagrams. |
| 20:36 | <KevinMarks_> | well, a lot of HTTP setup and teardowns? |
| 20:36 | <KevinMarks_> | or you mean inline SVG? |
| 20:36 | <IZh> | Inline |
| 20:36 | <TabAtkins> | KevinMarks_: Inline SVG. |
| 20:36 | <KevinMarks_> | ah, OK. |
| 20:36 | <TabAtkins> | Yeah, 1k external resources is clearly worse, but there's no reason to do that. |
| 20:37 | <KevinMarks_> | well the reason is creating separate links for each diagram so you can share just one |
| 20:37 | <KevinMarks_> | with existing img UA model |
| 20:37 | <TabAtkins> | You can do this too, with an appropriately smart preprocessor. |
| 20:38 | <KevinMarks_> | or img with a data URI for the SVG |
| 20:38 | <TabAtkins> | And just make them linkable with an ID. Why link to them separately? |
| 20:38 | <TabAtkins> | Like, http://dev.w3.org/csswg/css-syntax/#token-diagrams is just fine. |
| 20:40 | <IZh> | http://www.bootchart.org/images/bootchart.png |
| 20:41 | <KevinMarks_> | as long as you don't want to copy one image |
| 20:41 | <IZh> | I want something like this. |
| 20:41 | <IZh> | But I want to collapse/expand a subtree of processes |
| 20:41 | <IZh> | Like in a tree-like folder view. |
| 20:43 | <KevinMarks_> | d3 is good at that kind of thing https://github.com/mbostock/d3/wiki/Gallery |
| 20:45 | <IZh> | d3 is a library. But what will be in the DOM? Lots of <svg>? Is seems there is no other way. |
| 20:45 | <IZh> | Or to regenerate big image frow the data on the fly by d3.js. |
| 20:46 | <IZh> | From |
| 20:46 | <KevinMarks_> | yes, lots of svg in the dom |
| 20:46 | <Hixie> | does validator.nu have a "check the referer" option? |
| 20:46 | <Hixie> | or did that get killed along with badges |
| 20:47 | <TabAtkins> | IZh: I have no clue why you think "lots of <svg>" is a bad thing. It's not. Just let it happen. |
| 20:47 | <MikeSmith> | Hixie: does not have that option |
| 20:48 | <KevinMarks_> | SVG is great, shame more sites don't support it as an image type |
| 20:49 | <IZh> | TabAtkins: I thought it will be more easy for the browser to handle one big document than to handle 1000 inline documents. |
| 20:50 | <Hixie> | MikeSmith: k |
| 20:50 | <Hixie> | MikeSmith: is there a bookmarklet for validator.nu i could use? |
| 20:52 | <MikeSmith> | Hixie: there probably is but I don't know of any specific one. there are some browser plugins I know of |
| 20:52 | <Hixie> | k |
| 22:26 | <sicking> | abarth: ping |
| 22:26 | <abarth> | sicking: hiya |
| 22:27 | <sicking> | abarth: do you guys have any special rules regarding loading data from filesystem:// in sandboxed pages? |
| 22:27 | <abarth> | we've certainly had bugs in that area |
| 22:28 | <abarth> | but I thought we fixed them |
| 22:28 | <abarth> | the problem was that those URLs contain an origin string |
| 22:28 | <abarth> | and sandboxed iframes have origins that can't be represented a strings |
| 22:28 | <sicking> | that's not quite the attack I was thinking of though |
| 22:29 | <abarth> | https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/weborigin/SecurityOrigin.cpp&l=47 |
| 22:29 | <abarth> | i think we solve that problem with the security origin cache |
| 22:29 | <abarth> | which lets us use a memory address to represent a unique origin in some cases |
| 22:46 | <sicking> | abarth: speaking of origins. Did you see the recent discussion about origins for blob: URLs and data: URLs? |
| 22:47 | <sicking> | abarth: i put forward a proposal to fix the current mess of origins in data: URLs. I believe that different browsers still have different security handling of data: |
| 22:47 | <sicking> | a very handwavy proposal still |
| 22:51 | <abarth> | sicking: oh, what's the proposal |
| 22:51 | <abarth> | ? |
| 22:52 | <sicking> | abarth: basically treat data: as out-of-origin unless the loader explicitly opts in to something else |
| 22:52 | <sicking> | at least in cases where the contents of the data: can run script |
| 22:53 | <abarth> | ah, something like that could work |
| 22:53 | <sicking> | so for <iframe src="data:..."> it would be considered something similar to a sandboxed origin, unless you do <iframe src="data:..." allowinheritorigin? |
| 22:53 | <sicking> | > |
| 22:53 | <sicking> | we're working towards doing something similar internally in gecko |
| 22:53 | <abarth> | there's a little trickiness there |
| 22:54 | <abarth> | because you haven't linked the allowinheritorigin to the contents of the data URL in a strong way |
| 22:54 | <sicking> | yeah, navigation would get tricky |
| 22:55 | <abarth> | the trouble we have in our implementation is that when we're asked to load a URL in a frame |
| 22:55 | <sicking> | is that what you mean? |
| 22:55 | <abarth> | (yes) |
| 22:55 | <abarth> | we don't have a fool-proof way to figure out where the load request came from |
| 22:55 | <sicking> | just shoot from the hip, that's what we do :) |
| 22:56 | <sicking> | docshell is awesome |
| 22:56 | <abarth> | that might just be some work for us to boil that ocean and keep careful track of where the load comes from |
| 22:56 | <abarth> | it's harder in WebKit, but I guess that's more Apple's problem now |
| 22:56 | <sicking> | i think the idea would be to default all places to "treat data: as sandbox-origin", and then only whitelist particular code paths |
| 22:56 | <abarth> | in WebKit, the URL of the load can be mutated in arbitrary ways in the middle of the load |
| 22:57 | <abarth> | Blink still has all that machinery, but we can rip it out |
| 22:57 | <sicking> | hmm... interesting |
| 22:57 | <sicking> | we have similar abilities |
| 22:58 | <sicking> | an addon can redirect and say "don't load that URL, load this one instead" |
| 22:58 | <abarth> | what if they give a data URL? |
| 22:58 | <abarth> | does it get the origin of the site that originally asked to load http://example.com ? |
| 22:58 | <sicking> | it's a bit of a mess what we do now, so i don't know |
| 22:58 | <sicking> | but the idea would be to treat it as sandbox-origin |
| 22:59 | <abarth> | yeah, that makes sense |
| 22:59 | <abarth> | what's the usecase for making it same-origin? |
| 22:59 | <abarth> | i'm curious why srcdoc doesn't work instead |
| 22:59 | <sicking> | for workers i think there are strong use cases |
| 23:00 | <sicking> | i.e. doing new Worker("data:...") |
| 23:00 | <abarth> | oh, that case is much easier than the iframe case |
| 23:00 | <sicking> | in which case you want to consider the URL same-origin |
| 23:00 | <abarth> | because there's no navigation to worry about |
| 23:00 | <sicking> | right |
| 23:01 | <sicking> | for <iframe> i'm not sure. I'm sure people do use <iframe src="data:...">, but i'm not sure if they have strong use cases |
| 23:01 | <abarth> | so, you'd write new Worker("data:...", { dataURLsInheritOrigins: true } ) ? |
| 23:01 | <sicking> | yeah, something like that |
| 23:01 | <sicking> | *handwave* |
| 23:01 | <abarth> | yeah, that would be easy for us to implement |
| 23:02 | <abarth> | the worker loading path is complicated, but it's just a straight line :) |
| 23:03 | <sicking> | heh |
| 23:03 | <sicking> | a question is what to do if you write: new Worker("http://...", { dataURLsInheritOrigins: true }) |
| 23:03 | <sicking> | and the http server redirects to data: |
| 23:04 | <sicking> | I'd be inclined to say that it should be treated like sandbox-origin (which means that it'll fail) |
| 23:10 | <abarth> | I think we block redirects to data URLs entirely |
| 23:15 | <sicking> | ah |
| 23:15 | <sicking> | we don't |
| 23:16 | <sicking> | but we always treat them as sandbox-origin I think |
