| 00:07 | <TabAtkins> | gsnedders: Buy a Pixel. |
| 00:08 | <gsnedders> | TabAtkins: no. :) |
| 00:08 | <TabAtkins> | Too pricey, or does it fail one of your other criteria? |
| 00:08 | <gsnedders> | Too pricey. If I'm dropping that money, I'd get a Macbook of some variety. |
| 00:11 | <gsnedders> | (and then just entirely replace my existing MBP, instead of getting something more to replace my tablet than anything else) |
| 00:54 | <zewt> | the Most Annoying Thing On The Internet: http://social.msdn.microsoft.com/Forums/en-US/53ae87d1-dd83-4a44-8303-4a31c9c37015/stopping-scrollviewer-from-auto-scrolling-when-item-gets-focus |
| 00:54 | <zewt> | "how do I do this thing?" "never mind, here's the solution" *404* |
| 00:56 | <caitp> | there are many annoying things on the internet, there will be many more in the future |
| 00:56 | <caitp> | exponentially more |
| 02:18 | <zcorpan> | Hixie: i can fix the autorotate thing relatively soon i think |
| 02:29 | <MikeSmith> | zcorpan John told me he'd replied -- replied to you, I think. |
| 02:33 | <zcorpan> | MikeSmith: i don't see anything in my inbox and i don't see anything in http://lists.w3.org/Archives/Public/www-archive/2014May/thread.html |
| 02:34 | <zcorpan> | MikeSmith: he had replied to denis in private before all three of us emailed him and cc-ed www-archive i think, but i wanted a public record |
| 02:36 | <zcorpan> | MikeSmith: so the critic issue actually isn't resolved yet afaict |
| 02:36 | <Hixie> | zcorpan: cool. it sounds pretty straightforward. file a bug on me once you've done it to add it to the index. thanks! |
| 02:37 | <zcorpan> | Hixie: ok |
| 02:38 | <MikeSmith> | zcorpan: OK, when we have cases like this I'd like to suggest we open separate issues and then close the PR, if this kind of problem is the only thing blocking it |
| 02:38 | <MikeSmith> | zcorpan: I think it's bad for everybody to keep PRs hanging open for months on end |
| 02:39 | <MikeSmith> | zcorpan: they get stale and people lose interest in following up on them |
| 02:39 | <MikeSmith> | zcorpan: or in in this specific case, the guy who was responsible for that PR no longer is paid to work on testing, and has moved on |
| 02:40 | <zcorpan> | MikeSmith: i don't disagree that it's bad to have PRs open for a long time |
| 02:40 | <MikeSmith> | zcorpan: I'll ping John again and ask him if he can reply to your www-archive message |
| 02:41 | <zcorpan> | ok great |
| 02:42 | <zcorpan> | Hixie: as for styling, e.g. the stylesheet for http://dev.w3.org/csswg/cssom/ is a lot less busy than the whatwg stylesheet, but still has enough visible cue (at least for me) to see where the links are |
| 02:44 | <zcorpan> | Hixie: i'm not saying that stylesheet is without problems, but i agree with jgraham that it should be possible to create a stable and subtle yet usable style. i'm not sure i agree with jgraham about the underline, it doesn't bother me and something other than color is necessary for people with some color-blindnesses (unless you can find a color that works for all common color blindnesses) |
| 02:44 | <zcorpan> | (maybe a lighter shade would work to make a contrast difference even if you can't distinguish the color?) |
| 02:45 | <MikeSmith> | Hixie: as far as the undelrines, what zcorpan said |
| 02:45 | <MikeSmith> | people who have a problem with underlines are going to have a hard time on the internet |
| 02:47 | <MikeSmith> | Hixie: the underlines have a utility -- exactly the utility that you mentioned earlier (distinguishing, e.g., between hyperlinked <code> and unhyperlinked -- or whatever specific case you mentioned) |
| 02:48 | <MikeSmith> | Hixie: I think some people are willing to sacrifice the utility of the spec to aesthetics or making it look less "busy" or however they're stating it |
| 02:49 | <SamB> | hey, I've heard of this thing called alternate stylesheets |
| 02:50 | <zcorpan> | (i don't personally have a problem with the "busy" style, so long as it doesn't do the fading thing) |
| 02:50 | <MikeSmith> | zcorpan: yeah |
| 02:50 | <zewt> | things nobody should ever have to use: alternate stylesheets |
| 02:50 | <zcorpan> | SamB: that has already been brought up |
| 02:50 | <SamB> | 'kay |
| 02:51 | <zewt> | don't know what's changed, but the main TOC is pretty hard to look at right now, probably too much space around everything |
| 02:52 | <MikeSmith> | zcorpan: I could live without the fading thing, but I thought it was a good clever solution to the problem Hixie was trying to solve. Now, I think, it would be nice to solve that problem if it's solvable, but I'm not sure it is, and maybe it's not worth spending a lot of time trying to solve. |
| 02:53 | <MikeSmith> | zewt: hmm yeah maybe there's too much line space there now |
| 02:53 | <zewt> | looks like all numbered lists have that problem |
| 02:53 | <MikeSmith> | zewt: ah yeah, seems so |
| 02:54 | <MikeSmith> | I guess Hixie should just rachet that back down a bit |
| 02:54 | <zewt> | dotted lists are fine |
| 02:55 | <MikeSmith> | anyway it would be a shame to see that spec change in ways that it less usable for implementors, even it if it made it slightly more usable for others |
| 02:56 | <MikeSmith> | I've never had any problem with the colors or anything else. in fact, the opposite -- I really appreciate that all those various cues are there are value them. I couldn't care less if it looks "busy" as long as it makes it easier for me to find what I need |
| 02:57 | <MikeSmith> | I'm not reading it for fun |
| 02:58 | <MikeSmith> | if people want less busy, there's always IETF style |
| 02:58 | <zewt> | 80 column with hardcoded page breaks for 80x55 daisy wheel printers? |
| 02:59 | <MikeSmith> | zewt: yeah but I meant more the lack of colors and the lack of hyperlinks |
| 03:00 | <SamB> | I like it how zewt says it though |
| 03:00 | <SamB> | I mean, it's funnier that way |
| 03:00 | <SamB> | not that I'd want to see the spec like that |
| 03:00 | <zewt> | i didn't have any issues with the formatting, my main issue with the spec is just wishing it loaded faster, heh |
| 03:01 | <zewt> | (maybe if the multipage referencing worked better i'd use it, though being able to text search the whole spec is probably also hard to do without) |
| 03:01 | <SamB> | so you want it to be less busy on the *inside* |
| 03:01 | <SamB> | me too |
| 03:01 | <zewt> | i don't know the first thing about why it's so slow, heh ("it's huge" is obviously a part, but I assume it's more complicated than that) |
| 03:02 | <SamB> | I remember a time when I could actually load the single-page spec |
| 03:02 | <zewt> | guess I could load it with no styles or scripts and find out |
| 03:03 | <TabAtkins> | It's huge, it does some JS loops over the whole document, and I'd bet the selectors aren't well-optimized. |
| 03:06 | <zewt> | "no copyright is asserted on this file"? is that really a valid way to disclaim copyright? heh |
| 03:10 | <MikeSmith> | Hixie: about the validator not catching the <dd> thing before you fixed it, I think it might have been because validator.nu hasn't been synched for a while and has an older version of the schema that wasn't going <dl><dt><dd> checking correctly for a while after we made the change to allow <script> and <template> in there |
| 03:11 | <MikeSmith> | Hixie: I think it works as expected in the current source and at http://sideshowbarker.net:8888/ and http://validator.w3.org/nu/ |
| 03:22 | <TabAtkins> | zewt: No, it's not a valid way. Copyright is automatic regardless of what you say. |
| 03:23 | <TabAtkins> | At least in US law, and most other countries. |
| 03:24 | <Hixie> | MikeSmith: cool |
| 03:25 | <Hixie> | i should probably change to ssb.n:8888 |
| 03:25 | <Hixie> | btw re the style sheet, there were some substantial changes earlier today, so i'm letting it sit for a few days to see how people like it |
| 03:26 | <Hixie> | (in particular, i think it might be less busy that the /csswg/cssom/ style sheet at this point) |
| 03:35 | <TabAtkins> | Still super-hate the fading thing. |
| 03:35 | <TabAtkins> | I didn't hate it earlier, but it's fading on me. ^_^ |
| 03:36 | <Hixie> | it's long gone |
| 04:14 | <TabAtkins> | Oh, hm, must need to force-refresh. |
| 04:33 | <zcorpan> | MikeSmith: can you look into the w3c-test:mirror thing? i want some people to look at the tests without having them clone and get wptserve running |
| 04:34 | <zcorpan> | MikeSmith: the PR is https://github.com/w3c/web-platform-tests/pull/996 |
| 04:35 | <zcorpan> | oh i see you replied in #testing |
| 04:41 | <MikeSmith> | zcorpan: checkong on it now |
| 04:50 | <zcorpan> | MikeSmith: thanks! |
| 04:50 | <zcorpan> | MikeSmith: maybe i don't have the right permissions, like jgraham said? |
| 04:52 | <MikeSmith> | yeah checking on that too |
| 04:55 | <MikeSmith> | zcorpan: http://w3c-test.org/submissions/996/ |
| 04:55 | <MikeSmith> | still working on the underlying cause |
| 04:56 | <zcorpan> | MikeSmith: thank you |
| 04:58 | <MikeSmith> | zcorpan: fwiw as far as the underlying cause, I think it might be a github bug |
| 04:58 | <MikeSmith> | because the script relies on https://api.github.com/repos/w3c/web-platform-tests/collaborators |
| 04:59 | <MikeSmith> | the sync script |
| 04:59 | <MikeSmith> | zcorpan: and you're not listed there and neither am I |
| 04:59 | <zcorpan> | weird |
| 05:00 | <MikeSmith> | yeah |
| 05:00 | <zcorpan> | i can report it to github if you like |
| 05:00 | <MikeSmith> | zcorpan: yeah please do if you have time |
| 05:01 | <MikeSmith> | zcorpan: and in the mean time I guess the workaround to get something mirrored is to ask somebody who's actually listed there to add a comment |
| 05:02 | <MikeSmith> | jgraham is not there either, no Ms2ger, so I guess we really should be checking it against some other list if there is one |
| 05:03 | <zcorpan> | MikeSmith: what's your github handle? |
| 05:03 | <MikeSmith> | zcorpan: sideshowbarker |
| 05:08 | <zcorpan> | MikeSmith: ok reported. didn't get a URL or anything for the issue and i failed to get under 140 chars so i didn't get a gold star |
| 05:08 | <zcorpan> | but i'll let you know when i get a reply |
| 05:13 | <MikeSmith> | zcorpan: thanks |
| 05:13 | <MikeSmith> | win 27 |
| 06:05 | <zcorpan> | Hixie: i think i didn't write ""; but actually wrote "list of available images"; in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25797 |
| 06:06 | <zcorpan> | Hixie: is there a bug somewhere tampering with it or am i mistaken about what i wrote? :-) |
| 06:06 | <Hixie> | i don't log anything for file-bug.cgi, so dunno |
| 06:07 | <zcorpan> | ok |
| 06:07 | <Hixie> | but i can't imagine what i could do to cause that :-) |
| 06:07 | <zcorpan> | yeah i dunno either |
| 06:07 | <zcorpan> | maybe it was what i wrote |
| 06:08 | <Hixie> | wait, i do log something |
| 06:08 | <Hixie> | when did you file this? just now? |
| 06:08 | <zcorpan> | 2014-05-19 07:37:09 UTC |
| 06:09 | Hixie | tries to work out what time zone he's in |
| 06:09 | <Hixie> | that's either two minutes in the future or an hour ago |
| 06:09 | <Hixie> | wait wtf |
| 06:09 | <Hixie> | this computer's clock is WAY off |
| 06:11 | <IZh> | Hixie: Hi. Last PDF was not generated because of missing fonts. It seems there are new rare characters in the spec. :-) I'll find suitable font and regenerate it. |
| 06:12 | <Hixie> | hehe thanks :-) |
| 06:12 | <Hixie> | zcorpan: ok according to the logs if there's a bug it's somewhere in Apache or Perl's core libraries |
| 06:13 | <Hixie> | zcorpan: because my code gets the text, then logs it immediately before fiddling with it, and it logged "". |
| 06:14 | <zcorpan> | Hixie: so that means it's unlikely that there is a bug |
| 06:14 | <zcorpan> | i can try filing a new bug with what i think i wrote, and see if it reproduces |
| 06:14 | <Hixie> | occam's razor suggests there isn't a bug. murphy's law suggests there is. your call. :-) |
| 06:16 | <zcorpan> | didn't reproduce |
| 06:19 | <IZh> | I have written a script that looks for missing characters and prints font list that contains it sorted by number of missing characters found in each font. :-) |
| 06:50 | <IZh> | Hixie: I've fixed it. :-) |
| 06:51 | <IZh> | Hixie: Currently the document needs 15 fonts. (And some web-fonts too.) |
| 07:47 | <annevk> | Hixie: I think the only reason you wanted FontLoader or some such is to be able to have a solution for fonts in workers |
| 07:47 | <annevk> | Hixie: in combination with <canvas> in workers |
| 07:56 | <TabAtkins> | Which exists! |
| 07:57 | <TabAtkins> | I need to make FontFace objects transferable, but you can definitely construct them inside of a worker and add them to the font source. |
| 07:58 | <TabAtkins> | Hm, I'm adding a .fonts property to the worker global. Is that okay? Should I be doing something else? |
| 07:58 | <TabAtkins> | It's added to document in normal pages. |
| 08:10 | <annevk> | TabAtkins: why not CSS.fonts ? |
| 08:11 | <TabAtkins> | annevk: Good question, I guess. |
| 08:20 | <annevk> | TabAtkins: I guess another thing to think about is how this would work with modules |
| 08:21 | <annevk> | TabAtkins: presumably once you import "css" this should be imported as well, but we haven't really explored the layering of the subsystems I suppose |
| 08:21 | <JakeA> | Hixie: What's your take on promise-vending .loaded() methods (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-March/253949.html)? The HTML Imports spec wants it (https://www.w3.org/Bugs/Public/show_bug.cgi?id=25007) but it'd be great to have it on other <link> elements too (and maybe img, script) |
| 08:47 | <annevk> | JakeA: why methods? |
| 08:52 | <JakeA> | annevk: because they're of the moment. As in, img.src = foo; img.loaded().then(...); img.src = bar; img.loaded().then(...) |
| 08:52 | <JakeA> | felt like methods made more sense, but it wouldn't break my world if they were properties :D |
| 09:09 | <annevk> | JakeA: if you invoke loaded() multiple times, do you get the same object? |
| 09:10 | <JakeA> | annevk: Yes, unless there's a good reason not to. Of course, as soon as you change "src" the promise vended by loaded() changes |
| 09:10 | <annevk> | JakeA: in that case a property seems fine |
| 09:11 | <JakeA> | annevk: navigator.serviceWorker.whenReady should be the same I guess |
| 09:11 | <JakeA> | (although I hate that API with a passion, but don't have a better idea) |
| 09:12 | <annevk> | JakeA: yeah makes sense |
| 09:34 | <tobie> | It feels kind of weird to have a promised not related to the action itself. |
| 09:35 | <tobie> | As in: img.loadResource(url).then(... |
| 09:42 | <JakeA> | tobie: I don't think it's a big deal. People have been using whatever.ready(callback) in various libraries |
| 09:42 | <annevk> | tobie: it's just status observation, seems fine for one-offs |
| 09:44 | <tobie> | Yeah. There seems to be cases where there's no other solution than that one. Thinking out loud really, but it seems it would help if we can classify those. |
| 09:47 | <hsivonen> | mathiasbynens: validator.nu seems to be up for me. maybe it was just busy earlier? |
| 09:50 | <tobie> | Seems most of them are around the declarative/imperative boundary (not sure whether this helps). |
| 09:55 | <mathiasbynens> | hsivonen: yeah, works fine now. I’ll keep an eye on it |
| 10:06 | <annevk> | tobie: well, serviceWorker.whenReady is not on that boundary I think |
| 10:07 | <JakeA> | Neither is document.ready() |
| 10:07 | <annevk> | tobie: I think the pattern is more that if you have something that multiple parties might want to observe, you need to expose it independently from the action |
| 10:07 | <tobie> | doc.ready is. |
| 10:07 | <annevk> | tobie: as a status-promise |
| 10:07 | <JakeA> | Or anyParserInsertedElement.loaded() |
| 10:07 | <annevk> | (again, I'd prefer document.ready and ele.loaded) |
| 10:08 | <JakeA> | ah yes, sorry |
| 10:08 | <tobie> | you mean props? |
| 10:08 | <tobie> | I agree. |
| 10:08 | <JakeA> | document.querySelector('img').loaded.then(...) |
| 10:09 | <mathiasbynens> | document.images[0].loaded.then(…) |
| 10:09 | <mathiasbynens> | </code-golf> |
| 10:09 | <JakeA> | haha |
| 10:10 | <JakeA> | but your IRC handle is longer, so it almost balances out |
| 10:12 | <tobie> | None of these (.ready, .ready() .whenReady()) are particularly nice. :( |
| 10:14 | <JakeA> | What's not nice about it? Do you feel the same about jquery's $(document).ready(callback)? |
| 10:14 | <tobie> | yeah. it's terrible. |
| 10:15 | <tobie> | but less ugly with a callback then with a promise. |
| 10:16 | <JakeA> | Got anything more constructive? :D |
| 10:16 | <tobie> | Man, I wish I had. |
| 10:18 | <TabAtkins> | FontFace uses a .loaded attribute to expose a promise. |
| 10:18 | <TabAtkins> | tobie: A promise is a callback. ^_^ |
| 10:19 | <JakeA> | TabAtkins: Ohh, I didn't realise that. Well, that's all the more reason for these to be attributes & not methods |
| 10:19 | <tobie> | agreed. |
| 10:19 | <annevk> | Oh right, TabAtkins is in Seoul, it all makes sense now |
| 10:20 | <TabAtkins> | Hah, wondering about my timezone? |
| 10:20 | <tobie> | when(font.loaded).then |
| 10:20 | <TabAtkins> | tobie: ??? No, font.loaded.then(...) |
| 10:20 | <tobie> | (sorry, toying with stuff) |
| 10:20 | <annevk> | TabAtkins: I was doing the math and at 3-4AM you're usually not around |
| 10:20 | <TabAtkins> | annevk: Yeah, checking gavin's stats I'm virtually never around in the 12am to 6am block. |
| 10:21 | <TabAtkins> | Still a good bit behind jgraham in the stats. I don't think I'll ever move past 5th place. |
| 10:22 | <annevk> | Whoa, Hixie made a solid comeback :-) |
| 10:22 | <JakeA> | await img.loaded; |
| 10:22 | <annevk> | JakeA: you can almost read it |
| 10:22 | <JakeA> | wfm |
| 10:23 | <tobie> | Only concern I still have is loaded feels a tad like a boolean |
| 10:23 | <TabAtkins> | tobie: Was my concern too, but shrug. |
| 10:23 | <tobie> | yeah. |
| 10:23 | <tobie> | What's gavin's stats? |
| 10:24 | <annevk> | tobie: see /topic |
| 10:24 | <tobie> | duh |
| 10:28 | <jgraham> | Also glob has stats under "about". Not as detailed as gavin's though |
| 10:28 | <jgraham> | But using more data, I think? |
| 10:28 | <TabAtkins> | dear gavin (or gavin__ ), your stats page doesn't handle unicode properly. |
| 10:29 | <TabAtkins> | Saw some curly quotes turned into “ |
| 10:30 | TabAtkins | will never get over that Divya holds both first and second place for most all-caps shouting. |
| 10:30 | <TabAtkins> | Even when you cut her shouting in half, she beats everyone else. |
| 10:34 | <jgraham> | I have a theory that the most productive place to write documentation is on the train. Maybe I should just go and sit on the circle line for the rest of the day. |
| 10:34 | <jgraham> | (yes, I know you can't actually just go round and round the circle line anymore) |
| 10:34 | <Ms2ger> | Sounds like a theory to be tested |
| 10:35 | <TabAtkins> | I certainly like writing on the train. |
| 10:42 | <JakeA> | annevk: Looking at https://github.com/slightlyoff/ServiceWorker/issues/235#issuecomment-40742195 - agree the tagging thing is weird, but what can fetchEvent.default() resolve to? |
| 10:49 | <JakeA> | annevk: event.default() could do a fetch but return OpaqueResponse for redirects. Could say that OpaqueResponse redirects don't go back through the serviceworker |
| 10:49 | <JakeA> | feels like trading one kind of magic for another |
| 10:50 | <annevk> | JakeA: I think part of the problem is that you're not observing this from the perspective of how APIs use Fetch (the platform layer, not the API) |
| 10:50 | <annevk> | JakeA: most APIs use Fetch and have it follow redirects |
| 10:51 | <annevk> | JakeA: the navigate action uses Fetch and explicitly tells it to not follow redirects, it's the only part of the platform that does that as far as I know (and maybe AppCache now?) |
| 10:51 | <annevk> | JakeA: so in the typical case all redirects will be followed and you get back a normal Response |
| 10:52 | <annevk> | JakeA: in the navigate case you can already get back an OpaqueResponse as the user can navigate away from your site |
| 10:53 | <annevk> | JakeA: so there we'd hand back an OpaqueResponse for redirects (because Fetch was instructed not to follow them) and allow the navigate action to inspect that and take appropriate action |
| 10:54 | <annevk> | JakeA: but I don't think explaining this in terms of fetch() helps, as that might throw away CSP things, priorities, etc. |
| 10:55 | <annevk> | JakeA: also, there's some things we need to consider with respect to what happens when the user navigates away and the service worker hands back a generated response or some such |
| 10:56 | <JakeA> | annevk: So, if I have <link rel=stylesheet href=blah>, it goes off into the fetch layer, does its redirects, and gives the page its response. How is the base url of the CSS handled, via the response url? |
| 10:58 | <annevk> | JakeA: yes |
| 10:58 | <annevk> | (assuming no service workers in play) |
| 11:11 | <zcorpan> | Hixie: i ran a screenshot of the spec through a color blindness simulator, and it seems OK with protanopia and deuteranopia (1-5% in males), but the link is almost the same as the surrounding text with tritanopia (< 0.003% of males and females) |
| 11:12 | <zcorpan> | (unvisited link, didn't include a visited link in the image) |
| 11:13 | <wilhelm> | jgraham: So like Yamanote parties, just more boring? :D |
| 11:15 | <zcorpan> | http://www.etre.com/simulate.php?image=defa540b013c2e5c3fdfcbd79b63c773&condition=tritanopia&type=jpeg - tritanopia (zoom in, i guess the blurry result can simulate some other visual impairedness :-P) |
| 11:26 | <zcorpan> | Hixie: that said, i think the current style is an improvement |
| 11:29 | <jgraham> | wilhelm: I'm not sure I would want to try and work on the Tokyo metro |
| 11:35 | <JakeA> | annevk: Can I get a sanity check of this? https://github.com/slightlyoff/ServiceWorker/issues/235#issuecomment-43614413 |
| 11:38 | <zcorpan> | Hixie: i'm not entirely sure about the :target styling. i think i'd want the arrow and its box to be smaller. some color for that thing seems OK to me |
| 11:41 | <wilhelm> | zcorpan: It could be fun to have a designer play with a revision of the stylesheet. |
| 11:41 | wilhelm | has one in mind. (c: |
| 11:42 | <zcorpan> | wilhelm: like http://developers.whatwg.org ? |
| 11:43 | <wilhelm> | Oh, I hadn't seen that one. That's certainly more readable. (c: |
| 11:44 | <zcorpan> | Hixie: the "next" link at the bottom is a nice thing in the dev version |
| 11:49 | <annevk> | JakeA: looks wrong |
| 11:50 | <annevk> | JakeA: default() just needs to use incoming "fetchStandardRequest" that could have manualRedirect either set to true or false |
| 11:50 | <zcorpan> | benschwarz_: seems like the svg doesn't load/exist in http://developers.whatwg.org/content-models.html#kinds-of-content |
| 11:50 | <annevk> | JakeA: e.g. <img src=...> comes in SW, SW does default(), redirects will be followed |
| 11:51 | <JakeA> | annevk: isn't that correct? |
| 11:52 | <annevk> | JakeA: oh wait, I missed the if statement |
| 11:53 | <zcorpan> | annevk: so <img> is going to be able to load two resources in parallel |
| 11:53 | <zcorpan> | in case that affects things for SW |
| 11:54 | <annevk> | JakeA: even so, there's no castToOpaqueResponse needed, that should be wrapped automagically |
| 11:54 | <annevk> | zcorpan: that'll just be two events quickly after another |
| 11:54 | <annevk> | zcorpan: SW can't do true parallel |
| 11:55 | <annevk> | JakeA: as in, the way I think this should work is that .default() just hands the request back to Fetch and Fetch does the rest |
| 11:56 | <jgraham> | wilhelm++ for getting a designer to play with the stylesheet. Although they have to understand the functional requirements (most of the things that have style have it for a reason, but the styles that they have aren't necessarily good) |
| 11:56 | <annevk> | JakeA: and then Fetch hands a Response, potentially Opaque, back to .default()'s promise |
| 11:56 | <zcorpan> | annevk: not sure i follow, but then i basically know nothing about SW :-) |
| 11:57 | <annevk> | zcorpan: the network stack is still on a single thread |
| 11:58 | <annevk> | zcorpan: anyway, it should be fine |
| 11:58 | <zcorpan> | annevk: so you can only fetch one thing at a time in a SW? |
| 11:58 | <annevk> | zcorpan: you can queue one thing at a time |
| 11:58 | <annevk> | zcorpan: it's a subtle but important difference, and that's not really limited to SW |
| 11:59 | <zcorpan> | but then you could have mutliple things fetching at the same time? |
| 12:00 | <annevk> | zcorpan: yeah, it's not really different from constructing several XHRs in a row and then invoking send() in them in a row and waiting for data to come back |
| 12:01 | <zcorpan> | ok. so i didn't mean that <img> is able to queue two things in parallel. i meant that it could start fetch A at time T and start fetch B at time T+x which would not necessarily abort A |
| 12:02 | <wilhelm> | jgraham: Indeed. (c: |
| 12:02 | <annevk> | zcorpan: I can't think offhand of places that assume 1 API : 1 fetch |
| 12:02 | <zcorpan> | ok |
| 12:03 | <annevk> | zcorpan: well... sounds like a potential problem for integrity="" |
| 12:03 | <annevk> | zcorpan: and of course you can't control crossorigin for each fetch |
| 12:04 | <annevk> | zcorpan: you might want to email public-webappsec⊙wo with regards to integrity="" I suppose, given that this kind of loading is actually a feature people want to use |
| 12:04 | <annevk> | s/given/provided/ |
| 12:05 | <zcorpan> | annevk: do you have a pointer to integrity=""? |
| 12:05 | <zcorpan> | annevk: it's not so much want to use, more required for web compat |
| 12:05 | <annevk> | zcorpan: http://w3c.github.io/webappsec/specs/subresourceintegrity/ |
| 12:05 | <annevk> | zcorpan: basically allows you to specify a hash for the resource |
| 12:08 | <zcorpan> | so... for example let's say you have <img src=foo integrity=bar> and then, while foo is loading but the dimensions are known, you do .src = 'baz'; .integrity = 'quux'; which starts a pending fetch. then foo completes loading and the UA compares the hash and finds that it doesn't match quux? |
| 12:11 | <zcorpan> | maybe the integrity thing could check the value of the integrity attribute at the time you resolve the URL or at the time you start the fetch, instead of when you're done fetching |
| 12:13 | <annevk> | zcorpan: it could be an argument for tight coupling the integrity data with the fetch |
| 12:13 | <zcorpan> | seems like it does take the integrity at the time of start of fetch |
| 12:14 | <zcorpan> | also: monkey patching |
| 12:14 | <annevk> | zcorpan: yeah, temporarily |
| 12:15 | <annevk> | Temporarily monkey patching is actually somewhat beneficial, it's just that people don't always follow up on cleaning up |
| 12:15 | <zcorpan> | it seems like the general approach is compatible with <img>'s dual fetching |
| 12:15 | <zcorpan> | yeah |
| 12:17 | <zcorpan> | do people want to use integrity together with picture/srcset ? |
| 12:19 | <annevk> | prolly |
| 12:19 | <zcorpan> | <img srcset="foo.jpg 100w integrity(foo), bar.jpg 200w integrity(bar)"> maybe |
| 12:19 | <annevk> | if that works that could be nice |
| 12:20 | <annevk> | can you do url(foo.jpg) too? |
| 12:20 | <zcorpan> | no |
| 12:20 | <annevk> | oh |
| 12:20 | <annevk> | I would expect CSS to end up with fetch(foo.jpg, other stuff here) |
| 12:20 | <annevk> | and deal with integrity that way if we want it there |
| 12:21 | <zcorpan> | can you give an example of how it would work together with some property (like background-image, say)? |
| 12:25 | <annevk> | background-image:fetch(foo.jpg, some new syntax) |
| 12:26 | <jgraham> | that's pretty ugly |
| 12:26 | <jgraham> | (using "fetch" there sounds very imperative whereas css is typically declarative) |
| 12:28 | <zcorpan> | annevk: i think foo.jpg will need to be either a string or a url() to remain sanity |
| 12:29 | <zcorpan> | but i also agree with jgraham about the imperative part |
| 12:29 | <annevk> | zcorpan: I'm sort of indifferent on the name and the syntax particulars |
| 12:29 | <zcorpan> | ok |
| 12:29 | <zcorpan> | so now there's a thing called image() in css |
| 12:30 | <zcorpan> | with some new syntax |
| 12:30 | <annevk> | it's more that we need to be able to pass more data along with a URL |
| 12:30 | <zcorpan> | so maybe integrity can go in that |
| 12:30 | <annevk> | can image() be used for SVG subresources and shapes and things? |
| 12:30 | <annevk> | also doesn't work for @import |
| 12:34 | <zcorpan> | yeah i guess we've deferred on supporting crossorigin for @import |
| 12:37 | <annevk> | :/ |
| 12:38 | <zcorpan> | maybe i can bring it up tomorrow |
| 12:38 | <zcorpan> | is there an email somewhere about this? |
| 12:39 | <annevk> | don't think so |
| 12:39 | <zcorpan> | can you send one to www-style? :-) |
| 12:39 | <annevk> | well, there's a long thread on public-fx somewhere |
| 12:39 | <annevk> | regarding what to do with shapes and SVG and what not and how they can all work together |
| 12:41 | <annevk> | how can you figure out if two things happen in the same task? |
| 12:42 | zcorpan | doesn't follow |
| 12:44 | <annevk> | http://dump.testsuite.org/xhr/upload-events.html I want to know if (upload) "loadend: 1" is in the same task as "xhr onreadystatechange: 2" |
| 12:46 | <annevk> | Hmm, in Chrome they are not |
| 12:54 | <zcorpan> | annevk: like load() a video in the first event and check the networkState in the second event |
| 12:55 | <annevk> | zcorpan: for next time :-) |
| 12:55 | <zcorpan> | annevk: if it's NETWORK_NO_SOURCE then they were the same task, if it's NETWORK_EMPTY then they were separate tasks |
| 12:56 | <zcorpan> | for a <video> without src or source |
| 12:58 | <zcorpan> | annevk: do you have a pointer to public-fx thread? |
| 13:00 | <zcorpan> | annevk: otherwise, please send a short message to www-style so i can bring it up tomorrow. now i need to sleep |
| 13:02 | <annevk> | zcorpan: around http://lists.w3.org/Archives/Public/public-fx/2013AprJun/thread.html#msg176 |
| 13:11 | <zcorpan> | annevk: thx |
| 13:38 | <foolip> | annevk: but note that <video> doesn't use tasks as per spec in at least WebKit, Blink and Presto, so if it doesn't work be careful about which code to blame :) |
| 13:39 | <jgraham> | foolip: That sounded a lot like "if it doesn't work, blame foolip" :) |
| 13:42 | <foolip> | jgraham: that wouldn't be entirely unfair :) |
| 13:52 | <annevk> | I wonder what happend to HTTPbis https://www.w3.org/Bugs/Public/show_bug.cgi?id=25097#c0 |
| 13:53 | <JakeA> | annevk: if the request is to the same origin, but it responds with a redirect to /somewhere-else/?secret=1234567890, will that be an OpaqueResponse? |
| 13:53 | <JakeA> | annevk: I thought it wouldn't be, which is why I added the cast |
| 13:55 | <annevk> | JakeA: yeah, currently Fetch does not say that because the redirect would not be exposed to script, but once that's an option I'll make sure to do that right at the source |
| 13:55 | <MikeSmith> | annevk: yeah I thought I remembered seeing a tweet from Julian months ago that implied it had been sent to the IETF editor for publication |
| 13:57 | <MikeSmith> | annevk: btw html5.org/tools/web-apps-tracker is hanging atm |
| 13:57 | <annevk> | MikeSmith: prolly means svn.whatwg.org is hanging |
| 13:57 | <annevk> | hmm no |
| 13:59 | <annevk> | MikeSmith: seems to work again |
| 13:59 | <MikeSmith> | annevk: yeah wfm too now |
| 14:40 | <zewt> | annevk: whew? (re: dodging another onclick) |
| 14:41 | <annevk> | zewt: I have no idea what is going on |
| 14:41 | <annevk> | zewt: I blame DOM Level 3 Events for not cleaning this up |
| 14:41 | <zewt> | i think we should discourage people from ever using the phrase "default action" |
| 14:41 | <annevk> | I have been trying to call it out each time I see it |
| 14:41 | <annevk> | zewt: what onclick behavior though? |
| 14:42 | <zewt> | the fact that onclick does have "in-dispatch" behavior |
| 14:43 | <zewt> | i think we need a new name for that, to clearly distinguish it from what people think of as "default actions" |
| 14:43 | <annevk> | zewt: pointer to the spec for that? I think I'm missing something |
| 14:43 | <JakeA> | annevk: if a fetch is performed as part of a navigation, is the responses url redundant? |
| 14:43 | <zewt> | i don't know if it's specced anywhere |
| 14:43 | <JakeA> | response's* |
| 14:44 | <annevk> | JakeA: could still be relevant if the SW returned something unexpected |
| 14:44 | <JakeA> | annevk: like? |
| 14:45 | <annevk> | JakeA: navigate to /bar SW returns response for http://www.google.com/ |
| 14:45 | <zewt> | annevk: https://zewt.org/~glenn/test-stupid-click-event.html |
| 14:45 | <JakeA> | annevk: I think the exception there is OpaqueResponse, not url |
| 14:45 | <Domenic> | annevk: I think it was good guidance that events are for notification, not actions. I hadn't read that anywhere before. |
| 14:46 | <annevk> | JakeA: it's not really an exception |
| 14:46 | <annevk> | JakeA: but it would be a CORSResponse |
| 14:46 | <JakeA> | That's fine though, isn't it? |
| 14:47 | <annevk> | JakeA: but in that case you want to look at the url of the response |
| 14:47 | <zewt> | i think there are a couple other events like that but I don't know what they are |
| 14:47 | <annevk> | JakeA: you being the navigate algorithm |
| 14:47 | <annevk> | Domenic: yeah, maybe I should add that more explicitly to the DOM specification |
| 14:48 | <zewt> | i wonder if that could be explained in terms of capturing the event on the link, then queuing a task to look at defaultPrevented after the event finishes... probably not, since that could be broken by stopPropagationImmediate |
| 14:49 | <Domenic> | annevk: +1, that would be excellent. |
| 14:49 | <annevk> | zewt: so when I tested myself I forgot to generate an event that is a MouseEvent |
| 14:50 | <zewt> | sorry, I thought we talked about this before or I'd have made more noise about it |
| 14:50 | <JakeA> | annevk: I'm wondering if we can ditch fetchEvent.default(). If subresources have a base url of response.url, but navigations use window.location.href (as in, what's in the url bar), I don't think we need .default() |
| 14:51 | <Domenic> | annevk: oh wow, i was wondering when someone would bring up the ArrayBuffer mess |
| 14:52 | <annevk> | JakeA: default() is for preserving the request instance |
| 14:52 | <annevk> | JakeA: so you preserve e.g. that redirects are not to be followed |
| 14:52 | <annevk> | JakeA: and that CSP applies |
| 14:54 | <annevk> | zewt: HTML has a bunch of stuff around "synthetic click" |
| 14:55 | <annevk> | Domenic: I'm not sure what is going on there |
| 14:56 | <annevk> | Domenic: or how their implementations have been moved to ES without anyone else noticing this |
| 14:56 | <zewt> | html spec seems to be thrashing chrome on load way more than it was |
| 14:56 | <Domenic> | annevk: my guess is that they only looked at the Khronos spec, which doesn't contain neutering? (Is that true?) |
| 14:56 | <zewt> | heh now I'm scrolling the spec and getting a transparent background |
| 14:57 | <annevk> | Domenic: no Khronos defines what to do when something is neutered |
| 14:57 | <annevk> | Domenic: http://www.khronos.org/registry/typedarray/specs/latest/ |
| 14:57 | <JakeA> | annevk: hmm, true |
| 14:57 | <zewt> | annevk: there's "synthetic click activation steps", which has nothing to do with events I think |
| 14:58 | <zewt> | (click-like things to do when other things happen, not when the user dispatches his own click event) |
| 14:58 | <Domenic> | annevk: welp... more cases where Allen is not properly integrating with existing systems, IMO. |
| 14:58 | Domenic | is still disgruntled about ES tasks vs. HTML microtasks |
| 14:58 | <zewt> | why would the language level have tasks? that doesn't even make sense |
| 14:59 | <zewt> | tasks are part of the event loop, which don't belong at the language layer |
| 14:59 | <annevk> | zewt: how can you have asynchronous language then? |
| 14:59 | <zewt> | that doesn't belong at the language layer either |
| 15:00 | <annevk> | zewt: I think you're right that HTML basically does not define this; I slowly start to remember a long time ago when we looked at this and decided it was for DOM Level 3 Events to define and that of course never happened |
| 15:00 | <annevk> | zewt: see async/await syntax |
| 15:00 | <zewt> | especially here, where the web has a complex event loop mechanism; the language is at a lower layer than it |
| 15:01 | <zewt> | annevk: i don't think an external spec could define it without monkey patching, since it seems to need a hook in dispatchEvent |
| 15:04 | <annevk> | zewt: I found https://www.w3.org/Bugs/Public/show_bug.cgi?id=10897 |
| 15:05 | <zewt> | don't think the popup counterexample is valid (just check the trusted flag) |
| 15:06 | <zewt> | i wrote code myself that dispatched click myself (before I knew what I was doing), so it seems guaranteed that other people have too |
| 15:06 | <zewt> | (i was capturing events on document, cancelling them, doing other stuff, then re-dispatching them later; it worked for click, and I recall being annoyed that it didn't work with submit) |
| 15:06 | <annevk> | zewt: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230 seems to be master bug |
| 15:08 | <zewt> | (it does work with submit? maybe it was some other event I had trouble with) |
| 15:08 | <zewt> | or maybe not (according to comment 10); retesting... |
| 15:12 | <zewt> | submits for me in firefox, but not chrome |
| 15:12 | <zewt> | (maybe that's what I was annoyed about--probably wrote the code in firefox first) |
| 15:13 | <zewt> | (test at same url) |
| 15:13 | <dglazkov> | good morning, Whatwg! |
| 15:14 | <caitp> | i need to script my client to say good morning like that in every channel, it's so charming |
| 15:15 | <JakeA> | annevk: if I do event.respondWith(caches.match('/fallback.html')), what's the base url for the resulting page (assuming no <base> element)? Is it event.request.url or the cachedRepsonse.url? |
| 15:15 | <zewt> | (don't, it's really annoying; highlights everyone's window for no reason) |
| 15:15 | <JakeA> | annevk: Feels like it should be the former |
| 15:17 | <annevk> | JakeA: yes |
| 15:18 | <annevk> | JakeA: I think we jotted this on the etherpad at some point |
| 15:20 | <JakeA> | annevk: What if fetch(request) didn't follow redirects if the context was one of the navigation ones? Then the only benefit of event.default() is CSP, right? |
| 15:23 | <annevk> | JakeA: prioritization |
| 15:24 | <annevk> | JakeA: oh, and default() follows redirects for subresources and updates the resulting url |
| 15:25 | <annevk> | JakeA: e.g. if you do respondWith(fetch("something-that-redirects")) it wasn't clear to me we'd use the response's url as base URL |
| 15:27 | <JakeA> | annevk: I think using the responses url as base url for non-navigations is fine. I wasn't keen on that at first, but it fits in with the fetch spec nicely |
| 15:28 | <annevk> | but not with typical server setups |
| 15:31 | <JakeA> | annevk: yeah, the concept of responses with a url property felt really alien to me at first |
| 15:32 | <JakeA> | annevk: But then, in a typical server setup, the base url would be event.request.url, but if I did event.respondWith(fetch(url)) the base would be url & not event.request.url, right? |
| 15:33 | <JakeA> | unless respondWith overrides the response url, but then how can it tell the difference between event.default() and fetch() |
| 15:37 | <Domenic> | response URLs make sense to me, they're the URL after all redirects, right? |
| 15:38 | <JakeA> | Domenic: yeah, but they don't exist in the traditional client/server model |
| 15:38 | <Domenic> | JakeA: right, but there's a difference between ClientRequest/ClientResponse and ServerRequest/ServerResponse |
| 15:39 | <Domenic> | if writing a web server, you use the latter; if sending requests as a client, you use the former |
| 15:39 | <Domenic> | Node.js actually has 4 different classes for this |
| 15:39 | <annevk> | JakeA: Fetch uses the latest url of Request, as url for Response |
| 15:39 | <annevk> | JakeA: but note that SW sits a layer deeper |
| 15:40 | <annevk> | JakeA: so the latest url of Request is the one that the SW was opened for |
| 15:40 | <annevk> | JakeA: if you use default() however, the url of that Request will be updated further |
| 15:41 | <JakeA> | Domenic: right, so here's the question, if I do fetchEvent.respondWith(fetch(url)), assuming the fetch is for some CSS, what's the base-url for the response? a) fetchEvent.request.url b) url c) the final redirect while fetching url |
| 15:43 | <Domenic> | JakeA: I don't feel qualified to give an answer that fits well with the rest of the moving parts involved, but my gut instinct is c). |
| 15:44 | <JakeA> | Domenic: Gut instinct is fine. I think my original instinct was a), but I'm coming round to c) |
| 15:47 | <JakeA> | annevk: wouldn't fetch take the response url from response.url, as provided by the serviceworker? |
| 15:52 | <gavin> | TabAtkins: blame pisg, probably |
| 15:53 | <annevk> | JakeA: not how it's currently written |
| 15:56 | <annevk> | JakeA: I feel like I/we should create a series of examples of request / response flows when there's a SW and figure out what all the various parties want to know |
| 15:56 | <JakeA> | annevk: I'll make a ticket to try and summarise this. I'd love to kill event.default() if we can |
| 15:56 | <annevk> | JakeA: I was hoping that would be done as part of providing hooks for Fetch, but I can take a stab at it too I suppose |
| 15:57 | <annevk> | JakeA: killing that does not make much sense to me, I'd prefer we focus on understanding the problem space first |
| 15:58 | <JakeA> | annevk: Ok, I'll provide examples in the ticket and see what we're left with |
| 16:04 | <JakeA> | annevk: event.default(), .installing/waiting/active/controller, and serviceWorker.waitUntil are keeping me awake at night |
| 16:08 | <Domenic> | JakeA: this reminds me, we need to figure out our story for .loaded vs. .loaded() |
| 16:08 | <Domenic> | I was going to comment in bug, I should probably do that so that there's a record. |
| 16:09 | <Domenic> | but basically https://github.com/w3ctag/promises-guide/issues/25 |
| 16:11 | <Hixie> | why would loaded() be a method? |
| 16:11 | <Hixie> | shouldn't there be one promise per load attempt? |
| 16:11 | <Hixie> | the FontFace API approach seems sensible |
| 16:13 | <JakeA> | There was a conversation around this earlier http://krijnhoetmer.nl/irc-logs/whatwg/20140520#l-395 |
| 16:13 | <Hixie> | yes that's what led to my question |
| 16:14 | <JakeA> | Doing the same as FontFace is compelling |
| 16:14 | <Hixie> | well they should clearly be consistent, but if a method makes more sense thenwe should do that |
| 16:14 | <Hixie> | i just don't see why a method would make sense here |
| 16:14 | <Hixie> | since it's vending the same value each time |
| 16:14 | <Hixie> | a method implies that work is done |
| 16:14 | <Hixie> | whereas here no work is done except "return the cached value" |
| 16:15 | <JakeA> | well, the value can change |
| 16:15 | <JakeA> | if .src is changed |
| 16:15 | <JakeA> | but that's easy enough |
| 16:15 | <Hixie> | right, but that's the .src setter doing work |
| 16:15 | <JakeA> | yeah |
| 16:15 | <Hixie> | not loaded()/.loaded |
| 16:16 | <Hixie> | in totally different news, i must admit to something. this no-underline style is actually growing on me. i was clearly wrong about that. |
| 16:17 | <JakeA> | For the record, I've never found a style-related readability problem with the html spec. Except for that bit where there was a gradient at the top. Those were dark times for the web. |
| 16:17 | <Hixie> | the backgrounds on examples and notes are prettier too. |
| 16:17 | <Hixie> | JakeA: there's actually a gradient there still. :-D |
| 16:18 | <Hixie> | JakeA: and yeah, me either, but we consistently get feedback about it |
| 16:18 | <Hixie> | JakeA: i did a survey a few months ago, and it was funny, i got a bunch of feedback "this spec is really pretty" and a bunch of feedback "this spec is really ugly" |
| 16:19 | <JakeA> | ohh, the gradient is at the bottom now. Hadn't noticed that |
| 16:19 | <Hixie> | i figured it was more subtle than the line that we had before |
| 16:19 | <Hixie> | (the line got harder to do right after i added a max-width on body) |
| 16:29 | <TabAtkins> | Hixie: FontFace returns a promise from the .load() method, but also exposes a .loaded promise for when you want to listen for the load status without actually triggering a load. |
| 16:29 | <Hixie> | right |
| 16:29 | <Hixie> | same promise right? |
| 16:30 | <Hixie> | .loaded just returns the last value .load() created? |
| 16:30 | <TabAtkins> | No, it was easier to just return a fresh promise that is resolved to the .loaded promise. |
| 16:30 | <Hixie> | that seems confusing |
| 16:30 | <Hixie> | why would it be easier? |
| 16:31 | <TabAtkins> | .loaded is the same promise all the time. |
| 16:31 | <TabAtkins> | .load() returns fresh promises, I think. Lemme see... |
| 16:31 | <Hixie> | until the next load, right? |
| 16:31 | <TabAtkins> | A given font only loads once. |
| 16:31 | <Hixie> | ah ok |
| 16:31 | <Hixie> | well then why have more than one promise? |
| 16:31 | <Hixie> | just have The One Promise Of The FontLoad Object |
| 16:31 | <TabAtkins> | Oh, no, they all return the same promise. |
| 16:31 | <TabAtkins> | Yes. |
| 16:31 | <Hixie> | or if you're doing it the JS style, [[The One Promise Of The FontLoad Object]] |
| 16:31 | <TabAtkins> | Every call to .load() returns the .loaded promise. |
| 16:31 | <TabAtkins> | That's the [[FontStatusPromise]] |
| 16:32 | <Hixie> | called it |
| 16:32 | <Hixie> | :-P |
| 16:32 | <TabAtkins> | hehe |
| 16:33 | <Domenic> | I dunno, I kind of feel that for things that could change, a method might be better? |
| 16:33 | <Domenic> | That way, if it's a property, it's the same every time, whereas if it's a method, it's more like "getPromiseForNextTransitionToLoadedState()" |
| 16:34 | <Domenic> | except we shorten that to ".loaded()" |
| 16:34 | <Domenic> | (or, "whenLoaded()" or "waitForLoad()"??) |
| 16:34 | <Hixie> | when* and wait* are ugly |
| 16:35 | <Domenic> | when doesn't seem so bad. but yes. |
| 16:35 | <Hixie> | but i don't understand what you mean |
| 16:35 | <Hixie> | attributes can change |
| 16:35 | <Hixie> | if they couldn't, we'd call them constants :-) |
| 16:35 | <Hixie> | the thing to avoid with attributes is not that they change when state changes, but that they change every time they are called |
| 16:35 | <Hixie> | that is, the getter should be idempotent |
| 16:36 | <Domenic> | yeah, that's true |
| 16:36 | <Hixie> | but that's all really |
| 16:36 | <Domenic> | i think i am just trying to use the method vs. attribute designation to signal something only tangentially-related |
| 16:37 | <Domenic> | i.e. we have to classes of these promises: "generic state transitions" for state machines that could go back and forth, or "intrinsic properties of the object" for whether something has completed its one-time transition from not-loaded to loaded, or similar. |
| 16:37 | <Domenic> | s/to/two |
| 16:39 | <Domenic> | but the methods i am proposing are definitely not actions, so that's a point against methods |
| 16:39 | <Domenic> | most getter-methods get named with a `get` prefix, and `.getLoaded()` is horrible... |
| 16:39 | <Domenic> | .nextLoad property maybe?? |
| 16:40 | <TabAtkins> | Domenic: In support of your point, the promise for "are there are pending font loads, or are we cool?" is returned by a method. |
| 16:40 | <Domenic> | or i can just be ok with the fact that there will be slightly different types of promises returned, both by getters... |
| 16:40 | <Hixie> | i think we should be consistent between one-shot objects and reusable objects, and for one-shot objects "nextLoad" is confusing |
| 16:40 | <Hixie> | 'loaded' seems fine to me |
| 16:40 | <TabAtkins> | I return a fresh promise with every call there, though. |
| 16:40 | <Domenic> | Hixie: I think it is exactly that consistency I am arguing against, actually. |
| 16:40 | <JakeA> | await document.ready |
| 16:40 | <TabAtkins> | I made most of these choices without conscious attempts at consistency, though. |
| 16:41 | <Hixie> | most reusable objects are treated by most authors as one-shot objects |
| 16:41 | <Domenic> | that is true |
| 16:41 | <Hixie> | so i don't think optimising e.g. img for people using it for multiple loads is a good idea |
| 16:42 | <Domenic> | i kind of liked the idea of force-feeding authors the knowledge that they are reusable, heh. |
| 16:42 | <Domenic> | but in practice, thinking about the dev experience, i guess it's bad |
| 16:42 | <Domenic> | you have to keep a table in your head of reusable vs. one-shot objects |
| 16:42 | <Domenic> | "use .nextLoad for img, but .loaded for documents..." |
| 16:43 | <Domenic> | or, probably worst, "use .loaded() for img, but .loaded for documents..." |
| 16:43 | <JakeA> | "await img.loaded" seems better than "await img.nextLoad" |
| 16:43 | <caitp> | it doesn't really matter what the API looks like, it's going to both suck and be adequate and even enjoyable simultaneously, depending on who uses it and what problem they're solving |
| 16:44 | <JakeA> | I might get a tattoo of that |
| 16:44 | <Hixie> | Domenic: documents can be reused |
| 16:44 | <Domenic> | welp |
| 16:45 | <Domenic> | what *can't* be reused, actually... |
| 16:45 | <Hixie> | which i think is a solid argument against making a distinction in the api :-) |
| 16:45 | <Hixie> | even xhr can be reused |
| 16:45 | <Hixie> | websocket can't |
| 16:49 | <Domenic> | JakeA: you have too many internet names |
| 16:50 | <JakeA> | Domenic: yeahhhhh, I should probably drop the jaffathecake thing |
| 16:50 | <caitp> | why would you want to do that |
| 16:52 | <JakeA> | consistency? |
| 16:52 | <JakeA> | it's all the rage these days |
| 16:52 | <Hixie> | it's been "all the rage" for a long time :-) |
| 16:53 | <JakeA> | how appropriate! |
| 16:53 | <caitp> | every nickname is just a different expression of a different facet of a different side of your personality's current mood, as it should be |
| 17:31 | <Hixie> | Domenic: i don't understand why you keep saying "JavaScript does not make such a distinction" |
| 17:33 | <Hixie> | Domenic: it doesn't make a distinction between functions that return a value and functions that don't return a value either, but i hope you agree that to programmers they are different things nonetheless. |
| 17:33 | <Ms2ger> | No |
| 17:33 | Ms2ger | ducks |
| 17:33 | <Hixie> | Ms2ger: context is https://github.com/domenic/promises-unwrapping/issues/24#issuecomment-43657022 |
| 17:33 | <Domenic> | I don't agree with that. All functions return a value; sometimes that value is `undefined`. |
| 17:34 | <Ms2ger> | See? |
| 17:34 | <Hixie> | ... |
| 17:34 | <Hixie> | Domenic: that is entirely my point. |
| 17:34 | <Hixie> | Domenic: all functions return something in JS. but programmers ignore the return values of functions that return undefined. |
| 17:34 | <Hixie> | they are different to the programmer. |
| 17:34 | <Ms2ger> | inb4 "No" |
| 17:35 | <Domenic> | Sure. But language-level features do not do different things with undefined-returning functions vs. anything-else-returning functions. |
| 17:35 | <caitp> | where would we be if we weren't putting a reference to an undefined JSValue into EAX after every function call |
| 17:35 | <caitp> | it would be chaos |
| 17:36 | <Hixie> | Domenic: i don't understand the relevance of your statement |
| 17:36 | <Domenic> | Hixie: Language-level features like promises are not designed to handle different types of errors in different ways |
| 17:37 | <Domenic> | Hixie: all errors that an async function can result in go through the promise, just like all errors that a sync function can throw get bubbled as exceptions |
| 17:37 | <Domenic> | We don't e.g. return some as return values and some as thrown exceptions |
| 17:37 | <Hixie> | Domenic: well, a, promised shouldn't be a language-level feature imho. but b, yes, that's the bug. |
| 17:37 | <Domenic> | We just throw them all |
| 17:37 | <Hixie> | Domenic: i understand what you want. i'm saying it's bad. |
| 17:37 | <Domenic> | So similarly deciding to use throw vs. reject as a channel to interject your preference for dividing up errors into two categories is not really good language design |
| 17:38 | <Domenic> | ok. well I am saying it's good. |
| 17:38 | <Hixie> | i pretty fundamentally disagree here. |
| 17:38 | <Domenic> | I can offer years of experience working with promise APIs, if it helps? |
| 17:38 | <Hixie> | it does not. |
| 17:38 | <Ms2ger> | Your brain must be fried by now :) |
| 17:39 | <Hixie> | Domenic: did some promise APIs send TypeErrors on the promises? |
| 17:39 | <Domenic> | Hixie: of course, whenever there was a TypeError. |
| 17:39 | <Hixie> | how did you implement that? |
| 17:40 | <Domenic> | I don't understand the question |
| 17:40 | <Hixie> | well your years of using promises in JS had to be built on top of a non-promise-native JS, right? |
| 17:40 | <Domenic> | sure |
| 17:41 | <Hixie> | and you had IDL-like APIs that did type checking? |
| 17:41 | <Domenic> | in some cases, yeah |
| 17:41 | <Hixie> | so how did you send the type checks to the promises? they'd be caught before the function's code ran. |
| 17:41 | <Domenic> | wait what? |
| 17:41 | <Domenic> | i'm in javascript; there are no type checks before the function's code runs |
| 17:42 | <Domenic> | the functions code is the thing doing the type checks |
| 17:42 | <Hixie> | maybe that's where the disagreement stems from |
| 17:42 | <Hixie> | i'm not in JavaScript. |
| 17:42 | <Hixie> | i'm in WebIDL. |
| 17:42 | <Domenic> | Which is a macro system for writing JavaScript ;) |
| 17:42 | <Hixie> | not really, it's usually implemented in C++. |
| 17:43 | <Domenic> | Yes, but that C++ just invokes JS engine C++ APIs |
| 17:43 | <Ms2ger> | Or Rust |
| 17:43 | <Domenic> | And the spec is done in terms of JS semantics |
| 17:43 | <Hixie> | i'm finding it hard to express just how much i would hate to use an API where a type error would get sent to a promise. |
| 17:43 | <Hixie> | i hate it enough that it's run-time not compile-time |
| 17:43 | <Hixie> | but this is like an order of magnitude worse. |
| 17:43 | <Domenic> | i mean, i can say the same thing about how much i would hate apis that force me to handle errors through two channels |
| 17:43 | <Hixie> | you don't have to handle the errors i'm talking abuot. |
| 17:43 | <Hixie> | that's the _entire_ point. |
| 17:43 | <Domenic> | you do! |
| 17:44 | <Domenic> | when building robust systems, you *definitely* need to handle errors |
| 17:44 | <caitp> | why not push for dart then, then you can at least get some level of static typechecking and throw these errors during parsing/compilation rather than at runtime |
| 17:44 | <Hixie> | (dart's not even remotely enough.) |
| 17:44 | <caitp> | change the web! |
| 17:44 | <caitp> | I joke, I joke |
| 17:45 | <Hixie> | Domenic: if you call a function with bogus data, but the bogus data is not fatal, then you're just going to call more and more functions with that bogus data. it's going to propagate the errors throughout the system. |
| 17:45 | <Hixie> | Domenic: if you instead throw an exception, the code will crash. |
| 17:45 | <Hixie> | Domenic: and the damage will be limited. |
| 17:45 | <Domenic> | rejections are just as fatal to async systems as exceptions are to sync ones |
| 17:45 | <Domenic> | you literally cannot do any more work until you handle the rejection |
| 17:45 | <Hixie> | no they're not |
| 17:45 | <Hixie> | sure you can |
| 17:46 | <Hixie> | var promise = func(); |
| 17:46 | <Hixie> | moreCode(); |
| 17:46 | <caitp> | presumably if you get a rejection that you care about, you don't recover |
| 17:46 | <Domenic> | you cannot do any more work that depends on the result of that computation |
| 17:46 | <Hixie> | sure, but you can do lots more work with the original bad data. |
| 17:46 | <caitp> | you don't always care about rejections |
| 17:46 | <Domenic> | caitp: you recover, or don't recover, in the same way you would at sync code: add judicious catches at the boundaries of the system to encapsulate parts that can be wrapped and retried/signaled to the user without breaking the rest of the program. |
| 17:47 | <caitp> | that's what I'm saying |
| 17:47 | <caitp> | it's not too different from regular try/catch |
| 17:47 | <Domenic> | it's exactly the same :) |
| 17:47 | <Hixie> | you don't have to recover from logic errors at all in sync code. The code is bad. There's by definition no way to recover sanely. The best you can do is catch onerror and send a report to the server, then tell the user that the code is bad. |
| 17:47 | <Domenic> | that's just not true. you can easily recover from logic errors |
| 17:47 | <Domenic> | this keeps webpages running without breaking at the first sign of things going wrong |
| 17:47 | <caitp> | there are a lot of errors that you can recover from |
| 17:48 | <caitp> | like JSON.parse() throwing |
| 17:48 | <Hixie> | JSON.parse() throwing isn't a logic error. |
| 17:48 | <caitp> | not everything is necessarily fatal |
| 17:48 | <Hixie> | it's a data error. |
| 17:48 | <Hixie> | i'm talking about things like null derefs, calling a function with the wrong arguments, etc. |
| 17:48 | <Hixie> | stuff that should never have gotten checked in in the first place. |
| 17:48 | <Domenic> | there is no distinction. |
| 17:48 | <Domenic> | (in JavaScript) |
| 17:48 | <Hixie> | agreed |
| 17:49 | <Hixie> | the distinction is a programmer-level distinction. |
| 17:49 | <Hixie> | even more important. |
| 17:49 | <Domenic> | the user can click into a rare code path that generates a TypeError, and it's nice to be able to say "oops, we couldn't load the current bid right now!" without crashing the entire app/server. |
| 17:49 | <Domenic> | you'd give the same error for a NetworkError |
| 17:49 | <caitp> | much like you can distinguish from a catch block, you can also distinguish from a rejection handler |
| 17:50 | <caitp> | at the programmer-level |
| 17:50 | <Domenic> | yeah, in both cases, you might log the NetworkError, but not the TypeError, to the server. |
| 17:50 | <Domenic> | er,,, other way around |
| 17:50 | <Hixie> | the distinction is at the API level, and it does exist. |
| 17:51 | <Hixie> | it's the difference between firing onerror and throwing, today. |
| 17:51 | <Hixie> | all i'm saying is that I want my APIs to maintain that difference. |
| 17:52 | <caitp> | maybe some day people will be happy with mobile phones statically analyzing scripts for their applications before running, so that they can throw typeerrors that might never be reached |
| 17:52 | <Ms2ger> | Hixie, why do you want to set JS back to the stone age? |
| 17:52 | Hixie | feeds Ms2ger |
| 17:53 | <caitp> | > implying it ever left the stone age |
| 18:10 | <jtcranmer> | Domenic: ping |
| 18:18 | <smaug____> | Hixie: want to interpret what http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#inappropriate-for-the-control means |
| 18:20 | <Domenic> | jtcranmer: pong |
| 18:22 | <jtcranmer> | Domenic: when are you planning on working on the streams spec again? |
| 18:23 | <Domenic> | jtcranmer: as soon as possible; i had a conversation with an implementer the other day that brought up a number of things to get my head back in the game |
| 18:25 | <jtcranmer> | that's good to hear |
| 18:25 | <jtcranmer> | I hadn't seen any progress since the CSP... firestorm a month ago |
| 18:26 | <smaug____> | Hixie: especially " the first row describing that autofill field in the table below." part |
| 18:26 | <smaug____> | also, is anyone shipping this API |
| 18:26 | <smaug____> | or could we like... rewrite it |
| 19:03 | <Hixie> | smaug____: here now, what's up? |
| 19:04 | <smaug____> | trying to interpret what the spec says |
| 19:05 | <smaug____> | first, should the tokens be in order |
| 19:05 | <smaug____> | "set of space-separated tokens" hints no ordering |
| 19:05 | <smaug____> | (since a set isn't normally ordered) |
| 19:05 | <Hixie> | are you asking for implementations, or authors? |
| 19:05 | <smaug____> | implementations |
| 19:05 | <Hixie> | k let me see... |
| 19:06 | <smaug____> | but then there is "in the order given below" |
| 19:06 | <Hixie> | you want the next section |
| 19:06 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#processing-model-2 |
| 19:07 | <smaug____> | then in http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#inappropriate-for-the-control I have no idea what it means the there is "name" and under that some other values which are indented a bit |
| 19:07 | <smaug____> | are those other values somehow special |
| 19:07 | <smaug____> | the text above talks about "first row", but of what |
| 19:08 | <Hixie> | are we switching to talking about author conformance criteria? |
| 19:09 | <smaug____> | I don't know what in the spec says it isn't implementation thing |
| 19:10 | <Hixie> | there aren't any requirements that apply to UAs in that first section |
| 19:10 | <Hixie> | it doesn't say that anywhere, it's just a description of what is in that section |
| 19:10 | <Hixie> | the only "must"s are things that would apply to authors (and validators) |
| 19:11 | <smaug____> | "The attribute, if present, must have a value that is a set of space-separated tokens consisting of either a single token that is an ASCII case-insensitive match for the string "off", or a single token that is an ASCII case-insensitive match for the string "on", or the following, in the order given below:" |
| 19:11 | <smaug____> | why is that not for implementations ? |
| 19:11 | <Hixie> | it's saying what the value must be |
| 19:12 | <Hixie> | how could that be an implementation requirement? |
| 19:12 | <Hixie> | i don't understand what the requirement would be if it was an implementation requirement |
| 19:12 | <Hixie> | the spec talks a bit about this here: http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-to-read-this-specification |
| 19:12 | <Hixie> | does that help? |
| 19:12 | <Hixie> | (second paragraph) |
| 19:12 | <smaug____> | ok, I see |
| 19:13 | <smaug____> | this is just unusually hard to interpret |
| 19:13 | <smaug____> | also, does anyone implement this stuff yet? |
| 19:14 | <smaug____> | (since if not, I might r- patches trying to implement it) |
| 19:14 | <Hixie> | yeah, chrome has shipped this for some time. i tried to get impl feedback on it before they shipped but mozilla was being unusually confusing in its responses and didn't give feedback, and apple and microsoft didn't say anything at all iirc. |
| 19:14 | <Hixie> | (they waited many months before shipping, and it only got specced a year or so later when mozilla started implementing) |
| 19:14 | <Hixie> | (actually, the rAc() is what didn't get specced. I guess the attribute was specced earlier.) |
| 19:15 | <Hixie> | i can try to make it clearer |
| 19:15 | <Hixie> | not sure what is hard to interpret though |
| 19:17 | <smaug____> | well, the whole API is odd |
| 19:17 | <Hixie> | how so? |
| 19:17 | <smaug____> | trying to do so much using just one attribute |
| 19:18 | <Hixie> | it's not doing that much, it's just saying what the field represents |
| 19:18 | <smaug____> | in very different level |
| 19:19 | <smaug____> | shipping|billing could be one attribute, name etc one |
| 19:19 | <smaug____> | home|work|etc one |
| 19:20 | <Hixie> | isn't that just syntactically equivalent? |
| 19:20 | <Hixie> | i don't understand the difference |
| 19:20 | <Hixie> | (except that having multiple attributes means more confusion about when things take effect) |
| 19:20 | <smaug____> | easier to understand what the attribute is about |
| 19:21 | <Hixie> | seems to me to be exactly equivalent, but ok |
| 19:21 | <Hixie> | either way, i didn't design this, i just specced what had shipped |
| 19:21 | <smaug____> | but if this is shipping in chrome, perhaps I'll need to live with this |
| 19:21 | <Hixie> | so it's about 2 years too late for that kind of feedback :-) |
| 19:21 | <Hixie> | next time, send feedback when it's requested :-) |
| 19:21 | <smaug____> | I can't really follow all the spec stuff |
| 19:22 | <Hixie> | i hear ya |
| 19:22 | <smaug____> | I end up commenting when someone asks for a review |
| 19:22 | <smaug____> | Hixie: but ok, thanks |
| 19:23 | <Hixie> | fwiw, https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&resolution=---&target_milestone=Needs%20Impl%20Interest is a list of bugs that represent features that are not yet implemented for which feedback is being requested |
| 19:24 | <Hixie> | (especially feedback of the form "we want to implement this" or "we think this is dumb and should not exist", but also api design) |
| 19:24 | <Hixie> | so looking at that list every few weeks would be a good way to keep on top of this kind of thing in the future |
| 19:28 | smaug____ | bookmarks |
| 19:30 | <caitp> | if only there were some way to undumb the dumb of old |
| 19:32 | <Hixie> | you can have a pretty API, or you can have a successful API. your call. :-) |
| 19:33 | <caitp> | lots of pretty people are successful, no reason pretty APIs can't be |
| 19:44 | <Hixie> | caitp: i think there is a reason, actually |
| 19:44 | <Hixie> | caitp: the problem is that once an API is deployed, you can't change it. But you can't work out how to make it perfect before it's deployed. |
| 19:49 | <Philip`> | I think caitp is suggesting that you should design seven billion variations of an API, and then let people work out which ones are pretty, and those ones will become successful |
| 19:49 | <caitp> | or you could break peoples applications periodically, preferably early on |
| 19:49 | <caitp> | or any number of other ways |
| 19:50 | <caitp> | peoples lives don't depend on this stuff, and people aren't going to stop using the web just because they have to change a few letters in some application |
| 19:51 | <caitp> | just my opinion, nobody gotta take it, but nobody's life depends on this stuff never changing |
| 19:51 | <Domenic> | that's precisely what they'll do |
| 19:51 | <Domenic> | or worse, they'll stop using your browser |
| 19:51 | <caitp> | what alternative are they going to turn to? |
| 19:51 | <Domenic> | iOS/Android |
| 19:51 | <Domenic> | and/or a browser that didn't break their sites |
| 19:52 | <caitp> | they might go outside or read a book or get back to working on curing cancer |
| 19:52 | <Hixie> | breaking people's applications is how you get "pretty and not successful" |
| 19:52 | <caitp> | there are plenty of examples of apis with breaking changes which don't really hurt their use |
| 19:52 | <caitp> | openGL and openglES for one |
| 19:53 | <caitp> | for two, rather |
| 19:53 | <Hixie> | (at least, not successful on the scale of the Web or Windows) |
| 19:53 | <caitp> | gtk2 vs gtk3 |
| 19:53 | <Hixie> | get back to me when gtk has a billion users. |
| 19:53 | <caitp> | well hopefully it never gets there, if we're lucky it will die off and be replaced by something pretty and successful |
| 19:54 | <caitp> | breaking changes are valuable. you don't want them every day, but at least a few times a decade |
| 19:54 | <Philip`> | caitp: Assuming you mean the breaking transition from GL to GLES, that worked because GLES existed on a new platform that no existing GL application could possibly run on anyway, so application developers had to start from scratch and could use whatever API was there |
| 19:55 | <caitp> | OpenGL2 vs OpenGL3 is massively different, and there have been breaking changes from early gles to more recent gles as well, but it's just an example |
| 19:55 | <Hixie> | caitp: https://plus.google.com/+IanHickson/posts/SiLdNL9MsFw |
| 19:55 | <caitp> | I've read it, it's a nice post |
| 19:58 | <caitp> | but I think people greatly exaggerate the importance of users changing browsers for a while, or of users not browsing the web for a while. It's never going to make any real difference to anybody |
| 20:00 | <Hixie> | let's suppose that you're right. it actually still doesn't matter. what matters is that the people developing browsers think it's true. |
| 20:01 | <caitp> | imagine if people started using IE again to browse tumblr because of some rendering glitch in a particular theme that affected gecko or blink, due to a breaking change |
| 20:01 | <caitp> | maybe you'd see less irrational complaints about "IE is awful/slow/etc", and more reality |
| 20:02 | <caitp> | you'd bring honesty back! |
| 20:02 | <caitp> | man, that would be great |
| 20:03 | <Domenic> | and people would get fired from mozilla and google (or get very poor performance reviews) |
| 20:03 | <Domenic> | you have to remember that there are real consequences to effin up the software you ship |
| 20:04 | <Hixie> | what would happen is that just one browser (the one that implemented the breaking change) would not work |
| 20:04 | <Hixie> | and users would blame the browser and move to another one |
| 20:05 | <Hixie> | some very small number of users if it was just one breaking change |
| 20:05 | <Hixie> | and the other browser vendors would see this and say "well we're not doing _that_" |
| 20:05 | <Hixie> | just look at the level of difficulty that browsers are facing trying to drop showModalDialog() |
| 20:05 | <Hixie> | an API that every browser vendor desperately wants to drop |
| 20:05 | <Hixie> | an API that has virtually no use on the Web itself |
| 20:06 | <Hixie> | an API that causes security problems |
| 20:06 | <Hixie> | an API that massively complicates the specs and implementations |
| 20:06 | <Hixie> | an API that was originally non-standard |
| 20:07 | <caitp> | I know it's hard, Hixie |
| 20:08 | <caitp> | but it's hard because of an attitude problem, and that is a bug worth fixing |
| 20:09 | <Hixie> | i have no idea whatsoever how to fix humans. good luck. in the meantime... |
| 20:09 | <zewt> | if you're working for a browser vendor trying to get politics and practicalities changed, great; if you're not, that's a lovely statement but not an actionable one |
| 20:09 | <Hixie> | (this is the same argument i have against RDF&co. Embedding structured data in the web page is essentially a human problem, and it's harder to fix that problem than it is for us to develop NLP.) |
| 20:10 | <Hixie> | (not that NLP is easy at all. It's just that social problems are even harder.) |
| 20:10 | <Domenic> | an attitude problem O_O |
| 20:10 | <caitp> | I think it can be done |
| 20:10 | <zewt> | Domenic: that's what business realities look like, when it's not your job :P |
| 20:11 | <caitp> | for most of the browser vendors out there, browser use isn't their main business |
| 20:11 | <caitp> | well, okay, maybe not most |
| 20:11 | <caitp> | lets say 2 out of 5 |
| 20:11 | <caitp> | maybe you could even throw apple in there too, since they push objc |
| 20:11 | <Domenic> | Yes, and for Goldman Sachs, structured investments isn't their main business. Doesn't mean the structured investments group wants to give all their business to Citigroup. |
| 20:12 | <caitp> | that's comparing an apple to an orchard, don't you think? |
| 20:12 | <Domenic> | not at all |
| 20:12 | <caitp> | there's a lot more money in one arena than the other |
| 20:12 | <Domenic> | business units and companies and responsibility and performance reviews work the same way in both environments |
| 20:12 | <caitp> | thus the attitude problem |
| 20:13 | <Domenic> | if you say so... |
| 20:13 | <caitp> | when something doesn't have a real impact, either financially or culturally, it must not be held to such a high standard |
| 20:14 | <Hixie> | as you said before, it's an attitude problem. Specifically, the attitude of the engineers on the browser teams, and the people who evaluate their performance. |
| 20:14 | <Hixie> | for those people, browser use is their main business. |
| 20:15 | <Hixie> | btw, even if all the browser vendors were to agree to break things together, even that wouldn't solve your problem. You'd just make the Web platform less attractive and cause Web developers to consider becoming developers for other platforms. |
| 20:16 | <caitp> | and that would be just fine |
| 20:16 | <caitp> | it really doesn't matter in the grand scheme of things :) |
| 20:16 | <caitp> | it really doesn't |
| 20:16 | <caitp> | but, I know I don't have to convince you of that |
| 20:16 | <Hixie> | well, it greatly matters to me that the open multi-vendor platforms be more successful than the proprietary ones. |
| 20:17 | <Hixie> | Also, do you really want to be breaking these web apps? Consider if one of them is the ticketing app for an airline. Suddenly over the course of a week all the browsers stop working on that site. Can you imagine the chaos that that company would face? Now multiply that across the whole of our economy. |
| 20:18 | <IZh> | It's hot here today. ;-) |
| 20:18 | <caitp> | fortunately, it's possible to have relationships with businesses who use your product, and inform them of coming breaking changes |
| 20:19 | <Hixie> | in practice, those relationships don't exist. |
| 20:19 | <Hixie> | i mean, i would love to live in the world you describe, don't get me wrong. |
| 20:19 | <caitp> | sure they do, I have participated in them |
| 20:19 | <Hixie> | but it's not the world i live in. |
| 20:19 | <caitp> | you can have more of them |
| 20:19 | <caitp> | you can encourage effective communication |
| 20:20 | <caitp> | there is no shortage of ways to make things suck less than they do, and just no real effort to take on those endeavors |
| 20:20 | <Hixie> | well that's just offensive. |
| 20:20 | <caitp> | but I don't want to have a fight about this |
| 20:20 | <Hixie> | you basically just said that the last 15 years of my life have been "no real effort" |
| 20:21 | <caitp> | oh come now Hixie, I'm not saying that |
| 20:21 | <Hixie> | you really did. |
| 20:21 | <caitp> | maybe "no real effort" was the wrong choice of words |
| 20:21 | <Hixie> | (not just my life, either.) |
| 20:21 | <IZh> | Evolution vs revolution. |
| 20:23 | <caitp> | various organizations are certainly making an effort to open the process and get more input from different interested parties, so yes, that effort is being made |
| 20:24 | <Hixie> | we've also spent years trying to improve the web concretely, by providing better APIs, defining the platform better to improve interop, etc. |
| 20:24 | <Hixie> | not to mention all the work on test suites |
| 20:24 | <Hixie> | and all the work on developer advocacy |
| 20:25 | <Hixie> | and all the work on campaigning to browser vendors that they better support standards |
| 20:25 | <Hixie> | and all the work trying to convince each other that particular design patterns are better than others |
| 20:25 | <caitp> | and that's all awesome, no doubt |
| 20:26 | <Hixie> | what have _you_ done to improve the web? |
| 20:26 | <caitp> | I've worked on improving compliance with various proposed standards, improving application frameworks, and am not quiet at all about my opinions on the problems with it and how they can be addressed |
| 20:27 | <Domenic> | it's interesting that you flipped the offensive bit at "no real effort"; I flipped it at "attitude problem" |
| 20:27 | <caitp> | and have even campaigned to some degree to address some of those problems |
| 20:27 | <Hixie> | urls? |
| 20:27 | <caitp> | but I'm just one person, and I am very snarky, not necessarily diplomatic |
| 20:27 | <caitp> | so campaigning is not my strongpoint |
| 20:28 | <IZh> | 8 |
| 20:28 | <IZh> | Oops |
| 20:35 | <caitp> | sorry Hixie I didn't mean to come across as saying that there have been __no__ efforts to improve things, but I don't think there has been much of a real effort to give people a reality check about the importance of number-of-downloads/users/etc |
| 20:36 | <caitp> | so I apologize for that =) |
| 20:43 | <Hixie> | caitp: i think if you tried to tell a browser vendor that users were less important, they'd respond with a precise dollar figure per user and ask you how many dollars you think they should give up in order to make some API slightly prettier |
| 20:45 | <caitp> | sure, and then you say "whatever it takes", because the reality is that the revenue models for most of these vendors don't really come from people using their particular browser all the time |
| 20:45 | <Hixie> | i also think the reaction would probably depend on whether they were currently increasing in market share or losing it. It's worth noting that Chrome is more willing to break APIs these days than other browsers; I don't think their relative market numbers are unrelated to this. |
| 20:45 | <Hixie> | uh |
| 20:45 | <Domenic> | what i am hearing is that caitp hates capitalism ;) |
| 20:45 | <Hixie> | the revenue model of all browsers is pretty much entirely based on how much they use their browsers. |
| 20:46 | <Hixie> | caitp: what do you think the revenue model of browsers is? |
| 20:46 | <caitp> | you've got a number of revenue models |
| 20:46 | <Hixie> | you do? |
| 20:46 | <Domenic> | hmm, i was pretty sure the argument from a few minutes ago was that revenue wasn't important, and people should go outside and read books or something. |
| 20:46 | <caitp> | in Mozilla's case, you have donations to the foundation, ad revenue for the corporation. In the case of Google, you have piles of ad revenue. in the case of Mozilla, you have cloud services, OEM licensing, and other models |
| 20:47 | <caitp> | in the case of Apple, you have iPhone sales, etc etc |
| 20:47 | <caitp> | it's not that revenue isn't important, it's that the impact on revenue breaking changes would have is exaggerated |
| 20:48 | <Hixie> | um... you might want to look at mozilla's financials more closely. |
| 20:48 | <Domenic> | JakeA: curious what https://twitter.com/trygve_lie/status/468839273010323456 is about? |
| 20:48 | <Hixie> | and in the case of iPhone, sales of the device are going to drop if people find that browsers on their device don't work (there's only one rendering engine for all browsers on iPhones) |
| 20:49 | <caitp> | and that's only significant if it breaks a huge amount of the web |
| 20:49 | <caitp> | you can break a lot with minimal impact |
| 20:49 | <Hixie> | what is a huge amount? a million pages? |
| 20:49 | <Hixie> | a hundred thousand? |
| 20:50 | <caitp> | lets put it this way, hamstersmut.com rendering a paragraph wrong is probably not going to severely impact sales |
| 20:50 | <Hixie> | so 2 million? |
| 20:51 | <caitp> | a number of pages that have real audiences |
| 20:51 | <Hixie> | the tail on the web is very long |
| 20:51 | <caitp> | and the number of those pages breaking could be mitigated by discussing with them |
| 20:51 | <Hixie> | veeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeery long |
| 20:51 | <JakeA> | Domenic: https://twitter.com/leftieFriele/status/468836645362757633, although I was genuinely unaware of the meaning of "webbles", I just found " web rebels " difficult to say |
| 20:51 | <Hixie> | google knows of ~100 trillion pages |
| 20:51 | <Hixie> | how do you plan to contact them? phone calls? |
| 20:51 | <caitp> | mass email to DNS providers >:D |
| 20:52 | <Domenic> | JakeA: haha wow |
| 20:52 | <Hixie> | yeah, because spamming the world is definitely going to improve sales |
| 20:53 | <caitp> | for applications with real audiences, which have a real impact on sales, you could even go with face to face conversation to discuss breaking changes |
| 20:53 | <caitp> | does it scale? no, but it doesn't have to |
| 20:54 | <Hixie> | 100 trillion pages. |
| 20:55 | <Hixie> | 0.001% of them is a billion pages. |
| 20:55 | <Hixie> | i think it might have to scale. |
| 20:55 | <caitp> | pages is not necessarily "domains" |
| 20:56 | <Hixie> | there's more than a quarter of a billion domains |
| 20:56 | <caitp> | and a given organization may have many domains |
| 20:56 | <Domenic> | 100 trillion, really? that's awesome. |
| 20:56 | <Hixie> | 0.001% is 2500 domains that have to be contacted |
| 20:56 | <caitp> | which is totally doable |
| 20:57 | <caitp> | and then you could even bundle them by industry |
| 20:57 | <caitp> | government, utilities/transportation, entertainment, etc |
| 20:57 | <Hixie> | at five hours per domain, that's a year and a half non-stop per breaking change |
| 20:57 | <Hixie> | are you paying for that? |
| 20:58 | <Hixie> | also, have you seen the response you get from developers when you tell them there's going to be a breaking change? look in blink-dev at the reaction around showModalDialog(). |
| 20:58 | <caitp> | out of my own pocket? hey, I'm a genius, not an oil executive |
| 20:58 | <Hixie> | so who's going to be paying for it? |
| 20:58 | <caitp> | who indeed |
| 20:59 | <Hixie> | hello browser vendor executive, please make a choice: we could do nothing, and it would cost nothing, or we could make this breaking change, and it would cost us x% of users or a year and a half of intensive conversations with developers who will be angry at us for breaking their site. |
| 21:00 | <caitp> | hey, what is money if it doesn't flow down the river |
| 21:00 | <wilhelm> | Hey, opportunity cost. (c: |
| 21:01 | <Hixie> | that's true, i forgot about hte opportunity cost. All the effort spent making that breaking change could instead have been spent making the browser a bit faster or more stable or whatever. |
| 21:02 | <caitp> | if you remove brokenness, you might see a performance and stability improvement, too :D |
| 21:02 | <Hixie> | do you have an example of how that could happen? |
| 21:02 | <Hixie> | generally, changing APIs just introduces bugs, it doesn't remove them |
| 21:03 | <caitp> | sure, suppose we removed 12 million lines of code, which no longer has to be linked into a binary |
| 21:03 | <Domenic> | Hixie: where in the spec would I go to find out what DOM should result from the strings "" vs. " " |
| 21:03 | <caitp> | no longer ends up getting called and no longer takes up cache lines |
| 21:03 | <caitp> | beautiful |
| 21:03 | <Domenic> | Hixie: as in, I saved an empty .html file and opened it in my browser, vs. a one-byte one containing a space. |
| 21:03 | <Hixie> | Domenic: you mean in parsing? |
| 21:04 | <Domenic> | Hixie: yeah I'd imagine so. |
| 21:04 | <Hixie> | Domenic: http://www.whatwg.org/specs/web-apps/current-work/#parsing |
| 21:04 | <Domenic> | Noooo trolled by the single-page spec again :P |
| 21:04 | <Hixie> | caitp: you were talking about changing APIs, not removing APIs |
| 21:04 | <caitp> | it's an example hixie, you could definitely do a lot of both |
| 21:04 | <Domenic> | if i were a browser engine implementer i would spend all my time improving browser speed when viewing the html standard, just as a matter of improving my own productivity :P |
| 21:05 | <Hixie> | caitp: you say "definitely", but i don't see on what you're basing this |
| 21:05 | <Domenic> | Hixie: I really like the new "Note", "Example", etc. |
| 21:05 | <caitp> | I base things on hypothetical scenarios |
| 21:05 | <Hixie> | Domenic: chrome is pretty fast at loading it. I don't really understand why the other browsers aren't improving to match it. |
| 21:05 | <caitp> | it's the best source of evidence |
| 21:06 | <Domenic> | (stunned silence) |
| 21:06 | <caitp> | such empirical, much scientific, wow |
| 21:06 | <Hixie> | i'll take that as a concession speech... |
| 21:06 | <caitp> | hardly |
| 21:07 | <caitp> | just a little good humour |
| 21:07 | <Hixie> | caitp: so what are you basing it on then? |
| 21:07 | <caitp> | let me scroll up to see what I said "definitely" baout |
| 21:07 | <caitp> | about* |
| 21:08 | <Domenic> | Hixie: well it turns out today is not the day I'm going to spend understanding the HTML parsing algorithm :P. Do you happen to know off the top of your head what behavior should be for "" vs " "? I can always test browsers I suppose. |
| 21:08 | <caitp> | oh, definitely remove and change apis |
| 21:08 | <caitp> | sure, there's a lot of complete crap that you could remove, like most of the parsing algorithm |
| 21:08 | <caitp> | (just for example) |
| 21:08 | <caitp> | most of the DOM api |
| 21:09 | <caitp> | most of CSS |
| 21:09 | <Hixie> | Domenic: i can look... |
| 21:09 | <caitp> | although removing a lot of that wouldn't make anyone very happy, it would be a marked improvement |
| 21:10 | <Hixie> | Domenic: looks like no difference. a space at the very start gets dropped on the floor. |
| 21:11 | <Hixie> | caitp: ok so removing "most of the parsing algorithm" would in fact affect trillions of pages on hundreds of millions of domains. |
| 21:11 | <caitp> | yeah, but think of how much code smell you could get rid of 8) |
| 21:11 | <Hixie> | caitp: so that's a non-starter even if i concede everything you said earlier about how easy it is to make breaking changes |
| 21:11 | <Hixie> | caitp: i'm going to assume that "msot of the DOM api" and "most of CSS" are just more "little good humour" |
| 21:12 | <Domenic> | Hixie: appreciated, thanks. |
| 21:12 | <caitp> | nah, if you could do it all over again, you could learn from past mistakes and improve it, and minimize special casing and bizarre behaviour |
| 21:12 | <caitp> | it would be beautiful |
| 21:13 | <caitp> | but obviously that's a wild leap beyond removal of simple things |
| 21:13 | <caitp> | but oh man, it would be glorious |
| 21:14 | <Hixie> | it would be glorious for about a month |
| 21:14 | <Hixie> | until the next new feature developed by someone who didn't have anything to do with the initial glorious design was added |
| 21:14 | <Hixie> | or until the next browser shipped with a minor bug that the web then started depending on |
| 21:15 | <Hixie> | and within a year we'd be back where we started |
| 21:15 | <caitp> | yeah but in another 2 decades you could do it all over again |
| 21:15 | <caitp> | totally worth it |
| 21:15 | <Hixie> | (or, more likely, it wouldn't take off in the first place, since it would have to compete with the existing web, and 100 trillion existing documents in ugly code would trump the 0 documents of beautiful code in users' eyes, since they don't see the code) |
| 21:15 | <wilhelm> | caitp: Aw, you're 12 years late. Here you go: http://www.w3.org/TR/xhtml2/ |
| 21:16 | <caitp> | I have good friends on that WG |
| 21:16 | <caitp> | well, the xmlwg |
| 21:16 | <Domenic> | hehehehe |
| 21:16 | <Domenic> | wilhelm++ |
| 21:16 | <Hixie> | well that explains a lot |
| 21:16 | <wilhelm> | :D |
| 21:17 | <caitp> | good people is good people, and sometimes they have sensible ideas |
| 21:18 | <jgraham> | caitp: So the real-world example with the closest properties to what you describe was Opera+Presto. It didn't intentionally break APIs, but due to low marketshare sites didn't go out of their way to support it. As a result Opera did a huge amount of outreach to sites, and a huge amount of work on implementation quality. But often sites wouldn't apply fixes even if you literally sent them a patch file to apply to their code. Not small site either; hu |
| 21:18 | <wilhelm> | jgraham: /load splitlong.pl |
| 21:18 | <jgraham> | wilhelm: Oh, I thought I already had |
| 21:19 | <jgraham> | caitp: So the real-world example with the closest properties to what you describe was Opera+Presto. It didn't intentionally break APIs, but due to low marketshare sites didn't go out of their way to support it. As a result Opera did a huge amount of outreach to sites, and a huge amount of work on implementation quality. But often sites wouldn't apply fixes even if you literally sent them a patch file to apply to their code. Not small site either; hu |
| 21:19 | <jgraham> | ... got hundreds of thousands of Opera users. |
| 21:19 | <caitp> | yeah but if all of our mighty browser vendor overlords joined in for the breaking changes, people wouldn't really have a choice. but I do know that it's not something that's going to happen any time soon, it's a pipedream |
| 21:20 | <jgraham> | Yes, but getting everyone to act like that isn't a Nash equilibrium |
| 21:22 | <Hixie> | jgraham: your text cut off at "Not small site either; hug" then contined with "... got hundreds" |
| 21:22 | <Hixie> | continued |
| 21:23 | <Hixie> | caitp: i don't think anyone is arguing that "people" aren't "good people". Just that said "people", apparently including you, have an unrealistic idea of what is achievable when it involves changing how people think or act. |
| 21:24 | <caitp> | or you know what might happen instead, maybe the WWW will simply stop existing as nationstates put up huge national firewalls, and architect strong protections against those firewalls being undermined, and that greatly reduces the pool of applications that would be affected |
| 21:24 | <caitp> | it's not that I have an unrealistic sense of what is achievable |
| 21:24 | <Hixie> | that is debatable. |
| 21:24 | <caitp> | it's that I have a lot of confidence |
| 21:24 | <jgraham> | "huge ones that probably" |
| 21:25 | <Hixie> | ok, you have an unrealistic level of confidence in what is achievable. |
| 21:25 | <Hixie> | imho |
| 21:25 | <wilhelm> | Not unrealistic. Positively harmful. What a waste of good engineers. (c: |
| 21:25 | <caitp> | hey, at least I'm not trying to start the next snapchat |
| 21:27 | <Hixie> | as jgraham says, getting all the browser vendors to work in this way is not a nash equilibrium. In practice, humans do act to find a nash equilibrium. |
| 21:46 | <Hixie> | Domenic: how does the promise pattern fit into models where we use onreadystatechange today, where the object can be in multiple states and transitions through them one by one? |
| 21:47 | <Domenic> | Hixie: three answers to that... |
| 21:47 | <Domenic> | 1) it doesn't; promises are for simple one and done async ops |
| 21:48 | <Domenic> | 2) it might be useful for users to have a promise for the 80% case, e.g. completely-loaded |
| 21:49 | <Domenic> | 3) in certain cases it can be natural to model individual state transitions as promises. E.g. you could have both ".headersReceived" and ".loaded" promises. (I don't remember the other ready states besides loaded... picked headersReceived because it seemed plausible.) |
| 21:49 | <Domenic> | 3) is pretty rare though |
| 21:50 | <Domenic> | you could consider document.ready vs. document.loaded as an instance of 3), I guess. |
| 21:54 | <Hixie> | Domenic: i'm looking at script and resource loading, and there's all kinds of edge cases, different states, etc. |
| 21:55 | <Hixie> | Domenic: e.g. you want to know when some things are downloaded but not yet executed, so you can execute something when everything is ready |
| 21:55 | <Hixie> | Domenic: or you want to know when everything has executed, so you can use the api |
| 21:55 | <Hixie> | Domenic: or you want to know when things have started downloading, to show progress UI |
| 21:55 | <Domenic> | some of the questions to ask are: is it useful for a "late" subscriber to know that these things occurred? |
| 21:56 | <Domenic> | e.g. if the script has already executed, do you usually want to run the same code in response to that, as you would run if you had queued up a handler before the execution happened? |
| 21:56 | <Domenic> | with events, if you miss your chance for registration, then you have to switch programming patterns |
| 21:57 | <Domenic> | if (alreadyExecuted) { doStuff1(); } else { addEventListener("executed", doStuff2); } |
| 21:57 | <Domenic> | if doStuff1 and doStuff2 are always the same code, then promises are better |
| 21:57 | <Domenic> | if they are always different, events are better |
| 21:57 | <Domenic> | (a common case being doStuff1 is a noop, whereas doStuff2 takes action) |
| 21:58 | <Domenic> | progress is pretty explicitly out of scope for promises |
| 21:58 | <Domenic> | events work well for that |
| 21:58 | <Domenic> | although the use case of knowing when progress *starts* is an interesting one... my gut says it's not a common use case? |
| 21:59 | <Domenic> | i could potentially see .executed and .loaded as two separate state-transition-signalling promises |
| 21:59 | <Domenic> | but i am not sure it is worth the use case |
| 22:00 | <Domenic> | oh, the other big question is, can this event occur more than once |
| 22:00 | <Domenic> | if it occurs only 0 or 1 times, then a promise might be a good fit. Especially if the alternative to occuring once is an error. |
| 22:01 | <Domenic> | More than once, and you should probably not use a promise, except for the cases we were talking about earlier where "most of the time" authors use them as one-shots, like <img> |
| 22:01 | <Domenic> | bigger picture |
| 22:02 | <Domenic> | the utility of adding promises for e.g. script loading is they are easily combinatored, e.g. Promise.all([script1.loaded, script2.loaded]).then(() => { doStuff(); return script3.loaded.then(() => doStuffDependingOnScript3()); } |
| 22:03 | <Domenic> | going through each potential thing that the platform wants to expose and agonizing over the "correct" paradigm to use when exposing is as important as considering the value-add for common use cases like that. |
| 22:03 | <Domenic> | s/is as/is not as/ |
| 22:03 | <Domenic> | although upon reflection it seems likely that script.executed would be more useful in that sense than script.loaded |
| 22:11 | <Hixie> | Domenic: well if the .loaded promise needs to get reset each time you load a new one, it's not clear to me why others wouldn't as well |
| 22:12 | <Hixie> | Domenic: i'll be providing events for anything provided with promises anyway |
| 22:12 | <Hixie> | Domenic: so you always have the choice of doing it the event way |
| 22:12 | <Domenic> | Hixie: they probably would need to be reset. |
| 22:13 | <Hixie> | also, what's the pattern for handing a promise to an API to tell the API to not do anything until that promise has resolved somehow? |
| 22:15 | <Domenic> | "When _p_ becomes fulfilled..." or similar phrasings. There's a particular WebIDL thing you can link to |
| 22:16 | <Domenic> | http://heycam.github.io/webidl/#es-promise |
| 22:16 | <Domenic> | erform some steps once a promise is settled |
| 22:16 | <Domenic> | I had a few more https://github.com/w3ctag/promises-guide#shorthand-phrases |
| 22:16 | <Domenic> | but they belong in WebIDL |
| 22:23 | <Hixie> | i mean the api surface itself |
| 22:23 | <Hixie> | not how to spec it |
| 22:24 | <Domenic> | promise.then(theAPI)? |
| 22:25 | <Domenic> | or promise.then(() => theAPI(promise)) if it is important the API receives a promise |
| 22:27 | <Hixie> | no no, the idea is that the API would be given a handful of promises and other dependencies, and would wait until they've all been fulfilled |
| 22:27 | <Hixie> | so you can't just wait until your promise has fulfilled before informing the API for it, otherwise the API wouldn't know to wait |
| 22:28 | <Domenic> | I don't quite understand the second sentence, but the first sounds like Promise.all([p1, p2, p3]).then(([v1, v2, v3]) => ...) |
| 22:32 | <Hixie> | suppose you have a <script> |
| 22:32 | <Hixie> | it depends on an <img> element and another <script> element, identified by IDs, and specified via an attribute in the markup. |
| 22:32 | <Hixie> | and another script wants to say "also, wait until promise P is done too" |
| 22:33 | <Hixie> | so you have script S, and promise P, and... go |
| 22:33 | <Hixie> | or suppose you have a script S and two separate other scripts that don't know about each other want to add promises P1 and P2 to the list of promises that S is waiting on before executing |
| 22:34 | <Hixie> | what would the script behind P1 do? |
| 22:34 | <Hixie> | S.addDependency(P1)? |
| 22:35 | <Domenic> | Oh, we want to add the ability for a script to block another script's execution on arbitrary async events?? |
| 22:35 | <SamB> | are we trying to add Make to JS now? |
| 22:35 | <Hixie> | SamB: see http://www.whatwg.org/specs/web-apps/current-work/multipage#abstract |
| 22:36 | <Hixie> | Domenic: right |
| 22:36 | <Hixie> | Domenic: (or something else, doesn't have to be a script we're blocking) |
| 22:36 | <Hixie> | Domenic: (could be, don't load this style sheet unless all these promises have resolved) |
| 22:36 | <Domenic> | Hixie: Do you want to actually block execution, or block other people from being notified of execution? |
| 22:36 | <Hixie> | block execution |
| 22:36 | <Domenic> | Wait, "don't load this style sheet unless all these promises have resolved" is easy: |
| 22:36 | <Hixie> | (and possibly download) |
| 22:37 | <benjamingr> | Hixie `.then` unwraps things recursively, if each promise returns a promise for all its dependencies (via .all) , that promises will resolve when all those dependencies are resolved. |
| 22:37 | <Domenic> | Promise.all([p1, p2, p3]).then(() => stylesheet.load()) |
| 22:37 | <Hixie> | there might be two separate scripts independently doing this to the same style sheet |
| 22:37 | <Domenic> | So script 2 can affect how script 1 loads resources |
| 22:37 | <Domenic> | honestly this feels like a service worker level thing, if you want scripts to interfere with network-level operations like that |
| 22:38 | <benjamingr> | loadDependends = (obj) => getDependents(obj).then(deps => Promise.all(deps.map(getDependents)) |
| 22:38 | <Hixie> | Domenic: i don't really see how this would fit into service workers |
| 22:39 | <Hixie> | i've no idea what that code is doing |
| 22:39 | <Domenic> | Hixie: onfetch = function (ev) { if (isStylesheetIWantToDelay(ev.req)) { otherPromise.then(() => ev.respondWith(...)); } |
| 22:39 | <Domenic> | benjamingr: I don't think that's what Hixie is asking about |
| 22:39 | <Domenic> | Hixie: you are saying that you want the ability for scripts to intercept arbitrary resource loads and delay them based on other async ops |
| 22:39 | <benjamingr> | Hixie: :) Ok, it takes an object, and calls getDependents on it, then, when those arrive, it maps each dependent to its own dependencies and continues to resolve the dependencies until it reaches everything - I thought that's what you meant. |
| 22:39 | <Hixie> | i've no idea what _that_ code is doign either |
| 22:39 | <Domenic> | that is basically service worker |
| 22:40 | <Hixie> | how does the service worker know what the style sheet is? |
| 22:40 | <Domenic> | presumably script1 told it |
| 22:40 | <Hixie> | Domenic: not quite, but close |
| 22:40 | <Hixie> | the api i'm thinking of would be something like: |
| 22:40 | <Hixie> | myStylesheet.addDependency(myPromise); |
| 22:41 | <Hixie> | that seems simpler than the stuff y'all are describing above... |
| 22:41 | <Hixie> | especially the stuff with => where i can't tell where the lambda starts and where it finishes |
| 22:41 | <benjamingr> | Hixie: that has to be a builder pattern though, right? I'd have to call a `.init()` or something, otherwise I would never know when I'm done calling `addDependency` |
| 22:42 | <Domenic> | Hixie: that seems like an API you would build on top of service worker, yeah. Only service worker has that kind of interception capability right now. |
| 22:42 | <Hixie> | benjamingr: there's a separate method to say "ok now i need you, load all your pending dependencies and once everything is ready, apply yourself and let me know you're done" |
| 22:42 | <Domenic> | Hixie: in particular, the ability to interfere with loads you yourself do not execute is the new thing |
| 22:42 | <benjamingr> | Ah, I think I understand now, lemme see if I can write something like this in ES5ish |
| 22:43 | <Hixie> | Domenic: i don't see what service workers have to do with anything here. How do you delay the application of a <link> element, or <style>, or <img>, or <script>, from a service worker? You can't get to the DOM from those. |
| 22:43 | <zewt> | hard to believe that "we don't have code to generate unguessable uuids" is actually being used as a reason for anything |
| 22:43 | <Domenic> | Hixie: you prevent the HTTP response from coming back! |
| 22:43 | <Hixie> | who said anything about HTTP? |
| 22:43 | <zewt> | hard to believe that any browser would generate guessable uuids, for that matter |
| 22:43 | <Hixie> | UUIDs are usually surprisingly guessable |
| 22:43 | <Hixie> | by design |
| 22:45 | <Domenic> | Hixie: it is use-case equivalent to prevent something from being loaded vs. being applied. (You have to be clever and send the response anyway, but delay relaying it to the main thread until the delay is over, so as to avoid extra latency from excessive laziness. But straightforward.) |
| 22:45 | <Domenic> | If you disagree with that, then that seems like an argument for separating the APIs that load and apply these resources, more than anything. |
| 22:45 | <benjamingr> | Hixie: you mean something like this? https://gist.github.com/benjamingr/749bfe2b3c0411c7430c (in terms of API) |
| 22:46 | <Domenic> | that gist is pretty good |
| 22:46 | <benjamingr> | whoops, cache is not needed I decided it complicates things so I edited. Sorry about that. |
| 22:46 | <Hixie> | Domenic: well you definitely want to be able to fetch the resources ahead of time (and even compile / decode them) |
| 22:46 | <Domenic> | in fact it's probably best to ignore my insistence that this is service-worker level and focus on this gist. |
| 22:47 | <Hixie> | i don't understand what tht gist is trying to do |
| 22:47 | <Domenic> | it is giving you your API |
| 22:48 | <Hixie> | how would you use this? |
| 22:48 | <Domenic> | var resource = new ResourceBuilder(); |
| 22:48 | <Domenic> | resourceBuilder.addDependency('foo'); |
| 22:48 | <Domenic> | reosurceBuilder.addDependency('bar'); |
| 22:48 | <Domenic> | resourceBuilder.get().then(() => { 'foo' and 'bar' have been loaded }) |
| 22:49 | <Domenic> | in the gist there is a separation between dependencies (strings in my example) and promises, with the loadDependency function converting dependencies into promises |
| 22:49 | <Hixie> | how is this better than just foo.addDependency(bar) ? |
| 22:49 | <Hixie> | where foo is an element and bar is a promise |
| 22:49 | <zewt> | death to all "Builder" classes |
| 22:49 | <Domenic> | Hixie: it's not; if you don't need that extra level of intermediation then it's unnecessary |
| 22:50 | <benjamingr> | Hixie: How can you ever know if foo is ready? |
| 22:50 | <Hixie> | benjamingr: what do you mean by "ready"? and why would you want to know? |
| 22:50 | <zewt> | (usually they're just extra busywork, eg. BlobBuilder vs. new Blob) |
| 22:50 | <Domenic> | zewt: Hixie's argument is that the creator of the resource is not the same as the person who adds dependencies to the resource |
| 22:50 | <Domenic> | zewt: so you hand out the "building" capability to other people |
| 22:50 | <benjamingr> | Hixie: how can I use `foo` if I don't know yet if it has all the dependencies it requires to be used? |
| 22:51 | <Domenic> | benjamingr: Hixie: I think you two are talking past each other. |
| 22:51 | <Domenic> | Modulo benjamingr's gist having an unnecessary level of indirection, it illustrates exactly what Hixie was asking for. |
| 22:52 | <Hixie> | benjamingr: well presumably whoever is doing this would set up all the dependencies before telling anything to actually get applied/executed |
| 22:53 | <Domenic> | Here, forked and clarified https://gist.github.com/domenic/f19ba7fb48d53e2590fa |
| 22:53 | <Domenic> | i wasn't sure if you wanted resource to load in parallel with dependencies or after it |
| 22:53 | <Domenic> | right now it's in parallel |
| 22:54 | <benjamingr> | Hixie: this is exactly what the builder does for you and why I used that indirection, the `.get` method is what actually contains the logic to get the instance, and is what gives us a guarantee that we're only going to use the dependencies we have so far to build this instance, if we fail to do it with those resources, we fail. It 'snapshots' the current |
| 22:54 | <benjamingr> | dependencies. |
| 22:55 | <Hixie> | benjamingr: so suppose that the thing that we're blocking on is <script src="a.js" whenneeded needs="b.js c.js"></script> |
| 22:55 | <Domenic> | .get() is Hixie's "there's a separate method to say "ok now i need you, load all your pending dependencies and once everything is ready, apply yourself and let me know you're done" from earlier |
| 22:55 | <Hixie> | benjamingr: and support that one script wants to say "a.js also needs to wait for my style sheet" and b.js wants to say "a.js also needs to wait for my promise" |
| 22:56 | <Hixie> | benjamingr: and then once that's all done, some other script calls scriptA.execute() |
| 22:56 | <Hixie> | benjamingr: how does your gist fit into this? |
| 22:56 | <benjamingr> | Hixie: yes! we'd like a.js loading to trigger loading b.js and c.js too :) That's what I attempted to initially describe with all those arrows (and failed), let me see if I write a more readable function that does it. |
| 22:57 | <Hixie> | (the needs="" attribute here being the stuff i proposed last year, syntax probably to change) |
| 22:57 | <Hixie> | (well, whenneeded is more likely to change than needs="". people seemed ok with needs="".) |
| 22:58 | Hixie | mumbles, on an unrelated note, about how repeatedly referencing zalgo isn't particularly helpful in making one's case |
| 22:59 | <benjamingr> | Hixie: how would we know that b.js also needs d.js or a stylesheet? |
| 22:59 | <Hixie> | benjamingr: who's "we" here? and what are those other resources? |
| 22:59 | <benjamingr> | Let's say I'm c.js and I'm not in a script tag, how do we know my dependencies? When it was a.js, I knew the dependencies by reading the script tag. |
| 23:01 | <Hixie> | how would you not be in a script tag? |
| 23:02 | <Hixie> | the only way to run an external script file is from a script element |
| 23:02 | <benjamingr> | In your above example, a had a b.js dependency, however - b.js may have dependencies of its own - right? Where are those specified? |
| 23:02 | <Hixie> | on the <script src="b.js"></script> element |
| 23:02 | <benjamingr> | Ah, cool :) |
| 23:02 | <benjamingr> | Ok, gisting |
| 23:02 | <Hixie> | needs="" doesn't cause any script to run |
| 23:03 | <Hixie> | it just says "I need to have previously had <script>s pointing to these URLs executed" |
| 23:03 | <Hixie> | (or, later, modules or whatnot) |
| 23:04 | <benjamingr> | I think I understand what we're doing a lot better now, gisting :) |
| 23:06 | <benjamingr> | Hixie: what would you like to do about a recursive depencency? Right now I deadlock |
| 23:07 | <Hixie> | i can fix those easily enough |
| 23:07 | <Hixie> | don't worry about those |
| 23:08 | <Hixie> | i'm more interested in what the API looks like |
| 23:08 | <Hixie> | the UA-provided API, i mean |
| 23:09 | <benjamingr> | Hixie: https://gist.github.com/benjamingr/0ed038727f38fb77e7ee |
| 23:10 | <benjamingr> | This is just the function that resolves a dependency, let's add it to the API :) |
| 23:14 | <Hixie> | let's try this a different way |
| 23:14 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3030 |
| 23:14 | <benjamingr> | I'm still writing :) |
| 23:14 | <Hixie> | what would you put in place of the two places there that say // INSERT CODE ? |
| 23:15 | <benjamingr> | ah cool, this is easier |
| 23:17 | <Hixie> | (for the record, here's what my current straw man is: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3031 ) |
| 23:18 | <benjamingr> | Oh, I thought you wanted me to actually code something that does this :) |
| 23:18 | <Hixie> | oh |
| 23:18 | <Hixie> | no no |
| 23:18 | <Hixie> | sorry |
| 23:19 | <Hixie> | that's the browser vendors' problem :-) |
| 23:19 | <benjamingr> | Ah, wouldn't that make talking about it easier though? |
| 23:20 | <Hixie> | well it couldn't hurt |
| 23:20 | <Hixie> | but the end goal is to figure out what the UA API should be |
| 23:21 | <benjamingr> | Yeah, but that's hard to do without something working to test on :) |
| 23:22 | <Hixie> | i usually find that if i can make a convincing shim that does the same thing, it means i don't need an API |
| 23:23 | <Hixie> | so usually i only need to be designing APIs when making a convincing shim is either very hard, or implausible |
| 23:23 | <benjamingr> | I can make a convincing shim if I do `data-src` instead of `src` |
| 23:29 | <Domenic> | ^ pointing to how separating execution from loading is really what's at stake here |