| 01:07 | <Domenic_> | crocket: no I mean recruiters. "HTML5/CSS3, Object oriented JavaScript, and jQuery experience preferred." |
| 01:08 | <zewt> | heh, well, being able to use JS in an OO-fashion is actually probably a pretty decent metric of someone who can actually write sensible JS |
| 03:48 | <crocket> | zewt, not very |
| 03:48 | <crocket> | A recruiter has to actually read codes. |
| 03:48 | <crocket> | A recruiter has to actually read codes written by applicants. |
| 04:25 | <zewt> | (that doesn't seem to have anything to do with what I said) |
| 10:21 | <jgraham> | anyone know anything about http://w3c-test.org/web-platform-tests/master/eventsource/eventsource-cross-origin.htm ? |
| 10:24 | <Ms2ger> | Mmm |
| 10:24 | <Ms2ger> | Blame says you |
| 10:25 | <Ms2ger> | The <--/*--> hack says zcorpan |
| 10:27 | <jgraham> | It wasn't me! |
| 10:28 | <zcorpan> | i don't see <!--/*--> there |
| 10:29 | <zcorpan> | but i think odinho wrote the eventsource+cors tests |
| 10:29 | <Ms2ger> | Oh |
| 10:29 | <zcorpan> | and annevk wrote the initial set of eventsource tests |
| 10:29 | <Ms2ger> | That was in another file |
| 10:29 | <zcorpan> | ondinho might have copied my hack for all i know :-) |
| 10:31 | <zcorpan> | i have probably reviewed the eventsource tests so i might know something about them. what's the question? |
| 10:33 | <jgraham> | The second test always times out afaict |
| 10:33 | <jgraham> | Any idea why? |
| 10:33 | <jgraham> | I mean, is it a broken test or a correct test that doesn't match implementations |
| 11:14 | <zcorpan> | jgraham: the test seems correct from what i can tell. "HTTP 301 Moved Permanently, 302 Found, 303 See Other, and 307 Temporary Redirect responses are handled by the fetching and CORS algorithms." http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#processing-model-7 |
| 11:15 | <zcorpan> | but i don't have the cors stuff paged in |
| 11:17 | <jgraham> | So |
| 11:18 | <jgraham> | Chrome and Firefox fail "EventSource: cross-origin redirect use" |
| 11:18 | <zcorpan> | hmm, i think the redirect script needs CORS headers for the redirect to succeed |
| 11:19 | <jgraham> | Opera 12 and Firefox fail "EventSource: cross-origin redirect use recon" on localhost, but not on w3c-test.org |
| 11:19 | <jgraham> | Chrome passes |
| 11:20 | <jgraham> | I can't tell if this is because I have broken things in my conversion, but they utterly refuse to send cookies with the cross-origin event source request |
| 11:20 | <jgraham> | (on localhost) |
| 11:20 | <Ms2ger> | r? https://critic.hoppipolla.co.uk/r/208 |
| 11:21 | <zcorpan> | but message.php also doesn't use CORS headers, which it should have i think |
| 11:21 | <zcorpan> | i'll ask odin |
| 11:21 | <jgraham> | cors.php adds CORS headers to everything |
| 11:21 | <jgraham> | So maybe it should redirect to cors.php with message as the handler? |
| 11:22 | <zcorpan> | aha |
| 11:22 | <zcorpan> | that's the thing |
| 11:22 | <jgraham> | Oh and Opera doesn't show Event Source in the network tab |
| 11:22 | <zcorpan> | the redirect works, but message.php fails the cors check |
| 11:22 | <zcorpan> | so the test is broken |
| 11:22 | <jgraham> | and Firefox won't let me copy the response |
| 11:25 | <jgraham> | zcorpan: OK, fixed that test |
| 11:25 | <jgraham> | One left |
| 11:26 | <zcorpan> | Ms2ger: btw it seems i wrote the eventsource+worker tests |
| 11:28 | <jgraham> | Is there anything special I should know wrt CORS and cookies on localhost or non-default ports? I don't see anything, but I am not a CORS expert |
| 11:29 | <jgraham> | Oh awesome, the test works on reload in Opera |
| 11:29 | <jgraham> | So there is obviously something stateful there |
| 11:30 | <Oliver_> | Hi |
| 11:32 | <MikeSmith> | I don't think /win 21 |
| 11:32 | <MikeSmith> | oofs |
| 11:33 | <jgraham> | Was that "oofs" the "Descartes pop" as MikeSmith vanished? |
| 11:37 | <MikeSmith> | heheh |
| 11:50 | <darobin> | Descartes pop? |
| 11:52 | <MikeSmith> | those were actually my Kirby krackle |
| 12:02 | <MikeSmith> | in the "why o god why" department, on a chance visit to #developers to offer my condolences to bz on becoming a W3C editor, I discover that virtualbox is using xpcom |
| 12:02 | <MikeSmith> | proof that mental illness is contagious? |
| 12:11 | <MikeSmith> | oh god a "srcN attribute" |
| 12:12 | <MikeSmith> | (speaking of mental illness) |
| 12:12 | <MikeSmith> | sorry I meant to write, What a great idea!! |
| 12:14 | <MikeSmith> | I want whatever hippy crack all the responsive images folks are smoking |
| 12:23 | <Ms2ger> | Ask TabAtkins :) |
| 12:27 | <jgraham> | Yeah, numbered attributes are kind of ugly |
| 12:27 | <jgraham> | Makes you wish HTML had more than just string types really |
| 12:28 | <Ms2ger> | I should deal with those File API tests |
| 12:29 | <zcorpan> | TabAtkins: is www-style the right list for the respimg proposal? |
| 12:30 | <Ms2ger> | Didn't they hide in a CG with its own ML? |
| 12:37 | <zcorpan> | there's a separate mailing list, but tab's draft says to send feedback to www-style |
| 12:37 | <jgraham> | Yeah, but it also seems rather likely to just be because all his other drafts say that |
| 12:44 | <MikeSmith> | I don't think we'd be able to implement microsyntax checking of srcN values without some ugly hack |
| 12:46 | <darobin> | yeah, I don't reckon that www-style is the right place, I reckon TabAtkins just pasted his usual Bikeshed empty draft or whatever |
| 12:47 | <MikeSmith> | I think what we'd need to do is to add a filter that changes all the srcN attributes in memory to some other arbitrary single attribute name to which we could actually bind some syntax-checking. I think I'd go with "TabAtkins" is that attribute name. Either that or "xpcom". |
| 12:49 | darobin | wonders why MikeSmith would have to do that... |
| 12:49 | zcorpan | too |
| 12:50 | <jgraham> | Presumably because the code assumes that each microsyntax is bound to a finite set of attributes |
| 12:52 | <MikeSmith> | because the validator backend by default considers any attribute invalid unless it's explicitly told that it's valid |
| 12:53 | <darobin> | ah |
| 12:53 | <MikeSmith> | and there is no way to tell that core part of the validator that a pattern or wildcard for an attribute name is valid |
| 12:53 | <darobin> | but since you're going to have to add support for matching on patterns for the hyphen-attributes anyway, you can also do src\d+ at the same time |
| 12:53 | darobin | giggles and hides |
| 12:53 | <MikeSmith> | so if as src1000 attribute is exposed to that part of the validator as-is, it will emit an error |
| 12:54 | <MikeSmith> | hah |
| 12:54 | <darobin> | how do you handle data-*? |
| 12:55 | <MikeSmith> | well in the case of hyphen-attributes there are many more reasons what that's plainly a bad idea that have nothing to do with the validator |
| 12:57 | <darobin> | yeah yeah, but how do you have data-*? does the same trick not work with srcN? |
| 12:57 | <MikeSmith> | darobin: I'll send a reply on the list but as far as validation, consider what happens when an author misttypes aria-described-by as aria-descibes-by |
| 12:57 | <darobin> | MikeSmith: I was thinking it would be more of a problem if the author mistyped aira-described-by |
| 12:57 | <MikeSmith> | I'm pretty sure we just completely drop the data-* attributes and don't do any checking on their values |
| 12:57 | <MikeSmith> | expect that the parser checks the values for parse errors |
| 12:57 | <darobin> | since I'd expect the validator to look at the prefix of attributes it knows about |
| 12:58 | <darobin> | ah, so you drop them before, makes sense |
| 12:58 | darobin | looks forward to the TabAtkins attribute then |
| 12:59 | <MikeSmith> | darobin: the validator does not have any concept of what a prefix is |
| 12:59 | <darobin> | MikeSmith: I'd guess, but that's a SMOP :) |
| 12:59 | <MikeSmith> | it only understands explicit names |
| 12:59 | <MikeSmith> | darobin: sure |
| 13:01 | <MikeSmith> | but like most SMOP it would simple only to the people who don't have to SMOP it and maintain it |
| 13:36 | <GPHemsley> | Hixie_: I was discussing the issue with bz off-list at the time. (Mozila IRC, IIRC.) |
| 13:37 | <GPHemsley> | Hixie_: As I told him then, I was waiting for others to respond before I said/did anything. The main problem with mimesniff is that no one pays any attention to it. |
| 13:37 | <GPHemsley> | Hixie_: I never get any feedback from anybody unless I specifically go and request it (or else do something that offends someone's sensibilities wrt spec writing). |
| 13:39 | <hallvors> | Hixie_: if you've got a moment, comments on https://bugzilla.mozilla.org/show_bug.cgi?id=881072#c44 would be welcome.. (Sorry to interrupt, GPHemsley) |
| 13:39 | <GPHemsley> | hallvors: No worries. I imagine Hixie_ is sleeping anyway. |
| 13:41 | <hallvors> | You mean you're trying to interfere with his dreams, asking questions on IRC? Do spec writers dream in chat channels? ;-) |
| 13:42 | <GPHemsley> | I think Hixie_ dreams in cat channels |
| 13:45 | <jgraham> | hallvors: ! |
| 13:45 | <jgraham> | Did the cors tests ever work properly? Do you in fact know about those or only the XHR ones? |
| 13:47 | <hallvors> | jgraham: haven't looked much at the CORS tests (but there are a handful of CORS tests in the XHR suite now) |
| 13:48 | <jgraham> | hallvors: I remember you poking at getting cors headers working on w3c-test.org |
| 13:48 | <hallvors> | yes, but that was probably to get the XHR suite working :-p |
| 13:49 | <jgraham> | Oh, OK |
| 13:49 | <hallvors> | who worked on the CORS suite? Odin? |
| 13:49 | jgraham | wonders what PHP does if you send it mutliple request headers with the same name |
| 13:49 | <jgraham> | hallvors: Yeah |
| 13:49 | <jgraham> | He is MIA though |
| 13:49 | <jgraham> | Or at least not in the channel, which is more or less the same thing |
| 13:51 | <jgraham> | (the documentation doesn't say. It doesn't even say that all headers end up in $_SERVER) |
| 14:16 | <annevk> | hallvors: I recommend getting zcorpan to look at https://bugzilla.mozilla.org/show_bug.cgi?id=881072#c44 |
| 14:19 | <annevk> | hallvors: in any event, stable states are provided all the time |
| 14:19 | <hallvors> | I would expect a "stable state" after parsing and before DOMContentLoaded |
| 14:20 | <hallvors> | (and I would expect the "synchronous parts" of the resource selection to run when the implementation reaches the *first* stable state) |
| 14:20 | <hallvors> | - so why doesn't that seem to happen in the Webkit - based browsers? |
| 14:26 | <jgraham> | You get a stable state after each event on the event loop afaict |
| 14:30 | <annevk> | hallvors: you get "stable state" before </script> too, and during each task in the event loop it seems |
| 14:30 | <annevk> | hallvors: and a number of other places, load the full page spec and click "provide a stable state" to find the various places |
| 14:32 | <hallvors> | right - makes those other browsers' behaviour seem even weirder.. :-/ |
| 14:32 | <jgraham> | Oh, so sending a HTTPS request to a non-https server doesn't work so well |
| 14:33 | <annevk> | jgraham: Firefox blocks "intranet" stuff with CORS as well |
| 14:33 | <jgraham> | annevk: So localhost doesn't work? |
| 14:35 | <annevk> | jgraham: might not I suppose, sicking gave some details once long ago |
| 14:35 | <jgraham> | OK |
| 14:36 | <jgraham> | Well it would be consistent with my observations I guess |
| 14:36 | <jgraham> | On the other hand, so would "there is a vindictive God who is out to ruin my day" |
| 14:36 | <jgraham> | So I don't think that my observations in isolation can prove much |
| 14:38 | Ms2ger | denies being that vindictive God |
| 14:40 | <annevk> | jgraham: if there's nothing logged in console that might be worth complaining about |
| 15:39 | <Domenic_> | annevk: http://w3cmemes.tumblr.com/post/49409867666/and-if-you-dont-have-an-api-you-might-as-well-set |
| 15:44 | <annevk> | Domenic_: given the super long reply I think this argument is over |
| 15:44 | <Domenic_> | annevk: as in, he's made up his mind and not going to change it? |
| 15:44 | <annevk> | Domenic_: combined with the fact that he's not gonna decide what lands in browsers, yes |
| 15:45 | <Domenic_> | he seems open to adding both |
| 15:46 | <Domenic_> | maybe get both in and then later, feedback comes in that the events are redundant and error-prone. |
| 15:46 | <annevk> | I'd rather not waste precious engineering and specification writing time on an exercise in futility |
| 15:46 | <Domenic_> | sounds good |
| 16:16 | <jgraham> | annevk: Looks like you were right |
| 17:37 | <TabAtkins> | zcorpan: If possible, send feedback to the respimg cg. |
| 17:38 | <TabAtkins> | It is indeed a failure of bikeshed at the moment that it always says to send feedback to www-style. |
| 17:40 | <TabAtkins> | MikeSmith: Hey, it's either separate attrs (numbered for uniqueness+ordering), separate elements (implementors hate them), or a big mashed together syntax with 5 levels of separator characters. |
| 17:40 | <astearns> | that last one sounds intriguing :) |
| 18:16 | <Hixie_> | hallvors: re https://bugzilla.mozilla.org/show_bug.cgi?id=881072#c44 - which test case are we talking about? |
| 18:20 | <Ms2ger> | Hixie_, https://bug881072.bugzilla.mozilla.org/attachment.cgi?id=803768 ? |
| 18:31 | <Hixie_> | oh duh |
| 18:31 | <Hixie_> | my brain totally ignored the grayed out stuff |
| 18:44 | <Ms2ger> | http://lists.w3.org/Archives/Public/public-test-infra/2013JulSep/0272.html |
| 18:44 | <Ms2ger> | Wut |
| 18:45 | <miketaylr> | E N E R G I Z E |
| 19:02 | <annevk> | Hixie_: thanks for adding a comment there |
| 19:02 | <Hixie_> | np |
| 19:26 | <hallvors> | Hixie_: +1 thanks - now, I guess the harder part is to get WebKit devs to fix the bug and break vine.co and video.js like Mozilla does :-p |
| 19:44 | <TabAtkins> | annevk, Domenic_: What's the super-long argument about? |
| 19:45 | <annevk> | TabAtkins: public-webapps thread on whether or not to use promises for something |
| 19:45 | <annevk> | TabAtkins: it wasn't super long |
| 19:45 | <Domenic_> | thread wasn't, but the message saying "no events are better" was pretty long. |
| 19:50 | <dglazkov> | fwiw, there aren't any events in Web Components specs defined so far. |
| 19:50 | <dglazkov> | I should respond to this thread, I guess |
| 20:08 | <annevk> | Domenic_: if something is enumerable and visible to for-in, does that mean you can also test for it using "in"? |
| 20:09 | <Domenic_> | annevk: "in" always works, enumerable doesn't matter for that |
| 20:09 | <annevk> | Domenic_: aight |
| 20:11 | <annevk> | It seems symbols are better for e.g. HTMLCollection: |
| 20:12 | <annevk> | <div id=@iterator></div> |
| 20:12 | <annevk> | <script>alert(document.getElementsByTagName("div")["@iterator"])</script> |
| 20:12 | <Domenic_> | good one, use that |
| 20:12 | <Domenic_> | except, functions |
| 20:13 | <Domenic_> | counterexamples work better when you can manage to create a spurious @iterator function |
| 20:13 | <annevk> | how would that work better? |
| 20:15 | <Domenic_> | because then it's a real hazard, concretely demonstrating that "@iterator" the string will screw things up |
| 20:16 | <Domenic_> | if it's not a function, he can just argue that the test for iterability (or any similar protocol) should be "@iterator" in obj && typeof obj["@iterator"] === "function" |
| 20:18 | <annevk> | oh my point is that we want to make HTMLCollection iterable |
| 20:19 | <Domenic_> | ah right that makes sense, pages could break iterability with such an element. |
| 20:39 | <annevk> | Hixie_: why is transferring not inlined with structured cloning? |
| 20:39 | <Hixie_> | it used to be separate |
| 20:39 | <Hixie_> | like, unrelated |
| 20:40 | <annevk> | Hixie_: structured cloning is abstracted at the top of the spec, but then postMessage() details transferring around it |
| 20:40 | <annevk> | Hixie_: k |
| 20:40 | <Hixie_> | i should probably clean it up but i have much bigger fish to fry right now |
| 20:40 | <Hixie_> | same reason i haven't deferred to fetch yet |
| 20:40 | <annevk> | Hixie_: I'm trying to get TC39 to take over structured cloning |
| 20:40 | <annevk> | Hixie_: so don't worry too much about it |
| 20:44 | hober | is looking forward to structured clone handling Map & Set |
| 20:46 | <annevk> | Hixie_: also don't worry too much about Fetch |
| 20:46 | <Hixie_> | k |
| 20:46 | <annevk> | Hixie_: I'm going to land it for XMLHttpRequest first as a guinea pig, and there's a couple of things I need to change for that |
| 20:46 | <Hixie_> | lgtm |
| 21:30 | <annevk> | Hixie_: you can neuter a Blob via Blob.close(), but then it can still be cloned, is that useful? |
| 21:31 | <Hixie_> | you can't clone neutered things, by definiton |
| 21:31 | <Hixie_> | definition |
| 21:31 | <Hixie_> | no? |
| 21:33 | <Hixie_> | hm, i guess the check of whether a neutered thing can be cloned is done each time by the cloning steps for that thing |
| 21:33 | <Hixie_> | maybe the blob cloning steps are missing that? |
| 21:35 | <annevk> | yeah, prolly because a Blob is not neutered as side-effect of being transfered, it's a distinct operation |
| 21:36 | <annevk> | (Blob always clone and don't transfer, as they're readonly) |
| 21:36 | <Hixie_> | oh then the neutering is something else entirely |
| 21:36 | <Hixie_> | i thought you meant "neuter" in the trasfer sense |
| 21:37 | <Hixie_> | createImageBitmap() throws InvalidStateError if a Blob "has been neutered through the close method" |
| 21:37 | <Hixie_> | i would be happy to add the same clause to the structured clone stuff |
| 21:37 | <Hixie_> | if you think we should |
| 21:37 | <Hixie_> | file a bug |
| 21:38 | <annevk> | File API uses the same definition of neutering so I guess |
| 21:39 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=23385 |
| 21:40 | <Hixie_> | same definition as what? |
| 21:40 | <Hixie_> | i don't understand the second part of that bug |
| 21:41 | <annevk> | I.e. as step 2 of the internal structured cloning algorithm have "if input is neutered, throw ..." |
| 21:46 | <Hixie_> | annevk: you can't get that far if an input is neutered in the transfer sense. |
| 21:46 | <Hixie_> | annevk: and blob shouldn't be using the transfer sense if it's no transferable. |
| 21:46 | <annevk> | Hixie_: why does ArrayBuffer do the check there? |
| 21:47 | <Hixie_> | interesting question |
| 21:48 | <Hixie_> | that entire entry shouldn't be there |
| 21:48 | <Hixie_> | it'll never get invoked |
| 21:48 | <annevk> | Hixie_: I think it's because it's recursive |
| 21:48 | <annevk> | Hixie_: and ArrayBuffer can be cloned as well as transfered |
| 21:48 | <Hixie_> | oh, oh, right. |
| 21:48 | <Hixie_> | that's why. |
| 21:49 | <Hixie_> | it's because you can clone as well as transfer. |
| 21:49 | <Hixie_> | anyway. you can't transfer a blob. so it shouldn't use the transfer notion of 'neuter'. |
| 21:50 | <Hixie_> | it can have its own notion of neutering |
| 21:50 | <annevk> | and although Blob cannot be in the transferMap, it can be neutered so just checking for neutering there makes sense |
| 21:50 | <annevk> | mah |
| 21:50 | <Hixie_> | but it's unrelated to transfering. |
| 21:50 | <annevk> | I suppose |
| 21:50 | <Hixie_> | just like if it had a computed value, it wouldn't be the CSS sense of "computed value" |
| 22:39 | jamesr__ | would appreciate if y'all parser folks would take a look at his recent whatwg@ email |
| 22:42 | <jamesr__> | it's possible that there is more magic in some of these algorithms that mean my proposal isn't an actual change in behavior, but if so then i think my proposed text will be a lot easier to understand |
| 22:54 | <annevk> | Domenic_: man I hope it's not that complicated |
| 22:54 | <annevk> | Domenic_: /tc39 should just be community space |
| 22:55 | <Domenic_> | annevk: hmm dunno that feels weird, seems like it should have some air of legitimacy at least... |
| 22:55 | <Domenic_> | I think it's really about GitHub's access model though, i.e. can i edit something in the tc39 org without being in the tc39 org. |
| 22:55 | <Domenic_> | Pretty sure I can. |
| 22:57 | <annevk> | Well if you need to pay in order to be legit, I don't think it's good for the web |