| 00:12 | <admin_000> | news |
| 02:07 | <roc> | zewt: ah, right. Yeah, they're using icon fonts. |
| 02:08 | <roc> | I think we should probably allow pages to specify fonts for PUA characters even when "allow pages to choose their own fonts" is unchecked. |
| 02:08 | <roc> | I'll file a bug |
| 02:11 | <SamB> | these aren't the droids you're looking for! |
| 02:12 | <roc> | https://bugzilla.mozilla.org/show_bug.cgi?id=1054817 |
| 02:13 | <SamB> | where is the "disvote" option |
| 02:18 | <astearns> | makes sense to me. there's no point (almost by definition) in rendering PUA characters in a different font |
| 02:20 | <SamB> | there are those of us who would prefer to be aware of the meaningless codepoints we are being subjected to, however ... |
| 02:23 | <roc> | all five of you |
| 02:23 | <SamB> | roc, astearns: also, it would introduce a perverse insentive to use meaningless codepoints when meaningful codepoints exist |
| 02:23 | astearns | wonders where in the priority of constituencies people concerned with codepoints lies |
| 02:25 | <astearns> | SamB: I don't find PUA codepoints perverse, so in my mind author intent trumps your particular use case |
| 02:25 | <astearns> | I do see the utility in users choosing their own fonts, when they want |
| 02:26 | <astearns> | but when their fonts are almost guaranteed not to have anything useful to display... |
| 02:26 | <SamB> | astearns: you don't think it's dumb to use a meaningless PUA codepoint when there's a perfectly good non-PUA codepoint for the symbol in question? |
| 02:26 | <astearns> | depends on when there is an alternative. for the icon case we were discussing, my guess is that there often is not an alternative |
| 02:27 | <SamB> | using SVG with a reasonable filename would honestly be more accessible ... |
| 02:27 | <SamB> | (or a ligature trick) |
| 02:29 | <astearns> | I agree - and using an agreed-upon codepoint is preferable to making up your own |
| 02:29 | <SamB> | some browsers just can't render webfonts |
| 02:29 | <astearns> | and some browsers don't run script |
| 02:30 | <SamB> | yeah |
| 02:30 | <SamB> | I know |
| 02:30 | <astearns> | hopefully both of those situations will get less and less relevant |
| 02:30 | <SamB> | also screenreaders will NEVER know WTF those PUA codepoints are supposed to be |
| 02:54 | <roc> | yeah, but a screenreader can't make sense of a PNG icon either. |
| 02:55 | <caitp-> | a braille display could |
| 03:03 | <SamB> | roc: it could read the filename out, though! |
| 03:04 | <roc> | a braille display can render the glyphs for unknown Unicode codepoints too :-) |
| 03:05 | <roc> | SamB: what if it's a data URL? hate to read that out :-) |
| 03:05 | <SamB> | roc: well don't do that then! |
| 03:05 | <SamB> | of course, github clearly don't CARE |
| 06:46 | <MikeSmith> | surprised there so far hasn't been much discussion anywhere about the technical claims the blink team has been with regard to pointer events vs touch events |
| 06:46 | <MikeSmith> | except for smaug's reply |
| 06:46 | <MikeSmith> | http://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0052.html |
| 08:19 | <annevk> | prolly because this was all already sorted behind the scenes |
| 08:25 | <MikeSmith> | annevk: ah |
| 08:25 | <MikeSmith> | open and transparency ftw |
| 08:26 | <annevk> | I don't really know MikeSmith |
| 08:27 | <annevk> | I don't know enough about UI events and even less about touch specifically |
| 08:27 | <MikeSmith> | yeah me neither |
| 08:27 | <annevk> | But given that touch is mostly for mobile and that's mostly Google/Apple, and pointer events never had buy-in from Apple, ... |
| 08:28 | <MikeSmith> | right |
| 08:28 | <annevk> | It would work if Apple was doing nothing like Microsoft did with IE6 |
| 08:29 | <MikeSmith> | well it seems like for Windows 8 Microsoft has bought into touch |
| 08:29 | <MikeSmith> | even for their desktop OS |
| 08:29 | <MikeSmith> | which they have still quite a lot of market share for |
| 08:29 | <MikeSmith> | so it's kinda not just about mobile |
| 08:30 | <MikeSmith> | though I guess it's unclear how successful they've been so far with bringing touch to desktop |
| 08:31 | <annevk> | The only user I know is Domenic |
| 08:31 | <othermaciej> | there’s quite a few touchscreen windows laptops |
| 08:31 | <othermaciej> | I dunno if anyone actually uses the touch capabilities |
| 08:31 | <annevk> | Yeah, not sure if he uses the touch screen either, he has a keyboard attached |
| 08:35 | <MikeSmith> | in my limited experience using Windows 8 on a laptop it works a lot better if you use touch instead of trying to use the mouse/pointer |
| 08:35 | <MikeSmith> | it's kind of like, when you're using the pointer, you feel like you're emulating touch actions |
| 08:38 | <smaug____> | oh, this pointer events stuff |
| 08:39 | <othermaciej> | I think Google is right that there’s a difference between mouse and touch UIs that pointer events handle badly |
| 08:40 | <smaug____> | blink is happy to say no pointer events, and one reasoning is that webkit doesn't support them, yet they are happy to implement a lot more complicate stuff, which slows down various things and not supported by webkit, web components |
| 08:40 | <othermaciej> | specifically, on touch UI platforms, touches are always captured based on what you touch first - there’s no such thing as swiping your finger across a row of controls and getting their hover effects |
| 08:41 | <smaug____> | othermaciej: pointer events can handle that |
| 08:41 | <othermaciej> | that makes all the leave/in/out machinery and the rule of targeting based on hit testing useless or perhaps even harmful |
| 08:41 | <smaug____> | similar way as touch events |
| 08:41 | <othermaciej> | they do have the capture mode |
| 08:41 | <smaug____> | and pointer events don't have the odd touchList stuff |
| 08:41 | <smaug____> | if one needs touch lists, that can be done within the web app |
| 08:42 | <smaug____> | anyhow, I think pointer events are pretty much dead now |
| 08:42 | <othermaciej> | who knows? Google might change their mind again |
| 08:42 | <smaug____> | that is possible |
| 08:42 | <othermaciej> | their implementation decisions seem kind of mysterious to me |
| 08:43 | <smaug____> | I'm not going to remove pointer events support from Gecko any time soon |
| 08:43 | <annevk> | othermaciej: yeah, with Apple it's always clearcut |
| 08:43 | <annevk> | ;) |
| 08:44 | <othermaciej> | usually our pattern is we don’t say anything (or actively say no), then we ship it |
| 08:44 | <smaug____> | s/anyhow, I think pointer events are pretty much dead now/anyhow, I think pointer events are pretty much dead for now/ |
| 08:45 | <jgraham> | I'm pretty sure my Mum would use a tocuhscrren laptop, based on the fact she kept trying to touch things on the screen of my laptop last time she used it. I'm not sure why; I think she just uses a tablet so much that she now assumes all devices work in the same way |
| 08:45 | <othermaciej> | how do pointer events handle multi-touch? |
| 08:45 | <othermaciej> | separate event for each touch? |
| 08:45 | <smaug____> | right |
| 08:46 | <MikeSmith> | othermaciej: I would think that hover could be implemented in touch environments that also had relatively finer-grained proximity-sensor support. My Galaxy S4 has that sort of proximity sensor and some parts of the UI already use it to produce effects on hover -- e.g., you can actually hover over a row of controls and it gives you the hover effects you'd expect |
| 08:48 | <othermaciej> | I can’t remember the whole reason for the TouchList thing, but I think it was invented so you could implement gestures involving multiple touches without having to keep a lot of state to know what was happening with the active touch points |
| 08:48 | <MikeSmith> | jgraham: I would think touchscreen laptops are way more intuitive for first-time computer users -- or for anybody already used to a mobile phone with a touchscreen |
| 08:48 | <othermaciej> | whether it helps with that, I don’t know |
| 08:48 | <othermaciej> | it doesn’t seem like bespoke multitouch gestures has turned out to be much of a thing |
| 08:49 | <smaug____> | indeed |
| 08:49 | <annevk> | foolip: you around? |
| 08:49 | <othermaciej> | it does at least let you avoid accidentally treating an extra touch with fingers already down as an independent tap that activates something |
| 08:49 | <annevk> | foolip: I think I'll make Attr.prototype.value readonly for now in the specification and open a bug about what we should do if that cannot be implemented |
| 08:50 | <annevk> | foolip: if that cannot be done we can basically do the thing where Attr objects can be added to objects and Attr objects can be created, etc. and have an ownerElement |
| 08:51 | <smaug____> | pointer events have the concept of primary pointer |
| 09:06 | <jgraham> | MikeSmith: Yeah. In this case she's familiar with the concept of non-touch-screen devices but just assumed that any new device is touch-capable. However there are an increasing number of people who have never used a non-touch device. |
| 09:11 | zcorpan | recalls a video of a 2-year old concluding that the paper magazine is broken because it doesn't respond to touch |
| 09:17 | <zcorpan> | https://www.youtube.com/watch?v=aXV-yaFmQNk |
| 09:18 | <zcorpan> | 1 year old |
| 11:28 | <foolip> | annevk: here! |
| 11:28 | <annevk> | yay |
| 11:28 | <annevk> | foolip: see bugmail :-) |
| 11:28 | <foolip> | will do |
| 11:28 | <foolip> | also, we have a fullscreen issue here |
| 11:29 | <foolip> | things get weird when you have display:none on a parent of the fullscreen element |
| 11:29 | <foolip> | the spec says "It is not rendered if it, or an ancestor, has the display property set to none." and that's pretty much what happens |
| 11:30 | <foolip> | the consequence on a site we've been debugging is that one is left in fullscreen even though the fullscreen content isn't showing any longer |
| 11:30 | <foolip> | don't know how to fix it, so I wanted to ask if there's a great reason why things in the top layer don't ignore display:none on their parents? |
| 11:32 | <annevk> | that would be a first in CSS |
| 11:32 | <foolip> | yeah, I suspected as much |
| 11:32 | <annevk> | and on the face of it seems like it might destroy a bunch of optimizations in the CSS engine |
| 11:32 | <foolip> | and exiting fullscreen would require reacting to changes in computed style |
| 11:34 | <annevk> | i guess at some point we might get a computed style observer thingie that would make that possible |
| 11:35 | <foolip> | wild idea: an extra backdrop which you can't make transparent that ends up below the ::backdrop pseudo elements, so that you can never see anything other than the :fullscreen element and its children? |
| 11:36 | <annevk> | seems like that is something we want to be able to show though |
| 11:37 | <foolip> | right now you can fullscreen some random element and set it to display:none, and it looks like you've entered fullscreen for documentElement or document.body, it's pretty weird |
| 11:37 | <foolip> | but it also only seems to happen when the site has done something strange (in this case didn't consider that it might be in fullscreen even though it had a fullscreen button) |
| 11:39 | <foolip> | are there use cases for doing that kind of thing, or is it just consequence of keeping things simple? |
| 11:40 | <annevk> | keeping things simple I guess |
| 11:41 | <annevk> | e.g. :root { display:none } is possible too |
| 11:43 | <foolip> | yeah |
| 11:43 | <foolip> | we'll try to get the site fixed and see if the problem keeps coming up |
| 11:44 | <foolip> | to the bugmail |
| 12:29 | <annevk> | foolip: :-( |
| 12:30 | <annevk> | So what remains? Attributes can't have child nodes |
| 12:30 | <annevk> | And they are not nodes, although whether that matters much is up for debate now |
| 12:32 | <foolip> | annevk: yeah, getting rid of the child nodes is the only remaining simplification I'm aware of |
| 12:32 | <foolip> | there's a relevant use counter for that, let me find it |
| 12:33 | <foolip> | Attr.textContent: http://www.chromestatus.com/metrics/feature/timeline/popularity/349 |
| 12:33 | <annevk> | Attributes not being nodes also simplifies some stuff as other algorithms don't have to deal with the fact of being passed an Attr node |
| 12:33 | <foolip> | so textContent would have to be made an alias at the very leat |
| 12:33 | <annevk> | foolip: we could support that as an alias to .value |
| 12:33 | <annevk> | seems like it |
| 12:33 | <foolip> | not sure how to effectively measure if child nodes themselves are needed |
| 12:34 | <annevk> | does Chrome even support that? |
| 12:34 | <annevk> | that means attr.appendChild(text) is supported |
| 12:34 | <foolip> | modifying child elements causes the attribute value to be updated last I checked |
| 12:34 | <foolip> | it's really weird :) |
| 12:35 | <annevk> | oh, some weird hack? |
| 12:35 | <annevk> | hmm |
| 12:35 | <annevk> | and going through childNodes? |
| 12:35 | <annevk> | I guess I can check myself |
| 12:36 | <foolip> | Attr::childrenChanged in Source/core/dom/Attr.cpp |
| 12:36 | <foolip> | not so crazy implementation-wise, but it's a crazy API for changing attributes |
| 12:36 | <foolip> | I guess you knew that |
| 12:37 | <foolip> | I guess as a start one could measure in Attr::childrenChanged, but getting rid of only that while still keeping the child nodes doesn't seem great |
| 12:37 | <zcorpan> | annevk: did you switch away from anolis? |
| 12:56 | <zcorpan> | maybe we need an Exif5 spec |
| 13:05 | <annevk> | zcorpan: no |
| 13:05 | <annevk> | TabAtkins: I started updating DOM again btw |
| 13:06 | <zcorpan> | annevk: ok |
| 13:06 | <annevk> | TabAtkins: since you never pinged back on switch to Bikeshed |
| 13:08 | <annevk> | zcorpan: I do plan on switching to what TabAtkins made as it seems better maintained |
| 13:08 | <annevk> | zcorpan: I have not made the time however and I think there's a few things it does differently at the moment that make switching harder |
| 13:41 | <annevk> | foolip: I think I'll try to leave out some of the *NS methods as they just don't seem used and do actually make things more complicated |
| 13:51 | <foolip> | annevk: they do? which ones? |
| 13:51 | <annevk> | foolip: setAttributeNodeNS, getAttributeNodeNS, but I guess we could leave those too |
| 13:51 | <annevk> | foolip: createAttributeNodeNS |
| 13:51 | <annevk> | euh, createAttributeNS() |
| 13:53 | <foolip> | I have no love for any of those, but what complexity do they add on top of the non-namespaced variants? |
| 13:55 | <annevk> | yeah you're right |
| 13:55 | <annevk> | :-( :-( |
| 13:56 | <foolip> | there aren't enough sad faces to throw at Attr |
| 13:56 | <foolip> | do you know who came up with this API to begin with? |
| 13:57 | <foolip> | or is it hidden in a teleconf from 1995? |
| 14:00 | <annevk> | the Java guys involved in designing the DOM |
| 14:01 | <annevk> | and then they added all the complexity for XML in a nonsensical manner |
| 14:01 | <annevk> | so crazy |
| 14:08 | <foolip> | web platform is best platform |
| 14:33 | <TabAtkins> | annevk: Oh right, sorry. I'd stopped while we worked out the header/footer situation with Domenic for Streams, and never got back to it. |
| 14:40 | <TabAtkins> | smaug____: Re: not staying logged in, use an incognito window? |
| 14:41 | <TabAtkins> | smaug____: (You have to stay logged in for *some* period of time just to use multiple pages at once, so you're just asking for the ability to auto-logout after a much shorter period than normal.) |
| 14:41 | <smaug____> | TabAtkins: right, private browsing mode should work |
| 14:42 | <smaug____> | I'm asking for a mode where I would be logged out automatically after closing top level Google (not search) tabs |
| 14:42 | <smaug____> | well, even search |
| 14:42 | <smaug____> | because search just doesn't need the account information for anything |
| 14:43 | <smaug____> | (except for targeted ads, which are super annoying ) |
| 14:44 | <TabAtkins> | I don't see how that's possible, actually. Pages can't maintain state like that. |
| 14:44 | <TabAtkins> | Without something like storing all state on the server and doing heartbeat pings. |
| 14:47 | <annevk> | Isn't that sessionStorage? |
| 14:48 | <jgraham> | Or you could use a shared worker |
| 14:57 | <annevk> | foolip: you still want to fix bugs in Chrome I think |
| 14:57 | <annevk> | foolip: e.g. what it does for var x = document.createAttribute("test:test");w(x.localName) is pretty weird |
| 14:58 | <annevk> | foolip: Chrome doesn't throw for document.createAttributeNS("test:test") which is somewhat odd too |
| 15:02 | <Domenic> | The great Attr retreat of 2014 :( |
| 15:04 | <annevk> | Domenic: haven't given up completely yet, but yeah, we're adding back some complexity to the spec |
| 15:04 | <Domenic> | Yeah, was just a sad set of emails to wake up to |
| 15:12 | <TabAtkins> | annevk: Hmm, sessionStorage doesn't apply across domains. |
| 15:12 | <TabAtkins> | (Also, it's a variant of localStorage, which we don't like.) |
| 15:13 | <TabAtkins> | Using a Shared Worker is possible. A lot of complexity for something solved by "use an incognito window", though. |
| 15:14 | <boogyman> | TabAtkins: sub domains i could see, but i think there would have security issues if data-storage occurs across domains. |
| 15:18 | <TabAtkins> | I meant subdomains too. |
| 15:29 | <annevk> | There's issues with "subdomains" too: https://publicsuffix.org/ |
| 15:29 | <annevk> | Which is why we tie things to origins |
| 15:29 | <annevk> | new things, anyway |
| 15:41 | <MikeSmith> | oh joy http://lists.w3.org/Archives/Public/semantic-web/2014Aug/0063.html |
| 15:41 | <MikeSmith> | ーHTML either misuses or fails to appropriately use the well-defined vocabulary terms of URIs used in all other Web-related standards, including the recent updates of RDF [4] and HTTP [5], and the newly published CoAP [6]. Where I would expect to see terms like "URI Reference" and "IRI", I see only "URL", which in the strictest sense would be incompatible with RDF's IRIs. |
| 15:42 | <Domenic> | Hehehehehe |
| 15:43 | <TabAtkins> | And then talk about "some legacy pages" being broken in favor of RDF-based apps, as if the numbers were within even a few powers-of-ten of each other. |
| 15:54 | <Domenic> | https://twitter.com/mikeal/status/501391405714268161 |
| 16:30 | <annevk> | MikeSmith: I wonder when they notice we dropped DTDs |
| 16:31 | <annevk> | Domenic: that's how we implement ES6 at Mozilla it seems |
| 16:31 | <annevk> | (Although we wouldn't call HTML HTML5) |
| 16:31 | <Domenic> | Yeah, it's not the most informed tweet, but its heart is in the right place. |
| 16:34 | <annevk> | Whenever I make nice cleanup to DOM it's somewhat upsetting all my hard work is just going to be copypasted to /TR/dom/. So far there's been no benefit from this fork... |
| 16:34 | <annevk> | Arguably TR/encoding/ had some benefit, although not sure whether it was worth the cost, probably not |
| 16:36 | <annevk> | Hixie_: dfn.js seems to sometimes overwrite dfnReturnLink with a link to the chapter |
| 16:37 | <Hixie_> | file a bug, i'm off tools work until i get the script stuff done |
| 16:38 | <Hixie_> | (i figured i'd spent enough time without progress for a while!) |
| 16:39 | <Hixie_> | that semantic-web e-mail is awesome |
| 16:39 | <Hixie_> | "though I'm not aware of any such documents" |
| 16:42 | <zenparsing> | can/should we try to get these in the 420 branch? |
| 16:42 | <zenparsing> | uh - oops |
| 17:00 | <Domenic> | What does /TR/encoding give? |
| 17:05 | <annevk> | Domenic: got some review from people who otherwise might not have cared |
| 17:05 | <annevk> | Domenic: if I'm being optimistic |
| 17:07 | <SamB> | annevk: did they add bugs to /TR/dom/ ? |
| 17:09 | <annevk> | mostly confusion, perhaps some subsetting, not sure |
| 17:39 | <Hixie_> | huh |
| 17:39 | <Hixie_> | ES6 module loader doesn't support incremental loading, either |
| 17:39 | <Hixie_> | which means it won't work for HTML imports |
| 17:41 | <annevk> | Ah yeah, just a promise... |
| 17:41 | <annevk> | That is kind of sad |
| 17:43 | <Hixie_> | i suppose I can make 'fetch' return straight away for html imports |
| 17:43 | <Hixie_> | but i can't incrementally add dependencies then |
| 17:44 | <annevk> | Hixie_: is any browser vendor interested in reconciling all these systems btw? |
| 17:44 | <annevk> | Hixie_: I haven't seen many emails from implementers in these threads :/ |
| 17:45 | <Hixie_> | are there are browser vendors interested in implementing two separate dependency systems? |
| 17:49 | <Hixie_> | actually i guess it's ok |
| 17:49 | <Hixie_> | it doesn't need to return straight away |
| 17:49 | <Hixie_> | it can just create it incrementally in "fetch" |
| 17:50 | <Hixie_> | "translate" would and "instantiate" would be no-ops |
| 17:50 | <Hixie_> | this assumes we can add dependencies on the fly, of course |
| 18:20 | <Hixie_> | TabAtkins: CSS doesn't parse incrementally, right? |
| 18:20 | <Hixie_> | at least, not visibly |
| 18:21 | <TabAtkins> | Right. |
| 18:21 | <Hixie_> | k |
| 18:21 | <TabAtkins> | Well... |
| 18:21 | <Hixie_> | uh oh |
| 18:21 | <TabAtkins> | Actually, not sure. Some impls *might* start applying rules as they come off the wire. |
| 18:21 | <Hixie_> | wait, applying rules incrementally? |
| 18:22 | <Hixie_> | i just meant parsing exposed to the dom |
| 18:22 | <TabAtkins> | Oh, no, definitely not. Stylesheet is all or nothing. |
| 18:22 | <Hixie_> | applying rules incrementally seems rather ungood |
| 18:22 | <Hixie_> | ok good |
| 18:23 | <TabAtkins> | Hixie_: Merging all the thread responses together really did make it impossible to follow. |
| 18:23 | <TabAtkins> | That's fine to do when you're responding to a collection of independent months-old things, but not when you're replying to your own threads that are currently active. |
| 18:23 | <TabAtkins> | Totally breaks threading. :/ |
| 18:24 | <Hixie_> | yeah, seems that way |
| 18:24 | <Hixie_> | the list seems to the throttling me though |
| 18:25 | <TabAtkins> | Weird. |
| 18:25 | <Hixie_> | there's at least two e-mails i've sent that haven't made it to the list |
| 18:26 | <Domenic> | +1 to TabAtkins's feedback on not breaking threading |
| 18:34 | <Hixie_> | and now i'm not receiving jjb's responses either |
| 18:35 | <Hixie_> | i see them on http://esdiscuss.org/1 |
| 18:35 | <Hixie_> | waah, the list software doesn't like me! |
| 18:43 | <Hixie_> | So..... |
| 18:43 | <Hixie_> | Domenic: promise question |
| 18:43 | <Hixie_> | Domenic: say you have promises #1 through #5, and you want to wait for all of them to be done before continuing |
| 18:44 | <Hixie_> | Domenic: you can just make a new promise that's the "all" of those five promises, right? |
| 18:44 | <Domenic> | Hixie_: yes exactly |
| 18:44 | <Hixie_> | Domenic: ok. Now what if you later discover that actually #3 isn't needed, so you just want to depend on #1, #2, #4, and #5. Also, you need to add #6. How do you update the promise? |
| 18:45 | <Domenic> | Yeah, at that point you have to write your own combinator |
| 18:45 | <Domenic> | Notably, if 1,2,3,4,5 all came back, you can't add #6 |
| 18:45 | <Domenic> | since once a promise has settled it no longer changes state |
| 18:45 | <Hixie_> | sure, if it's already resolved then whatever |
| 18:45 | <Hixie_> | so here's my problem |
| 18:46 | <Hixie_> | i already have this All promise. the ES6 module loader makes it for me. |
| 18:46 | <Hixie_> | I need to dynamically modify it later. |
| 18:46 | <caitp> | modify it? |
| 18:47 | <Domenic> | One way I can think of is making #3 a "proxy" promise. So that if you determine you need #3 after all, you resolve the proxy with #3. But if you don't want it, you resolve it with undefined or something. |
| 18:48 | <Domenic> | Not sure about adding latter... |
| 18:49 | <Hixie_> | i can't control #3 either, that's also created by the ES6 module loader |
| 18:49 | <Hixie_> | and it's a real promise, it might be hte "#6" of another "all" promise, or whatever |
| 18:49 | <Hixie_> | e.g. if someone tweaks the dependencies so that A depends on D instead of C, and B depends on C instead of D. |
| 18:50 | <caitp> | i'm confused by what is meant by wanting to modify the promise ._> |
| 18:52 | <Hixie_> | caitp: i just explained it abve? |
| 18:52 | <Hixie_> | caitp: see where i said "So....." and the next four lines from me |
| 18:53 | <caitp> | sounds like something like the "some" approach vs all |
| 18:53 | <caitp> | but not exactly |
| 18:53 | <Domenic> | Yeah, I mean, I don't think this is really an issue where promises can give you what you want inherently; you need the spec patched to allow you to do a custom combinator instead of all() |
| 18:54 | <Hixie_> | yeah, that was my assumption |
| 18:54 | <Hixie_> | pity |
| 18:57 | <caitp> | complicated flow control has always kind of sucked with that particular abstraction, but it's doable |
| 19:01 | <caitp> | but, for what it's worth, you don't really need the promise spec patched in order to implement that or talk about it in a whatwg spec |
| 19:04 | <Hixie_> | caitp: not the promise spec, the module loader spec |
| 19:05 | <caitp> | if the module loader as written isn't really implementable because they're too specific about how it needs to work, that sounds like a bug in harmony :> but otherwise it sounds like an implementation detail that could be solved any number of ways |
| 19:06 | <Hixie_> | it's implementable fine, the problem is i want to support use cases it doesn't handle |
| 19:06 | <Hixie_> | like dynamically changing the dependencies |
| 19:06 | <zenparsing> | right - it assumes that the dependency graph is static |
| 19:12 | <zenparsing> | the linkage graph is static, to be more precise |
| 19:26 | <caitp> | how would you much such a graph dynamic though? is what I'm failing to see |
| 19:27 | <caitp> | even using the import/load methods of Reflect.Loader, wouldn't evaluation of the scripts be deferred until each static module is loaded? |
| 19:27 | <caitp> | s/much/make/ |
| 19:41 | <Hixie_> | zenparsing: we're probably gonna need to fix that |
| 19:41 | <Hixie_> | caitp: see es-discuss |
| 19:44 | <zenparsing> | Hixie_ in a ideal world, might it make more sense to have the host (HTML) define a dependency system and let the embedded scripting language hook into that? instead of the other way round? |
| 19:45 | <Hixie_> | in an ideal world, HTML and the scripting language would be one coherent thing and we'd have one dependency system |
| 19:45 | <Hixie_> | but in a world where we have design barriers, i don't think it's particularly important which side hooks into which |
| 19:45 | <Hixie_> | so long as the implementors don't have to implement two :-) |
| 19:50 | <caitp> | so your issue is that you want the context which uses html imports to be aware of when the imported html's script modules are loaded, and have a way to access the loaded modules? |
| 19:52 | <zenparsing> | Hixie_ does the ES side consider this unification important (yet)? |
| 19:54 | <zenparsing> | btw, i like your "foo/" => "foo/default.js" idea |
| 19:55 | <caitp> | not in favour of index.js? :p |
| 19:55 | <Hixie_> | caitp: something like that |
| 19:56 | <Hixie_> | zenparsing: dunno, none of them are really replying |
| 19:56 | <Hixie_> | zenparsing: but i'm assuming the implementors don't want to implement two dependency systems |
| 20:25 | <Hixie_> | annevk: you around? |
| 20:26 | <boogyman> | caitp: maybe an override to the default "index.<some extension" |
| 20:30 | <Sleepyvic> | Hi ! |
| 20:33 | <Sleepyvic> | anyone here ? |
| 20:33 | <boogyman> | no |
| 20:34 | <Sleepyvic> | ok I'm new to irc, i'm testing it |
| 20:34 | <Sleepyvic> | :) |
| 20:34 | <boogyman> | welcome |
| 20:34 | <Sleepyvic> | thanks |
| 20:34 | <Hixie_> | there's some people here |
| 20:34 | <Sleepyvic> | what's going on here on this channel ? |
| 20:35 | <Hixie_> | right now, not much! |
| 20:35 | <Hixie_> | but generally we chat about web standards that we're implementing or speccing |
| 20:35 | <Hixie_> | or testing |
| 20:35 | <Hixie_> | or reviewing |
| 20:35 | <Sleepyvic> | ok I found this channel on a tutorial on how to use irc |
| 20:36 | <Sleepyvic> | but i'm not into whatever you're saying |
| 20:36 | <Sleepyvic> | sounds like chinese to me :) |
| 20:36 | <Hixie_> | :-) |
| 20:36 | <Hixie_> | what tutorial? |
| 20:36 | <Sleepyvic> | http://kernelmeltdown.org/blog/how-to-set-up-irc-using-hexchat-beginners-walkthrough/ |
| 20:37 | <Sleepyvic> | and |
| 20:37 | <Sleepyvic> | http://code.tutsplus.com/tutorials/irc-is-back-heres-your-starter-guide--net-31369 |
| 20:38 | <caitp> | oh man, you found an exciting channel |
| 20:39 | <Sleepyvic> | really how exciting is it ? |
| 20:39 | <boogyman> | Sleepyvic: feel free to sit around here if you wish, but you can also type /msg alis help list and follow the instructions there to help find other channels. |
| 20:40 | <Sleepyvic> | No i'm gonna look for another channel |
| 20:40 | <Sleepyvic> | take care guys |
| 20:41 | <caitp> | oh man, you guys almost caught a fresh one |
| 20:41 | <caitp> | so close. |
| 20:42 | <boogyman> | (s)he'll get caught in the interwebs. It is all seeing after all. |
| 20:43 | <TabAtkins> | I just submitted a comment on the second article suggesting that #whatwg be taken off the list of "awesome channels for web developers". |
| 20:48 | <caitp> | where else are they gonna hang out? the web development community is so tiny |
| 20:50 | <boogyman> | caitp: not according to the numerous one-offs of channels (and thats just on freenode). |
| 20:50 | <Hixie_> | TabAtkins: oh? i thought it was pretty good that we'd get exposed to web devs |
| 20:50 | <wanderview> | : |
| 20:51 | <wanderview> | oops |
| 20:51 | <TabAtkins> | It was in a list of channels where it's appropriate to ask "how do I web?" questions, of which this is not one. |
| 20:51 | <caitp> | I emit a lot of sarcasm, boogyman, it takes practice to notice it thoguh |
| 20:51 | <caitp> | also a lot of typos. |
| 21:03 | <annevk> | Hixie_: anything important? |
| 21:03 | <charl> | exit |
| 21:03 | <charl> | bah sorry, wrong window :) |
| 21:03 | <TabAtkins> | And typo! |
| 21:03 | <Hixie_> | annevk: just curious about the new fetch apis |
| 21:03 | <Hixie_> | annevk: nothing urgen |
| 21:03 | <Hixie_> | t |
| 21:03 | <annevk> | Hixie_: anything unclear in the draft? |
| 21:04 | <annevk> | Hixie_: I haven't tried figuring out the <img>.request thing yet, there's an open bug now, but there seem to be some tricky bits since both HTML attributes and some object would control request state, which is always icky (see e.g. .style) |
| 21:04 | <Hixie_> | annevk: My first question was going to be: what's with the Request() constructor taking both a Request and a RequestInit |
| 21:05 | <Hixie_> | annevk: yeah, that's the source of my interest. |
| 21:05 | <Hixie_> | annevk: mostly I'm curious about whether you're going to be exposing dependency tree info and priority info for HTTP2 |
| 21:05 | <Hixie_> | annevk: (both of those are mutable during the request, iirc) |
| 21:05 | <annevk> | Hixie_: the idea behind passing in a request is for service workers |
| 21:05 | <Hixie_> | annevk: (so not just at init time) |
| 21:06 | <annevk> | Hixie_: e.g. you have fetchEvent.request and then you pass that to fetch() or a cache.add(); you would then use RequestInit to modify some stuff if any |
| 21:06 | <Hixie_> | annevk: ah, ok |
| 21:07 | <annevk> | Hixie_: my idea for things mutable during the fetch was to have methods on Request that invoke some cross-process action |
| 21:07 | <Hixie_> | annevk: so why does the other form of "new Request()" take a URL and a dict? why not the URL in the dict? |
| 21:08 | <annevk> | Hixie_: a URL is required, everything else is optional |
| 21:08 | <annevk> | (well everything else can have sensible defaults) |
| 21:08 | <Hixie_> | aah |
| 21:08 | <Hixie_> | so anyway, you're thinking we'd expose a .request object? |
| 21:09 | <Hixie_> | and that would have like img.request.changePriority(25) ? |
| 21:09 | <annevk> | at a high-level, yes, at a low-level I'm not sure how it'll work yet |
| 21:09 | <Hixie_> | i don't know enough about HTTP2's dependency stuff to have useful comments on that |
| 21:09 | <annevk> | yeah, something like that |
| 21:09 | <annevk> | for priorities anyway |
| 21:09 | <Hixie_> | k |
| 21:09 | <annevk> | and queryPriority() or something I guess with promises |
| 21:09 | <Hixie_> | so the UA is the one who would create that Request |
| 21:10 | <annevk> | yeah, the spec for the <img> element would set it up |
| 21:10 | <Hixie_> | so logically, we could have src="" and src-request-init="{ priority: 25; ... }" |
| 21:10 | <Hixie_> | and whenever you would create the Request, you'd actually pass that in |
| 21:10 | <annevk> | yeah |
| 21:10 | <Hixie_> | no race, which is nice |
| 21:10 | <Hixie_> | well, there's a race |
| 21:10 | <Hixie_> | but there's a well-defined time at which it is used |
| 21:10 | <Hixie_> | so interop should be ok |
| 21:11 | <annevk> | yeah, as long as we define the task and such |
| 21:11 | <Hixie_> | and then after that the attribute would be pointless |
| 21:11 | <annevk> | that might be good yes |
| 21:11 | <Hixie_> | do you know the bug# or have a search keyword i can find the bug with? |
| 21:11 | <annevk> | I was wondering what to do if someone modified Request, that was the tricky bit |
| 21:11 | <annevk> | or accessed .request and then set a crossorigin attribute |
| 21:11 | <Hixie_> | well presumably once the request is in flight it's mostly immutable, no? |
| 21:11 | <annevk> | Hixie_: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26533 |
| 21:12 | <Hixie_> | other than, like, the priority or whatever HTTP2 lets you chagne |
| 21:12 | <annevk> | Hixie_: currently Request is mostly immutable actually |
| 21:12 | <Hixie_> | lgtm |
| 21:12 | <annevk> | Hixie_: so yeah, depending on the specifics of the HTML side it might all work out fine |
| 21:12 | <annevk> | Hixie_: there were some requests to make it more mutable before the fetch happens so you could modify things in the service worker more easily |
| 21:13 | <annevk> | Hixie_: but there's already various modes for at least the Headers object so we can always shield things off |
| 21:13 | <Hixie_> | oh creating the request doesn't triger it? |
| 21:13 | <annevk> | Hixie_: no |
| 21:13 | <Hixie_> | ah ok |
| 21:13 | <Hixie_> | how do you actually trigger it? |
| 21:13 | <annevk> | you pass a Request to fetch() |
| 21:13 | <annevk> | which returns a promise for a Response |
| 21:13 | <Hixie_> | should we be creating the Request object earlier then? for <img> and co? |
| 21:14 | <annevk> | well yeah, that's the open question |
| 21:14 | <annevk> | but then you get into the problem of .request vs setting crossorigin |
| 21:14 | <Hixie_> | seems to me like it'd be saner to only do it once you do the fetch |
| 21:14 | <annevk> | I hadn't figured out a good story there |
| 21:18 | <Hixie_> | ok, commented on the bug |
| 21:20 | <annevk> | cool, ttyl |
| 21:21 | <Hixie_> | later |
| 21:51 | <bholley> | Hixie_: yt? |
| 23:57 | <Hixie_> | bholley: here now |
| 23:58 | <Hixie_> | Domenic: you around? |