| 01:21 | <Domenic_> | annevk-cloud: does https://twitter.com/briankardell/status/390635642407124992 mean copy-paste from WHATWG to W3C? |
| 01:27 | <MikeSmith> | Domenic_: what it means will be up to slightlyoff and Robin, but I think you know them well enough to know they may not just going to be doing copy-paste |
| 01:28 | <Domenic_> | more forking? :-/ |
| 01:28 | <MikeSmith> | though really I'm just speculating because I don't actually know what the details of the plan are |
| 01:30 | <MikeSmith> | Domenic_: yeah, one way or the other |
| 01:35 | <MikeSmith> | Domenic_: but really if you want more than speculation I guess you should ask slightlyoff and robin what the plan is :) |
| 01:36 | <Domenic_> | MikeSmith: indeed, I forgot they lurked here sometimes. |
| 03:47 | <Hixie_> | i feel like i'm missing some context or the lastest w3c meme :-) |
| 03:49 | <nimbu1> | lol latest one is gold. |
| 04:12 | <cabanier> | I get all my news from w3c memes |
| 04:20 | <nimbu1> | ahahhahahah |
| 04:20 | <nimbu1> | that can be a meme cabanier |
| 05:13 | <MikeSmith> | So I interpret that w3c meme as coded language that's basically saying, "Hakon should be the chair of the CSS WG" |
| 05:13 | <MikeSmith> | in which case, +1 |
| 05:20 | <karlcow> | http://lists.w3.org/Archives/Public/www-style/2013Oct/0385.html |
| 05:21 | <nimbu1> | lol MikeSmith |
| 05:44 | <Hixie_> | karlcow: it's the bottom text i don't understand, and the caption at the bottom |
| 05:48 | <MikeSmith> | I don't know if the context of the caption at all but even out of whatever the intended context is, It's just funny |
| 06:01 | <annevk> | Domenic_: you'll have to ask darobin and slightlyoff as I've no idea |
| 06:01 | <annevk> | Domenic_: W3C just forks, they don't really communicate about it with the original author |
| 06:02 | <annevk> | Domenic_: see http://lists.w3.org/Archives/Public/public-i18n-core/2013OctDec/0013.html |
| 08:40 | <zcorpan> | Hixie_: so if i understand correctly, the objection with DOMRectReadOnly wasn't that nobody is allowed to mutate it, but that DOMRect inherits from DOMRectReadOnly and so a mutable object has DOMRectReadOnly in the prototype chain which looks like a lie |
| 08:41 | <annevk> | hsivonen: so I thought <iframe></iframe><script>window[0].document.body.innerHTML = "bah"</script> was required to work |
| 08:41 | <annevk> | hsivonen: but it seems it's not... |
| 08:54 | <MikeSmith> | zcorpan: I haven't had time to mess around with the non-spec parsing idea further. I think where we had left it, it seems like my hacks were causing the script end tag to not get emitted as expected. Because the script element was still on the stack of open elements at the point where it crashed (where it's supposed to be handling the body start tag) |
| 08:56 | <zcorpan> | MikeSmith: ok. i guess it's clear that none of us know what we're doing :-P |
| 08:57 | <zcorpan> | i don't understand how the handling of the script end tag is affected by the changes |
| 09:01 | <MikeSmith> | zcorpan: yeah I looked back at the code and I don't understand either how it would be affecting it. Honestly it could just be that the hack I put in to serialize the stack out to |
| 09:01 | <MikeSmith> | ...stdout is broken too |
| 09:02 | <annevk> | zcorpan: so a subclass should not be able to access private state? |
| 09:02 | <annevk> | zcorpan: is that the contention? |
| 09:02 | <MikeSmith> | zcorpan: but yeah I don't really know what I'm doing with that code |
| 09:03 | <zcorpan> | annevk: see http://lists.w3.org/Archives/Public/public-script-coord/2013OctDec/0126.html |
| 09:04 | <annevk> | zcorpan: all I read in that email is Mark Miller agreeing |
| 09:06 | <zcorpan> | annevk: yet he objects to the name ReadOnly, so i must have misunderstood the argument. also see http://www.w3.org/mid/CABHxS9j_HshM-sHBL1cxpk+ACf91eKhvcihrLYtGJxCWEE=yBQ⊙mgc |
| 09:09 | <annevk> | zcorpan: interesting, I wonder if he's willing to expand on that, I'll reply |
| 09:42 | <zcorpan> | maybe role=region by default for <section> is a mistake? |
| 09:45 | <zcorpan> | aria's definition of region seems like a good match (except "large" i guess) http://www.w3.org/TR/wai-aria/roles#region |
| 09:47 | <zcorpan> | "Authors SHOULD ensure that a region has a heading referenced by aria-labelledby." |
| 10:05 | <annevk> | Game of Thrones fans: http://www.youtube.com/watch?v=5Krz-dyD-UQ |
| 10:27 | <jgraham> | (fwiw I note that using "readonly" to mean "not user editable" appears to be very common in GUI framworks e.g. both win32 and Qt seem to use that terminology) |
| 10:29 | <jgraham> | zcorpan: I assume the argument against making DOMRect extends DOMRectReadOnly is that DOMRect violates the contract of DOMRectReadOnly so it doesn't follow the LSP |
| 10:30 | <zcorpan> | jgraham: right |
| 10:30 | <jgraham> | It's an argument of the form "you can't have Square extends Rectangle because doing sqaure.width = 4 will also set square.height = 4, which violates the invariants of Rectangle |
| 10:31 | <jgraham> | Personally I'm not convinced that it's a more-than-theoretical concern |
| 10:31 | <jgraham> | Especially in JS |
| 10:33 | <jgraham> | (I don't really see how you could have any inheritance between a Foo and a Foo[View|ReadOnly] and conform with the LSP, so I think the only theoretically pure solution is to have two entirely seperate interfaces) |
| 10:34 | <annevk> | Yeah, use mixins or some such |
| 10:34 | <jgraham> | (even if they access the same underlying data) |
| 10:38 | <annevk> | Well, what roc suggested early on in the thread works too. |
| 10:38 | <annevk> | DOMRectBase; DOMRectReadonly extends DOMRectBase; DOMRect extends DOMRectBase; |
| 10:39 | <darobin> | it might be a completely stupid idea, but could frozen objects be used instead here? |
| 10:39 | <darobin> | I mean, you just define DOMRect, which is mutable and all |
| 10:39 | <annevk> | darobin: frozen doesn't mean what you think it means |
| 10:39 | <darobin> | and when you need to return a readonly one, you say [Frozen] DOMRect |
| 10:39 | <darobin> | oh, right, not the values |
| 10:40 | <annevk> | Best to mostly forget about Object.freeze() et al. They're only useful for Caja... |
| 10:40 | <darobin> | wrong term, but the idea still holds |
| 10:40 | <darobin> | I was thinking frozen as in, you know, frozen; not Object.freeze() |
| 10:40 | <annevk> | darobin: TabAtkins explored that idea, same fread |
| 10:40 | <annevk> | thread, evne |
| 10:40 | <darobin> | ah. missed that |
| 10:40 | <annevk> | even, even |
| 10:46 | <MikeSmith> | annevk: thanks for the info about JSIDL |
| 10:46 | <MikeSmith> | hope somebody takes an interest in working on it |
| 10:46 | <jgraham> | Yes, an abstract base class works |
| 10:46 | <annevk> | MikeSmith: apparently Domenic_ was planning to, but then we hijacked him to work on Promises & Streams, which seems much more useful anyway |
| 10:47 | <jgraham> | But javascript doesn't have any real concept of abstract classes |
| 10:47 | <MikeSmith> | annevk: I thought you guys were done on Promises |
| 10:47 | <MikeSmith> | btw what is XHR referencing for Streams now? |
| 10:48 | <annevk> | I kinda like my idea of last night to have the ECMAScript standard library defined in IDL. Anyway... |
| 10:48 | <annevk> | MikeSmith: nothing at the moment |
| 10:48 | <MikeSmith> | last I remember CHrome had implemented some support for Feras's spec |
| 10:48 | <annevk> | MikeSmith: ES5 promises is done, ES6 promises requires subclassing, which is tricky so there's a few issues left in the spec |
| 10:48 | <Domenic_> | MikeSmith: to have them be ES6-acceptable they need to work well with ES6 subclassing, so that's what's currently undergoing work. They are complete at the ES5 level |
| 10:48 | jgraham | thinks JSIDL seems like a waste of time |
| 10:48 | <Domenic_> | haha jinx |
| 10:49 | <Domenic_> | annevk: I like that idea to, for sure. |
| 10:49 | <MikeSmith> | getting Domenic_ and annevk in stereo :) |
| 10:50 | <MikeSmith> | so is Feras's Streams spec dead? |
| 10:50 | <annevk> | MikeSmith: yeah and the discussion on public-webapps is mostly being ignored too |
| 10:50 | <MikeSmith> | ok |
| 10:51 | <annevk> | jgraham: it's not helpful to be so negative all the time |
| 10:52 | <jgraham> | I'm not being negative all the time |
| 10:52 | <annevk> | jgraham: about JSIDL you are |
| 10:52 | <jgraham> | I think that JSIDL has lots of costs and very little value |
| 10:52 | <annevk> | jgraham: there are some smart people out there that want to explore it, let them be, just saying "it's a waste of time" isn't helping anyone |
| 10:52 | <jgraham> | for any person that's qualified to work on it, there are half a dozen more useful things that they could be doing |
| 10:53 | <annevk> | jgraham: the same could be said for working on Fetch |
| 10:53 | <annevk> | jgraham: improvements to the immediate status quo are marginal |
| 10:53 | <jgraham> | If you really believe that, I urge you to stop working on Fetch |
| 10:54 | <annevk> | I don't believe that, but if there's someone out there that would keep saying "it's a waste of time", I fould find that hugely irritating |
| 10:54 | <annevk> | and not very helpful |
| 10:55 | <jgraham> | Well if people are determined to work on it then nothing I can say is going to stop them. But so far the arguments in favour of it have been very weak. "Syntax slightly more like JS" doesn't seem like a big win. |
| 10:56 | <jgraham> | And there is a huge cost if specs start using something that isn't supported by bindings generators for implementations |
| 10:56 | <annevk> | If you think that's the main argument... |
| 10:57 | <jgraham> | Because you either need to implement a second set of bindings generators or port everything to WebIDL |
| 10:57 | <darobin> | the cost isn't in the binding generators |
| 10:57 | <darobin> | the cost is in remembering what a given WebIDL construct actually does in JS when the match doesn't line up all that well |
| 10:57 | <jgraham> | It's the main argument that I've heard that couldn't be achieved by incremental improvements to WebIDL |
| 10:58 | <jgraham> | darobin: Those seem like costs for quite different people |
| 10:59 | <darobin> | yeah, for the people writing and reading specs; they tend to be a pretty important constituency for this stuff :) |
| 11:00 | <darobin> | and anyway, when people are working on something that doesn't seem very useful to me, there are two situations |
| 11:00 | <darobin> | 1) they're smart, so they probably know why they're doing it |
| 11:00 | <darobin> | 2) they're dumb, so it doesn't matter |
| 11:01 | <annevk> | darobin++ |
| 11:01 | <jgraham> | I don't think those are an active characterisation of the possibilities at all |
| 11:01 | <jgraham> | For example there is 3) They are smart but haven't considered the oppertunity costs of the work |
| 11:01 | <darobin> | no, but you have to admit that it makes for neat little boxes |
| 11:02 | <jgraham> | (and a whole bunch more about oppertunity costs and so on that I won't type out) |
| 11:02 | <darobin> | there clearly would be an opportunity cost in you typing more about opportunity costs |
| 11:03 | <jgraham> | If the world was full of smart people doing useful things and dumb people doing irrelevent things it would be a lot better |
| 11:03 | <annevk> | Playing the conservative card is not helpful. Disruption is good. |
| 11:03 | <jgraham> | But instead you have lots of smart people doing irrelevant things |
| 11:03 | <darobin> | smart people shaving yaks have been known to produce useful things once in a while |
| 11:04 | darobin | makes some tea for grumpy jgraham |
| 11:04 | <Domenic_> | like yak fur |
| 11:04 | <darobin> | mmmm, a yak fur pillow |
| 11:04 | <jgraham> | I'm not really grumpy. If there's one thing I'm sure of it's that the people who talk about JSIDL don't give a fuck what I think |
| 11:05 | <darobin> | anyway, with these fine words about smart people doing irrelevant things let me get back to work |
| 11:05 | <Domenic_> | jgraham: i dunno, your words are more hurtful/discouraging than you might imagine. |
| 11:06 | <darobin> | yeah, being negative on the premise that people don't care runs the risk that they actually do |
| 11:06 | <jgraham> | But I don't want all discussions in the present to be dragged through "but in the future JSIDL…" |
| 11:06 | <annevk> | jgraham: I have invested time in JSIDL and I care |
| 11:06 | <darobin> | that is very much a fair (and constructive) point |
| 11:07 | <annevk> | And I do think it's useful to think about what things might look like five years from now. And how a world where C++ is an implementation detail would work, and what that would simplify at the IDL level. |
| 11:08 | <annevk> | And whether we call that JSIDL or an iteration over IDL I care less about. I have been pushing changes to the latter in the absence of the former, but it's the same thing imo. |
| 11:08 | <jgraham> | I don't think it's the same thing at all |
| 11:09 | <jgraham> | One is iterative improvement |
| 11:09 | <jgraham> | The other is "throw it all out and start again" |
| 11:09 | <annevk> | Even heycam thinks he might have to do a bunch of drastic changes at once which would require a bunch of down-level work. |
| 11:09 | <darobin> | those aren't the only two options jgraham |
| 11:10 | <darobin> | jgraham: for instance, you can have "look, we figured out where we want to get that's a nice place, now we can move WebIDL closer to that in increments" |
| 11:10 | <annevk> | And having some people work on a clean slate approach helps informing the iterative movement. |
| 11:10 | <darobin> | figuring out what works and how to get there are different things |
| 11:11 | <jgraham> | I have already said that I think iterative improvements are good |
| 11:12 | <jgraham> | What *does* make me grumpy is crap like they are pulling with ServiceWorker where people refuse to use WebIDL and end up externalising the cost onto vendors and ultimately users through poorer interop. |
| 11:12 | <annevk> | Both are good. Just like having many programming languages is good. Temporary competition here can be great I think. |
| 11:12 | <annevk> | ServiceWorker isn't even a specification... It's just a set of notes and a TypeScript file... |
| 11:12 | <jgraham> | And yet it is being implemented |
| 11:13 | <jgraham> | That is exactly what is annoying about it |
| 11:13 | <annevk> | IDL or JSIDL has nothing to do with that. |
| 11:13 | <darobin> | didn't I just see that there was IDL somewhere that was gonna be contributed there? |
| 11:13 | <annevk> | Yeah, jdm created some IDL. |
| 11:14 | <jgraham> | annevk: It does if some specs are written in one dialect and some are written in another dialect and people only implement a single dialect |
| 11:14 | <annevk> | jgraham: ServiceWorker is not a spec |
| 11:14 | <jgraham> | annevk: You are not making it better |
| 11:14 | <annevk> | jgraham: and do you honestly think that's going to be the end situation? |
| 11:14 | <jgraham> | It is a technology that is being put in browsers |
| 11:14 | <annevk> | jgraham: transitions are always messy |
| 11:15 | <jgraham> | I don't really care if it gets a spec months after the implementations have shipped |
| 11:15 | <jgraham> | Because by then the damage is done |
| 11:15 | <annevk> | IDL is not going to make the damage any less, I can tell you that |
| 11:15 | <jgraham> | Seriously? |
| 11:15 | <annevk> | Especially since IDL is not interoperably implemented at the moment |
| 11:15 | <jgraham> | There are two reasons it would |
| 11:16 | <jgraham> | One is that IDL is directly supported by browsers so you can quickly get some level of interop at the bindings layer |
| 11:16 | <annevk> | All the issues are going to be in the processing model. Lifetime and such. |
| 11:17 | <jgraham> | And the second is that being prepared to write a spec and IDL suggests an interest in working with the community on their own terms, rather than doing your own thing because you can't hold your nose and use a technology you don't like |
| 11:18 | <annevk> | It seems your beef is with ServiceWorker and not the idea of JSIDL... |
| 11:18 | <annevk> | Did you email Alex? |
| 11:19 | <jgraham> | I specifically said that this complaint was about ServiceWorker |
| 11:33 | <MikeSmith> | about IDL not being interoperably implemented, does that mainly mean not implemented per spec in Blink? |
| 11:33 | <MikeSmith> | because Gecko now prety much follows the current spec, right? |
| 12:25 | <annevk> | MikeSmith: yeah, Blink and WebKit I suppose |
| 12:26 | <annevk> | Though to be fair to them, there's a bunch of bugs against the spec, too |
| 12:27 | <MikeSmith> | annevk: yeah but modulo those bugs I've heard there's some problem that prevents them from implementing it per spec |
| 12:27 | <MikeSmith> | performance issue or something? |
| 12:28 | <MikeSmith> | I know there's some intentional difference with extended attributes |
| 12:28 | <annevk> | Oh, there might be something like that with respect to getting the prototype chain correct |
| 12:28 | <MikeSmith> | and commas |
| 12:28 | <MikeSmith> | trailing commas |
| 12:28 | <annevk> | I forgot the details, but yeah, that rings true |
| 12:29 | <MikeSmith> | would be nice if the future IDL work (incremental or otherwise) finds some way to address that |
| 12:30 | <MikeSmith> | because it would really suck to have people do a bunch of new work on IDL in any form and then it still doesn't get implemented in Blink and WebKit per spec |
| 12:30 | <annevk> | I think this is something Blink and WebKit have agreed to figure out, because what they have now doesn't make much sense ES-wise |
| 12:39 | <MikeSmith> | ok |
| 12:40 | <annevk> | Hmm, HTML's fetching algorithm doesn't deal with termination |
| 12:44 | <annevk> | I guess I'll say that fetching can be <dfn>terminated</dfn> with a /reason/ |
| 12:44 | <annevk> | Then annotate response objects with <dfn>termination</dfn> = /reason/ |
| 12:44 | <annevk> | And then XHR can check if response.termination == "end-user abort" or some such |
| 13:14 | <annevk> | Hixie_: for dfn.js, it'd be kinda neat if references from obvious non-normative places were styled differently |
| 13:15 | <annevk> | Hixie_: I like to reference algorithms all over, but when looking up where an algorithm is used I only care about none-.note related usage |
| 15:02 | <zcorpan> | at least darobin is sensible enough to not let the new dom fork rot |
| 15:03 | <Ms2ger> | Another one? |
| 15:03 | <zcorpan> | why not? forking is fun |
| 15:06 | <Ms2ger> | Clearly |
| 15:16 | <jgraham> | The W3C needs more spooning |
| 15:31 | <SteveF> | jgraham here here |
| 15:33 | <annevk> | hear? |
| 15:33 | <annevk> | but yes |
| 15:41 | <SteveF> | probably |
| 15:55 | <niloy> | can someone look at this and please tell me if this a problem with firefox/chrome http://jsfiddle.net/4KbML/ |
| 16:00 | <annevk> | niloy: 1 is not an IDENT |
| 16:00 | <annevk> | niloy: so you need quotes or an escape |
| 16:01 | <niloy> | annevk, got it, thanks |
| 16:01 | <annevk> | [data-cid=\31] should work |
| 16:01 | <annevk> | niloy: see http://mothereff.in/css-escapes |
| 16:02 | <niloy> | annevk, [data-cid=\1] failed |
| 16:02 | <annevk> | niloy: well that's not what I suggested |
| 16:02 | <TabAtkins> | niloy: That's because that's an escape for u+0001 |
| 16:02 | <TabAtkins> | But using quotes is better. Don't do escapes for this, it's silly. |
| 16:04 | <niloy> | yes got it |
| 16:05 | <Hixie_> | annevk: there's a "nobackref" class or something that lets you exclude them from dfn.js, if you that works |
| 16:05 | <annevk> | oooh |
| 16:06 | <annevk> | Hixie_: ah, and it can also be applied on the parent |
| 16:06 | <Hixie_> | if that works for you, even. not sure what my word happened. |
| 16:07 | <annevk> | Hixie_: seems like adding && links[k].parentNode.className != "note" would be trivial |
| 16:07 | <Hixie_> | i use it in the <input type=foo> sections to exclude the "doesn't apply" sections |
| 16:07 | <Hixie_> | annevk: yeah i'm happy to add something else if you want it |
| 16:07 | <annevk> | I'll play with this first I suppose |
| 16:08 | <Hixie_> | wow, i didn't realise the w3c even forked the URL spec |
| 16:08 | <Hixie_> | that's special |
| 16:08 | <Hixie_> | why would they not fork it when it was in the IETF but would fork it when it was at the WHATWG??? |
| 16:09 | <Hixie_> | i mean, that's crazy. we fork the IETF spec, and they then fork the WHATWG spec. |
| 16:10 | <sgalineau> | it's forking all the way down |
| 16:11 | <annevk> | We technically didn't fork. I wrote the whole thing from scratch to prevent issues. |
| 16:12 | <Hixie_> | yeah i don't mean that the spec text was forked |
| 16:12 | <Hixie_> | and i guess the IETF had said they wouldn't maintain it, so it was more like HTML4->WHATWG HTML |
| 16:13 | <Hixie_> | i just don't get it. |
| 16:13 | <annevk_> | So there's http://www.w3.org/TR/url/ |
| 16:13 | <sgalineau> | right; rebooting something frozen isn't forking |
| 16:13 | <annevk_> | I remember Charles at some point saying he was going to write the URL spec |
| 16:13 | <Hixie_> | it's like the w3c's desire to piss off the whatwg is greater than their desire for to not piss off the ietf. |
| 16:13 | <annevk_> | He was quite explicit about it not going to be a fork, but I think at the moment it's nothing... |
| 16:14 | <jgraham> | Nothing is not a fork |
| 16:14 | <jgraham> | So he was true to his word |
| 16:14 | <sgalineau> | it's a spork! |
| 16:20 | tantek | waits for URL naming bikeshedding so he can update his table. |
| 16:20 | <tantek> | for *more |
| 16:21 | <annevk> | tantek: I'd like for http://url.spec.whatwg.org/ to be final, as a bunch of specs depend on that now |
| 16:22 | <annevk> | tantek: also, I guess people can bikeshed, but at this point they'll need bargaining chips to get change |
| 16:24 | <tantek> | annevk: Fine with me. |
| 16:27 | <annevk> | In other news: https://blog.mozilla.org/research/2013/10/17/studying-lossy-image-compression-efficiency/ |
| 16:32 | <jgraham> | The right feedback for that study is "graphs without axis labels? Really?" |
| 16:37 | <zewt> | declaring php the ultimate failure |
| 16:37 | <zewt> | re: syntax changes depending on configuration |
| 16:42 | <Domenic_> | annevk: nrrr fix https://github.com/annevk/url/issues/1 |
| 16:43 | <Domenic_> | file:/// should never exist on Windows systems. |
| 16:43 | <annevk> | so many special casing for that |
| 16:43 | <annevk> | Domenic_: so people run Node.js on top of Windows? |
| 16:43 | <astearns> | annevk: if a CORS-enabled fetch is in Anonymous mode, the 'omit credentials flag' is set. What is it set to? |
| 16:44 | <annevk> | astearns: a flag is either set or unset |
| 16:44 | <annevk> | astearns: it's the English equivalent of a boolean |
| 16:44 | <astearns> | ah, I'm looking for the omit credentials mode |
| 16:44 | <annevk> | astearns: ooh, mode would be set to CORS |
| 16:44 | <astearns> | ok, good |
| 16:44 | <astearns> | thanks! |
| 16:44 | <Domenic_> | annevk: yeah, it's pretty big on Windows |
| 16:45 | <annevk> | poor Node |
| 16:45 | <Domenic_> | Most of the web runs on Windows, all you elitist Mac users forget that :P |
| 16:46 | <Domenic_> | (most of the web's users, I mean) |
| 16:46 | <annevk> | I thought most of the web ran on Linux |
| 16:46 | <annevk> | runs, even |
| 16:50 | <sgalineau> | a big chunk of the back end is linux; most of the front end remains windows |
| 16:51 | <sgalineau> | though windows 8 could fix that *cough* |
| 16:51 | <astearns> | annevk: the mode being set to CORS makes sense, but I'm not seeing the part in the spec that says this |
| 16:52 | <annevk> | astearns: http://fetch.spec.whatwg.org/#requests has CORS as a value |
| 16:53 | <astearns> | it does, and HTML fetch says what it's set to, but none of the other fetch steps mention setting the value |
| 16:53 | <annevk> | astearns: the algorithm only reads it |
| 16:55 | <annevk> | there's a few fields on a Request that are supposed to be writable, but most is only ever read |
| 16:56 | <astearns> | annevk: I just want to make sure that what I define here: http://dev.w3.org/csswg/css-shapes/#shape-outside-property has the mode set to CORS and not 'never' |
| 16:57 | <astearns> | and I'm not seeing the spec text that tells me one way or the other |
| 16:58 | <annevk> | astearns: oh wait, it sets it to /always/ |
| 16:58 | <annevk> | astearns: which is good |
| 16:58 | <astearns> | so it follows the HTML fetch steps? |
| 16:59 | <annevk> | so it's a slight change for same-origin requests |
| 17:00 | <annevk> | and that change was made after Hixie_ said he intended for it to be modeled after XHR anonymous mode |
| 17:00 | <annevk> | but I suppose we might need to change that back at some point |
| 17:00 | <annevk> | meeting, biab |
| 17:00 | <annevk> | gonna discuss JSON with the TAG |
| 17:01 | <annevk> | cannot really think of anything more exciting |
| 17:15 | <Domenic_> | haha |
| 17:42 | jgraham | still doesn't understand what's wrong with DOMRectReadOnly |
| 17:43 | <TabAtkins> | Me neither. :/ But DOMRectView is fine, I suppose. Way better than DOMRectRead. |
| 17:45 | <jgraham> | Isn't DOMRectView confusing with ArrayBufferView? |
| 17:46 | <jgraham> | (since afacit ArrayBufferViews are not read-only) |
| 17:46 | <Hixie_> | is there a quick way to add tests to the html5lib test suite? |
| 17:46 | <Hixie_> | or do i need to check it out or something |
| 17:47 | <jgraham> | YOu can probably edit it directly on github, if that's your thing |
| 17:47 | <jgraham> | You still need to make a pull request though |
| 17:47 | <Hixie_> | wonder if i have hg |
| 17:47 | <jgraham> | It's git |
| 17:48 | <jgraham> | https://github.com/html5lib/html5lib-tests |
| 17:48 | <Hixie_> | oh it moved to github? k |
| 17:48 | <Hixie_> | google search found the google code repo |
| 17:48 | <Hixie_> | we should probably close that if it's dead |
| 17:49 | <Ms2ger> | "NOTE: html5lib is now hosted at github: https://github.com/html5lib"; |
| 17:53 | <Hixie_> | is there some way to test my test? |
| 17:54 | <jgraham> | Like what? |
| 17:55 | <jgraham> | YOu can run the testsuite in html5lib |
| 17:55 | <jgraham> | It might fail of course |
| 17:55 | <jgraham> | Depending on what you are testing |
| 17:55 | <Hixie_> | guess i'd better get html5lib too |
| 17:55 | <Hixie_> | i just want to make sure my syntax is right :-) |
| 17:56 | <TabAtkins> | jgraham: Hmm, maybe, yeah. |
| 17:59 | <TabAtkins> | The whole conversation is ridiculous. LSP isn't dependent on the name of a class, so being okay with subtyping under one name but not another is silly. |
| 17:59 | <jgraham> | Wait, what? |
| 17:59 | <jgraham> | I assume he still wasn't OK with subtyping because that would make no sense |
| 18:00 | <Hixie_> | man, i've no idea what i'm doing with these newfangled source repos and stuff |
| 18:01 | <Hixie_> | if i've got a local copy of the html5lib repo, how do i run it? |
| 18:01 | <Hixie_> | i don't want to install it... |
| 18:02 | <jgraham> | Well I don't think you can anymore because it needs a compat library to work in both Python 2 and 3 |
| 18:02 | <Hixie_> | so how does an html5lib developer, like, develop it? |
| 18:02 | <jgraham> | But you should use a python virtualenvironment that you can blow away when you are done |
| 18:03 | <Hixie_> | i miss the old days of just downloading a tarball, running "make", and then sending the devs a diff. |
| 18:04 | <TabAtkins> | jgraham: No, no, subtyping is fine. |
| 18:04 | <Hixie_> | http://simononsoftware.com/virtualenv-tutorial/ "Installation is very easy." first example involves sudo. |
| 18:04 | <jgraham> | Hixie_: You do something like "virtualenv html5lib; source html5lib/bin/activate; cd /path/to/html5lib/clone; pip install -e ./" |
| 18:04 | <TabAtkins> | Virtually everything requires sudo. That's not a marker of "not easy". |
| 18:05 | <jgraham> | TabAtkins: Is fine in principle or in practice? |
| 18:05 | <TabAtkins> | jgraham: Don't care, because practice is good enough for me. |
| 18:05 | <Hixie_> | wow, i actually have virtualenv installed on this box. |
| 18:05 | <Hixie_> | jgraham: thanks |
| 18:05 | <gsnedders> | TabAtkins: You can do almost everything without sudo. |
| 18:06 | <TabAtkins> | Except installing things. |
| 18:06 | <gsnedders> | TabAtkins: Just install into non-standard locations. |
| 18:06 | <jgraham> | I'm pretty sure that DOMRect extends DOMRectReadOnly violates the LSP. I'm not convinved that's a real problem in js, but I don't have a convincing argument |
| 18:06 | <TabAtkins> | Which i susually more difficult. |
| 18:06 | <gsnedders> | jgraham: Why would it violate the LSP? |
| 18:06 | <TabAtkins> | jgraham: Only if you consider "can't be modified by me, but might be modified by something else" an ability which you lose, in which case LSP would prevent virtually all subclassing. |
| 18:07 | <Ms2ger> | Maybe the other way around? |
| 18:07 | <Hixie_> | great, i have virtualenv, but not pip. sigh. |
| 18:07 | <gsnedders> | Hixie_: easy_install pip! |
| 18:07 | <Hixie_> | gsnedders: see above re sudo. :-) |
| 18:07 | <jgraham> | Because part of the contract of the superclass is to be ReadOnly, surely? |
| 18:07 | <gsnedders> | Hixie_: (what's pip? a package manager. how do I install it? `easy_install pip`. what's easy_install? a package manager) |
| 18:07 | <Osmose1000> | "What's pip?" "A python package manager." "How do I install it?" "easy_install pip" "What's easy_install?" "A python package manager." |
| 18:07 | <Osmose1000> | gsnedders++ |
| 18:08 | <gsnedders> | (Yes, this is A Thing.) |
| 18:08 | <jgraham> | Although I guess, since this is actually mutable, it doesn't matter |
| 18:08 | <jgraham> | OK, I am mildly convinced |
| 18:08 | <Hixie_> | ok let's pretend i tested this test and it's good... |
| 18:08 | <Ms2ger> | wfm |
| 18:09 | <TabAtkins> | jgraham: Yeah, it's already mutable, just not by *you*. |
| 18:09 | <Hixie_> | hm, i guess i haven't put in the right #errors |
| 18:09 | <gsnedders> | jgraham: Typically mutation isn't considered part of the contract, as there are (at a high level) no setters |
| 18:09 | <TabAtkins> | So it's a *very weak* thing to depend on if you're trying to design by contracts. |
| 18:09 | <Hixie_> | not gonna be able to guess what those should be |
| 18:09 | <Ms2ger> | Does anyone care about errors? |
| 18:09 | <Hixie_> | most of the tests seem to list them |
| 18:09 | <jgraham> | Yep |
| 18:10 | <jgraham> | So inheriting from DOMRectReadOnly is fine, and ReadOnly is a better name than View |
| 18:10 | <Hixie_> | wait hold on. if i'm using virtualenv, why does easy_install want to install as root. |
| 18:10 | <Hixie_> | isn't the whole point here that i don't have to do that? |
| 18:11 | <jgraham> | That seems wrong |
| 18:11 | <jgraham> | OTOH installing pip as root makes more sense. I would do it with your system package manager |
| 18:12 | <Hixie_> | i'd rather not screw around with my root on this machine, at least not for something this minor |
| 18:12 | <gsnedders> | Hixie_: The only thing you should need installed as root is virtualenv |
| 18:13 | <jgraham> | Well then if you activated the virtualenv easy_install pip should work |
| 18:13 | <Hixie_> | yeah, i have that |
| 18:13 | <jgraham> | Ait |
| 18:13 | <jgraham> | *Wait |
| 18:13 | <jgraham> | Doesn't venv automatically install pip? |
| 18:13 | <Hixie_> | oh, i see. |
| 18:13 | <Hixie_> | activation is a per-shell thing. |
| 18:13 | <jgraham> | Are you sure that it is activated? |
| 18:13 | <jgraham> | YEs |
| 18:13 | <Hixie_> | my bad. |
| 18:14 | <jgraham> | It is just setting environment variables really |
| 18:14 | <Hixie_> | there we go. |
| 18:14 | <Hixie_> | yeah it makes sense, i just didn't realise what it was doing. |
| 18:14 | <gsnedders> | Mutating PATH and a couple of other things, basically |
| 18:15 | <Hixie_> | ok, making progress now. |
| 18:16 | <jgraham> | I'm going home, so I will leave you in the capable, if slightly dirty, hands of gsnedders |
| 18:16 | <Hixie_> | :-) |
| 18:16 | <Hixie_> | thanks for the help |
| 18:17 | <Hixie_> | so, how do i run the tests now that it's installed? |
| 18:17 | <Hixie_> | "nosetests"? |
| 18:18 | <Hixie_> | ok, that worked. |
| 18:18 | <gsnedders> | jgraham: … |
| 18:22 | <Hixie_> | jesus we have a lot of tests |
| 18:22 | <Hixie_> | are these Fs expected? |
| 18:23 | <Hixie_> | boo, it didn't tell me what #errors i should put in |
| 18:24 | <Domenic_> | I think the issue is `function f(rect) { if (!(rect instanceof DOMRectReadOnly)) { throw new Error("Anyone can modify this, I don't want to give it to untrusted consumers"); } else { untrustedConsumer.useRect(rect); /* can assume rect was not modified */ } }` |
| 18:26 | <Domenic_> | or more simply, `if (rect instanceof DOMRectReadOnly) { untrustedConsumer.useRect(rect); /* subsequent code can assume rect was not modified */ }` |
| 18:27 | <Hixie_> | gsnedders: so... what should i do with respect to #errors? |
| 18:27 | <Hixie_> | does hsivonen have code that tells me what they should be? |
| 18:27 | <Hixie_> | :-) |
| 18:39 | <Ms2ger> | Hixie_, ignore them, I think |
| 18:39 | <Ms2ger> | Hixie_, people who care will fix them up |
| 18:40 | <Ms2ger> | MikeSmith, there's been some work on the Blink side at least to get prototypes set up per webidl |
| 19:22 | <gsnedders> | Hixie_: As in what strings should they be? |
| 19:22 | <gsnedders> | Hixie_: And what failures where? |
| 19:23 | <gsnedders> | Hixie_: Up-to-date html5lib git should fail nothing, as should the latest release. |
| 19:30 | <Hixie_> | gsnedders: as in what strings, yeah |
| 19:30 | <Hixie_> | (the Fs were errors in my test) |
| 19:31 | <Hixie_> | gsnedders: so... how do i submit a pull request? i'm guessing that "git clone" does a local clone, which you probably can't get to... |
| 19:33 | Hixie_ | follows https://help.github.com/articles/fork-a-repo |
| 19:52 | <Hixie_> | why on earth does git diff try to paginate |
| 19:52 | <Hixie_> | i'm in an emacs buffer, i'm good for pagination thanks |
| 19:53 | <Ms2ger> | You might find that git and UX don't exactly get on well |
| 19:54 | <Hixie_> | i'm using emacs, i'm not expecting anything impressive in terms of UX :-P |
| 19:54 | <Hixie_> | but seriously, this is unix, who runs a pager by default. sheesh. |
| 19:54 | <Hixie_> | (/me learns of git config --global core.pager cat) |
| 19:56 | <Hixie_> | wow, really? |git diff| and |git commit| work on different sets? |
| 19:56 | <TabAtkins> | ...yes? |
| 19:57 | <TabAtkins> | For good reason, so you don't have to put stuff into the staging area just to get a diff, and so you actually have a staging area, respectively. |
| 19:57 | <Hixie_> | what's a "staging area" if it's not my working repository? |
| 19:58 | <Hixie_> | seems weird to assume that i'd want changes from only some files, but that i'd want all the changes in those files. |
| 19:58 | <TabAtkins> | You've got your working files, which are the shit you're actively editing. The staging area, which are the edits you're prepping for commit. And then the actual repo, which contains the commited stuff. |
| 19:58 | <Hixie_> | i don't understand the difference between the first two of those |
| 19:58 | <TabAtkins> | That way you can easily commit only some files, or only parts of some files, etc etc. |
| 19:58 | <Hixie_> | how do you only commit a part of a file? |
| 19:58 | <TabAtkins> | `git add -p` |
| 19:59 | <Hixie_> | funku |
| 19:59 | <TabAtkins> | It rolls through all the edited chunks of the chosen file, asking whether to stage it or not. |
| 19:59 | <Hixie_> | funky, even |
| 19:59 | <TabAtkins> | I've been using that a lot today. |
| 19:59 | <Domenic_> | yeah it's something you end up not being able to live without |
| 19:59 | <TabAtkins> | As I make general improvement to some functions while in the middle of edits to unrelated stuff that I dont' want to commit yet. |
| 19:59 | <Domenic_> | does seem weird and useless at first though |
| 19:59 | <Hixie_> | with other source control systems, i just create a different tree for each different working environment. |
| 19:59 | <Hixie_> | that way i can build each thing separately. |
| 19:59 | <Ms2ger> | I could live without git very well :) |
| 19:59 | <Hixie_> | otherwise, how do you test it? |
| 20:00 | <Ms2ger> | Hixie_, you don't test |
| 20:00 | <TabAtkins> | Sure, you can do that with git too, just branch more eagerly. But that's a lot of effort that you don't always want to go to. |
| 20:00 | <TabAtkins> | I think you can tell diff to look at the staging area instead of the active files. |
| 20:00 | <TabAtkins> | In case that's what you want. |
| 20:01 | <Hixie_> | well i have to say the number of times i have more than one edit going on at once is basically never, so it's not clear i'd care either way, but ok |
| 20:01 | <Hixie_> | y'all have fun with your -p :-) |
| 20:01 | <TabAtkins> | I used to think that too, then I didn't. Shrug. |
| 20:01 | <TabAtkins> | In any case, you can ignore the staging area entirely if you just always do `git commit -a`. |
| 20:01 | <TabAtkins> | (Well, almost. When adding brand new files to the repo, you still have to add them manually. Or maybe -A does that? I haven't looked recently.) |
| 20:02 | <JakeA_> | Hixie_: It's really handy if you've done a chunk of work that, in retrospect, deserves to be documented as separate commits |
| 20:03 | <JakeA_> | Eg, if you're adding a new feature & spot a typo in another feature |
| 20:03 | <Hixie_> | gsnedders: https://github.com/html5lib/html5lib-tests/pull/23 |
| 20:03 | Hixie_ | closes all his github windows and nukes his local copies and goes back to hug his subversion |
| 20:04 | <JakeA_> | SourceTree is a really nice GUI that does the -p stuff betterer |
| 20:07 | <Hixie_> | (for the record, despite my sarcastic whining above, git seems to be no worse than svn or cvs or perforce or any of the other repo systems i've interacted with) |
| 20:07 | <Ms2ger> | Oh, it is ;) |
| 20:07 | <Hixie_> | (there's something about the problem of version control that just seems to result in weird UX all around) |
| 20:10 | <Hixie_> | Ms2ger: it's definitely no worse than perforce. |
| 20:10 | <Hixie_> | Ms2ger: or cvs |
| 20:11 | <Hixie_> | it being worse than svn or not probably boils down to whether you like distributed repos or not |
| 20:11 | <Hixie_> | and i could see that going either way |
| 20:13 | <gsnedders> | Hixie_: FY |
| 20:13 | <TabAtkins> | Every source control system is absolutely terrible when you initially compare it to what you're used to. |
| 20:13 | <gsnedders> | Hixie_: *FYI, the error strings are meaningless, currently. |
| 20:13 | <gsnedders> | Hixie_: One line per parse error. That's the syntax. Content is meaningless. |
| 20:14 | <Hixie_> | gsnedders: well in the pull request i put up, i put no errors. no idea how many errors there should be, but i expect more than one. |
| 20:18 | <gsnedders> | Hixie_: Ideally we'd have position and message assertions, but it's hard to know what to do (what position should a parse error be triggered? probably where the input stream is when the tokenizer/tree builder says parse error |
| 20:19 | <Hixie_> | yeah |
| 20:19 | <gsnedders> | Hixie_: and what message do we check for to make they've got the right parse error?) |
| 20:20 | <gsnedders> | In theory Nolan got all the positions and numbers up to date. His impl is the only one that has used the parse errors in the tests in years, though. |
| 20:21 | <gsnedders> | When I update html5lib-python to match the spec I'll do something. |
| 20:22 | <Ms2ger> | Hixie_, so it this a test for a change you're making? |
| 20:22 | <Hixie_> | no, mostly just an excuse to see if i can add a test. |
| 20:23 | <Ms2ger> | Okay |
| 20:23 | Ms2ger | reviews |
| 20:23 | <gsnedders> | Hixie_: The format hasn't changed since you last wrote any! |
| 20:23 | <Hixie_> | yeah, but the source code repo has changed twice since then :-P |
| 20:23 | <gsnedders> | This is true. |
| 20:23 | <Ms2ger> | Hixie_, let's see if the spec confuses me as much as the last time I tried this ;) |
| 20:24 | <Hixie_> | hehe |
| 20:24 | gsnedders | is currently trying to implement the spec using CSP! |
| 20:29 | <Ms2ger> | Hrm |
| 20:29 | <Hixie_> | did i screw up? |
| 20:31 | <Ms2ger> | In <svg><x>, how does x end up in the svg namespace? |
| 20:31 | <Hixie_> | why would it not? |
| 20:32 | <Hixie_> | http://www.whatwg.org/specs/web-apps/current-work/#tree-construction |
| 20:32 | <gsnedders> | It should |
| 20:32 | <Hixie_> | http://whatwg.org/html#tree-construction |
| 20:32 | <Hixie_> | "As each token is emitted from the tokenizer" |
| 20:32 | <Hixie_> | ends up in "Otherwise" |
| 20:32 | <Ms2ger> | Aha |
| 20:32 | <Hixie_> | -> foreign content |
| 20:32 | <Hixie_> | -> Any other start tag |
| 20:32 | <Hixie_> | -> Insert a foreign element for the token, in the same namespace as the adjusted current node. |
| 20:44 | <Ms2ger> | jgraham / gsnedders: I've reviewed it, but it doesn't seem like I have access to merge it |
| 20:45 | <gsnedders> | Ms2ger: Yes you do. |
| 20:45 | <Ms2ger> | ... now :) |
| 20:45 | <gsnedders> | :) |
| 20:46 | <Ms2ger> | Thanks |
| 20:46 | <gsnedders> | Anyone else you think who should be added as reviewer? |
| 20:46 | <Ms2ger> | Not off hand |
| 20:47 | <gsnedders> | Okay. Then I'll leave it as is for now. |
| 20:48 | <jgraham> | gsnedders: Not sure how Content Security Policy would help you implement a parser :p |
| 20:49 | <gsnedders> | jgraham: CSP is far too overloaded! |
| 20:50 | <jgraham> | Don't you mean CPS? |
| 20:50 | <jgraham> | If not I have no idea what you do mean? |
| 20:54 | <Domenic_> | DOMRECTS!!! |
| 20:55 | <Ms2ger> | And on that note, I'm out :) |
| 21:08 | <gsnedders> | jgraham: Communicating sequential processes |
| 21:08 | <gsnedders> | (Everything I'm doing seems to resolve around CSP at the moment. Under at least five different definitions of CSP.) |
| 21:30 | <zcorpan> | ok what should devicePixelRatio return if there's no screen at all? |
| 21:32 | <zcorpan> | or if there is a screen but it doesn't have a concept of pixels? |
| 21:45 | <TabAtkins> | zcorpan: Every screen has some notion of resolution. |
| 21:45 | <TabAtkins> | (and d-p-r is just the inverse of resolution) |
| 21:45 | <TabAtkins> | If there's no screen at all, I dunno. |
| 21:46 | <zcorpan> | if my screen is a guy painting on a canvas with a brush, what's the resolution? :-) |
| 21:53 | <TabAtkins> | I dunno, you'd have to test him. How tiny can he paint? |
| 21:53 | <TabAtkins> | (Approximate resolutions are fine - printers have fuzzy resolutions in some cases too.) |
| 22:25 | <annevk> | FWIW, if anyone wants IRCCloud, let me know |
| 22:51 | <zcorpan> | i think i'll return 1 for the no-screen case, i guess it's less likely to confuse scripts than returning e.g. 0 |
| 22:58 | <zcorpan> | there. now bed time |