| 01:41 | <MikeSmith> | Hixie: š± shows up fine for me in from my mac over ssh to irssi running within tmux, but not if I run within screen |
| 01:43 | <MikeSmith> | Hixie: and if you happen to be using mosh on osx, note that mosh won't display it correctly on osx due to osx using some outdated libc |
| 01:44 | <MikeSmith> | needs libc 2.8+ |
| 02:02 | <Hixie> | ah, yeah, i'm in screen |
| 02:02 | <Hixie> | wonder what screen is doing to screw that up |
| 02:02 | <Hixie> | it doesn't display right for me in chrome either |
| 02:02 | <Hixie> | i guess chrome doesn't do the fallback to colour emoji fonts right |
| 02:03 | <SamB_> | what is this, a Type 3 font you're talking about? |
| 02:04 | SamB_ | doesn't know any other fonts that can have colored glyphs |
| 02:25 | <MikeSmith> | SamB: I don't know what font osx is using but for the unicode emoji characters it does seem to use colored glyphs |
| 02:25 | <MikeSmith> | Hixie: yeah chrome doesn't display any unicode emoji properly yet |
| 02:25 | <MikeSmith> | Hixie: there's a chrome bug open for it |
| 02:25 | <MikeSmith> | chrome on osx |
| 02:25 | <MikeSmith> | Hixie: https://code.google.com/p/chromium/issues/detail?id=62435 fwiw |
| 02:27 | <zewt> | neat, nvidia's driver download webpage is totally broken if you won't let it run java |
| 02:27 | <zewt> | welcome to the awesome future |
| 02:32 | <MikeSmith> | SamB: apparently they're just PNGs https://bugzilla.mozilla.org/show_bug.cgi?id=715798#c2 |
| 02:36 | <MikeSmith> | SamB: hmm maybe it changed though, some time during the last two years. Because when I zoom on them now I don't see pixelation |
| 02:38 | <MikeSmith> | SamB: scratch that. if you scale them up big enough you will see the pixelation |
| 02:49 | <Hixie> | few years from now we'll all be talking about the megapixel count of our emoji font characters... |
| 02:53 | <MikeSmith> | heh |
| 02:54 | <MikeSmith> | nice to have something to look forward to |
| 03:12 | <SamB> | MikeSmith: you'd think they'd have heard of SVG by now |
| 04:14 | <MikeSmith> | SamB_: ... then they'd have two problems |
| 04:14 | <SamB_> | oh? |
| 04:15 | <MikeSmith> | SamB_: just doing the mandatory trolling of SVG that's required any time somebody mentions it on this channel |
| 04:15 | <SamB_> | why's that required? |
| 04:17 | <MikeSmith> | SamB_: because SVG is crazy. It tries to add a *socket API* to the platform. I mean, what kind of crazy-ass spec tries to add a socket API!! nuts |
| 04:17 | <SamB_> | huh, didn't know about that |
| 04:18 | <SamB_> | which version of SVG tries that? |
| 04:18 | <MikeSmith> | the bad version |
| 04:18 | <MikeSmith> | wait, all versions of SVG are bad |
| 04:18 | <MikeSmith> | so I guess I have to qualify that |
| 04:19 | <MikeSmith> | I think it has "5th Edition" in the title |
| 04:19 | <MikeSmith> | wait, no that's a different spec, some other spec |
| 04:19 | <SamB_> | is that just XML trolling now? |
| 04:20 | <MikeSmith> | SVG trolling XML? |
| 04:20 | <MikeSmith> | could be |
| 04:23 | <SamB_> | hmm, I thought there were two MIME types for svg |
| 04:24 | <SamB_> | one image/ and one application/ |
| 04:25 | <MikeSmith> | Hixie: btw recently I started trying out using mutt on my mobile. Over ssh of course. To mutt running on the mail server in a tmux/screen session. I just tried it on a lark and didn't expect to be very usable. But it turns out it is and I've pretty much completely quit using the Android mail client I had been using (K-9). |
| 04:25 | <MikeSmith> | Hixie: which is all a way of saying I bet it would work OK for Alpine too |
| 04:26 | <MikeSmith> | Hixie: the main trick I think is to use an android ssh client that has support for swipe typing |
| 04:26 | <zewt> | this is all the worst thing i've ever heard of in my life today |
| 04:27 | <MikeSmith> | Hixie: which the one I use does (irrssiconnectbot) but others (e.g., JuiceSSH) don't |
| 04:27 | <MikeSmith> | zewt: which part? you got a lot to choose from |
| 04:28 | <MikeSmith> | SamB_: if so I doubt there's any need for the application/ one |
| 04:29 | <SamB_> | how are you *supposed* to keep the scripts from running? |
| 04:30 | <MikeSmith> | you do that by not using SVG I guess |
| 04:30 | <SamB_> | I guess that's an <img> vs. <object> thing? |
| 04:37 | <zewt> | wow, chrome fullscreen is totally unusable now, pops up a "you have gone fullscreen" over the page if you come within half a light year of the top of the screen |
| 04:39 | <zewt> | aggravating when things are crippled for me because someone *else* might be stupid |
| 05:30 | <Hixie> | MikeSmith: in the past the problems i've found with trying to do pine on my phone are (a) the phone's screen is about 22 inches too small, (b) the phone's keyboard is about 12 inches too small, (c) the phone's keyboard is missing half the keys i need (or is an unusable custom keyboard), and (d) latency is terrible |
| 05:30 | <Hixie> | MikeSmith: so i don't bother with e-mail on my phone. |
| 05:34 | <MikeSmith> | Hixie: yeah trying to write mail on mobile is still a PITA. But I guess my main use case is just reading mail during the 1 hour or so commute on the train back and forth from my office. |
| 05:35 | <MikeSmith> | Hixie: which is often, I'm either standing, or I'm sitting shoulder-to-shoulder with people on each side, and can't really use my laptop |
| 05:36 | <MikeSmith> | Hixie: so I read a lot of bugmail then, and list mail, and just flag particular messages for later (to reply to later or read further later) |
| 05:36 | <MikeSmith> | Hixie: so it's more kind of just triaging mail from mobile. inbox gardening |
| 05:43 | <JakeA> | Hixie: yeah, you can imagine <video> having .ready but not .loaded. Not sure when ready would resolve for video though |
| 07:26 | <annevk> | So per https://code.google.com/p/chromium/issues/detail?id=43394#c80 they are taking the perf hit in order to be compliant for now and will fix the V8 side later. |
| 07:27 | <Ms2ger> | Again? |
| 07:44 | <MikeSmith> | groundhog day |
| 07:46 | <TabAtkins> | Hixie: Yeah, subclassing Promises should be possible. Ping Domenic or Alex Russell about the details. |
| 07:46 | <TabAtkins> | JakeA: Maybe <video>.ready would resolve when the appropriate amount of preload data loads? |
| 08:00 | <annevk> | I wonder why https://code.google.com/p/pdfium/ hasn't been axed yet in favor of https://github.com/mozilla/pdf.js to reduce Blink's Core |
| 08:01 | <annevk> | Maybe because it's part of Chromium and therefore Blink doesn't have a say... |
| 08:07 | <Ms2ger> | Mobile performance |
| 08:07 | <JakeA> | TabAtkins: that's a possibility. Also it could resolve once the duration is known. Lots of possibilities |
| 08:07 | <JakeA> | probably want promises for each |
| 08:07 | <annevk> | https://github.com/slightlyoff/ServiceWorker/issues/266#issuecomment-43848275 *sigh* |
| 08:08 | <annevk> | Maybe I should just write a script that extracts the specification and publishes it somewhere |
| 08:09 | <JakeA> | annevk: On some projects I have a "build" directory in my master branch that's a submodule pointing at the gh-pages branch |
| 08:09 | <JakeA> | that works pretty well for deployments |
| 08:09 | <JakeA> | overkill for this though |
| 08:09 | <JakeA> | we should just be using gh-pages |
| 08:09 | <darobin> | wow, this is an actual discussion? |
| 08:10 | <MikeSmith> | github should just make stuff be web published from the master branch by default and dispense with the whole gh-pages PITA thing |
| 08:11 | <jgraham_> | darobin: It turns out they ran out of bikesheds to paint, so have now turned their attention to painting shoeboxes instead |
| 08:12 | <darobin> | jgraham_++ |
| 08:12 | <darobin> | I think standards do something bad to people's brains |
| 08:15 | <JakeA> | :D |
| 08:15 | <JakeA> | MikeSmith: Or the ability to select a branch to publish |
| 08:15 | <MikeSmith> | darobin: my brain fine, work good |
| 08:16 | <MikeSmith> | JakeA: yeah |
| 08:16 | <darobin> | haha |
| 08:16 | <darobin> | last I asked GitHub they said no one else had expressed that request |
| 08:16 | <MikeSmith> | JakeA: or call the gh-pages branch the dance-monkey-dance branch |
| 08:16 | <darobin> | somehow, I can't believe that's actually true |
| 08:19 | <darobin> | feel free to hammer out some RTing for https://twitter.com/robinberjon/status/469392018331164672 |
| 08:22 | <MikeSmith> | darobin: you need to create Github Haters account to retweet that from |
| 08:23 | <darobin> | lol |
| 08:23 | <MikeSmith> | darobin: similar to that GNOME Haters account your create a while back |
| 08:23 | <MikeSmith> | you're doing great stuff with that account, getting the word out |
| 08:23 | <darobin> | that was me? I thought it came from Mr Last Week |
| 08:24 | <MikeSmith> | "Y U NOT ADD MORE PREFERENCES" indeed |
| 08:25 | <MikeSmith> | "AT LEAST WE KNOW THAT GNOME WILL NOT SUPPORT DRM, AS THEY DO NOT ADD NEW FEATURES, ONLY REMOVE THEM" etc. |
| 08:25 | <darobin> | yeah, that one made me think it was hsivonen's secret angry alter ego |
| 08:27 | <JakeA> | annevk: About to change ignoreQuerystring to ignoreQuery in the cache filtering params. Would you rather ignoreSeach? |
| 08:27 | <JakeA> | actually, now I've typed it, ignoreSearch is really confusing |
| 08:29 | <annevk> | JakeA: but it does match the name better... |
| 08:30 | <annevk> | JakeA: why is it confusing? |
| 08:31 | <JakeA> | annevk: cache.matchAll(request, {ignoreSearch: true}) |
| 08:31 | <annevk> | JakeA: ignoreURLSearch |
| 08:31 | <JakeA> | maybe it's ok |
| 08:31 | <JakeA> | worried that the context is kinda "searching" |
| 08:33 | <annevk> | JakeA: seems you typo'd prefiMatch |
| 08:33 | <JakeA> | annevk: let's go with ignoreSearch, consistency wins |
| 08:33 | <JakeA> | annevk: Yeah, spotted that, fixing now |
| 08:34 | <annevk> | JakeA: I think what's confusing is that some options apply to URLs and some to HTTP |
| 08:35 | <annevk> | JakeA: request has a URL which has a search; request has a method; response has headers which have Vary; not sure what prefixMatch is about |
| 08:35 | <annevk> | but maybe you just need to learn this |
| 08:36 | <annevk> | I can't really think of an API that separates those concerns better |
| 08:38 | <jgraham> | By "search" do we mean "query"? |
| 08:40 | <annevk> | jgraham: depends, by "query", do you mean "search"? |
| 08:40 | <JakeA> | annevk: cache.matchAll("/hello/", {prefixMatch: true}) would match caches entries with urls like "/hello/world/" |
| 08:40 | <JakeA> | It's sorta like appcache's FALLBACK |
| 08:41 | <jgraham> | annevk: I'm pretty sure no one calls it a "url search" despite the wacky terminology in the location API |
| 08:41 | <annevk> | JakeA: after parsing the URL argument I suppose? |
| 08:41 | <annevk> | jgraham: all URL APIs call it search |
| 08:41 | <JakeA> | jgraham: ignoreQuery/ignoreSearch means that the query string is ignored in matching |
| 08:42 | <jgraham> | annevk: And that's a bug in those APIs :) |
| 08:42 | <JakeA> | annevk: Yeah, it basically does this https://github.com/slightlyoff/ServiceWorker/blob/master/service_worker.ts#L537 |
| 08:44 | <JakeA> | annevk: although I dunno what requestPath is, that should just be request |
| 08:44 | <JakeA> | actually, requestUrl |
| 08:45 | <annevk> | JakeA: shouldn't it be called pathPrefixMatch then? |
| 08:45 | <annevk> | JakeA: or pathnamePrefixMatch; seems like you don't care about query there... |
| 08:46 | <annevk> | e.g. /?x=s&y=z /?x=s |
| 08:47 | <JakeA> | hmm, yeah, I think the impl is wrong |
| 08:50 | <JakeA> | will change those pathnames to hrefs |
| 08:54 | <IZh> | What is the type of media.currentTime? Is it integer or float? |
| 09:02 | <kinetik> | IZh: double (http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#htmlmediaelement) |
| 09:02 | <IZh> | kinetik: Thanks. |
| 10:11 | <darobin> | what was the name of that proposal to have workers that could handle the layout of elements? |
| 10:11 | <Ms2ger> | "dumb"? |
| 10:11 | <caitp> | that's a bit rude mister twogy =) |
| 10:12 | <darobin> | hahaha |
| 10:19 | <jgraham> | I thought we were going with "optimistic" |
| 10:22 | <annevk> | darobin: something with box/layout |
| 10:23 | <darobin> | annevk: yeah, but that's not showing anything up. I wonder if I only heard it orally |
| 10:23 | <annevk> | darobin: from the Extensible Web Summit page there should be a link to an oksoclap with a discussion |
| 10:24 | <darobin> | mmmm, thanks annevk, looking |
| 10:30 | <darobin> | ah, found it in http://oksoclap.com/p/P3aS4GtR2L, it doesn't really have a name |
| 12:36 | <annevk> | JakeA: shouldn't the Cache API be described outside of service workers if it's going to be distinct? I guess grouping them is fine for now... |
| 12:36 | <JakeA> | annevk: yes, fetch() too |
| 12:37 | <annevk> | JakeA: yeah, I plan on starting work on fetch() real soon now |
| 12:37 | <JakeA> | \o/ |
| 12:37 | <JakeA> | I need to spend some quality time with the fetch spec so I can figure out how default() works |
| 12:37 | <annevk> | I'm basically going through the bug lists for specs I maintain at the moment to make sure I can actually handle it all |
| 12:37 | <JakeA> | annevk: I'm worried we all have a slightly different idea on what default() does |
| 12:38 | <annevk> | JakeA: agreed (which is why I wanted to go through it in detail at the meeting) |
| 12:38 | <annevk> | JakeA: but we can have another meeting at some point, maybe in Europe this time |
| 12:38 | <annevk> | JakeA: in fact, how about ZĆ¼rich |
| 12:38 | <JakeA> | agreed |
| 12:38 | <JakeA> | ohh, that could work |
| 12:39 | <JakeA> | I'm fine going out there, although it's a lot easier for me than the others |
| 12:39 | <JakeA> | annevk: having said that, I'm going to be in SF for Google I/O |
| 12:39 | <annevk> | no rush, ZĆ¼rich works great for tobie too |
| 12:40 | <JakeA> | Sounds good. Never been to ZĆ¼rich |
| 13:03 | <annevk> | MikeSmith: I filed another issue with UTS46 this time asking more explicitly for them to define a syntax for domain names |
| 13:03 | <annevk> | MikeSmith: hasn't entered the public record yet I think |
| 13:05 | <annevk> | MikeSmith: it will probably end up here: http://www.unicode.org/review/pri264/feedback.html |
| 13:22 | <MikeSmith> | annevk: excellente |
| 13:23 | <MikeSmith> | annevk: "I suggest carefully reviewing the diffs."? |
| 13:23 | <MikeSmith> | who's he suggesting should review the diffs? |
| 13:24 | <MikeSmith> | oh nm |
| 13:24 | <annevk> | MikeSmith: yeah I got confused too, but that's not a reply but a separate piece of feedback :) |
| 13:24 | <MikeSmith> | yeah, I thought at first that was a response to your report |
| 13:26 | <annevk> | MikeSmith: https://gist.github.com/annevk/5465e886cf7c45db8a1d is my feedback |
| 13:28 | MikeSmith | looks |
| 13:33 | <MikeSmith> | annevk: yeah for error messages that get emitted by checkers it would really help to have a declarative description to point to |
| 14:07 | <zewt> | annevk: i wasn't expecting this, but XHR in FF with blob urls seems to do exactly what we ended up with, grabbing the blob at open() (at least in a very simple test) |
| 14:08 | <zewt> | don't know if it works in all cases (hard to test fully without some hack to force GC) |
| 14:08 | <annevk> | zewt: except per sicking Gecko doesn't do parse/fetch distinction |
| 14:08 | <annevk> | zewt: though on the other hand that'd be weird if you passed in an HTTP URL... |
| 14:08 | <zewt> | http://zewt.org/~glenn/test-grabbing-blob-url-references.html this passes in firefox, fails in chrome |
| 14:09 | <annevk> | zewt: you should submit some stuff to the platform test thingie, that's great |
| 14:09 | <zewt> | though chrome fails weirdly, it runs onload (not onerror) |
| 14:09 | <annevk> | zewt: thanks for helping us out arriving at a somewhat sane solution there |
| 14:09 | annevk | still really dislikes blob URLs |
| 14:10 | <zewt> | hopefully if this blob URL thing gets traction we can then make the auto-revoke thing happen properly, and they'll be a lot saner, at least for users |
| 14:11 | <zewt> | hmm, actually if this stuff is implemented, then you could polyfill auto-revoke with just createAutoRevokeBlob = function(blob) { var url = URL.createObjectURL(url); setTimeout(function() { URL.revokeObjectURL(url); }, 0); return url; }; |
| 14:25 | <Domenic> | annevk: wait, that is your feedback to them? Isn't the URL standard the most non-grammary thing around? |
| 14:25 | <annevk> | Domenic: I define the value space of schemes and things like that |
| 14:25 | <annevk> | Domenic: i.e. the syntax |
| 14:27 | <zewt> | annevk: i was sad when I did new URL("custom-scheme://host.com/path";) and everything but the scheme ended up in pathname :( |
| 14:27 | <zewt> | (in Chrome, didn't check if that's what the spec says) |
| 14:27 | <annevk> | zewt: URLs are sad |
| 14:27 | <zewt> | means I still have to carry around my own URL parser... |
| 14:27 | <jgraham> | zewt: http://hoppipolla.co.uk/410/xhr_blob.html fwiw (your test adapted to testharness.js format but with full domain names which will need to be removed for a PR) |
| 14:28 | <zewt> | jgraham: cool |
| 14:29 | <zewt> | jgraham: 2-space indentation is unreadable, though |
| 14:30 | <jgraham> | Yeah, it's not ideal. Do you want to turn this into a real PR or should I? |
| 14:30 | <zewt> | i don't know where they go (and I have to head to work at the moment) |
| 14:31 | <jgraham> | OK, I can do it |
| 14:31 | <zewt> | does it assume the test is done if any assertion fails? |
| 14:31 | <jgraham> | Yes |
| 14:32 | <zewt> | so if there was an assertion in a progress event or something, it'd need to be careful (since it would think the test is done when something is still running) |
| 14:32 | <zewt> | cool, just understanding the lifecycle |
| 14:33 | <zewt> | afk |
| 14:35 | <annevk> | jgraham: yay |
| 14:43 | <annevk> | Hahaha, https://twitter.com/g16n/status/469104662092992512 accusing Hixie of reusing <br> rather than <l> from XHTML2 on the basis of NIH |
| 14:43 | <annevk> | People are silly |
| 14:49 | <jgraham> | zewt: https://github.com/w3c/web-platform-tests/pull/1004 |
| 14:57 | <Ms2ger> | annevk, no, NHI |
| 14:57 | <annevk> | Ms2ger: oh, well then it makes perfect sense |
| 15:00 | <annevk> | Domenic: mathiasbynens: Hixie: https://gist.github.com/annevk/3db3fbda2b95e5ae9427 |
| 15:05 | <Domenic> | well, at least emotion markup is now fully covered by patent commitments. |
| 15:07 | <annevk> | Wait what? |
| 15:08 | <annevk> | Domenic: ooh, "No patent disclosures have been made for any specifications of this group." |
| 15:08 | <annevk> | Domenic: I thought this was much more hilarious/sad |
| 15:09 | <annevk> | They managed to create a namespace even more ugly than the HTML namespace. That's talent. |
| 15:09 | <Domenic> | it's a Rec; isn't that ever spec's dream? |
| 15:11 | <annevk> | I'm not proud http://www.w3.org/TR/css3-namespace/ |
| 15:12 | <annevk> | Oh, seems Elika moved me to Former Editors while editing the document in place |
| 15:12 | <annevk> | "edited in place" isn't quite what it used to mean I guess |
| 15:28 | <Domenic> | annevk: I don't understand the use case for https://www.w3.org/Bugs/Public/show_bug.cgi?id=22343 |
| 15:29 | <Ms2ger> | annevk, I thought replacing WebIDL was more of a TC39 -> platform request? |
| 15:32 | <jgraham> | It's very unclear to me why the solution to "specification is undermaintained" is "start new specification from scratch" |
| 15:32 | <annevk> | Domenic: I'm not sure either, I think it's a hack around custom elements not being based upon subclassing |
| 16:00 | <annevk> | TabAtkins: https://gist.github.com/annevk/3db3fbda2b95e5ae9427 |
| 17:09 | <arunranga> | annevk, do you think the Blob URL store should not be per unit of similar origin browsing contexts, to allow tainted cross-origin requests? |
| 17:15 | <arunranga> | annevk, canāt think of how else to solve this for multi-process cross origin uses. |
| 17:18 | <Domenic> | annevk: bigints |
| 17:18 | <annevk> | Domenic: specifically for crypto? |
| 17:19 | <annevk> | arunranga: I think I'm in the camp that wants blob URLs to be origin-restricted now |
| 17:19 | <annevk> | arunranga: limiting their harm seems good |
| 17:19 | <Domenic> | annevk: probably not |
| 17:19 | <annevk> | Domenic: if it's not for crypto doesn't seem that important |
| 17:20 | <arunranga> | annevk, that would make things straightforward, since then we have all the pieces solved. |
| 17:20 | <annevk> | arunranga: apart from data URLs, but I guess that's not your problem |
| 17:21 | <Domenic> | annevk: ok, how about: a better cohesive story about error typing and detection |
| 17:21 | <arunranga> | annevk, yeah, the data URL problem seems hard, since 2007ās demonstrated hack |
| 17:22 | <arunranga> | annevk, cool, Iāll have an update that solves some of the bugs you logged and ping you for review. |
| 17:22 | <annevk> | Domenic: adding |
| 17:27 | <annevk> | JakeA: I guess like you need to understand Fetch, I need to study those SW algorithms a bit more |
| 17:27 | <annevk> | JakeA: will get back to you tomorrow |
| 17:36 | <IZh> | Is there a guarantee that media.fastSeek will not jump after desired position? |
| 17:40 | <annevk> | Hmm, HTML imports reached beta |
| 17:43 | <JakeA> | annevk: those are the bits I know pretty well, so feel free to bug me |
| 17:43 | <JakeA> | (The SW thing, not the imports) |
| 18:16 | <Hixie> | annevk: if we're really gonna have to spec this event handling behaviour (which is really sad, i thought we'd eradicated that a few years ago), then i think the way to do it is for DOM to add a step before step 10 that invokes "the legacy event handler defined by the specification that defines the target, if any" on the target node |
| 18:20 | <annevk> | Hixie: many tears will be shed over that commit |
| 18:20 | <Hixie> | yeah no kidding |
| 18:20 | <Hixie> | i'm still skeptical it's actually required for compat |
| 18:21 | <Hixie> | maybe we can limit it to quirks mode or something, that's why i want to see urls |
| 18:21 | <annevk> | I think sicking might still be in our camp, but he obviously has no time to clean this up, maybe arv_ can find some free time |
| 18:22 | <Ms2ger> | Which? |
| 18:23 | <annevk> | Ms2ger: read https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230 and weep |
| 18:24 | <Ms2ger> | :/ |
| 18:25 | <sicking> | yeah, this is a pretty terrible setup |
| 18:25 | <sicking> | iirc there's quite a few events that cause actions to happen |
| 18:26 | <sicking> | i believe firing a "click" event (or maybe just some mouse events) on a <a> will also follow the link |
| 18:26 | <sicking> | I think Smaug was in favor of this behavior. I'm not sure if he still is |
| 18:27 | <sicking> | I really dislike it |
| 18:27 | <Hixie> | yeah it's pretty terrible and makes no sense, imho |
| 18:27 | <Hixie> | hoenstly i thought we'd eradicated it years ago |
| 18:27 | <Hixie> | otherwise i would have long specced it |
| 18:27 | <sicking> | oh hey, look at that, i've commented in the bug saying that :) |
| 18:28 | <sicking> | i think the way to go about it would be to get a group of implementers together and discuss |
| 18:28 | <sicking> | and then add telemetry |
| 18:28 | <sicking> | maybe telemetry would be the first step actually |
| 18:29 | smaug____ | doesn't like the click behavior |
| 18:29 | <JonathanNeal> | Anyone here familiar with css matrix3d? |
| 18:29 | <Hixie> | i'd really like to know quite how widespread this behaviour is (in terms of what events on what targets can do something) and what pages depend on it |
| 18:30 | <Hixie> | i feel like i've just discovered ants in my bathroom and i'm not sure if it's a stray or if i have a nest in my walls |
| 18:30 | <sicking> | get Chrome and Gecko to add telemetry |
| 18:31 | <smaug____> | IIRC I broke quite a few web sites when synthetic click didn't cause link to be followed |
| 18:31 | <sicking> | sads |
| 18:32 | <sicking> | smaug____: did .click() still work when you made that change? |
| 18:33 | <smaug____> | IIRC there were to separate regressions |
| 18:33 | <Hixie> | i'm amazed that pages use dispatchEvent() |
| 18:33 | <smaug____> | s/to/two/ |
| 18:34 | <smaug____> | I probably broke click, but dispatchEvent case was also needed to work |
| 18:34 | <smaug____> | and all the browsers do handle that case the same way |
| 18:34 | <sicking> | i still think it'd be interesting to get telemetry |
| 18:35 | <sicking> | things might have change since then. Either for the better or for the worse |
| 18:35 | <smaug____> | yup |
| 18:35 | smaug____ | files a bug |
| 18:35 | <sicking> | hopefully heycam will finish the telemetry infrastructure he's working on at some point |
| 18:35 | <Ms2ger> | When is he getting back? |
| 18:35 | <sicking> | right now it's kind of a pain for us to gather data on how much a specific web feature is used as I understand it |
| 18:35 | <sicking> | (I don't understand why though) |
| 18:36 | <sicking> | Ms2ger: no idea |
| 18:36 | <Ms2ger> | 1 June, apparently |
| 18:36 | <sicking> | Ms2ger: also, when will you finish the 'id'/'class' bug? :) |
| 18:36 | <Ms2ger> | Ah, that |
| 18:36 | <Ms2ger> | Last time I think one of the B2G desktop builds failed with GetClassNameW things |
| 18:37 | <Ms2ger> | I need to check if that still happens |
| 18:37 | <sicking> | didn't Ehsan fix that for you long long ago? |
| 18:37 | <ehsan> | I did |
| 18:37 | <Ms2ger> | No, that was desktop Windows |
| 18:37 | <ehsan> | Ms2ger: still hitting issues? |
| 18:37 | <Ms2ger> | Perhaps |
| 18:37 | <sicking> | Ms2ger: my concern is that the longer we wait, the less likely it is that we can do it |
| 18:37 | <Ms2ger> | I'll push to try and see if it magically fixed itself |
| 18:38 | <Ms2ger> | sicking, yeah, fair |
| 18:38 | <sicking> | iirc there were some review comments too |
| 18:38 | <Ms2ger> | Too many balls in the air :/ |
| 18:38 | <sicking> | but i didn't look at what they were |
| 18:38 | <sicking> | Ms2ger: if there are still build issues, paste a build error in the bug |
| 18:38 | <Ms2ger> | Yep, will do |
| 18:39 | <ehsan> | Ms2ger: also ping me if you needed help |
| 18:39 | <zcorpan> | MikeSmith: i got a reply from github to check out [1] http://developer.github.com/v3/#pagination |
| 18:39 | <Ms2ger> | And now you distracted from fixing that bug for bz... |
| 18:40 | <zcorpan> | MikeSmith: so fetch the urls in Link: also |
| 18:40 | <zcorpan> | MikeSmith: this is about w3c-test:mirror script not picking me up as collaborator |
| 18:41 | <zcorpan> | or maybe &per_page=1000 works |
| 18:43 | <Ms2ger> | It's clamped to 100, AIUI |
| 18:43 | <Ms2ger> | And I thought denis fixed that |
| 18:49 | <Ms2ger> | sicking, ehsan, alright, rebasing... |
| 18:49 | <sicking> | Ms2ger: thanks! |
| 18:52 | <Hixie> | annevk: 500 from tracker |
| 19:05 | <ehsan> | Ms2ger: /me holds breath |
| 19:05 | <Ms2ger> | Don't, our builds aren't that fast ;) |
| 19:06 | <ehsan> | lol |
| 19:07 | <Ms2ger> | And I haven't built locally, so... ;) |
| 19:24 | <TabAtkins> | annevk: What was that gist about? |
| 19:56 | <odinho> | Can anyone quickly review some IndexedDB prev cursor? => https://critic.hoppipolla.co.uk/r/1621 |
| 20:37 | <IZh> | Does html5 support 3D videos? |
| 20:37 | <annevk> | TabAtkins: see title of it |
| 20:37 | <Hixie> | html (not html5, we dropped the version number years ago) is agnostic to the exact video codec used |
| 20:39 | <IZh> | I mean, often there are no any marks in the video stream itself that it is 3D. Even hardware players needs a hint from human to figure what type of encoding is used -- top-bottom halves of the frame or left-right. |
| 20:40 | <IZh> | So the the player needs to be told in some way that this url points to 3D video, for example, with top-bottom frames encoding. |
| 20:41 | <IZh> | Because often a 3D video could be played just as ordinary 2D. There are no special file formats for it, as I know. |
| 20:43 | <IZh> | So the browser itself can't guess whether it is a 3D-file or not. Probably some parameter is needed. |
| 20:44 | <Hixie> | there's nothing like that in html currently |
| 20:45 | <odinho> | But there is a bug about showing more metadata waiting for vendor feedback. :] |
| 20:46 | <IZh> | And it's hard to stick this parameter to a particular codec because 3D video can be incoded with any codec. |
| 20:50 | <IZh> | Currently there are following encoding that I know: squize left and right frame horizontally (and expand while playing), the same but vertically. These are most used variants. Also it's possible to interleave left and right frames, use double sized frame (left-right or top-bottom) and use 2 separate video streams. All these things could be put to ordinary file. That's why some metadata needed. |
| 20:50 | <IZh> | Squize = squeeze |
| 20:51 | <Hixie> | Domenic: if a promise gets garbage collected, does it reject, or just do nothing forever? |
| 20:54 | <Hixie> | man, a lot of the code i'm seeing where people use promises to show how simple things are with promises are... not simple |
| 20:55 | <Hixie> | lots of reducing and chaining callbacks and code of the form blabla(very-long-lambda-that-spans-many-lines, anotherargument) |
| 20:56 | <zewt> | lambdas have no place in any language with inline functions (javascript) |
| 20:56 | <Hixie> | how are those not the same thing |
| 20:57 | <zewt> | lambdas are just a dumb restricted form of inline functions, no point in having them if you have real inline functions |
| 20:57 | <Philip`> | Do you mean Python-style lambdas where there's a distinction between expressions and statements, and lambdas can only contain expressions? |
| 20:57 | <jgraham> | Isn't that just python's "lambda" rather than lambdas in general? |
| 20:58 | <Hixie> | ok well i just meant an inline function |
| 20:58 | <zewt> | most "promises" examples I see are very unobvious to me, which makes me nervous about them |
| 20:58 | <annevk> | smaug____: what's the bug ID? |
| 20:58 | <Philip`> | (Proper languages don't have that restriction) |
| 20:58 | <annevk> | smaug____: for the synthetic events thing you filed earlier |
| 20:58 | <jgraham> | Oh, it's Philip` |
| 20:58 | <Hixie> | (wikipedia seems to agree with my usage of the term, fwiw) |
| 20:58 | <Philip`> | jgraham: That's statistically unlikely |
| 20:59 | <zewt> | "lambda" in programming languages means "an inline function that's just a single expression", eg. function(args) { return %1; } |
| 20:59 | <zewt> | anyway |
| 20:59 | <jgraham> | Philip`: I think we need P(Philip`|data) rather than just p(Philip`) |
| 20:59 | <Hixie> | not according to wikipedia... |
| 20:59 | <zewt> | wikipedia is wrong, then |
| 21:00 | <smaug____> | annevk: https://bugzilla.mozilla.org/show_bug.cgi?id=1014762 |
| 21:01 | <jgraham> | I'm pretty sure that "lambda" is just a fancy word for "anonymous function" that makes people feel like they are doing abstract mathematics when in fact they ae just writing yet another DOM wrapper library (or something) |
| 21:01 | <Hixie> | i'm not finding anything that supports limiting lambdas to just an expression, except in lambda calculus, where everything is just an expression anyway. |
| 21:02 | <Philip`> | zewt: So C++11 lambda expressions and Java lambda expressions are not lambdas, because you can put multiple statements in them? |
| 21:02 | <Hixie> | also i've now officially read the word "lambda" too many times in a row and it's lost its meaning and looks silly. |
| 21:03 | <zewt> | Philip`: "anonymous functions being called the wrong thing" |
| 21:03 | <zewt> | Hixie: it looks pretty silly to start with... |
| 21:03 | <annevk> | I guess I need to find some time to write a better web-apps-tracker :/ |
| 21:03 | <annevk> | I wish someone would take over, but apparently nobody is annoyed enough |
| 21:05 | <Hixie> | so what's the state of the art with JS modules these days |
| 21:05 | <Hixie> | is there something that makes sense yet? |
| 21:05 | <Hixie> | is there something i can integrate with yet? |
| 21:06 | <annevk> | Hixie: I would wait until browsers start implementing |
| 21:06 | <annevk> | Hixie: the spec only recently "finished" |
| 21:06 | <zewt> | (grr: building in Unity takes a couple minutes, and when I tab over to IRC because I'm twiddling my thumbs waiting, Xcode steals focus 4-5 times during the build process) |
| 21:06 | <Hixie> | annevk: oh there's something that people think is finished? where? i couldn't find any recent links. |
| 21:07 | <zewt> | (then something I'm typing on IRC gets vomited into a source file, breaking the build) |
| 21:07 | <annevk> | Hixie: oh it seems ES6 still has some todos |
| 21:07 | <Hixie> | is one of those todos "tell hixie about it" |
| 21:07 | <annevk> | Hixie: there's also https://people.mozilla.org/~jorendorff/js-loaders/Loader.html |
| 21:07 | <annevk> | Hixie: not sure |
| 21:08 | <jorendorff> | what don't look at that |
| 21:08 | <zewt> | W:D |
| 21:08 | <jorendorff> | Hixie, annevk: well, for your purposes actually it's not *that* terrible |
| 21:09 | <Hixie> | i'm hoping it's not terrible at all :-) |
| 21:09 | <jorendorff> | but expect bugs and api changes |
| 21:09 | <Hixie> | i just want to know how to integrate it with my <script> preloading/dependency stuff, and <script type=module> and so forth. |
| 21:09 | <Hixie> | not to mention html imports |
| 21:10 | <Hixie> | cos i don't want to end up with two or three entirely separate dependency chain management systems on the web |
| 21:10 | <jorendorff> | uh huh |
| 21:10 | <Hixie> | which right now seems to be where we're headed |
| 21:10 | <jorendorff> | well, this Loader stuff is definitely async depenedency chain management |
| 21:14 | <jorendorff> | Hixie: do you want a primer or would you rather read that code |
| 21:14 | <annevk> | nn |
| 21:14 | <Hixie> | jorendorff: i'd rather read a spec |
| 21:14 | <Hixie> | if there is one |
| 21:15 | <jorendorff> | Hixie: it's in the ES6 spec but afaict totally unreadable |
| 21:15 | <jorendorff> | it's impossible to tell what's going on |
| 21:15 | <Hixie> | well that's encouraging |
| 21:15 | <Hixie> | if you have a moment, i can ask you some questions |
| 21:15 | <jorendorff> | I do |
| 21:15 | <Ms2ger> | jorendorff, you're repeating yourself ;) |
| 21:16 | <Hixie> | the first one would be, "what are the use cases that this thing is for?" |
| 21:16 | <Hixie> | like, what is the space that "Modules" are intended to address? |
| 21:18 | <Ms2ger> | Consensus |
| 21:18 | <jorendorff> | Hixie: so the champions are dave herman and sam tobin-hochstadt and you should ask those guys; the use case I care about is "like require.js but with better syntax" |
| 21:19 | <jorendorff> | it's for getting JS into a web page, |
| 21:19 | <jorendorff> | in such a way that you can separately configure where it's loading from / how it's loading |
| 21:19 | <jorendorff> | changing deployment without having to change your code |
| 21:19 | <Hixie> | how do you mean "where" and "how"? |
| 21:20 | <jorendorff> | related |
| 21:20 | <jorendorff> | what protocol, what file format |
| 21:20 | <zewt> | jorendorff: eg. "switch from loading jquery-1.2.3.js from the jquery website to our trusted bucket on S3"? |
| 21:20 | <Hixie> | file format? |
| 21:20 | <jorendorff> | yep |
| 21:20 | <Hixie> | like, javascript vs dart? |
| 21:20 | <jorendorff> | Hixie: i meant "hundreds of .js files vs. a single zip file" |
| 21:20 | <jorendorff> | but the module system also has a hook for different languages |
| 21:21 | <Hixie> | js modules supports sending files as zip files? |
| 21:21 | <zewt> | (hope not, that's the wrong layer for that) |
| 21:21 | <Hixie> | that seems like an odd place to fix that problem... |
| 21:21 | <jorendorff> | Hixie: not natively, but the part of the module system where we load code is literally just a fetch hook |
| 21:21 | <jorendorff> | which we call |
| 21:21 | <zewt> | (better) |
| 21:21 | <Hixie> | ok, hold on |
| 21:21 | <jorendorff> | and it returns a promise for the code |
| 21:21 | <Hixie> | let's try this from a different angle. |
| 21:22 | <Hixie> | what does modules provide? |
| 21:22 | <Hixie> | cos what you've described so far seems redundant with <script> and service workers. :-) |
| 21:22 | <jorendorff> | import/export syntax, an object model for Modules, and an API for loading them |
| 21:23 | <zewt> | (seems strange to add *syntax* for something like this) |
| 21:23 | <Hixie> | tell me more about this API |
| 21:23 | <TabAtkins> | The main use case to me is fixing the "there's no way for a script to include another script sanely" problem. |
| 21:23 | <zewt> | (it'd probably keep anyone from using it for years, since syntax is hard or impossible to polyfill) |
| 21:24 | <Hixie> | is there really not a spec i can look at for this |
| 21:24 | <TabAtkins> | You have to either bake all the script files you need into your html, or use a preprocessor to manually include them, or use s library like require.js |
| 21:25 | <jorendorff> | Hixie: ES6, search for Reflect.Loader |
| 21:25 | <TabAtkins> | annevk: I got the title, yes. Why did you name-mention me with it, though? |
| 21:26 | <Hixie> | "The initialize value of Reflect.Loader is the %Loader% intrinsic object." |
| 21:26 | <Hixie> | man you're right, this is worse than html |
| 21:26 | <Ms2ger> | They particularly like their weird characters |
| 21:26 | <zewt> | D: |
| 21:27 | <Hixie> | "The @@create method of a Reflect.Loader function object F performs the following steps: [...] 2. Let obj be the result of calling OrdinaryCreateFromConstructor(F, "%LoaderPrototype%", ([[LoaderRecord]]))." |
| 21:27 | <jorendorff> | it's all microcode |
| 21:27 | <Ms2ger> | Bingo! |
| 21:27 | <Ms2ger> | jorendorff, it's microperl |
| 21:27 | <jorendorff> | ReturnIfAbrupt everywhere |
| 21:28 | <jorendorff> | even in perl you could `die` |
| 21:28 | <Hixie> | well ok this didn't help. bummer. |
| 21:28 | <Hixie> | are there like, examples somewhere? |
| 21:28 | <zewt> | Hixie: i have to worry that these are the people making syntax changes to JS... |
| 21:28 | <Hixie> | zewt: i'm sure it makes sense to JS implementors |
| 21:28 | <Hixie> | zewt: i mean, the HTML spec often looks the same way when i'm first writing a section |
| 21:28 | <jorendorff> | zewt: That is just random snark |
| 21:29 | <Ms2ger> | Random snark is what #whatwg is known for :) |
| 21:29 | <zewt> | nope, it isn't |
| 21:29 | <Hixie> | i mean, i have concerns over were js is going, but this isn't why :-) |
| 21:29 | <zewt> | it's "if someone likes this as a syntax, keep their hands off of the JS syntax" |
| 21:29 | <Hixie> | nah, that's not fair |
| 21:30 | <jorendorff> | zewt: but the person deciding how the spec is written is the editor, and the people deciding how JS looks is the committee |
| 21:30 | <Hixie> | an architect might be terrible at building things with wood and nails, but still design beautiful houses |
| 21:30 | <Hixie> | i really don't have a clue what this spec is telling me though |
| 21:31 | <jorendorff> | Hixie: please talk to yehuda katz |
| 21:31 | <Ms2ger> | wycats, ^ |
| 21:33 | <Hixie> | this module system is all done in JS itself, right |
| 21:33 | <jorendorff> | Hixie: there are two ways for JS code to ask for other JS code. syntax and API. The syntax is import-declarations. The API is mostly just Reflect.Loader.{define,import}. |
| 21:33 | <jorendorff> | Hixie: we're going to self-host it, yeah |
| 21:33 | <Hixie> | so there's no way for a module to have declared dependencies before it's started executing? |
| 21:34 | <jorendorff> | Hixie: the syntax is declarative |
| 21:34 | <jorendorff> | and only declarative |
| 21:34 | <Hixie> | but you have to be parsing it before you know of the dependencies |
| 21:34 | <jorendorff> | Hixie: I don't understand, what sort of alternative do you have in mind? |
| 21:34 | <Hixie> | it doesn't have an equivalent of <script src=a.js></script> <script src=b.js needs=a.js> |
| 21:35 | <Hixie> | where even before you've contacted the server for b.js, you know you need to first fetch a.js |
| 21:36 | <jorendorff> | the JS equivalent would be something like import a from "a"; import b from "b"; |
| 21:36 | <jorendorff> | not sure what the needs= thing is trying to say |
| 21:37 | <Hixie> | needs="" says "before you execute me, make sure you've executed that other thing" |
| 21:37 | <jorendorff> | imports do that |
| 21:38 | <Hixie> | but if b says "import a from 'a'", and you just have <script src=a.js></script> <script src=b.js></script>, you have no way to know that b needs a before b has been downloaded, right? |
| 21:39 | <jorendorff> | b doesn't start executing until after it has been parsed though |
| 21:39 | <JonathanNeal> | Iām about to make another post on specifiction about SVG files and would love any preliminary feedback before I post. https://gist.github.com/jonathantneal/1fc6a43f4fa8f448a368 |
| 21:39 | <zewt> | jorendorff: but if it does it *within* the script itself, you have to download the script before you can start downloading its dependencies, which would kill page load performance |
| 21:39 | <Hixie> | jorendorff: sure |
| 21:39 | <jorendorff> | as code comes in off the network, you parse it and see what else it needs; maybe you've already got it, maybe it's already loading, maybe you've never heard of it until now |
| 21:39 | <zewt> | right, that means no pipelining, which means terrible performance |
| 21:39 | <Hixie> | jorendorff: right but if you're trying to not download code that you don't need, that doesn't work |
| 21:40 | <jorendorff> | I still don't understand what needs= is doing |
| 21:41 | <Hixie> | jorendorff: say that A is used by B and D, and B is used by C, and you don't want to download anything you don't need, and then suddenly you find you need C. You tell C to execute, and the browser immediately downloads A, B, and C, and executes them in that order once it's got them. |
| 21:41 | <Hixie> | jorendorff: and then later you find you need D, and A's already executed so it's left alone, but D needs to be downloaded and executed and so that happens. |
| 21:42 | <Hixie> | jorendorff: do modules have a way to say what will need to be executed when you find you need C, without previously having downloaded A, B, C, or D? |
| 21:42 | <Hixie> | s/executed/downloaded and executed/ |
| 21:43 | <jorendorff> | Hixie: let me make sure i understand first -- <script src=b.js needs=a.js></script> means *don't* load b.js yet? |
| 21:43 | <Hixie> | jorendorff: well it doesn't mean anything precise yet. the exact syntax for the example i gave in the old proposal i had last year was more like <script src=b.js needs=a.js whenneeded> |
| 21:44 | <Hixie> | jorendorff: but i expect if a proposal comes out of this it will be different again |
| 21:44 | <jorendorff> | k |
| 21:44 | <Hixie> | jorendorff: the key is just having the dependency chain defined outside the script |
| 21:44 | <jorendorff> | huh... the people we spoke to -- and i'm not a web dev, so, who knows -- but the web devs we talked to wanted the opposite, they wanted to push the code they knew the client needed |
| 21:44 | <jorendorff> | eagerly |
| 21:45 | <Hixie> | oh i have people who've asked for every possible combination possible |
| 21:45 | <jorendorff> | so that later, when someone did .import("C"), there was the best chance of its already having been loaded |
| 21:45 | <Hixie> | i'm currently dealing with use cases labeled "L" through "Z" |
| 21:45 | <Hixie> | that's how many there are :-) |
| 21:45 | <zewt> | jorendorff: the "needs" mechanism allows that, the key difference is it lets you start downloading any or all of the dependencies without earlier deps needing to be fetched already |
| 21:45 | <jorendorff> | then there were the people who were like "HTTP2, therefore your argument is invalid" |
| 21:45 | <Hixie> | jorendorff: so the short answer is no? |
| 21:46 | <jorendorff> | Hixie: yeah, it's a no. the hooks are there so you could add it as a library, but no |
| 21:46 | <Hixie> | jorendorff: is there a way I can hook into the module system to provide this data from the needs="" attribute? |
| 21:46 | <jorendorff> | Hixie: yeah, lemme think |
| 21:46 | <zewt> | Hixie: yeah, i can see the value of being able to declare dependencies within scripts... depends on whether you care more about pipelining performance or encapsulation, I guess |
| 21:47 | <zewt> | most people probably care about both, but they seem like incompatible goals... |
| 21:47 | <jorendorff> | zewt: but if you know the dependency tree, it's trivial to just ask for everything you're going to need |
| 21:48 | <jorendorff> | also, if you have the dependencies in the code, you can extract them statically if you want to do stuff |
| 21:48 | <zewt> | jorendorff: where would you learn the dependency tree, if that lives inside the scripts themselves? that's exactly what "needs" is doing |
| 21:48 | <jorendorff> | zewt: needs isn't doing that for web developers, it's providing a way for them to express that information -- which they must figure out themselves somehow |
| 21:49 | <jorendorff> | right? |
| 21:49 | <zewt> | i guess you could use both: declare your real dependencies inside the script, then have your profiler/validator/whatever tell you "here are the dependencies you should add to your <script> to make this faster" |
| 21:49 | <jorendorff> | the dependencies themselves are always in the code... |
| 21:49 | <zewt> | jorendorff: in the previous @needs proposal, there were no dependencies in the code at all--@needs *was* the dependency declaration |
| 21:50 | <zewt> | (which again, means you lose encapsulation) |
| 21:50 | <jorendorff> | zewt: no i mean as a plain fact of life, dependencies are where one bit of code depends on another, and that's in the code |
| 21:50 | <zewt> | jorendorff: that's the underlying requirement, but the "dependencies" we're discussing are dependency declarations |
| 21:50 | <jsbell> | odinho: just saw your ping about idb prev cursor - looking now |
| 21:51 | <jorendorff> | Hixie: sorry, distracted. the loader pipeline is all exposed, it's a series of hooks that the Loader calls |
| 21:51 | <Hixie> | jorendorff: does the loader do any dependency management? |
| 21:52 | <jsbell> | odinho: Not that I have any magic status, but I can sanity check at least :) |
| 21:52 | <Hixie> | jorendorff: i'd like for there to be one piece of code in the web platform that knows to dispatch requests and so on based on dependencies, that supports HTML Imports, <script needs>, JS modules, and anything else we add later |
| 21:52 | <jorendorff> | Hixie: that sounds good, and Loader isn't it in the do-one-thing-do-it-well sense |
| 21:52 | <jorendorff> | Hixie: you can't tell a Loader what dependencies are in advance; but |
| 21:53 | <jorendorff> | Hixie: if you know what they are, your fetch() hook can say, ah, i see he is fetching C, I happen to know it'll need A and B, so let me just call this.import("A") and this.import("B") |
| 21:53 | <jorendorff> | which will get those started loading too |
| 21:54 | <odinho> | jsbell: Ahh, that's awesome Joshua :D |
| 21:54 | <zewt> | i imagine you'd want to be able to find out all of the dependencies in advance, even if some aren't being fetched yet? |
| 21:55 | <Hixie> | jorendorff: but there's no way i can also say "btw, if anything tells you to load A, can you tell me to load this image over here and that style sheet over there"? |
| 21:55 | <odinho> | jsbell: Was looking for a test to show Marc, but saw that it didn't exist. So thought I'd just quickly create one. |
| 21:55 | <jorendorff> | Hixie: no, nothing like that |
| 21:55 | <jorendorff> | just the hooks |
| 21:56 | <Hixie> | jorendorff: any chance we can move the logic out of JS so that JS hooks into a system that _does_ provide all that? |
| 21:56 | <JonathanNeal> | Well, if any of you have started using SVGs, Iāve prompted discussion to simplify the markup http://discourse.specifiction.org/t/simple-svg-markup/92 https://twitter.com/jon_neal/status/469597460793262080 |
| 21:56 | <jsbell> | odinho: Yeah, I made a jsfiddle but then it wasn't loading in FF for some reason. Did you notice any failures in any browsers? |
| 21:56 | <jorendorff> | Hixie: personally I don't have the weight to give you an answer to that |
| 21:56 | <jorendorff> | Hixie: sounds lovely to me |
| 21:57 | <odinho> | jsbell: Only have Opera, Chrome and Firefox, -- but passes in all of those. |
| 21:57 | <jorendorff> | Hixie: the problem is the system was designed for loading these JS module things and so it tries not to expose stuff before it has executed and is ready. An image is easier in that it won't have dependencies |
| 21:57 | <jorendorff> | you can expose it before all the other junk is loaded, no problem |
| 21:58 | <Hixie> | jorendorff: well, an image might have dependencies. It could be an SVG file that loads scripts... |
| 21:58 | <odinho> | I'd check the others if I'd been at work with access to non-Linux machines :) |
| 21:58 | <Hixie> | or an HTML import that loads a style sheet that binds a web component that loads scripts that... |
| 21:58 | <zewt> | stylesheets with @imports |
| 21:58 | <jorendorff> | Hixie: yeah, that's totally right, let me think about it a sec |
| 21:58 | <jsbell> | odinho: I recall that continue() in reverse over an index is a bit "odd" but continue() and advance() should match even in that case... so I dunno what Marc was seeing. |
| 22:01 | <Hixie> | dglazkov: btw, the conversation here is relevant to your interests |
| 22:02 | <jorendorff> | Hixie: and is it considered pretty much OK to expose a DOM for an SVG document before its dependencies are done loading? |
| 22:02 | <Ms2ger> | Why not? |
| 22:02 | <jorendorff> | maybe some dependencies, but not others? |
| 22:02 | <jorendorff> | i'm askign |
| 22:02 | <Ms2ger> | You also expose the HTML DOM before dependencies load |
| 22:02 | <jorendorff> | ...before the HTML is even done loading |
| 22:03 | <Ms2ger> | Yep |
| 22:03 | <jorendorff> | what i'm asking is kind of, is that a decision we're stuck with rather than a design principle to carry forward |
| 22:03 | <Hixie> | jorendorff: i imagine there are people who'd want it one way, and people who'd want it the other. i plan to support both. |
| 22:04 | <jsbell> | odinho: anyway, lgtm |
| 22:06 | <jorendorff> | Hixie: ok, so one thing modules do is, you import stuff by name rather than by URL, so import $ from "jquery"; that "jquery" isn't a URL |
| 22:06 | <Hixie> | jorendorff: fyi, looks like dglazkov actually has a bug on doing this same conversation with the es6 folk, but for integrating web components and es module loading: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25715 |
| 22:07 | <Hixie> | jorendorff: how does it map names to urls? |
| 22:08 | <jorendorff> | depends on the loader. there's a loader.locate() hook that does the mapping. annevk and David Herman were supposed to talk with you and figure out what the default locate() behavior should be in a browser |
| 22:09 | <Hixie> | ah |
| 22:09 | <Hixie> | (i haven't heard anything) |
| 22:09 | <jorendorff> | that was months ago |
| 22:13 | <Hixie> | jorendorff: btw the other question i have is about how modules are exposed in HTML -- is there anything different about script block that's a "module" and one that isn't? does it start with module { ... } or something? |
| 22:13 | <jorendorff> | no, modules are a toplevel concept, and you *can't* concatenate them |
| 22:13 | <jorendorff> | what i mean is, a module is a file |
| 22:13 | <jorendorff> | like python |
| 22:13 | <Hixie> | so it starts with a keyword, like in pascal say? "module foo; ..."? |
| 22:14 | <jorendorff> | the only syntactic difference from a script is that import and export are allowed |
| 22:14 | <Hixie> | ah |
| 22:14 | <Hixie> | how does the browser know to allow import and export then? |
| 22:14 | <Hixie> | or is just everything treated like a module |
| 22:14 | <jorendorff> | http://people.mozilla.org/~jorendorff/es6-draft.html#sec-modules this sort of thing at least is clear in the es spec |
| 22:15 | <jorendorff> | Hixie: has to be type=module or some similar clue |
| 22:15 | <Hixie> | aah |
| 22:15 | <Hixie> | ok |
| 22:15 | <Hixie> | haven't heard anything about that either |
| 22:16 | <Hixie> | (seems weird, why would it not just be inline?) |
| 22:16 | <jorendorff> | it seems weird to me too. |
| 22:17 | <jorendorff> | web developers concatenate js files, sometimes it's the best part of their day, i would have let them keep that |
| 22:17 | <jorendorff> | eh, what do i know |
| 22:19 | <Hixie> | seems very odd that you wouldn't be able to concatenate |
| 22:19 | <Hixie> | i mean, it'll just mean people concatenate them into an html import with multiple <script type=mod> or whatever |
| 22:21 | <jorendorff> | some will use Real Tools, and the provided hooks; some will use SPDY; some will use html imports; there was some noise for a while about urls that point to subresources within a bundle |
| 22:22 | <Hixie> | what's a script that's not a module called? |
| 22:22 | <Hixie> | program? |
| 22:23 | <jorendorff> | yes |
| 22:23 | <zewt> | jorendorff: more like, they'll keep doing it no matter what anyone tels them to do... |
| 22:24 | <zewt> | also, tells |
| 22:25 | <zewt> | (now, if we could get people to stop "minifying"^Wobfuscating scripts...) |
| 22:25 | <jorendorff> | oh, there's also the 80% of web developers who will just do nothing, and get no pipelining benefit whatsoever, just a lazy async graph walk |
| 22:25 | <jorendorff> | and be happy enough with it |
| 22:25 | <jorendorff> | no one concatenates everything |
| 22:26 | <zewt> | well that's a benefit of @needs on its own, the pipelining is built-in (from the developer's perspective) |
| 22:50 | <dglazkov> | Hixie: I think we need a brainmelt with dherman to come up with a coherent strategy for all these cool ideas |
| 22:50 | <dglazkov> | my experience from working with dherman is that he's very easy to work with |
| 23:33 | <Hixie> | annevk: catch me on irc some time soonish to talk about the "cleanup steps" bugs |
| 23:55 | <roc> | who decided that DOMTokenList.toggle should take a 'force' argument which makes it *not* toggle? |
| 23:57 | <zewt> | Hixie: fyi, the spec is significantly slower to load for me in chrome now; don't know if it's something that changed in chrome or something in the spec |
| 23:57 | <zewt> | now after the loading spinner stops, the page scrolls around over a transparent-grid-looking region when I try to scroll, or the tab freezes hard for a while |
| 23:58 | <Hixie> | zewt: i need to work on perf of loading on that page, but generally speaking, file a bug on chrome |
| 23:59 | <zewt> | roc: looks like it just turns it into a badly-named set(value) |
| 23:59 | <zewt> | which is useful, just confusing with that name |