| 00:11 | <abarth> | Hixie_: that's a long bug! |
| 00:11 | <abarth> | Hixie_: you're asking about what URL pattern to use? |
| 00:11 | <abarth> | I think ismap does the comma thing |
| 00:11 | <abarth> | or usemap |
| 00:11 | <abarth> | whichever it is |
| 00:23 | <raj> | the empty value option of a select should have color:#999 just as placeholders do in inputs |
| 01:13 | <Hixie_> | abarth: oops, sorry man. i meant the security bug from earlier. |
| 01:14 | <Hixie_> | abarth: i meant https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701 |
| 01:14 | <Hixie_> | abarth: last comment is all you need to look at, really |
| 01:35 | <Sympa> | Anyone remember someone called 'aspireonescs'? |
| 01:49 | <abarth> | Hixie_: the "Alien Object" thing is problematic |
| 01:49 | <abarth> | at least the definition I read earlier |
| 01:49 | <abarth> | it seems to require magic on the JS side |
| 01:53 | <abarth> | "We're not sure if the last bullet point in particular is enough" <--- it's not |
| 02:04 | <abarth> | Hixie_: I left a more extensive comment on the bug |
| 02:10 | <Hixie_> | abarth: thanks |
| 02:21 | <Hixie_> | abarth: responded |
| 02:40 | <abarth> | Hixie_: I replied on the bug :) |
| 03:43 | <Jasper> | Hixie_, whoops, I swore I removed whatwg@ from the To: field in gmail. |
| 03:43 | <Hixie_> | heh |
| 03:43 | <Hixie_> | no worries :-) |
| 03:43 | <Jasper> | just to see if I could get him to reply back with more crazy |
| 03:45 | <Jasper> | he replied back with "Is hypertext immaterial/imaginary?" |
| 03:45 | <Jasper> | which i guess is as good as i ca nget |
| 04:28 | <niloy> | I am making a webapp, I want to prefetch font and then make the entire page visible, how can I do that? |
| 04:32 | <Hixie_> | don't browsers do that automatically? |
| 04:32 | <Hixie_> | oh you don't want to show _anything_ until you have the font? |
| 04:32 | <niloy> | yes |
| 04:32 | <niloy> | coz it causes that jank |
| 04:33 | <niloy> | with Images, it is possible |
| 04:33 | <Hixie_> | hm, there's some sort of FontLoader API being developed, maybe that would do it |
| 04:33 | <Hixie_> | dunno, sorry |
| 04:34 | <Hixie_> | do fonts delay the main 'load' event? |
| 04:34 | <Hixie_> | i usually have the opposite problem, i want the text to show before the font is there, and then to swap in the font later when it's here... |
| 04:34 | <niloy> | that is good for websites |
| 04:35 | <niloy> | but for webapps, I am happy to show a loader |
| 04:35 | <niloy> | load all the resources, loading the other pages makes no request to server again |
| 04:36 | <niloy> | Example would be a HTML5 game, u dont want to font to load later |
| 04:36 | <Hixie_> | mine our games too :-) |
| 04:36 | <Hixie_> | are, even |
| 04:37 | <niloy> | Oh... that nice, but I hope you agree there is some validity in what am saying |
| 04:37 | <Hixie_> | absolutely |
| 04:38 | <niloy> | About the FontLoader API, why is a specific api being developed, this can be handled just as Images are handled |
| 04:38 | <niloy> | just expose a constructor to JS like Font(), and let us attach a 'load' event to it |
| 04:39 | <niloy> | thats how Images are prefetched |
| 04:40 | <Hixie_> | yeah i dunno, not my area |
| 04:40 | <Hixie_> | annevk-cloud: ping ^ |
| 04:40 | <Hixie_> | or TabAtkins ^ |
| 04:40 | <niloy> | oh okay thanks |
| 07:15 | <MikeSmith> | jdaggett: ↑ |
| 07:20 | <MikeSmith> | jgraham: FYI about HTML imports https://code.google.com/p/chromium/issues/detail?id=306292 and https://code.google.com/p/chromium/issues/detail?id=234509 |
| 07:22 | <MikeSmith> | specific to blink implementation but note Dominic's comment "Custom Elements is blocked on HTML Imports. In general the upgrade ordering problem is quite tricky. Currently it is infeasible", etc. |
| 07:24 | <MikeSmith> | actually maybe not necessarily so implementation-specific but perhaps a problem any implementor is going to run into with the current spec. Or maybe even with any spec for this mechanism at all |
| 07:25 | <MikeSmith> | because I don't see any suggestion in any of the comments about considering a spec change to address the issue |
| 08:02 | <jdaggett> | niloy: fonts are *not* like images |
| 08:02 | <MikeSmith> | Ms2ger: when you've got time can you let me know why the first test at http://w3c-test.org/web-platform-tests/submissions/366/notifications/interfaces.html is failing, and what would need to be fixed to make it pass? (e.g., some fix needed to idlharness.js?) |
| 08:03 | <jdaggett> | niloy: individual fonts are formed into families, each with weight/slope/width properties |
| 08:03 | <Ms2ger> | MikeSmith, in Gecko? |
| 08:03 | <jdaggett> | niloy: layout chooses a particular font based on the style of a given run of text |
| 08:04 | <Ms2ger> | MikeSmith, https://www.w3.org/Bugs/Public/show_bug.cgi?id=23133 |
| 08:04 | <jdaggett> | niloy: that's why loading doesn't follow the paradigm of image loading |
| 08:05 | <jdaggett> | niloy: as for font loads in current browsers, firefox waits for fonts to load, webkit doesn't |
| 08:06 | <jdaggett> | niloy: so for drawing text in canvas you need to use the font loader hacks (e.g. test a given character on timeouts to determine when the font load has completed) |
| 08:06 | <MikeSmith> | Ms2ger: yeah in Gecko. (btw in my workspace I now have all the tests there passing in Gecko except that one) |
| 08:07 | MikeSmith | checks Ms2ger url |
| 08:07 | <Ms2ger> | heycam|away, so that time you'd spend on IDL... :) |
| 08:08 | MikeSmith | finds https://github.com/w3c/testharness.js/issues/26 |
| 08:09 | <MikeSmith> | Ms2ger: so there's been no spec change for this yet? |
| 08:09 | <Ms2ger> | Nope |
| 08:10 | <MikeSmith> | k |
| 08:11 | <MikeSmith> | Ms2ger: thanks |
| 08:12 | <Ms2ger> | Np |
| 08:13 | <MikeSmith> | something for bz to work on before he goes on vacation.. |
| 08:14 | <Ms2ger> | More like time for heycam to start fixing all the stuff we made him promise to fix last weekend :) |
| 08:15 | Ms2ger | wonders why gsnedders is using NN2 |
| 08:17 | <Ms2ger> | MikeSmith, and I'll try to look at your PRs later |
| 08:47 | <annevk> | Where is bholley? |
| 08:47 | <annevk> | When he "cornered" me past weekend about re-parenting we didn't discuss the window.open() case! |
| 08:48 | <annevk> | But maybe doing something else for window.open() is okay? |
| 08:58 | <annevk> | *crickets* |
| 09:02 | <annevk> | http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0173.html is the relevant email |
| 09:02 | <MikeSmith> | annevk: looking at Peter Occil's URL parser I see it's not actually doing any error reporting. It might not be too hard to add error reporting to it. I assume the error=true cases in his code are places that the spec defines as errors. So we could throw an exception there with a message instead of just setting that flag. |
| 09:02 | <annevk> | MikeSmith: or log a message to an error logger |
| 09:02 | <MikeSmith> | or we could just write a URL parser from scratch which maybe also wouldn't be hard to do |
| 09:02 | <annevk> | MikeSmith: so you can log multiple errors |
| 09:03 | <MikeSmith> | yeah |
| 09:09 | <MikeSmith> | though currently the way the microsyntax/datatype checking in the validator is designed, we don't normally emit multiple errors for the same check. i.e., if we're checking an attribute value and find an error at some point we throw and the checking of the rest of value stops. But if we wanted for some case we could buffer the messages and just throw on exception with them at the end of the parsing. I think I may already be doing that in at least one ot |
| 09:09 | <MikeSmith> | anyway |
| 09:22 | <annevk> | MikeSmith: ah okay |
| 09:22 | <annevk> | MikeSmith: you might want to I suppose, makes some sense for style="" too |
| 09:23 | <MikeSmith> | yeah |
| 09:26 | <MikeSmith> | btw the design of the validator is such that we actually need to work from exceptions. We don't really have an eror logger. Or rather the error-logger type of thing that we do have consumes exceptions. We have errors coming from different places -- some internal code, some third-party code -- and we basically package those up as exceptions and feed them to the eror handler. |
| 11:06 | <hellyeah> | hey |
| 11:07 | <hellyeah> | do i need to close non-self ending tag in html like <input> |
| 11:15 | <jgraham> | What do you mean non-self-ending? |
| 11:16 | <hellyeah> | just a sec |
| 11:17 | <hellyeah> | there is a disucssion on the web |
| 11:18 | <hellyeah> | about <input> tag didnt need to be closed in html5 |
| 11:18 | <hellyeah> | but it needs to be closed in html4 |
| 11:18 | <hellyeah> | there is some special tag i believe in html |
| 11:19 | <hellyeah> | original question <xqo> do you need to close input tags? [13:57:12] <xqo> <input /> or just <input>? |
| 11:26 | <jgraham> | The answer is "either is fine, but one is two characters longer for no reason" |
| 11:34 | <odinho> | So, is there some event that has a default action, but it will only run if there is no other handler registered to that event? |
| 11:35 | <odinho> | (e.g., you don't have to do event.preventDefault(), it just automatically prevents when you add a new handler) |
| 11:35 | <odinho> | (yeah, surprising/no-good, but do we have any legacy like that?) |
| 11:42 | <lllllllll> | how can I make video object to show controls? |
| 11:48 | <odinho> | <video controls> |
| 12:39 | <gsnedders> | Ms2ger: Writing about the history of HTML parsers, and wondering how much of the DOM is in NN2. |
| 12:39 | <Ms2ger> | I see |
| 12:39 | <gsnedders> | Ms2ger: NN2 is basically only documented in dead-tree form, and I cannot find the correct dead-trees. |
| 12:41 | <Ms2ger> | Which dead-trees? |
| 12:42 | <Ms2ger> | "Touch Events is a W3C Recommendation" |
| 12:42 | <Ms2ger> | Ehehehehe |
| 12:44 | <gsnedders> | Ms2ger: Those with NN2 manuals on. |
| 12:59 | <jgraham> | gsnedders: Why would you believe the documentation? |
| 13:11 | <Ms2ger> | I don't think I've ever seen someone call ArtB "Bart" before |
| 13:26 | <annevk> | bholley: so what happens in the window.open() case with old Array objects and such? |
| 13:27 | <annevk> | bholley: it seems they too would not change, correct? |
| 13:27 | <bholley> | annevk: correct. non-DOM objects have never moved |
| 13:36 | <Ms2ger> | Promises? |
| 13:57 | <annevk> | bholley: so HTML says a bunch more objects change |
| 13:57 | <bholley> | annevk: hm? |
| 13:57 | <annevk> | bholley: http://www.whatwg.org/C#dom-document-open step 15 |
| 13:58 | bholley | reads |
| 13:58 | <Ms2ger> | annevk, that's such a terrible clause |
| 13:58 | <bholley> | annevk: "new instances" |
| 13:59 | <bholley> | annevk: that doesn't sound like "moving" to me |
| 13:59 | <bholley> | annevk: or maybe I misunderstood |
| 13:59 | <bholley> | annevk: can you elaborate on your concern? |
| 14:01 | <annevk> | bholley: I guess that's different from changing prototype indeed |
| 14:01 | <annevk> | bholley: but it's so vague... |
| 14:02 | <bholley> | annevk: we just create new ones |
| 14:02 | <bholley> | annevk: identity isn't preserved |
| 14:02 | <bholley> | annevk: that's the key point |
| 14:02 | <bholley> | annevk: the thing that makes document.open() special is that the identity of |document| is preserved |
| 14:02 | <bholley> | annevk: but nothing else |
| 14:02 | <annevk> | and if you have a reference to the old one things are weird? |
| 14:02 | <annevk> | do they represent the same underlying object? |
| 14:02 | <bholley> | annevk: there's no old one. They're the same reference. Same object |
| 14:03 | <annevk> | sorry, like the old Navigator object |
| 14:03 | <bholley> | annevk: oh. yeah |
| 14:03 | <bholley> | annevk: I don't know what happens in Gecko |
| 14:04 | <bholley> | annevk: my _guess_ would be that it would continue to operate in the old scope |
| 14:04 | <bholley> | annevk: or wait |
| 14:04 | <bholley> | annevk: navigator doesn't live on the document |
| 14:04 | <bholley> | annevk: yeah, so it's just like anything else |
| 14:04 | <bholley> | annevk: it operates in the old scope |
| 14:04 | <bholley> | annevk: easy |
| 14:05 | <bholley> | though the lack of a document is a bit tricky |
| 14:05 | <annevk> | is it? |
| 14:05 | <bholley> | annevk: is it easy or is it tricky? :-) |
| 14:05 | <annevk> | easy :) |
| 14:05 | <annevk> | doesn't seem so easy to me |
| 14:05 | <bholley> | annevk: yeah, from a spec perspective we should probably just neuter those objects |
| 14:05 | <annevk> | basically a huge special case here that changes all kinds of assumed invariants |
| 14:06 | <bholley> | annevk: right, for example Navigator sharing a Window with a Document |
| 14:07 | <annevk> | getting agreement on concept-node-adopt seems like a good start, document.open() can wait |
| 14:07 | <annevk> | that requires a bunch more testing |
| 14:07 | <bholley> | annevk: yeah |
| 14:07 | <bholley> | annevk: I think neutering is probably the way to go |
| 14:07 | <bholley> | annevk: we just need a list of objects to neuter |
| 14:07 | <annevk> | and define what neutering means for them |
| 14:08 | <annevk> | I wonder how this shit happened |
| 14:08 | <annevk> | nobody could ever have thought this to be a good idea |
| 14:14 | <MikeSmith> | ./topic Welcome to Web platform aka "I wonder how this shit happened. Nobody could ever have thought this to be a good idea." |
| 14:15 | <zewt> | i actually googled for a count on the exact phrase "who the fuck thought this was a good idea" a couple days ago (though not in a web context) |
| 14:15 | <zewt> | ~200k, modulo total meaninglessness of google search result counts |
| 14:19 | <MikeSmith> | hah |
| 14:22 | <MikeSmith> | what's great is if you google for something like that and you were to find some specific bad idea you're familiar with but then you notice that, way back when, you were one of the people who originally thought it was a good idea |
| 14:22 | <MikeSmith> | (just speaking hypothetically) |
| 14:23 | <Ms2ger> | Of course |
| 14:27 | <MikeSmith> | heh |
| 14:53 | <MikeSmith> | Ms2ger: so I'm wondering how much work it would be to add support for callback functions to idlharness.js |
| 14:53 | <Ms2ger> | MikeSmith, I have no idea |
| 14:53 | <jgraham> | MikeSmith: You don't mean to say you thought the web was a good idea once? Man, egg and your face are in alignment. |
| 14:54 | <MikeSmith> | heh |
| 14:58 | <zewt> | MikeSmith: what's odd is when you read halfway through a list post, go "wait, I've read this before", then find your name at the top of it from half a decade ago |
| 15:03 | <MikeSmith> | zewt: :) yup done that (or something close at least) |
| 15:04 | <zewt> | how about when you hit a weird problem, search for it, and the first hit is yourself asking about it on a list years earlier |
| 15:04 | <zewt> | that tends to kill any hope of finding a solution |
| 15:05 | <Ms2ger> | zewt, how about if there's also a reply from you that's just "I figured it out"? |
| 15:06 | <zewt> | i haven't screwed myself over in that particular fashion |
| 15:13 | <jgraham> | Hurrah for code commented as "not enabled, not needed at this time" that is actually needed |
| 15:14 | <zewt> | someone thought "this time" was a constant value |
| 15:55 | <zewt> | the heck? chrome alerts are window-modal? |
| 15:56 | <zewt> | seriously, wtf? |
| 15:57 | <zewt> | going back to 1998 |
| 17:10 | <gsnedders> | jgraham: Because it's effort to reverse engineer it, and it more easily gives me something to cite. |
| 17:37 | <hober> | so, hey, w3c-css-wg is interesting today. |
| 17:43 | <Ms2ger> | ██████████████████████████████ |
| 17:43 | <astearns> | yep |
| 17:44 | MikeSmith | reads to find what the names of the new CSS WG chairs are |
| 17:44 | <jgraham> | hober: I think the word you are looking for is "ironic" |
| 17:44 | <gsnedders> | hober: Tease. >_> |
| 17:45 | gsnedders | misses having MO access |
| 17:46 | <astearns> | given what's in the email, you might expect someone in WHATWG to know about it. But I'm betting that's not the case |
| 17:49 | <MikeSmith> | gsnedders: I probably shouldn't say this in non-member space but the news is that we're making Hixie_ the new co-chair of the CSS WG along wih the "is hypertext energy?" guy from the whatwg mailing list |
| 17:49 | <MikeSmith> | which I guess is what astearns meant to allude to |
| 17:50 | <astearns> | yep yep - the new guy is an amazing catch. Kudos on bringing him in |
| 17:50 | MikeSmith | pats himself on the back |
| 17:51 | <MikeSmith> | btw the current chairs of the CSS WG have been promoted to chairing the Tracking Protection WG |
| 17:55 | <jgraham> | Word has it that Obama is personally lining up a change to the constitution so that they can run for president |
| 17:58 | <MikeSmith> | jgraham: hmm, if you know about that, it seems you have accidentally revealed that you've got Platinum member access to the W3C transit lounge. Either or you're sitting outside the door stealing wifi access. |
| 18:05 | <MikeSmith> | in other news I will be talking to a tech report about Web Components in the next few days and am seriously attempting to figure out what claim I can reasonably make about how Web Components can make user experience better for actual end users |
| 18:06 | <Ms2ger> | "Not" |
| 18:07 | <jgraham> | "dglazkov will love you just a little bit more" |
| 18:07 | <jgraham> | Although eperts disagree on whether that is "better" |
| 18:07 | <astearns> | jgraham: that's negligible - he already loves everyone so much |
| 18:08 | <MikeSmith> | Ms2ger: in my experience reporters tend not to like "not". Instead they like to try to get you to say what they have already decided is the thing they're going to say. And if you don't say it, they paraphrase you in such a way as it sounds like you did. |
| 18:08 | <Ms2ger> | Sounds about right :) |
| 18:09 | <jgraham> | MikeSmith: I guess you have to make up something vauge about how it will allow more sophisticated web sites |
| 18:09 | <jgraham> | Since "sophisticated" is basically a weasle word in this context |
| 18:09 | <MikeSmith> | anyway my current plan is to mumble something about "improved UI responsiveness". The rest of time I plan to spend blowing sunshine up the chimney, as the English like to say. |
| 18:09 | <astearns> | MikeSmith: making more complex sites easier to create and maintain means less buggy experiences for end users |
| 18:09 | <Ms2ger> | MikeSmith, more FOUCs! |
| 18:10 | <Ms2ger> | Longer loading times! |
| 18:10 | <MikeSmith> | jgraham: it sounds like you have some practice already at blowing sunshine up the chimney. They must teach you guys that in school over there. |
| 18:10 | <MikeSmith> | Ms2ger: good brainstorming, we're making progress |
| 18:11 | <hober> | make it an environmental issue. FOUCs are becoming more endangered; the components work is an attempt to repopulate the species |
| 18:14 | <MikeSmith> | astearns: with my report hat on I find that you're not saying what I want to say. But what I heard you saying is "making more complex sites... buggy experiences for end users" |
| 18:14 | <MikeSmith> | so I'll quote you on that |
| 18:14 | <MikeSmith> | (didn't even have to paraphrase this time) |
| 18:15 | <astearns> | man I'm good at soundbites |
| 18:15 | <astearns> | "All of CSS is unnecessary" |
| 18:15 | <astearns> | (that's also a direct quote from a W3C presentation of mine) |
| 18:16 | <MikeSmith> | headline for the piece: "Web Components Brings Complex, Buggy Experiences for Users" |
| 18:16 | <MikeSmith> | astearns: hey I remember that one |
| 18:16 | <MikeSmith> | I think I actually requoted that one from you in some slides I used |
| 18:17 | <astearns> | heh |
| 18:20 | MikeSmith | prepares "Honk if you love FOUCs" bumper stickers for hober to distribute at the CSS drift-car rallies where he hangs out on the weekends |
| 18:22 | <hober> | shit, how did you know? |
| 18:46 | <sicking> | Hixie_: ping |
| 20:18 | <WesleyMcClane_> | hello, has someone ever considered to standardize the behavior of jquery's .closest() method? something like element.queryAncestor("div.foo[data-test]"); |
| 20:47 | <Hixie_> | sicking: pong |
| 20:48 | <sicking> | Hixie_: what's the proper procedure for giving something priority to get added in spec due to us being about to implement? |
| 20:49 | <Hixie_> | just poke me here |
| 20:49 | <sicking> | Hixie_: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0142.html |
| 20:49 | <Hixie_> | though to be honest right now i've so many things that fall into that bucket that that's basically all i'm working on, so the real question is "how do i get things higher in the list of important things" :-P |
| 20:49 | Hixie_ | looks |
| 20:51 | <Hixie_> | sicking: are there any other vendors on board? |
| 20:51 | <sicking> | Hixie_: so far no one else said anything, good nor bad |
| 20:52 | <Hixie_> | so, like requestAutocomplete(), then |
| 20:52 | <sicking> | Hixie_: i think there might be others that are interested in the second use-case, i'll try to poke them |
| 20:52 | <sicking> | Hixie_: yeah. We're going to have feedback on rAC soon |
| 20:53 | <Hixie_> | is "MessagePortAsyncSide" just a "MessagePort"? |
| 20:53 | <Hixie_> | i don't really understand this proposal |
| 20:53 | <Hixie_> | what problem is it solving? just being able to use message ports synchronously in workers? |
| 20:53 | <sicking> | Hixie_: use cases at the bottom |
| 20:54 | <Hixie_> | i don't really understand the relationship between synchronous APIs and those use cases |
| 20:54 | <sicking> | Hixie_: and answer to the first question is "yes-ish", see the email i'm replying to |
| 20:54 | <sicking> | Hixie_: using this API you can use libraries to implement synchronous APIs |
| 20:55 | <Hixie_> | the e-mail you were replying to is helpful, thanks |
| 20:55 | <Hixie_> | isn't this just going to end up in deadlocks though? |
| 20:55 | <sicking> | no, no risk of deadlocks in the traditional sense |
| 20:56 | <sicking> | async deadlocks are always possible of course, but that's true with setTimeout too |
| 20:56 | <zewt> | most of that fairly long thread was about ways to prevent deadlocks |
| 20:57 | <sicking> | preventing deadlocks are actually quite easy |
| 20:57 | <sicking> | we can even add more powerful locking mechanisms without risking that. But it's something we can do later if needed |
| 20:58 | <Hixie_> | when you post one of these to someone else, does it just turn into a MessagePort? |
| 20:58 | <zewt> | it's harder when you want to do it without limiting the API too much |
| 20:58 | <zewt> | which I suspect the proposal you quoted does, though it's been a long time and I haven't refreshed yet |
| 20:58 | <sicking> | Hixie_: no, the clone stays as whatever type the original object was |
| 20:58 | <Hixie_> | what happens when you send a sync one of these to a Window then? |
| 20:59 | <sicking> | Hixie_: you can't. See quoted restrictions at the bottom |
| 21:00 | <Hixie_> | hm, i see |
| 21:00 | <sicking> | Hixie_: i lost one restriction somewhere |
| 21:01 | <Hixie_> | note that in the spec now, DedicatedWorkerGlobalScope.postMessage and Worker.postMessage are really the same as MessagePort.postMessage, but I guess we can add some special magic there... |
| 21:01 | <sicking> | Hixie_: you also can't call waitForMessage() until one side has been transferred to another context |
| 21:01 | <Hixie_> | what if it gets transfered back? |
| 21:01 | <sicking> | Hixie_: you can't |
| 21:02 | <sicking> | Hixie_: see first quoted restrictions |
| 21:03 | <Hixie_> | so if you want to use this, you really have to bear in mind the hierarchy in which you created the workers... |
| 21:03 | <zewt> | so in this model, to have a worker block on a lower-level worker, you'd have to create the port in the parent worker (the one that blocks) and hand it down, not create the channel in the lower-level worker and pass it upwards |
| 21:03 | <Hixie_> | i have to be honest, if it was up to me, i'd tell people to suck it up and use the async API, especially with Promises and so on on the horizon. But if you get another vendor on board, I shall spec it, as usual. |
| 21:04 | <zewt> | (no amount of syntax sugar replaces synchronous programming) |
| 21:04 | <sicking> | Hixie_: not sure what you mean by "bear in mind". There are two very precise functions where you can send each type of port. You don't have to bear anything else in mind |
| 21:05 | <Hixie_> | sicking: well, generally when you're using MessagePort, especially when you're using it in a capabilities mindset, you'll have zillions of these flying around all over the place and you won't generally want to know what kind of port you're being handed |
| 21:05 | <sicking> | Hixie_: asking people to rewrite hundreds-of-thousands-of-lines codebases from sync APIs to async APIs is not really feasible |
| 21:05 | <Hixie_> | sicking: but here, you do have to bear in mind what kind of port it is |
| 21:05 | <Hixie_> | sicking: e.g. it matters who creates your channel |
| 21:05 | <sicking> | Hixie_: that's why you can always check the type |
| 21:06 | Hixie_ | wasn't particularly planning on asking anyone to rewrite their codebase |
| 21:06 | <Hixie_> | sicking: right, you have to bear it in mind. that's all i'm saying. |
| 21:06 | <Hixie_> | anyway, like i said, i'm not the one you have to convince. if you get another vendor on board, file a bug, i'll spec it |
| 21:07 | <sicking> | Hixie_: sure. Not hugely different from bearing in mind whether you are holding on to a Worker or a MessagePort |
| 21:07 | <Hixie_> | sicking: i would never hold on to a worker, personally. |
| 21:08 | <Hixie_> | you don't have to when you can use ports, the great thing about ports is you don't need to know who's implementing the other side. |
| 21:08 | <jsbell> | sicking: re: compiling sync codebases down to JS: is task.js-style use of ES6 generators infeasible? |
| 21:09 | <sicking> | Hixie_: sure, but the use cases demand a different type of port here. That neccesitates bearing that difference in mind. I don't think we can get around that. |
| 21:09 | <Hixie_> | sicking: agreed, if we address this use case, this seems like a well-designed solution. |
| 21:09 | <sicking> | Hixie_: but sure, the system is more complicated with two types of channels than one |
| 21:10 | <jsbell> | Hrm, now I'm remembering that you have to make everything async-with-generators all the way down, so probably impractical. |
| 21:10 | <sicking> | jsbell: that's a good question |
| 21:10 | <sicking> | jsbell: i suspect the overhead of making each function call a generator call is too high, but I don't actually know |
| 21:11 | <zewt> | the use case of being able to implement blocking APIs for workers in other workers seems more interesting, to me at least |
| 21:11 | <sicking> | jsbell: right, the fact that you have to do it everywhere is what makes it hard/slow |
| 21:11 | <Hixie_> | jsbell: yeah, i don't think 'yield' really works for this. in part because you can't make the original call from the browser be an invokation of a generator. |
| 21:12 | <zewt> | afk, home |
| 21:12 | <sicking> | jsbell: do you know if google can comment on compile-to-js strategies? So far my impression is that compile-to-nacl is the strategy? |
| 21:16 | <jsbell> | sicking: I have no idea re: strategy, but I'd ping dslomov |
| 21:18 | <sicking> | Hixie_: as far as I can tell the four choises we have is to say "please rewrite your code", "please target something like NaCl", "use sync API" or "sorry, the web doesn't support your software". The sync API is the least bad option IMHO. The first and last options are basically equivalent in many cases. |
| 21:22 | <Hixie_> | sicking: well, that's a simplification. they have to rewrite it anyway, typically, since the language is different. right? so really the question is, "when porting our software to a vendor-neutral platform, what do we have to do?" and the answers are "a lot of work (you can use this sync API if it helps)" or "a huge amount of work (you'll have to rethink some of your architecture to use async APIs)" |
| 21:22 | <sicking> | Hixie_: at some point in the future the "compile existing codebase to web" won't be an important use case. But I think that's only going to be true if we give people an on-ramp to migrate to the web. And the sync-api seems like the least invasive onramp. The alternative is to add a lot of other sync APIs to the platform (sync filesystem, sync IDB, sync websocket etc). |
| 21:23 | <sicking> | Hixie_: no, there are tools to complie C++ to JS. So no rewrite is needed |
| 21:23 | <Hixie_> | sicking: i think it's already true, personally. but i agree that this api, if we care about that use case, is a reasonable solution. i'm not sure what you're trying to convince me of. |
| 21:23 | <sicking> | Hixie_: trying to convince you to add it to the spec :) |
| 21:24 | <Hixie_> | sicking: me thinking it's a good idea isn't going to add it to the spec. If that was all it took, requestAutocomplete() would be in already. |
| 21:24 | <Hixie_> | sicking: what it takes is two (or ideally, four or five) vendors implementing. |
| 21:24 | <Hixie_> | or at least commenting positively. |
| 21:25 | <sicking> | ok, i'll see what i can dig up |
| 21:56 | <jsbell> | sicking: Hah, my attempt to make a demo using FF + task.js + Workers ran into https://bugzilla.mozilla.org/show_bug.cgi?id=487070 |
| 21:56 | <sicking> | jsbell: ha! |
| 21:56 | <sicking> | jsbell: that bug will be WONTFIX soon |
| 21:57 | <sicking> | jsbell: we're working on implementing the new generator syntax, which doesn't need js-version hacks |
| 21:58 | <sicking> | jsbell: oh, wait, they already landed! |
| 21:58 | <sicking> | jsbell: if you use an aurora or nightly build you should be able to use generators there |
| 21:59 | <jsbell> | sicking: nifty |
| 22:05 | <jsbell> | sicking: I'm not going to try now, and I bet task.js needs updates, but in theory https://gist.github.com/inexorabletash/6942721 would show what a demo using "yield post" would look like |
| 22:20 | <sicking> | jsbell: you might need to use strict mode |
| 22:20 | <jsbell> | sicking: I'll also need to toss in function* |
| 22:39 | <sicking> | jsbell: doesn't seem like 'let' is working in non-versioned JS in gecko yet :( |