| 00:50 | <TabAtkins> | Hixie: Haven't gotten back to my desk yet. ^_^ |
| 00:52 | <TabAtkins> | zcorpan: CSSConditionRule is what it sounds like - a superclass for all the condition rules. There are two of them right now (@media, @supports), but there was a third (@document) that got punted to the next level. |
| 00:56 | <TabAtkins> | Is anyone aware of anything in the platform where some default action only occurs if there is no listener attached to the element? That is, the "default action" is cancelled by default when an event listener runs? |
| 02:26 | <GPHemsley> | TabAtkins: It has been suggested that I ask you to also track how much web content sends style resources without any Content-Type header sent |
| 02:27 | <GPHemsley> | TabAtkins: In particular, to determine the cost of outright blocking/rejecting/ignoring CSS files that are served without a Content-Type (since CSS is difficult to sniff) |
| 02:30 | <GPHemsley> | TabAtkins: Though if you could track what types (or lack thereof) that style files are served as, that'd probably be an even bigger help |
| 04:21 | <annevk> | http://blog.tojicode.com/2013/06/a-tale-of-two-web-technologies.html#c2359382555491358783 is a pretty awesome comment on why we don't start from scratch. |
| 05:43 | <annevk> | TypeScript looks pretty exciting |
| 05:43 | <annevk> | http://channel9.msdn.com/Blogs/Charles/Anders-Hejlsberg-Steve-Lucco-and-Luke-Hoban-Inside-TypeScript-09 |
| 06:14 | <zcorpan> | annevk: using origin as the boundary seems best, is my immediate reaction |
| 06:14 | <annevk> | zcorpan: same, but a large number of people seem to see that as a large limitation : |
| 06:14 | <annevk> | :/ |
| 06:15 | <zcorpan> | i guess it is, too. but the Web works with it anyway |
| 06:23 | <annevk> | As in they're not willing to work with that limitation. I guess you still run into similar issues as to how to find the controller or event pages though so maybe sticking to origin only makes security boundaries clearer... |
| 06:43 | <MikeSmith> | "template content kidnapping" is a nice addition to the set of names for the various weird-ass parts of the parsing algorithm |
| 06:43 | <MikeSmith> | bravo Rafael |
| 06:43 | <MikeSmith> | http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0945.html |
| 06:43 | <MikeSmith> | Hixie: seriously you should use that |
| 06:58 | <annevk> | MikeSmith: also for http://wiki.whatwg.org/wiki/Band_names maybe? :) |
| 07:05 | <TabAtkins> | annevk: Per-origin would kinda suck. For example, I host several apps on my origin, and would like to host more. I don't have the ability to set up subdomains, I thinkk. |
| 07:05 | <annevk> | TabAtkins: yeah agreed |
| 07:06 | <annevk> | TabAtkins: "scope of an app" sucks too |
| 07:06 | <annevk> | but meh |
| 07:07 | <TabAtkins> | Yup. :/ |
| 07:08 | <annevk> | The other thing I (and others) have in mind long term is providing additional sandboxing for applications. E.g. being able to opt into not sharing your cache with URLs outside your applications. |
| 07:09 | <annevk> | And not sharing cookies and such either I suppose. |
| 07:09 | <annevk> | So <img src=resource> from within an app would potentially do a different request from one outside the app |
| 07:09 | <annevk> | (for instance) |
| 07:13 | <zcorpan> | maybe we don't need to prevent multiple apps per origin, but if there are multiple apps in one origin, they just share the security context? |
| 07:13 | <zcorpan> | i haven't followed discussions in this area so i might be saying useless things :-P |
| 07:15 | <zcorpan> | i think i've come to a state where the spec for scrollIntoView actually does something useful |
| 07:21 | <jgraham_> | MikeSmith: I fully support that naming convention. And not only because I managed to document a particularly confusing part of our code using relationship types (monogamy|polygamy|secret affair|just dating) |
| 07:25 | <MikeSmith> | hah |
| 07:25 | <MikeSmith> | nice |
| 07:27 | <Ms2ger> | jgraham, sounds like the thing that became the AAA in the spec |
| 07:28 | <jgraham> | Ms2ger: When I said "our code", I really meant "our test system" |
| 07:28 | <Ms2ger> | Ah |
| 07:31 | <zcorpan> | TabAtkins: yes, but the condition rules are different for all three... |
| 07:32 | <TabAtkins> | The verification rules for setting, yes. On getting, it's just the text. |
| 07:32 | <TabAtkins> | Similar to properties. |
| 07:35 | <annevk> | zcorpan: maybe, origin could grow path information potentially |
| 07:35 | <annevk> | zcorpan: as an opt-in thingie |
| 07:35 | <zcorpan> | TabAtkins: yeah. i'm still unconvinced that it's a good idea to expose a new property on CSSMediaRule is a good idea |
| 07:36 | <zcorpan> | annevk: that sounds scary :-) |
| 07:37 | <annevk> | change always does? :p |
| 07:37 | <annevk> | seems worth exploring what we can do to improve matters |
| 07:37 | <zcorpan> | particularly when it involves security foundations |
| 07:39 | <TabAtkins> | There's nothing really magical about the dot-separated part that makes it more secure, except that it's hard to breach one by accident. |
| 07:40 | <TabAtkins> | Interesting thing about opting-in to a "subdomain" carved out of the path segments is that you'll only know about it if you visit something in that path. If you first land elsewhere in the origin, you'll still be able to treat that path as same-domain. |
| 07:40 | <TabAtkins> | Unless it has to be sent in headers, perhaps? |
| 07:41 | <TabAtkins> | But then it'd just be something like an extra token sent in headers, and everything in an origin that returns the same token is in a sub-origin. |
| 07:41 | <TabAtkins> | (And the same resource can vary its origin over time by sending different tokens.) |
| 07:42 | <TabAtkins> | Well, maybe the token is just a (ancestral?) path segment. |
| 07:42 | <TabAtkins> | So you can't spoof it from elsewhere in the origin. |
| 07:43 | <zcorpan> | what would document.domain do when you've opted in to path origin? |
| 07:44 | <annevk> | I'd presume we'd disable that as part of opting in |
| 07:45 | <annevk> | TabAtkins: well yes, we need a way to identify whether a URL belongs to an application |
| 07:45 | <annevk> | TabAtkins: that could work with a manifest maybe, although that does not work for images per se, though I suspect the manifest could claim a URL space in some manner |
| 08:45 | <annevk> | zcorpan: btw, you might want to extract the "fetch a stylesheet" bits in CSSOM |
| 08:46 | <annevk> | zcorpan: to ensure they're identical for the various pieces that can do such a fetch |
| 08:46 | <zcorpan> | annevk: <?xml-stylesheet?> and Link: don't support crossorigin="" (should they?) |
| 08:47 | <annevk> | zcorpan: I'm not sure we should support Link: at all, but the crossorigin bit could be a parameter that xml-stylesheet simply doesn't supply |
| 08:47 | <zcorpan> | true |
| 08:48 | <zcorpan> | if gecko removes Link: i'll nuke it from the spec |
| 08:48 | <annevk> | I wonder if there's a bug on that |
| 08:48 | <zcorpan> | annevk: please file a bug (on the spec, about fetch) |
| 08:49 | <annevk> | https://bugzilla.mozilla.org/show_bug.cgi?id=748294 |
| 08:49 | <annevk> | zcorpan: k |
| 08:55 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=14072 o_O |
| 09:06 | <zcorpan> | would be nice if anolis supported defining macros |
| 09:10 | <Ms2ger> | zcorpan, interesting idea... I'd probably take patches ;) |
| 09:11 | <zcorpan> | filed https://bitbucket.org/ms2ger/anolis/issue/17/should-support-defining-macros |
| 09:11 | <Ms2ger> | Thanks |
| 09:26 | <jgraham> | annevk: I dont know what you mean "incompatible with existing web application infrastructure" |
| 09:27 | <annevk> | jgraham: multiple applications deployed on the same origin is pretty common |
| 09:27 | <jgraham> | At the moment, for a web application, if you are using > 1 application per origin, they have to be mutually trusting |
| 09:27 | <annevk> | sure |
| 09:30 | <jgraham> | Well I would say that the current infrastructure strongly favours the one app, one origin model. Although I agree that sometimes people make things that look like multiple apps on a single origin. However I would argue that *infrastructure* wise, they are really the same app. It's just that the UX doesn't match the infrastructure |
| 09:42 | <grr> | 367 new mails! these must be very interesting |
| 09:45 | <Ms2ger> | Sounds like an average day on public-html |
| 09:45 | <jgraham> | He said "new", not "useless" |
| 09:45 | <jgraham> | </rimshot> |
| 09:45 | <annevk> | "must be very interesting" does not follow from "new" |
| 09:46 | <jgraham> | Well no, from "new" we can't deduce intrestingness at all I guess |
| 09:46 | <annevk> | jgraham: depends on what you mean by infrastructure |
| 09:47 | <annevk> | jgraham: might very well be very different teams and very different code, just sharing a domain name |
| 09:47 | <jgraham> | Sure |
| 09:48 | <jgraham> | But from a web-infrastructure perspective they are making two parts of the same app |
| 09:49 | <annevk> | If you're just saying that currently we have an origin model that doesn't consider paths, well sure... |
| 09:49 | <annevk> | Not sure anyone is arguing against that :-) |
| 09:49 | <zcorpan> | Ms2ger: i guess this removes tail as well, in utils.py: node.getparent().remove(node) |
| 09:50 | <Ms2ger> | :( |
| 09:51 | <Ms2ger> | Sounds like we need to add a utils.removeFromParent |
| 09:54 | <zcorpan> | hmm, or something before that fiddles with the tail. not sure if it's correct (looks wrong if node is the first child) |
| 09:54 | <zcorpan> | so yeah |
| 11:07 | <zcorpan> | i've managed to get the defining macro removed but the instances are untouched |
| 11:10 | <zcorpan> | Ms2ger: http://pastebin.com/MJQmA0zV - is it obvious what i'm doing wrong? |
| 11:12 | <zcorpan> | the code path from line 51 works but 56 does nothing, not even throw when i use a bogus ident |
| 11:13 | <Ms2ger> | What if you use data-anolis-use=something? |
| 11:13 | <zcorpan> | same |
| 11:15 | <Ms2ger> | Nothing obvious to me |
| 11:16 | <zcorpan> | ok. :-/ i guess i'll dump the code for now and get on with something else |
| 11:30 | <zcorpan> | jgraham: if you could have a look at https://bitbucket.org/ms2ger/anolis/issue/17/should-support-defining-macros at some point that'd be much appreciated :-) |
| 11:34 | <jgraham> | zcorpan: Sure |
| 11:34 | <zcorpan> | thanks |
| 13:08 | <asmodai> | Mmm, second time around FF 21 on Ubuntu 13 with only 4 tabs open starts to claim 3-4 GB resident memory :| |
| 13:33 | <zewt_> | what the hell |
| 13:33 | <zewt_> | why is whatwg.com/c covering the page I'm trying to view with an obnoxious survey popup :| |
| 13:38 | <Ms2ger> | Anyone around who knows a little about the AAA? |
| 13:40 | <gsnedders> | Ms2ger: A little. |
| 13:41 | <Ms2ger> | Enough to tell if https://bugzilla.mozilla.org/show_bug.cgi?id=884795 hits the O(n�)-loop-protection-limit? |
| 13:43 | <gsnedders> | I believe it does. |
| 13:43 | <Ms2ger> | Thanks |
| 13:44 | <gsnedders> | That it depends on the attribute sounds like a real issue though |
| 13:47 | <jgraham> | zewt: Hixie hates you |
| 14:54 | <Hixie> | zewt: if you dismiss it (or reply to it) once it won't come back for at least 30 days |
| 14:55 | <Hixie> | in other news: it finally happened, someone asked if i can put a Promise API in HTML. anyone got a tutorial on promises up yet so i can figure out what that means? i've intentionally not been following that discussion since i have no spare bandwidth these days. |
| 14:58 | <SteveF> | zcorpan: FYI new html set available http://webdevdata.org/ |
| 15:05 | <Ms2ger> | Hixie, afaict, there's consensus on precisely nothing |
| 15:06 | <jgraham> | Ms2ger: Context? |
| 15:06 | <Ms2ger> | Promises |
| 15:06 | <jgraham> | Although I guess that statement is true in general\ |
| 15:06 | <jgraham> | Ah |
| 15:06 | <jgraham> | Yeah |
| 15:06 | <Ms2ger> | In other news, the Navigator spec is crap |
| 15:06 | <jgraham> | The consensus seems to be "Promise all the things" |
| 15:07 | <jgraham> | (with some Promises design we can't agree on) |
| 15:15 | <jgraham> | Navigator spec? |
| 15:16 | <Ms2ger> | The part that only defines half the stuff that should be on Navigator |
| 15:19 | <jgraham> | Oh you mean the Navigator part of the HTML spec |
| 15:19 | <jgraham> | Isn't some of the other stuff hidden away in other specs that just extend the interface? |
| 15:20 | <jgraham> | That might not be the half you are missing though |
| 15:21 | <jgraham> | (e.g. geolocation, web performance, probably others) |
| 15:21 | <jgraham> | (navigator has become a fashionable dumping ground) |
| 15:22 | <jgraham> | (extending other spec's interfaces is pretty annoying) |
| 15:23 | <Hixie> | Ms2ger: file bugs if it's the navigator stuff in the whatwg spec that's crap |
| 15:24 | <Hixie> | jgraham: don't partial interfaces make it reasonable? |
| 15:24 | <Ms2ger> | Hixie, bz is filing |
| 15:24 | <Hixie> | damnit, that means it'll be insightful and hard to fix |
| 15:25 | <Ms2ger> | Hixie, you've got them in comments in the spec source, just not in the actual spec |
| 15:25 | <Hixie> | oh the things that are comented out are commented out intentionally, because not everyone implements them, and it's better to drop them than implement them. |
| 15:25 | <Ms2ger> | I don't expect us to drop them |
| 15:25 | <Hixie> | booo |
| 15:25 | <Ms2ger> | Especially if weblinkit support them too |
| 15:28 | <Ms2ger> | And even more if IE+weblinkit+Gecko have them, like appCodeName |
| 15:29 | <Hixie> | if they all have them, then the spec should have them |
| 15:29 | <Ms2ger> | Right :) |
| 15:30 | <Hixie> | that one is marked "redundant" apparently |
| 15:30 | <Ms2ger> | They all claim Mozilla |
| 15:31 | <Ms2ger> | Following the usual rule that you should claim to be WebKit for CSS and Gecko for DOM |
| 15:33 | <dglazkov> | good morning, Whatwg! |
| 16:08 | <jgraham> | Hixie: The unreasonableness is that you have to look in N different places to find out about an interface, and you don't know either the value of N or waht any of the places are |
| 16:16 | <Hixie> | jgraham: oh well that's just a problem with having multiple specs. i'm happy to add links to other specs that add things in the HTML spec, if that would help for that kind of thing. |
| 16:17 | <Ms2ger> | Also, has anyone been involved with the DNT spec? |
| 16:49 | <jgraham> | Hixie: Well I would either like a tool that can scrape all the specs and produce a complete IDL for the web platform, with links to the relevant specs for each part of each interface, or a rule that each interface is only defined in one place, possibly with links to other specs to define specific interface members |
| 16:50 | <jgraham> | I imagine people would moan about the latter option, even though it is convenient for authors and matches the likely setup of implementations |
| 16:53 | Ms2ger | has had such a tool at the back of his mind for quite a while |
| 16:53 | <Ms2ger> | But I never found a good python webidl parser |
| 16:53 | <Ms2ger> | Maybe I should try Gecko's |
| 17:07 | <TabAtkins> | Hixie: Don't listen to Ms2ger. Promises are done, tc39 likes what we've got, etc. Anne is still bugfixing the algos, but that's it. |
| 17:07 | <Ms2ger> | We'll see |
| 17:07 | <TabAtkins> | Well, we'll all fight anyone who tries to change the core now. |
| 17:08 | <Ms2ger> | We'll see |
| 17:08 | <TabAtkins> | But anyway, Promises are easy as hell. I should write a blog post about how to use them in specs. |
| 17:20 | <dglazkov> | TabAtkins: do you use the csswg mirror on github? |
| 17:20 | <dglazkov> | and if anyone does, how does it work? |
| 17:23 | <TabAtkins> | dglazkov: No, it's a readonly mirror. |
| 17:23 | <dglazkov> | kay |
| 17:23 | <TabAtkins> | If you want to use git, you have to use git-hg or one of the bridges to still talk to the hg repo. |
| 17:25 | <SimonSapin> | dglazkov: I use git locally, but still need to push to Mercurial |
| 17:25 | <SimonSapin> | so I don’t use the github mirror |
| 17:25 | <dglazkov> | SimonSapin: I see |
| 17:26 | <SimonSapin> | sometimes I push to my fork on the mirror to get review before changing an ED |
| 17:29 | <dglazkov> | SimonSapin: can you share examples? |
| 17:30 | <SimonSapin> | eh, I removed my fork. These change ended up in EDs |
| 17:31 | <dglazkov> | :) |
| 17:31 | <SimonSapin> | it’s still all a bit experimental |
| 17:31 | <SimonSapin> | I’d love to be able to make pull requests |
| 17:37 | <dglazkov> | the problem I am trying to solve now is being to able to do the proper review cycle for spec changes |
| 17:37 | <dglazkov> | if anyone has great ideas/solutions, I am all ears |
| 17:41 | <Hixie> | jgraham: well i'm all for the former (a script that magically generates one spec), but let's not let the perfect be the enemy of the good -- if we can, in the meantime, just include references to other possibly relevant specs, that seems like a good start. |
| 17:42 | <SimonSapin> | dglazkov: switch to github, drop mercurial, do pull requests |
| 17:42 | <Hixie> | TabAtkins: something just slightly more fleshed out than http://dom.spec.whatwg.org/#promises would be perfect |
| 17:42 | <SimonSapin> | dglazkov: nobody changes/merges anything to master they have written themselves |
| 17:42 | <TabAtkins> | Yeah, you don't want to figure out how to spec a promise from that spec. ^_^ |
| 17:43 | <Hixie> | TabAtkins: right now the dom spec just goes from an overview from geostationary orbit to pseudocode, which is a bit of a deep dive :-) |
| 17:43 | <SimonSapin> | this requires at least two editors per document, so they can review each other |
| 17:43 | <Hixie> | TabAtkins: i'm sure it's straight-forward, i just haven't been watching the discussion so i know nothing yet |
| 17:43 | <TabAtkins> | Digging my way out of work email at the moment, but I'll get to that shortly. |
| 17:43 | <Hixie> | TabAtkins: if you're around this afternoon, i can just come over and have you brief me in person if you like :-) |
| 17:44 | <TabAtkins> | That works too! |
| 17:44 | <TabAtkins> | (I should still write the post, but I can give you a high-bandwidth summary pretty quick.) |
| 17:44 | <Hixie> | cool, will dorp by |
| 17:44 | <Hixie> | drop even |
| 17:45 | <Hixie> | though "dorp" is probably appriopriate too |
| 17:45 | <TabAtkins> | ^_^ |
| 18:01 | <SimonSapin> | dglazkov: If WebApps shows the way in getting reviews for every edit (possibly through pull requests) that would be a great help to push the same in CSS WG |
| 18:01 | <Ms2ger> | I don't see that happening |
| 18:02 | <SimonSapin> | Ms2ger: in either WG? Well, we can at least start pushing |
| 18:02 | <Ms2ger> | I'm not sure it would be a good idea in any case |
| 18:04 | <SimonSapin> | At least start with having the tools in place for the editors who do want to get and make reviews |
| 18:09 | <jgraham> | Not sure about doing pre-commit reviews on all spec changes |
| 18:11 | <jgraham> | Reviews done well have a significant cost |
| 18:13 | <TabAtkins> | Yeah, also: we make tons and tons of edits. |
| 18:14 | <Ms2ger> | Also: nobody reviews specs unless they're implementing, and then they review the spec, not the edits |
| 18:14 | <TabAtkins> | And it would render workflows like what fantasai and I do (pair-edit the specs in a marathon sessions) impossible. |
| 18:14 | <TabAtkins> | Given how productive those are, I'd straight-up ignore anything that made it harder to do that. |
| 18:15 | <SimonSapin1> | maybe that’s too much, but starting from "reviews are good" it’s a way to track what’s been reviewed or not. |
| 18:16 | <SimonSapin1> | TabAtkins: the point is to get two sets of eyes, so pair editing is fine |
| 18:16 | <SimonSapin1> | it’s great, even |
| 18:16 | <Hixie> | i'd hope we already have far more than two pairs of eyes per spec |
| 18:16 | <Hixie> | a spec with only two people paying attention is probably not going very far |
| 18:16 | <jgraham> | Right, I think the valuable review for specs is when they get implemented |
| 18:16 | <SimonSapin1> | Hixie: well, I don’t know :) |
| 18:16 | <TabAtkins> | I'm not sure that's really right. The point is to get an additional set of eyes that wasn't involved in teh original writing, and so isn't obviously subject to the same internal blindness as the author. |
| 18:17 | <TabAtkins> | While pair-editing does reduce the error rate, I'm not sure it qualifies. |
| 18:17 | <SimonSapin1> | TabAtkins: fair point |
| 18:17 | <jgraham> | and bz or jl or other two-letter people look at them |
| 18:17 | <Hixie> | jgraham: or you :-P |
| 18:18 | <Hixie> | or zcorpan... |
| 18:18 | <SimonSapin1> | Hixie: when I push changes to CSS Page Media, I’m not sure anyone looks at them until I bug fantasai about it |
| 18:18 | <Hixie> | the number of bugs you guys find |
| 18:18 | <Hixie> | is too damn high! |
| 18:18 | <Hixie> | :-P |
| 18:18 | <TabAtkins> | SimonSapin: That's because not many people are implementing Paged Media. |
| 18:18 | <SimonSapin> | and yes, it’s not a spec doing especially well … |
| 18:18 | <Ms2ger> | Hixie, the number of bugs in your spec is too damn high ;) |
| 18:19 | <Hixie> | SimonSapin: the problem isn't that you're able to edit the spec without review. the problem is that nobody is reviewing. pre-commit or post-commit wouldn't matter. |
| 18:19 | <SimonSapin> | ok |
| 18:19 | <Hixie> | SimonSapin: though i'll grant you that if you had to get a review pre-commit, it might stop you spending time on the spec at all, which, i guess, might be a good thing if nobody is implementing :-) |
| 18:19 | <SimonSapin> | still, tooling could be better |
| 18:19 | <Hixie> | Ms2ger: can't argue with that! |
| 18:19 | Hixie | likes the tooling the html spec has |
| 18:19 | <Hixie> | (http://html5.org/tools/web-apps-tracker) |
| 18:20 | <SimonSapin> | what are colors for? |
| 18:21 | <Hixie> | the redder, the more mature the part of the spec being edited |
| 18:21 | <Hixie> | gray is non-normative changes |
| 18:21 | <Ms2ger> | What I'd like is a way to attach test links to changes |
| 18:21 | <SimonSapin> | so red = danger when changing mature stuff? |
| 18:22 | <Hixie> | SimonSapin: basically |
| 18:22 | <Hixie> | Ms2ger: i usually put the tests either in the spec source or the bug that i mention in the checkin comment |
| 18:22 | <Hixie> | but sometimes my tests aren't really coherent enough for reuse, or there's just too many of them |
| 18:22 | <Ms2ger> | Hixie, no, I mean a pointer to a test in the spec's test suite |
| 18:22 | <Hixie> | oh, that kind of test |
| 18:23 | <Hixie> | yeah that'd be nice. i don't have a good enough handle on the html test suite at this time. |
| 18:23 | <Ms2ger> | A test that people that are not you look at :) |
| 18:23 | <Hixie> | right |
| 18:23 | <Ms2ger> | The status is that there's a repo and a bunch of pull requests |
| 18:23 | <Hixie> | i think anne's tool is in a repo somewhere if you want to try to hack that in, fwiw |
| 18:23 | <Ms2ger> | And that the HTMLWG claims everything is interoperable |
| 18:24 | <Ms2ger> | Yeah, I think I've even touched that code once :) |
| 18:24 | <Ms2ger> | But it'd need to store the links somewhere, I guess |
| 18:24 | <Hixie> | don't even get me started on the htmlwg's testing methodology |
| 18:24 | <Hixie> | i can provide a mysql db if you want one |
| 18:25 | <Hixie> | (though i'd recommend sqlite) |
| 18:25 | <Ms2ger> | Mm |
| 18:25 | <Ms2ger> | I think I used mysql once a decade ago or so |
| 18:25 | Ms2ger | usually avoids databases |
| 18:25 | <Hixie> | what i really want to do is a "blame" view of the spec that lets you drill down on a sentence nad work out what happened to it |
| 18:25 | <Hixie> | but that's a ton of work |
| 18:26 | <Hixie> | (a view of the spec parsed as html, not the source) |
| 18:26 | <Ms2ger> | That would be interesting |
| 18:47 | <jgraham> | Hixie: Which part of the W3C testing are you unhappy with? The part where they ignore testing for rec track purposes, or the mpore general effort? |
| 18:48 | <Hixie> | the former |
| 18:48 | <Hixie> | the testing effort as a whole is admirable |
| 18:49 | <Hixie> | one of the best things the w3c is doign right now |
| 18:54 | <jgraham> | Yeah. So my feeling is that the marriage of Rec. track and testing is an uneasy one at best. Not that many players seriously care about spec status, and the ones that do are unlikely to produce great tests when their goal is "get the spec to Rec. asap". I would rather that people seperately got specs to Rec quickly for the lawyers (and we eventually figured out a living standard model that would keep them happy) and developed tests aiming to find bu |
| 18:54 | <jgraham> | ... there aren't any. |
| 18:56 | <zcorpan> | SteveF: nice, thanks |
| 18:56 | <Ms2ger> | aiming to find bu[cut off] |
| 18:59 | <Hixie> | jgraham: yeah. lawyers in my experience would be happy with just going to REC every year, fwiw. |
| 18:59 | <Hixie> | not sure what it'll take to convince w3c |
| 19:00 | <jgraham> | Ms2ger: really? Sigh. "bugs rather than make out ..." |
| 19:01 | <Ms2ger> | I'm in violent agreement with all of you here :) |
| 19:15 | <gavinc> | So I think some of it has to do with the lovely bit of patent law that makes willful infringement create triple damages. Thus trying to make sure that patents are disclosed early enough that no one started an implementation that could be seen to be willfully infringing. Not sure that the "PROCESS" really makes that any better anyway |
| 19:17 | <gavinc> | That's the only reason I can imagine for tying the technical progress of a recommendation to the legal progress? |
| 19:17 | <Ms2ger> | I'm not sure how that relates |
| 19:20 | <gavinc> | "lawyers in my experience would be happy with just going to REC every year" |
| 19:20 | <Ms2ger> | Are you saying they wouldn't be? |
| 19:20 | <gavinc> | For established recommendations I would agree, not so sure for new ones? |
| 20:19 | <TabAtkins> | heycam|away: Bugging you to track addition of [MapClass]. ^_^ |
| 20:47 | <TabAtkins> | annevk: Do you still think that Beacon should just be in the XHR spec or something? https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html |
| 20:47 | <TabAtkins> | annevk: Since it's just a simple API for a lazy, no-response XHR. |
| 21:13 | <TabAtkins> | What are current thoughts on using NodeList? Should we still be using that for returning array of Nodes, or should we just return arrays of Nodes in new code? |
| 21:16 | <Hixie> | make a new subclass of HTMLCollection and return that |
| 21:16 | Hixie | runs away giggling |
| 21:22 | <TabAtkins> | ಠ_ಠ |
| 21:27 | <Hixie> | seriously though, i dunno, the best current practice seems to always be changing |
| 21:27 | <Hixie> | pretty sure whatever you want you don't want it to be live, and you don't want it to be returned from an attribute that is on an object that itself is live |
| 21:28 | <Hixie> | beyond that, array or NodeList, not sure there's much difference these days |
| 21:36 | <TabAtkins> | Well, the big difference is that NodeList still isn't an Array subclass, so you have to do [].slice.call(nodelist) if you want to do a .map(), .filter(), etc. on it. |
| 21:56 | <aklein> | Hixie: question about PopStateEvent.state: is it meant to behave differently whether it was created via history.pushState() or new PopStateEvent()? |
| 21:56 | <aklein> | Hixie: the spec says (non-normatively) that state 'Returns a copy of the information that was provided to pushState() or replaceState().'; but normatively, it also says 'The state attribute must return the value it was initialized to. ' |
| 21:57 | <aklein> | (looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#popstateevent) |
| 22:00 | <TabAtkins> | zcorpan: Mind altering the preprocessor you use to generate the same ToC markup as the other CSS specs? You're using the CSS stylesheet now, but the ToC looks ugly. ;_; |