| 00:06 | <benjamingr> | sorry, had to leave, I'll get back to this tomorrow :) |
| 00:08 | <coolbot95> | Can somebody tell me what the current state of HTML 5 audio is? I really wish to drop Flash finally now. Does HTML 5 audio - whatever it is called now - have support for multi-voice (multiple samples at once), panning and volume? |
| 00:08 | <coolbot95> | And support in all modern browsers? |
| 00:53 | <MikeSmith> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721 "Does choosing to run a javascript application mean that the user must accept all the choices made by this application?" ... |
| 00:54 | <Hixie> | coolbot95: it's called "Web Audio", and I believe the answer is yes |
| 01:05 | <zewt> | MikeSmith: bad%20life%20decisions.js |
| 01:06 | <Domenic> | MikeSmith: oh my god, that thread, I feel so bad for Ryan :( |
| 01:14 | <zewt> | did someone fall into a trap? |
| 01:23 | <coolbot95> | Hixie: Hmm... |
| 01:24 | <coolbot95> | Hixie: Can you link me to documentation? |
| 01:24 | <coolbot95> | It's such a jungle of different terms. |
| 01:24 | <coolbot95> | I think they tried to standardize this multiple times? |
| 01:24 | <coolbot95> | I really wanna leave Flash 100% now. |
| 01:24 | <coolbot95> | No more dependency on Flash objects for audio playback. |
| 01:33 | <bengl> | coolbot95: this isn't a half-bad place to start: http://www.html5rocks.com/en/tutorials/webaudio/intro |
| 01:42 | <zewt> | i wonder how much less hated windows APIs would be if they released source for them fifteen years ago |
| 01:43 | <zewt> | nothing to do with "open source" or changing anything, it's just 100x easier to figure out why their APIs (which are still terrible) are behaving strangely |
| 01:43 | <MikeSmith> | Domenic: yeah Ryan's gotta be admired for making the effort. He put way more time responding to that guy than I would have bothered to. |
| 01:46 | MikeSmith | imagines the discussion with the directory about that formal objection... "So here's how the web works, and over here is how this guy would like for it to work instead. Changing the way the entire web works is a bit out of scope for the crypto spec..." |
| 01:48 | <hober> | MikeSmith: Domenic: context? |
| 01:48 | <SamB> | zewt: then people would complain even MORE if undocumented aspects the behaviour changed, probably |
| 01:48 | <MikeSmith> | hober: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721 |
| 01:48 | <zewt> | "formal objections" seem to be a pretty reliable way to alienate everyone in earshot |
| 01:49 | <MikeSmith> | zewt: :) yeah pretty much. At least the few people who are actually listening |
| 01:49 | <SamB> | I think it should be required to wear formalwear to issue a formal objection |
| 01:50 | <MikeSmith> | making a formal objection is pretty much never a good idea |
| 01:50 | <zewt> | i mean if it was a known mozilla developer we'd probably stop and think "maybe he's doing this for a reason", but invariably it's someone at some hostname nobody's ever heard of |
| 01:50 | <SamB> | MikeSmith: the requirement to wear a tuxedo might reenforce that principle nicely |
| 01:53 | <zewt> | SamB: i don't really care how much people complain, it makes my life easier |
| 01:53 | <zewt> | not that it actually makes things like WPF not nightmarishly broken or anything |
| 01:53 | <SamB> | plus I figure the pictures would be funny |
| 01:54 | <MikeSmith> | SamB: we should add some other requirement like they have to physically nail the objection to somebody's front door |
| 01:54 | <SamB> | while wearing a tuxedo? |
| 01:54 | <zewt> | the only platforms I've done UI stuff on in living memory where I could pretty reliably tell what was going on, and avoid spending more time convincing the UI than actually getting stuff done, are the web and ... iOS, oddly |
| 01:54 | <SamB> | and post pictures on the 'net? |
| 01:54 | <zewt> | wpf: totally broken. android: totally broken. |
| 01:54 | <MikeSmith> | SamB: there we go. good brainstorming |
| 01:55 | <zewt> | (basically, the APIs that try to force "separation of business logic" crap on you, whether it makes sense or not, tend to be the ones that are nearly unusable) |
| 01:56 | <SamB> | wait, there's business logic in android apps? |
| 01:56 | SamB | thought they were all toys |
| 01:57 | <zewt> | android has a lack of toys, too, but that's a separate issue |
| 01:57 | <coolbot95> | zewt: Huh? The source code for their API? That makes no sense. |
| 01:57 | <coolbot95> | That must mean you want them to release the source code for their OS. |
| 01:57 | <zewt> | ... |
| 01:57 | <MikeSmith> | formal objections are usually just a formal statement of "Let this hereby be a formal record of the fact that I've failed to make a convincing argument." |
| 01:58 | <zewt> | they release source to chunks of APIs http://referencesource.microsoft.com/#PresentationFramework/src/Framework/System/Windows/Input/KeyboardNavigation.cs |
| 01:58 | <SamB> | but not the win32 APIs |
| 01:58 | <coolbot95> | But... and API... |
| 01:58 | <coolbot95> | Source code... to an API... |
| 01:58 | coolbot95 | 's head explodes. |
| 01:58 | <coolbot95> | *an API |
| 01:58 | <SamB> | coolbot95: it's a common sloppy usage ... |
| 01:58 | <zewt> | sorry, you're not being very interesting, informative or helpful |
| 01:59 | <SamB> | coolbot95: insert the term "implementation" in there somehow and it will make more sense |
| 01:59 | <zewt> | MikeSmith: with the other important detail: "... and I think I should be able to win the argument anyway because my employer gives money to the W3C" |
| 01:59 | <MikeSmith> | heh |
| 01:59 | <MikeSmith> | yeah that too |
| 01:59 | <caitp> | ralph: did you write software to generate those it's vs its typo fix patches, or are you just bored and doing that on your own? if it's software I'd like to see it, I'm interested |
| 02:00 | <zewt> | MikeSmith: it's probably the operative part, at least as far as the impression people make on me when they do it |
| 02:01 | <MikeSmith> | zewt: though in the case of that bug, their reporter neither works for the w3c nor has ever contributed in any way to developing new security/privacy-related technologies/standards for the platform |
| 02:01 | <coolbot95> | I have to use a god damn XMLHttpRequest to load sounds? Why isn't it just like Image()? |
| 02:01 | <MikeSmith> | zewt: yeah, that is the impression it makes in most case |
| 02:02 | <zewt> | coolbot95: well, god DAMN IT then |
| 02:03 | <coolbot95> | zewt: What? |
| 02:03 | <SamB> | wouldn't a regular XMLHttpRequest work just fine? |
| 02:03 | <zewt> | heretical xhr is cooler than sync xhr, that's for sure |
| 02:04 | <coolbot95> | SamB: It makes it look ugly. |
| 02:04 | <SamB> | I mean why do you need to use a god damn one |
| 02:04 | <coolbot95> | If Image() is done like that, why not Audio()? |
| 02:04 | <zewt> | SamB: "whoosh" |
| 02:04 | <coolbot95> | It's ugly to have to use an XMLHttpRequest. |
| 02:05 | <caitp> | if the api were pretty, it wouldn't be successful |
| 02:05 | <MikeSmith> | zewt: also the thing is, the director doesn't really care whether a comment is a formal objection or not. he care about the technical merit of the comment regardless. Also I think that spec is in last call right now, and if so, the WG will anyway be obligated to inform the director about any comments that were not resolved to the commenter's satisfication. So there's no different process effect between making a Last Call comment and making a formal obj |
| 02:05 | <caitp> | the only way for it to be successful is for it to be both A) terrible and B) the only option! |
| 02:06 | <SamB> | MikeSmith: except the "I'm a douchebag" effect |
| 02:06 | <zewt> | well, that's the main effect we've been talking about ... though that perhaps is a more succinct way of putting it |
| 02:07 | <coolbot95> | The linked-to article is from 2011. |
| 02:07 | <SamB> | I mean the formal objection will communicate this to the director, too |
| 02:07 | <coolbot95> | And does not mention anything about volume or panning as far as I can see. |
| 02:07 | <coolbot95> | Or about multi-voice. |
| 02:07 | MikeSmith | smiles about caitp's earlier "what is money if it doesn't flow down the river" |
| 02:07 | <zewt> | maybe a different aspect is "your arguments are irrelevant because we pay the W3C", which may be why it feels like an insult |
| 02:07 | <coolbot95> | It does mention realtime filters, though, which is unexpected. |
| 02:08 | <coolbot95> | You'd think panning and volume would be basics. |
| 02:08 | <bengl> | coolbot95: https://developer.mozilla.org/en-US/docs/Web_Audio_API |
| 02:08 | <coolbot95> | And realtime filters would be fancy. |
| 02:09 | <bengl> | coolbot95: also https://developer.mozilla.org/en-US/docs/Web/API/HTMLAudioElement |
| 02:10 | <caitp> | it's a great line mike, you've got to drop it at the appropriate time though, like when people are daring you to spend millions of dollars on something that nobody will ever agree on |
| 02:11 | <MikeSmith> | heh |
| 02:25 | <coolbot95> | Why is audio playback such a massive, over-engineered deal? |
| 02:25 | <coolbot95> | Even back in the MS-DOS days, a genius such as John Carmack would still license out the audio playback part. |
| 02:25 | <coolbot95> | He could code a fantastic 3D engine for very slow computers, but not audio playback. |
| 02:25 | <caitp> | it's just electronics |
| 02:26 | <coolbot95> | ? |
| 02:26 | <caitp> | surely you could build a neve mixer in your garage, how hard could it be |
| 02:26 | <coolbot95> | What? |
| 02:27 | <caitp> | super simple stuff |
| 02:52 | <coolbot95> | Have you been smoking crack cocaine? |
| 02:55 | <caitp> | oh dear |
| 03:03 | <TabAtkins> | Hixie: The way you handle the "don't do something until this promise I'm handing you settles" is by making a method that takes the promise as an arg. |
| 03:03 | <TabAtkins> | ServiceWorker has a .waitUntil(Promise) method for this. |
| 03:59 | <Hixie> | TabAtkins: yeah, that's what i assumed. i was getting confused by Domenic and benjamingr :-| |
| 04:00 | <Hixie> | TabAtkins: can waitUntil be called several times? |
| 04:59 | <TabAtkins> | Dunno. |
| 05:44 | <MikeSmith> | Hixie: the URL spec doesn't like your data: URLs http://sideshowbarker.net:8888/?doc=http%3A%2F%2Fwhatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2F |
| 06:04 | <zcorpan> | Hixie: i like the rotated labels :-) |
| 06:50 | <TabAtkins> | Hixie: And I like the :target styling, and will try to steal it for CSS. |
| 06:51 | <Hixie> | man is https://github.com/domenic/promises-unwrapping/issues/24#issuecomment-43714664 really the kind of code we can expect to see when promises are everywhere? that's horrifying |
| 06:52 | <Hixie> | just long changes of method calls with no obvious control flow |
| 06:52 | <Hixie> | chains |
| 06:52 | <Hixie> | TabAtkins: cool |
| 06:52 | <Hixie> | MikeSmith: any idea which character it is it doesn't like? |
| 06:54 | <TabAtkins> | Hixie: That's already the code we have today with callback functions (see: "callback hell"), except it's worse today due to the rightward march. |
| 06:54 | <TabAtkins> | Also terrible error-handling, no free synchronization primitives, etc. |
| 06:54 | <Hixie> | i don't recall every writing code that hard to read |
| 06:54 | <TabAtkins> | Hixie: Promise code is as close as we can get to straight-line sync code without new JS facilities. |
| 06:55 | <TabAtkins> | And new JS facilities *are* coming - the "await" keyword lets you write code that looks sync. |
| 06:55 | <Hixie> | yeah except i'll never be able to use it because it screws up throwing TypeErrors... |
| 06:55 | <MikeSmith> | Hixie: the braces I think |
| 06:55 | <TabAtkins> | Actually, "await fetch()" I suspect would throw a rejection. |
| 06:55 | <Hixie> | MikeSmith: ah |
| 06:56 | <TabAtkins> | No sure I've heard it. |
| 06:56 | <TabAtkins> | Rather, "not sure I've heard of the specific plans for what 'await' does for rejections". |
| 06:57 | <TabAtkins> | Because `try { await fetch(...) } catch(e) {...}` can get CPT-transformed into good code for you, in a way that is super clumsy and terrible when doing straight promises by themselves. |
| 06:57 | <TabAtkins> | If it makes you feel better, just remember that using raw promises everywhere is a middle step in the evolution of good async handling. |
| 06:58 | <TabAtkins> | (And that no matter how bad you think it looks, it looks much worse today.) |
| 06:58 | <TabAtkins> | (And if you think you write elegant beautiful callback-hell code, you can do the same thing with promises.) |
| 07:00 | <TabAtkins> | Hixie: Basically, check out http://www.xanthir.com/b4P_0. We're still in the Mauvascript stage of async code, with Promises being a pretty band-aid. |
| 07:02 | <Hixie> | i don't understand why .foo('5') should fail one way when you typoed "foo" and a different way when you typoed its argument. |
| 07:02 | <MikeSmith> | Hixie: btw I notice my chrome doesn't scroll to the right place when I visit http://url.spec.whatwg.org/#url-code-points (though Firefox does). I wonder if it's a side effect of the spec stylesheet redesign, and the :target thing |
| 07:02 | <Hixie> | MikeSmith: yeah i've noticed that too. i think it might be, though no idea why or how |
| 07:03 | <MikeSmith> | seems like a chrome bug |
| 07:03 | <Ms2ger> | Good morning, Hixie |
| 07:04 | <Hixie> | yeah i really should head to bed |
| 07:15 | <TabAtkins> | Hixie: I typed a more involved argument into GitHub. |
| 07:16 | <TabAtkins> | One you have `await` it won't be different (when you use await). |
| 07:16 | <TabAtkins> | Right now, and in the future when you're operating on the promise directly, it'll just be a wart from JS not supporting async from the get-go. Oh well. |
| 07:18 | <Ms2ger> | Yay, more warts |
| 07:18 | <TabAtkins> | It's an existing wart, so whatevs. |
| 07:19 | <Ms2ger> | I think it's funny how quickly promises moved from "the bright new future" to "wart" |
| 07:19 | <TabAtkins> | If JS had some different syntax for calling things async, it'd probably work - the language would catch any errors for you and package them into a rejected promise automatically. |
| 07:19 | <TabAtkins> | Ms2ger: Why are you implying they aren't both? |
| 07:20 | <zcorpan> | annevk: seems we're gonna try url("..." crossorigin etc); and you have to use quotes. possibly also support image("..." crossorigin etc, <color>); |
| 07:20 | <TabAtkins> | Promises are the stepping stone towards good async, representing the base notion of an "async value". They're great, and enable tons of great things that'll make lots of different programming concepts better. |
| 07:21 | <TabAtkins> | annevk: Specifically, I'm pretty sure I can adjust Syntax to parse a quoted-string url() as a plain function(), leaving only unquoted urls as a url-token. |
| 07:21 | <TabAtkins> | s/function()/function-token/ |
| 07:21 | <TabAtkins> | SimonSapin: ^^^ also |
| 07:28 | <SimonSapin> | TabAtkins: I’m missing context. Why would you want to do that? |
| 07:28 | <SimonSapin> | Also, how? It doesn’t sound possible unless you make tokenization context-aware |
| 07:31 | <IZh> | Is it possible for IDs to end with "?" character? |
| 07:33 | <IZh> | The spec has one. And a href to it. |
| 07:36 | <mathiasbynens> | IZh: sure, IDs can contain any symbol except for spaces http://mathiasbynens.be/notes/html5-id-class |
| 07:40 | <TabAtkins> | SimonSapin: Nope, no context-awareness needed. |
| 07:40 | <TabAtkins> | SimonSapin: After seeing "url(", consume whitespace until the next character is non-whitespace. If it's a double or single quote, return a function token named "url", otherwise switch into the crazytimes unquoted url consuming code. |
| 07:41 | <TabAtkins> | IZh: Note that HTML IDs and the CSS ID selector have different syntaxes. You could write <div id="foo?">, but to select it would need #foo\?. |
| 07:43 | <TabAtkins> | SimonSapin: The reasoning is so we can add cors, integrity, etc to urls in CSS without having to invent a function with a new name. |
| 07:44 | <SimonSapin> | TabAtkins: Oh, so <function-token> only for URLs with quoted strings. I thought you meant <function-token name=url content=[<unquoted-url-body>]> |
| 07:44 | <TabAtkins> | Yup. |
| 07:44 | <IZh> | The spec has <a href=#is-this-html5?>...</a> and <h3 id=is-this-html5?>...</h3>. |
| 07:45 | <TabAtkins> | IZh: Yeah, that works. |
| 07:45 | <TabAtkins> | (? has a meaning in urls, but only *before* the hash. Once you're in the hash ? doesn't mean anything special.) |
| 07:46 | <TabAtkins> | zcorpan: What's the "rotated labels" you talked about? |
| 07:47 | <SimonSapin> | TabAtkins: sounds reasonable. There is a slight impl bug potential in forgetting to update some of the parser places that expect a url token to also look for a function token with name URL, but it may be worth it |
| 07:48 | <TabAtkins> | SimonSapin: Yeah, good point. |
| 07:52 | <TabAtkins> | SimonSapin: If we were allowed to output multiple tokens in a single pass to/from the initial state, we could handle unquoted urls as functions just fine. |
| 07:52 | <TabAtkins> | Hm, except for bad-url I guess. |
| 07:55 | <zcorpan> | TabAtkins: "Note" etc in the html spec. you need a browser that supports unprefixed 'transform' |
| 07:55 | <SimonSapin> | Some bad-url would become parser-level errors |
| 07:58 | <TabAtkins> | zcorpan: Ah, kk. |
| 08:00 | <TabAtkins> | SimonSapin: I guess we could still output an error token in that case with the same effect - it's a token that's guaranteed to never be in any grammar. |
| 08:00 | <TabAtkins> | But anyway, the guarantee that we only ever output one token per pass is a nice quality to preserve. |
| 08:01 | <TabAtkins> | I suppose we could just add a single bit of state to the tokenizer - an "in unquoted url?" bool. |
| 08:01 | <benjamingr> | Hixie: half (read 95%) of the time with promises you're not in a sync context but in a promise chain anyway, just like in callbacks often you're inside an emitter callback. A promise rejection that's unhandled causes the chain to stop running (unless it is handled). Throwing synchronously means you create different behavior when you start the chain and when |
| 08:01 | <benjamingr> | you're running it. |
| 08:04 | <benjamingr> | Maybe you have a point and we have to wrap the initial API calls with `Promise.try` (in ES6, Promise.resolve().then) calls anyway though, thinking about it. |
| 08:07 | <TabAtkins> | I mean, that's certainly *a* way to go about things, to guarantee that any mistakes you make don't cause something crazy. |
| 08:44 | <JakeA> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/285 - you're saying 1. would be the CSS base url, right? |
| 08:45 | <JakeA> | annevk: Because I think Alex thinks it's 2. |
| 08:45 | <JakeA> | annevk: (and I think it should be 3, so yey!) |
| 08:46 | <annevk> | JakeA: I think it should be 3 if you use default() |
| 08:46 | <annevk> | JakeA: otherwise the /fallback.html stuff sucks |
| 08:47 | <annevk> | JakeA: a good way to think about it is what URL you'd expect in the address bar |
| 08:48 | <JakeA> | annevk: This is for a CSS subresource, not a navigate. What do you think the base url would be using the code as it is (using fetch()) |
| 08:48 | <annevk> | JakeA: I think it should be 1 |
| 08:48 | <annevk> | JakeA: I realize this is for CSS, but I don't think we should apply different semantics to navigate necessarily |
| 08:49 | <annevk> | JakeA: the only thing that's special about navigate is that the invoking algorithm needs to have a say in redirect handling |
| 08:50 | <annevk> | TabAtkins: url("..." ...) sounds nice |
| 09:17 | <JakeA> | annevk: yeah, that makes sense. Just hate the magic of event.default(). What about request.followRedirects, which would be true for stuff coming through event.request? |
| 09:18 | <JakeA> | So fetch(event.request) would return an OpaqueResponse redirect if it hit one |
| 09:18 | <annevk> | JakeA: where is this proposal specified? |
| 09:19 | <JakeA> | annevk: In IRC just now :D |
| 09:20 | <annevk> | JakeA: what is an <img> element going to do if it gets handed an OpaqueResponse? It'll just fail |
| 09:21 | <JakeA> | annevk: If the OpaqueResponse is a redirect, doesn't the fetch spec deal with the rest of the redirects? |
| 09:21 | <JakeA> | annevk: (also, images will render OpaqueResponses fine, but they'll taint canvases) |
| 09:22 | <annevk> | JakeA: (not if the OpaqueResponse is a redirect) |
| 09:22 | <annevk> | JakeA: I think the idea was that only an explicit redirect from the service worker would be handled by Fetch |
| 09:23 | <annevk> | JakeA: anything else would just be passed back up the stack |
| 09:23 | <annevk> | Although I guess I can see arguments both ways... Hmm |
| 09:24 | <JakeA> | annevk: Is an OpaqueResponse redirect not an explicit redirect? |
| 09:24 | <JakeA> | I thought that was how event.default() would work |
| 09:24 | <JakeA> | if event.default() resolves to a redirect, it must be OpaqueResponse for security reasons |
| 09:28 | <annevk> | JakeA: an explicit redirect would be something like new RedirectResponse({status:301, location:...}) |
| 09:28 | <JakeA> | annevk: But isn't exposing that a security no-no? |
| 09:28 | <annevk> | JakeA: no, only network-level redirects cannot be exposed |
| 09:29 | <annevk> | JakeA: sorry, we would also not expose that one to the API, we would indeed follow it |
| 09:29 | <annevk> | JakeA: but not because of security |
| 09:30 | <JakeA> | annevk: what does event.default() resolve to if it hits a redirect? |
| 09:31 | <JakeA> | I thought it would be a redirect response, which would be opaque for security reasons |
| 09:35 | <annevk> | JakeA: it depends on the request instance |
| 09:35 | <annevk> | JakeA: if the manual redirect flag is not set (most cases), it just follows them and hands back a "flattened" response |
| 09:37 | <JakeA> | annevk: But there's a difference between SW doing the flattening and the fetch spec doing the flattening |
| 09:37 | <annevk> | JakeA: Fetch does it |
| 09:37 | <JakeA> | annevk: If you do fetch(url) the response url will always be the original url, despite redirects, right? |
| 09:38 | <annevk> | JakeA: the only case where an SW might be able to have another crack at a redirect (and this depends on the context) is when the manual redirect flag is set (navigate) or when the SW returns a redirect it created itself |
| 09:38 | <JakeA> | agreed |
| 09:38 | <annevk> | JakeA: if you do fetch(url) the response's url will be the final url |
| 09:38 | <annevk> | JakeA: no different from XHR.responseURL |
| 09:39 | <annevk> | JakeA: however, it's not clear the layer above SW (Fetch) cares about that URL |
| 09:39 | <annevk> | JakeA: my assumption has been that it does not, because of the /fallback and other cases |
| 09:40 | <JakeA> | annevk: I thought we couldn't expose responseURL for security reasons |
| 09:40 | <annevk> | JakeA: it might not be exposed in all cases |
| 09:40 | <annevk> | JakeA: depends on the type of response |
| 09:41 | <annevk> | (but it's certainly known to the UA) |
| 09:41 | <JakeA> | yeah |
| 09:44 | <annevk> | XHR can always expose it because XHR only does CORS, no tainted stuff |
| 09:44 | <JakeA> | annevk: event.default() returns a redirect if it hits one, which gets handed back to the fetch spec, which either hands that to the top level (if manual redirect is set) or follows the redirects without further SW interaction & uses the final url as the base url, right? |
| 09:44 | <JakeA> | (by top level I mean the fetch spec caller, sorry) |
| 09:45 | <annevk> | event.default() invokes Fetch with the original request instance and an override to bypass the SW; whatever it gets out of that it hands back to the SW |
| 09:46 | <annevk> | so it's very much like fetch() except that it uses the original request instance |
| 09:48 | <annevk> | (which also means it modifies the original request instance and therefore response's url and such are different; there's some details to figure out there as obviously the Request object exposed in the API cannot change, that needs to be a snapshot) |
| 09:49 | <JakeA> | annevk: So, going back to the CSS example, how does the response from respondWith(event.default()) end up with a difference base url than respondWith(fetch(event.request))? |
| 09:50 | <annevk> | I wish we had gone through this more at the F2F, I tried to push for it but everyone else seemed to think it was somehow clear... |
| 09:50 | <JakeA> | annevk: Thanks for going through it now though. Happy to jump on VC if you think it'd be easier |
| 09:50 | <annevk> | JakeA: fetch() creates a new (you could think of it as nested) instance of the request |
| 09:51 | <JakeA> | annevk: I don't think it matters what fetch() does, as the base url is set in the fetch spec, once it gets a response from SW |
| 09:52 | <JakeA> | annevk: As far as I can tell, the fetch spec gets the response from SW, and sets its response url (for base purposes) to request.url |
| 09:53 | <JakeA> | annevk: That's how the example on https://github.com/slightlyoff/ServiceWorker/issues/285 becomes 1. |
| 09:54 | <annevk> | JakeA: Fetch gets a Request R1, opens SW, SW initaties a *new* Fetch with R2 using fetch() and gets back a response, hands that back to R1 (R1 never saw it's url field change so sets that on the response) |
| 09:54 | <annevk> | JakeA: default() however keeps using R1 |
| 09:55 | <JakeA> | Ohhh ok *thinks* |
| 09:57 | annevk | is still trying to go through the IRC backlog |
| 09:58 | <JakeA> | Sorry, I realise I'm not helping |
| 10:02 | <JakeA> | annevk: I thought the fetch spec would open SW before step 7 of http://fetch.spec.whatwg.org/#concept-http-fetch, but the response would still hit step 10 that deals with redirects & 304 |
| 10:03 | <annevk> | JakeA: heh, it's just very long today, that's all |
| 10:04 | <JakeA> | so if the SW respondWith a redirect (opaque or not), it'd go through step 10, and follow the redirect but ignoring the SW |
| 10:05 | <annevk> | JakeA: well, a) it would follow the redirect if the manual redirect flag was unset and b) it would go back into the SW as following a redirect invokes Fetch |
| 10:18 | <annevk> | "I really wish people would just read the spec that Ian wrote and what I wrote about this on es-discuss in the past instead of making random assumptions..." |
| 10:19 | <annevk> | https://github.com/domenic/promises-unwrapping/issues/108#issuecomment-43691121 |
| 10:25 | <Ms2ger> | Let's move everything into ES |
| 10:25 | <Ms2ger> | There will certainly be no issues integrating them with the platform |
| 10:31 | <annevk> | Ms2ger: go do some homework :p |
| 10:32 | <Ms2ger> | Nah, I see what happens to bz's homework |
| 12:04 | <annevk> | JakeA: might want to check the logs regarding script loading |
| 12:05 | <annevk> | JakeA: seems <script needs> or some such is still floating around |
| 12:05 | JakeA | sobs |
| 12:13 | <annevk> | JakeA: if you don't like it you should talk to Hixie |
| 12:13 | <annevk> | JakeA: seems like he's investing time in it |
| 12:14 | <JakeA> | annevk: I'm not really against it, it was just a really painful thread last time around |
| 12:15 | <JakeA> | Hixie: Domenic: If we have <link rel=preload> which has a .loaded promise, you can do most of this delayed execution stuff yourself |
| 12:18 | <JakeA> | Hixie: Domenic: But for the simple case, I don't think we need anything more complex than <script depends=".css-selector">, where the CSS selector points to other script/img/link elements |
| 12:19 | <JakeA> | The dependencies can be calculated at document insertion time, which avoids circular dependencies. Also <script depends="script"> becomes a handy way to do sequential execution |
| 12:28 | <annevk> | JakeA: seems Hixie added ele.addDependency(promise) to the mix |
| 12:29 | <JakeA> | I think that's where having preload primitives is better. You can do whatever you want then |
| 13:26 | <jcgregorio> | annevk: I thought Object.observe didn't work for DOM? |
| 13:27 | <jcgregorio> | re navigator.language shipping thread |
| 13:27 | <annevk> | jcgregorio: it has hooks |
| 13:27 | <annevk> | jcgregorio: it doesn't work for everything, e.g. you wouldn't want it for ele.innerHTML, but for things where we already dispatch events it's fine |
| 13:30 | <jcgregorio> | ah ok, and for everything else there's MutationObserver? |
| 13:35 | <annevk> | jcgregorio: I guess it's more like MutationObserver is for trees, and O.o is for most other things |
| 13:47 | <caitp> | annevk (or others), is there a specific status code that should be expected when fetch/xhr send times out? |
| 13:48 | <caitp> | I'm not seeing one mentioned in fetch, but it's being asked about in a separate channel |
| 13:50 | <annevk> | caitp: 0 |
| 13:50 | <caitp> | where is that actually specified? |
| 13:50 | <annevk> | caitp: last bit is http://xhr.spec.whatwg.org/#request-error-steps where it sets response to a network error (whose status is 0) |
| 13:52 | <annevk> | One thing that could be improved is that XMLHttpRequest currently does not check the timeout attribute value continuously, seems a bit buggy |
| 13:57 | <caitp> | I believe it's stated in the specification (and tested in the wpt) that setting the attribute means setting the timeout to a new value relative to the start of the request, if a request had already started |
| 13:57 | <caitp> | which should mean "dispatch timeout if that time has already elapsed" |
| 13:57 | <annevk> | caitp: that's the bug I just mentioned |
| 13:58 | <caitp> | I'm not sure what you mean then, why would it need to be checked continuously if the behaviour that would happen when checking it, happens when the value changes? |
| 13:58 | <annevk> | if 50ms is enough accuracy I could just piggyback on the callbacks from Fetch |
| 13:59 | <annevk> | caitp: you might change the value to enlarge the window, but yeah, could be done in multiple ways, patches welcome |
| 14:00 | <jgraham> | hober: I think people still at Opera like critic too :p |
| 14:02 | <jgraham> | (but actually it generally seems like people who use it a bit don't have too many complaints, which fits my hypothesis that it's basically a good tool, with a learning curve and a slightly aesthetically displeasing frontend) |
| 14:02 | <caitp> | i'm still not sure what you mean, it seems like the instructions are spelled out, they just don't seem to be normative / are expressed sort of like hints |
| 14:02 | <caitp> | so if there's a bug, it's more that it's not expressed as a MUST or even SHOULD |
| 14:06 | <annevk> | caitp: there's none of that, everything follows from "The send(data) method must run these steps:" |
| 14:09 | <caitp> | http://xhr.spec.whatwg.org/#dom-xmlhttprequest-timeout it's more the "note" section, it's very awkward to have something like this stated as "this implies..." |
| 14:11 | <caitp> | fetch doesn't really make any mention of the behaviour dictated by this note, and nor does anywhere else in xhr, as far as I can see |
| 14:12 | <annevk> | caitp: right, that's why I said the text in the send() section is somewhat buggy |
| 14:13 | <caitp> | okay, I see what you're getting at |
| 14:50 | <zcorpan> | annevk: i introduced a new flag to <img> that is not exposed to JS in https://github.com/ResponsiveImagesCG/picture-element/pull/179 to fix https://code.google.com/p/chromium/issues/detail?id=372971 |
| 14:51 | <zcorpan> | annevk: but you can get an img with the flag set by doing innerHTML = '<img>' on an element in a document without a browsing context |
| 14:52 | <zcorpan> | not sure if this is relevant to the "implement a browser in JS" thing or whatever |
| 14:52 | <annevk> | zcorpan: I'm not sure what you're asking me, but "await a stable state" was recently factored out |
| 14:52 | <annevk> | zcorpan: ah I see |
| 14:53 | <annevk> | zcorpan: for that bit I recommend filing an issue here: https://github.com/dglazkov/html-as-custom-elements/issues |
| 14:53 | <zcorpan> | annevk: "await a stable state" is still defined, it's just defined in terms of microtasks |
| 14:53 | <annevk> | zcorpan: for removing "await a stable state" I suggest looking at how Hixie did that |
| 14:53 | <annevk> | oh |
| 14:54 | <annevk> | fair enough |
| 14:54 | <zcorpan> | so that should be fine i think. the img move happened after the stable state changes |
| 14:56 | <annevk> | Sometimes I wish the other XMLHttpRequest editors fixed some bugs |
| 14:58 | <zcorpan> | ok filed https://github.com/dglazkov/html-as-custom-elements/issues/15 |
| 15:03 | <zcorpan> | https://www.igvita.com/2014/05/20/script-injected-async-scripts-considered-harmful/ - was there any progress on declarative dependencies thing to get ordered execution for <script src async>? |
| 15:14 | <annevk> | zcorpan: see discussion from today's logs before we woke up |
| 15:43 | <annevk> | smaug____: if XHR provided a way to disable 401 dialogs, what should we call the flag? |
| 15:44 | <annevk> | smaug____: disableUserAgentAidedAuthentication |
| 15:45 | <annevk> | disableAssistedAuthentication |
| 15:45 | <Hixie> | annevk: 'await a stable state' is still there, actually, what was factored out is 'provide a stable state'. |
| 15:45 | <Hixie> | 'await a stable state' now just queues a microtask |
| 15:45 | <annevk> | Hixie: yeah zcorpan pointed that out, my bad |
| 15:45 | <Hixie> | ah right |
| 15:46 | <smaug____> | hmm |
| 15:46 | <smaug____> | the flag should have something about unauthorized |
| 15:47 | <annevk> | JakeA: this could be another difference between default() and fetch(); whether UA assisted authentication is enabled |
| 15:47 | <annevk> | smaug____: disable401Handling |
| 15:47 | <smaug____> | heh |
| 15:48 | <smaug____> | though, that is pretty clear |
| 15:48 | <annevk> | smaug____: Unauthorized is hard to spell |
| 15:48 | <annevk> | smaug____: and I don't think we want to mess with proxy authentication |
| 15:48 | <JakeA> | annevk: Makes sense |
| 15:48 | <annevk> | JakeA: for new APIs I'd really like to avoid popping up auth dialogs |
| 15:49 | <JakeA> | annevk: Should only be for navigations. Probably top-level at that |
| 15:49 | <annevk> | smaug____: can also have disable304Handling at some point |
| 15:50 | <annevk> | JakeA: currently pretty much everything does them |
| 15:50 | <annevk> | JakeA: might actually be compat problem to remove them |
| 15:50 | <smaug____> | I kind of like having the number there |
| 15:50 | <annevk> | JakeA: for things like <img> |
| 15:51 | <JakeA> | annevk: Yeah, actually hit that issue this morning. Interestingly, Chrome doesn't seem to support username:password@ urls on images |
| 15:51 | <JakeA> | iOS seems to |
| 15:51 | <JakeA> | Didn't test anything else |
| 15:52 | <JakeA> | Had to add an iframe to the page with the username:password@ url, *then* the images would load |
| 15:52 | <annevk> | JakeA: Fetch supports both variants, it's up to the API to define whether URL credentials take effect |
| 15:52 | <JakeA> | But the iframe made iOS have a phishing panic |
| 15:53 | <annevk> | smaug____: ta |
| 16:15 | <annevk> | Ms2ger: constraints seems correct, no? |
| 17:32 | <Ms2ger> | annevk, as the verb? Doesn't sound right to me, but I guess we should ask a native :) |
| 17:34 | <Ms2ger> | "The XMLHttpRequest standard intentionally constraints the use of HTTP here in line with contemporary implementations." |
| 17:34 | <Ms2ger> | Native speakers, please comment |
| 17:46 | <Domenic> | should be constrains |
| 17:46 | <Domenic> | a constraint is a noun; constrain is a verb |
| 17:47 | <SamB> | "in line with contemporary implementations" seems a bit odd ... somehow |
| 17:49 | <SamB> | (maybe some more specific explanation of the reasoning would be better?) |
| 18:54 | <IZh> | Some of the links in spec points to redirecting pages. Should it be corrected to point to "final" pages? |
| 18:56 | <IZh> | For example, there is a link to http://whatwg.org/html that redirects to http://www.whatwg.org/html that redirects to http://www.whatwg.org/specs/web-apps/current-work/multipage that redirects to http://www.whatwg.org/specs/web-apps/current-work/multipage/ |
| 18:57 | <IZh> | Shouldn't we point the link against real page? |
| 18:57 | <IZh> | Point to. |
| 18:59 | <IZh> | IMHO 3 redirects is too much. |
| 19:50 | <IZh> | For beautiful url with ability to change real page in the future, I suppose, one redirect is enough. |
| 19:51 | <SamB> | IZh: you would think it could at least combine the first two ... |
| 19:52 | <SamB> | well, actually, combining all three redirects into one wouldn't seem all that much to ask ... |
| 19:54 | <IZh> | In the spec there are dozen of links that points to redirects of different depth. The 3 is the maximum, but there are lots of 2 |
| 19:56 | <Hixie> | IZh: i use the link whatwg.org/html because that's the shortest link and so people might remember it. |
| 19:57 | <Hixie> | zcorpan: whatwg.org redirects everything to www.whatwg.org so that all cookies so that there's only one canonical domain |
| 19:57 | <SamB> | I thought there were technically some shorter ones (but which are irrelevant since not actually memorable) |
| 19:57 | <Hixie> | er, s/zcorpan/IZh/ |
| 19:58 | <Hixie> | IZh: then .../html does the redirect to .../multipage, since that's what it's a shortcut for |
| 19:58 | <Hixie> | IZh: then apache does the redirect to add the / |
| 19:58 | <Hixie> | IZh: we can't add the / at the third step because otherwise if you went to .../html/ you'd end up at .../multipage// |
| 19:59 | <SamB> | hmm |
| 19:59 | <SamB> | no regexen? |
| 19:59 | <Hixie> | it's even better if you go to .../html#foo because then you get a javascript redirect after all the above... |
| 19:59 | <IZh> | Hixie: yes, I see. But why not shorten the path? |
| 19:59 | <Hixie> | which path? |
| 20:00 | <IZh> | Hixie: I mean, why so deep? |
| 20:00 | <SamB> | oh, you mean just actually have the spec at /html/ ? |
| 20:00 | <Hixie> | oh well there used to be multiple specs and there used to be multiple snapshots |
| 20:00 | <zcorpan> | Hixie: can't you write two rules, /html redirects to multipage/ and /html/ redirects to multipage/ ? |
| 20:00 | <Hixie> | zcorpan: maybe, dunno |
| 20:00 | <IZh> | Why not point html to multipage/ in one step? |
| 20:00 | <Hixie> | <Hixie> IZh: we can't add the / at the third step because otherwise if you went to .../html/ you'd end up at .../multipage// |
| 20:01 | <Hixie> | zcorpan: btw should i be moving the <img> bugs you filed to HTML - <img>? |
| 20:01 | <Hixie> | zcorpan: or are they for me later? |
| 20:01 | <zcorpan> | Hixie: sure |
| 20:01 | <Hixie> | k |
| 20:01 | <zcorpan> | Hixie: one <img> is for you |
| 20:02 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=25848 |
| 20:02 | <Hixie> | i'm behind on bugs, been working on e-mail |
| 20:03 | <zcorpan> | but i think it's ok for you to wait a bit with that bug |
| 20:03 | <IZh> | Hixie: I think it's possible to make 2 redirects: both html and html/ to multipage/ |
| 20:03 | <Hixie> | yeah that's what zcorpan suggested |
| 20:03 | <Hixie> | zcorpan: k |
| 20:05 | <zcorpan> | Hixie: if you remember rationale for some of the <img> bugs i filed i'd be happy if you could add a comment |
| 20:05 | <Hixie> | k |
| 20:07 | <zcorpan> | in other news, i hate moving 7 timezones. it fucks up my sleep |
| 20:08 | <IZh> | Hixie: Good news. Validator that I use did not found any serious errors in the spec. :-) |
| 20:08 | <IZh> | Hixie: Just some accessibility and some CSS issues. |
| 20:10 | <zcorpan> | what are the claimed acc issues? |
| 20:11 | <IZh> | zcorpan: One iframe lacks of "title" attribute. |
| 20:12 | <zcorpan> | ... |
| 20:14 | <zcorpan> | gsnedders: have you checked out the Pixel one or whatever it's called? |
| 20:15 | <zcorpan> | oh, TabAtkins already suggested that |
| 20:25 | <IZh> | In the FAQ there are some broken links. |
| 20:25 | <IZh> | In "When will we be able to start using these new features?" there is a link to http://dev.opera.com/articles/html/ |
| 20:28 | <IZh> | In "What are the various versions of the HTML spec?" there is a broken link to W3C Microdata: http://dev.w3.org/html5/md/ |
| 20:29 | <IZh> | And at the same place the link to http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/ |
| 20:30 | <Hixie> | feel free to edit that page |
| 20:30 | <Hixie> | let me know if you need a login to the wiki |
| 20:31 | <IZh> | First of all we need alive links there. |
| 20:35 | <IZh> | Hixie: There are two links for Microdata: http://www.w3.org/TR/microdata/ and http://www.w3.org/html/wg/drafts/microdata/master/ Which one you prefer? |
| 20:36 | <IZh> | Latest published or editors draft? |
| 20:37 | <Hixie> | IZh: i "prefer" http://whatwg.org/html#microdata |
| 20:37 | <SamB> | IZh: well it was an editor's draft before |
| 20:38 | <Hixie> | if we're talking about what the url to the w3c fork of it should be, then it should be the one that isn't in /TR/ |
| 20:38 | <estellevw> | I just removed "The disabled attribute is ignored if the value of the type attribute is hidden" from the display attribute on MDN pages. I see that on w3schools, but I didn't see that as "fact" in the spec. Am I wrong? Is disabled is not supported on input type hidden? It doesn't submit in my test, but it's odd to think that a myth somehow got started. Was that ever the case? |
| 20:39 | <Hixie> | estellevw: see the "bookkeeping details" in http://www.whatwg.org/specs/web-apps/current-work/#hidden-state-(type=hidden) |
| 20:39 | <estellevw> | was disabled on input type hidden ever ignored, or is it ignored in any browsers that anyone knows of? |
| 20:39 | <estellevw> | thanks |
| 20:40 | <Hixie> | oh hm |
| 20:40 | <Hixie> | looks like "disabled" always applies maybe? |
| 20:40 | <Hixie> | yeah, check http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-disabled |
| 20:40 | <Hixie> | type=hidden has no relevance to disabled="" |
| 20:42 | <estellevw> | yeah, i had read both of those, so decided to remove that sentence from MDN page, but have since seen it mentioned on w3schools and stack overflow, so wanted to confirm |
| 20:42 | <estellevw> | thanks |
| 20:44 | <Hixie> | w3schools is so full of nonsense it's not worth even considering in any capacity regarding whether something is true or not |
| 20:49 | <wilhelm> | I recently discovered they're five guys, and have a turnover of more than 3M USD. Not too bad for a scam. |
| 20:49 | <Hixie> | i've been happy to see MDN starting to take over in my google results |
| 20:49 | Hixie | is a big fan of MDN |
| 20:50 | <estellevw> | yeah, that was why i got confused. MDN was wrong. Wasn't sure if W3Schools copied MDN or the other way around |
| 20:50 | <Hixie> | heh |
| 20:50 | <Hixie> | i'm sure w3schools didn't copy mdn |
| 20:50 | <Hixie> | they probably made it up |
| 20:51 | <wilhelm> | But MDN doesn't have certifications! How else can I document my skills? http://www.refsnesdata.no/certification/w3certified.asp?id=5204222 |
| 20:51 | <estellevw> | I am currently updating the Wufoo form pages, and that will hopefully be very accurate. I am updating MDN as i find new stuff for the Wufoo page. |
| 20:51 | <estellevw> | wilhelm: haha |
| 20:51 | <tantek> | wow, I just don't even: http://www.w3schools.com/cert/default.asp |
| 20:53 | <estellevw> | no longer haha. now whaaaaa, or however you write a cry. So sad. |
| 20:53 | <wilhelm> | tantek: Yup, that's how the manager of a five-person company can pay himself 1M USD per year. |
| 20:53 | <tantek> | from that page: "Highly Recommended / W3Schools' tutorials are recommended reading in over 100 Universities and High schools all over the world." (lists 9 examples of universities) |
| 20:54 | <tantek> | Ok, so the next time someone asks me about university-based web dev education vs. self-taught web dev hackers, I am going to point them to this. What a disaster. |
| 20:55 | <caitp> | you laugh, but those kids will be making the snapchats and tinder |
| 20:56 | <caitp> | of tomorrow |
| 20:56 | <tantek> | and their citations seem to check out too (checked 3 out of 9), and they link to specific University pages which link to W3schools |
| 20:56 | <caitp> | and getting rich off it despite not providing anything of any real value |
| 20:56 | <tantek> | caitp - not as bad as finance industry with making up financial "instruments" which then make money out of nothing |
| 20:56 | <IZh> | Hixie: Please make me an account on Wiki. |
| 20:57 | <tantek> | so what this tells me is that W3C should issue certificates instead |
| 20:57 | <tantek> | as a funding model alternative to membership fees |
| 20:57 | <caitp> | lets turn the W3C into a for-profit school like devry |
| 20:57 | <caitp> | it will be brilliant |
| 20:57 | <caitp> | nothing could go wrong |
| 20:58 | <wilhelm> | Here's a selection of gullible people paying money for that scam: https://google.com/search?q=site%3Arefsnesdata.no |
| 21:00 | <caitp> | you could even get the w3c its own faculty at university of phoenix |
| 21:00 | <Hixie> | IZh: e-mail address? |
| 21:01 | <IZh> | Hixie: izh1979⊙gc |
| 21:01 | <Hixie> | don |
| 21:01 | <Hixie> | done |
| 21:02 | <SamB> | tantek: you want the W3C to be a CA? |
| 21:02 | <IZh> | Hixie: Thank you. |
| 21:07 | <IZh> | Grr... Even http://www.w3.org/TR/microdata/ contains broken link to latest editor's draft. So there is no known link to it. |
| 21:09 | <tantek> | lZh don't bother linking to any W3C microdata resources - W3C has abandoned microdata. The *only* reference is WHATWG microdata. |
| 21:09 | <tantek> | (boom) |
| 21:10 | <SamB> | I can't tell if that's even nice |
| 21:10 | <Hixie> | it's what i'd like them to do to all the specs |
| 21:10 | <Hixie> | (that they fork from us) |
| 21:11 | <SamB> | well, I mean, is it because they despair of the idea or is it just that they dispair of hijacking the idea |
| 21:11 | <SamB> | the latter is clearly good |
| 21:11 | <Hixie> | oh i'm sure they did it because it competes with RDFa |
| 21:11 | <Hixie> | and since anyone who cares about microdata is just gonna do it in the WHATWG, they no longer had anyone there advocating for it |
| 21:11 | <Hixie> | so the RDFa voices could get their fork shut down |
| 21:12 | <Hixie> | speaking of forks, i wonder how the w3c's fork of anne's URL spec that replaces the IETF URL spec is coming along |
| 21:20 | m4nu | wakes up to RDFa/Microdata snarkiness. |
| 21:21 | <m4nu> | huh, when did Microdata become a NOTE at W3C? Last I heard, it was barreling down the REC track? |
| 21:21 | <Hixie> | hey, for once, there wasn't actually any snarkiness there :-) |
| 21:21 | <m4nu> | :P |
| 21:22 | <Hixie> | i mean, i have barrels of it i could deploy, but i was holding back :-) |
| 21:22 | m4nu | appreciates Hixie's restraint. |
| 21:22 | m4nu | wonders if he should see if HTML5+RDFa has been NOTE'd as well. |
| 21:22 | <m4nu> | 'cause I haven't been paying attention to what's been happening in the W3C HTML WG... |
| 21:22 | <Hixie> | heh |
| 21:23 | <Hixie> | text/html RDFa is happening in the HTMLWG? |
| 21:23 | <Hixie> | i thought that was an RDF world thing |
| 21:23 | <m4nu> | does seem kind of bad form to not point to WHATWG Microdata spec as "Latest Editor's Draft" |
| 21:23 | <SamB> | indeed |
| 21:23 | <Hixie> | that's the least of the troubles on that front |
| 21:24 | <Hixie> | q.v. http://lists.w3.org/Archives/Public/www-archive/2014Apr/0034.html |
| 21:26 | m4nu | remembers reading that missive... I remember agreeing w/ about 65% of it. |
| 21:27 | <Hixie> | presumably the consensus parts are in the 35%? |
| 21:29 | <m4nu> | maybe 20% of it - I'm not a card carrying consensus-is-the-only-way member. Other 15% had to do w/ things like "Tim has the final say." arguments (yes he does, but in practice, doesn't use it) |
| 21:29 | <Hixie> | well if he doesn't have the final say, that means the relevant wg's chair does |
| 21:30 | <Hixie> | the way the w3c is structured, there's always someone who has the final say. |
| 21:30 | <m4nu> | in any case, good email, I've been pointing people at it to try and explain why the WHATWG/W3C dynamic isn't a simple one. |
| 21:30 | <Hixie> | (and that person is rarely the person who truly has the final say, the implementor) |
| 21:31 | <m4nu> | yeah, but again - I don't think that's a terrible thing to have a tie-breaker... and I agree w/ you wrt. implementors have the final say. |
| 21:31 | <m4nu> | just think that there needs to be something there to balance the multi-billion dollar multinationals w/ the general public. |
| 21:31 | <m4nu> | (wrt. privacy rights, centralization, etc.) |
| 21:32 | <Hixie> | (there's also a less-well-written sequel, if you're pining for me hixie-ranting: http://lists.w3.org/Archives/Public/www-archive/2014Apr/0039.html ) |
| 21:32 | <m4nu> | anyway, don't want to spam this channel w/ all of that stuff... |
| 21:32 | <Hixie> | it's ok, nobody else is talking right now :-D |
| 21:32 | <Hixie> | obviously i don't think it's bad for someone to be tie-breaker |
| 21:33 | <Hixie> | since that's how everything works in the whatwg too :-) |
| 21:33 | <Hixie> | my point is mainly that the w3c's claimed process -- consensus -- isn't the actual process |
| 21:33 | <Hixie> | the actual process is more subtle and complicated |
| 21:33 | <SamB> | m4nu: what would you prefer it be spammed with? |
| 21:34 | <m4nu> | cat pictures and discussion about how we're going to fix the Web login mess... and pervasive monitoring. |
| 21:35 | <Hixie> | 🐱 ? |
| 21:35 | <m4nu> | \o/ ! |
| 21:35 | Hixie | wonders if that showed up right for anyone at all |
| 21:36 | <m4nu> | did for me... |
| 21:36 | <Hixie> | nice |
| 21:36 | <Hixie> | what irc client? |
| 21:36 | <m4nu> | xchat |
| 21:36 | <Hixie> | wow |
| 21:36 | <Hixie> | impressive |
| 21:36 | m4nu | thinks it has more to do w/ how your font server is configured than anything else. |
| 21:37 | <Hixie> | ah, could be |
| 21:37 | <Hixie> | i'm on mac here |
| 21:37 | <Hixie> | it displayed as a question mark :-) |
| 21:37 | <jeffreyatw> | it did for me, on colloquy |
| 21:37 | <m4nu> | Hixie: re: claimed process of consensus - yes, I agree that there are good points to be made that W3C doesn't practice what they preach at times (WHATWG spec forking being an example of that)... and there is a lot of big corporate interest in W3C that makes dumb stuff happen sometimes, and perhaps we'd be better off if that was tamped down a bit. |
| 21:39 | <m4nu> | anyway - bottom line - it's good that both the WHATWG and W3C exist and do what they do, even though it's a pain in all of our collective asses for a non-trivial chunk of the year. |
| 21:39 | m4nu | afks. |
| 21:40 | <SamB> | m4nu: which chunk of the year is it non-painful for? |
| 21:41 | <Hixie> | vacation? |
| 21:42 | <Hixie> | there's lots of specs being developed at the w3c that are fine |
| 21:42 | <Hixie> | it's just the way they insist on forking our specs that i find asinine |
| 22:02 | <tantek> | Hixie: ACK: 🐱 |
| 22:53 | <Hixie> | so about promises... |
| 22:53 | <Hixie> | is it possible to subclass promises so that they include more information? |
| 22:53 | <Hixie> | consider the thing we were talking about yesterday, where a script needs to be told to wait for an image, so the image's .loaded promise is given to the script so it can wait for the promise |
| 22:53 | <Hixie> | what if the image itself is also in "whenneeded" mode, and so is waiting until someone needs it before it loads? |
| 22:53 | <Hixie> | is there some way i can subclass the promise to provide a way to signal back to the promise vendor that the image is now needed? |
| 23:03 | <Hixie> | JakeA: why .ready for document and .loaded for img/link/etc ? |
| 23:04 | <Hixie> | oh, i see |
| 23:04 | <Hixie> | document would have .loaded too |
| 23:05 | <Hixie> | and .ready would be for just when it's parsed |
| 23:05 | <Hixie> | i suppose script could have a .ready too to mean .execute() would occur immediately if called |