| 07:00 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=11960#c19 - i wonder what demos and tests |
| 07:14 | <Ms3ger> | zcorpan: http://ie.microsoft.com/testdrive/performance/irishspring/ |
| 07:17 | <zcorpan> | <!-- The sounds -- oh the wonderful sounds! --> |
| 07:17 | <zcorpan> | i love firefox's source highlighting |
| 07:22 | <heycam> | Copyright � |
| 07:51 | <niloy> | browser is rendering an empty div with 50% width with 0 computed width, anyway to fix it? http://jsfiddle.net/hKtWM/ |
| 09:05 | <annevk> | "The first highlight is that this is a trinity of technologies which exists in a state of symbiosis." |
| 09:05 | <annevk> | why do people not right straightforward text for change proposals? http://www.w3.org/wiki/User:Cjones/ISSUE-195 |
| 09:06 | <annevk> | you'd think they're written to convince people, not bore them |
| 09:07 | <annevk> | oh wow |
| 09:07 | <annevk> | ISSUE-195 does not consider the security issues at all |
| 09:08 | <annevk> | and makes the attack surface surprisingly larger |
| 09:08 | <annevk> | well nobody will implement that |
| 09:08 | <jgraham> | annevk: The only people still reading public-html have a very high boredom threshold |
| 09:08 | <jgraham> | So it's not really surprising if they themselves write boring proposals |
| 09:09 | <annevk> | ISSUE-195 compares the security implications with XHR, which works completely differently from form submission |
| 09:09 | <annevk> | this does show that nobody of interest is following public-html, indeed |
| 09:22 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=11960#c19 bah |
| 09:26 | <zcorpan> | annevk: we have e.g. TextTrack which doesn't have anything to do with Text node |
| 09:27 | <zcorpan> | String seems to not make sense for one of encode/decode |
| 09:28 | <annevk> | yeah mkay |
| 09:28 | <annevk> | I argued for just having Encoder/Decoder |
| 09:29 | <zcorpan> | that wfm |
| 09:37 | <jgraham> | annevk: I lost the thread of that conversation |
| 09:37 | <jgraham> | I object if you want to have encoder/decoder objects even for the non-streaming case |
| 09:38 | <jgraham> | The non-streaming case should be String.prototype.encode(encoding) and ArrayBuffer[View].prototype.decode(encoding) |
| 09:38 | <zcorpan> | niloy: which browser? |
| 09:39 | <annevk> | jgraham: why offer two APIs that do almost the same thing? |
| 09:39 | <jgraham> | Having to create encoder objects for the simple case is crasy-overhead |
| 09:39 | <jgraham> | *crazy |
| 09:39 | <annevk> | given how often you need it, it seems not that much overhead to me |
| 09:40 | <jgraham> | No need to sell out the common case because of the rare case |
| 09:41 | <annevk> | both are pretty rare I think |
| 09:42 | <jgraham> | Well not on the web I need to encode/decode quite often. And I have never needed to use a streaming decoder. And I would be horrified at such a java-like API |
| 09:42 | <jgraham> | Having to construct an object to call one method on it, once is just nasty |
| 09:42 | <jgraham> | That means the code is 50% boilerplate! |
| 09:43 | <Velmont> | jgraham: js is not python, -- don't think you'd do encode/decode as much as in Python (which is every second line there :P) |
| 09:44 | <annevk> | really? I never encode/decode in Python |
| 09:44 | <jgraham> | It's not every second line, but it is quite often at IO boundaries |
| 09:44 | <jgraham> | The web platform so far has done that automatically |
| 09:44 | <jgraham> | But increasingly it won't |
| 09:45 | <jgraham> | as people send stuff over binary websockets, for example |
| 09:45 | <Velmont> | annevk: have to decode everything you take in, -- and encode everything you output. |
| 09:49 | <annevk> | Velmont: I guess I always use the default of open() |
| 09:50 | <Velmont> | in.decode('utf-8') <do text processing> out.encode('utf-8') |
| 09:50 | <Velmont> | annevk: Maybe you don't manipulate the text you read in? |
| 09:51 | <jgraham> | Maybe your programs aren't non-ascii-safe |
| 09:51 | <Velmont> | I at least gets loads of spurious exceptions if I don't do that, -- only for non-ascii stuff though. Which I do quite a lot of so :] |
| 09:51 | <jgraham> | (it is sadly quite easy to be non-ascii-safe in Python 2. Fixing this is part of the point of Python 3) |
| 09:52 | <annevk> | yeah dunno really, I guess I mostly read ASCII stuff in, write bytes out |
| 09:52 | <annevk> | the last couple of weeks anyway |
| 09:52 | <jgraham> | Umm, missing a negative there |
| 09:52 | <annevk> | or use some kind of JSON serializer stuff |
| 09:54 | <annevk> | jgraham: but euh, I guess say so on the list |
| 09:54 | <annevk> | oh you did |
| 09:57 | <Velmont> | Hmmm. Opera does <sup>text</sup> as an item when findNodes(".//text()") |
| 09:57 | <Velmont> | and that doesn't support bla.data |
| 09:58 | <jgraham> | Huh? |
| 09:58 | <Velmont> | jgraham: respec.js throws in Opera, -- the idb spec doesn't work because of it. |
| 09:59 | <Velmont> | jgraham: Trying to find out why. -- And found it. -- But now I need to find out what that xpath thingy should do. |
| 09:59 | <Velmont> | Is <sup>bla</sup> a textNode? Or should it rather take only the "bla"? |
| 10:00 | <jgraham> | Only the bla |
| 10:00 | <Velmont> | jgraham: So, bug then. |
| 10:00 | <jgraham> | I am pretty surprised if this is broken |
| 10:00 | <jgraham> | But it could be ofc |
| 10:02 | <zcorpan> | wasn't xpath supposed to be perfect? :-) |
| 10:02 | <annevk> | I think the problem in Opera is that it interprets the XPath specification literally |
| 10:02 | <annevk> | Velmont: try running document.normalize() before the XPath runs |
| 10:04 | <Velmont> | annevk: Yes, not my code, it's respec.js that isn't working in Opera. Always irritated me but haven't looked at it until now. |
| 10:04 | <Velmont> | annevk: But I found such a reference now, yes. |
| 10:05 | <Velmont> | The others have ignored the xpath spec there, -- and Opera following gets all the problems for doing that :P |
| 10:05 | <annevk> | well the problem is the intersection of XPath and DOM really |
| 10:05 | <annevk> | DOM allows multiple Text nodes |
| 10:05 | <annevk> | XPath assumes a tree model that doesn't |
| 10:06 | <annevk> | everyone else was like lets modify XPath to suit the DOM and I guess jl tried the opposite |
| 10:09 | <Velmont> | annevk: OK, it was fixed in Opera next actually. I tried that already, but it was so slow that I thought it didn't work. But idb spec is always like that on this slow computer. |
| 10:11 | <annevk> | respec's lack of incremental display is annoying |
| 10:11 | <annevk> | well, I think respec in general is annoying |
| 10:11 | <Velmont> | It's very annoying. It should render to HTML and save that. |
| 10:11 | <Velmont> | So much faster. |
| 10:12 | <annevk> | it encourages the old-style DOM spec writing which is terrible |
| 10:12 | <zcorpan> | respec is responsible for that? |
| 10:13 | <Velmont> | What is difference between old and new? New is more algorithmic? |
| 10:13 | <zcorpan> | old has all these useless <dl>s |
| 10:17 | <zcorpan> | matjas, hasather: incorrect |
| 10:18 | <zcorpan> | name and nmchar aren't tokens :-) |
| 10:23 | <hsivonen> | zcorpan: not tokens in the HTML sense or not tokens in the general sense? |
| 10:23 | <hasather> | hsivonen: CSS |
| 10:23 | <zcorpan> | hsivonen: not tokens in CSS |
| 10:24 | <hasather> | zcorpan: could it be DIMENSION? |
| 10:24 | <zcorpan> | hasather: bingo |
| 10:24 | <hasather> | yatzy! |
| 10:25 | <hsivonen> | I wonder if 10 weeks from new Chrome has surpassed IE on StatCounter... |
| 10:27 | <annevk> | Velmont: yes and less <dl> with stuff like "Exceptions:" "none" etc. |
| 10:44 | <annevk> | so aklein said this yesterday: "annevk: good morning. re your question yesterday about transient observers, they do need to be added everywhere you remove the children of the DocumentFragment (to each child of the fragment if the fragment has subtree observers)" |
| 10:44 | <annevk> | but that already happens |
| 10:44 | <annevk> | per the remove algorithm that is invoked for each child of the fragment |
| 10:44 | <annevk> | I could still do the simplification however |
| 10:51 | <annevk> | should warnings really be normative? https://www.w3.org/Bugs/Public/show_bug.cgi?id=16418 |
| 10:52 | <zcorpan> | annevk: why not? |
| 10:52 | <annevk> | it seems confusing to have normative statements in call out boxes |
| 10:53 | <annevk> | to me they seem more like "pay special attention to" or "see also" |
| 10:55 | <jgraham> | Indeed, I don't see how a warning can be normative |
| 10:57 | <jgraham> | Although I guess allowing SHOULD level statements aimed at users in warnings makes some sense |
| 11:00 | <zcorpan> | http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#plugins has should in a warning |
| 11:00 | <zcorpan> | http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#encrypted-http-and-related-security-concerns too |
| 11:02 | <zcorpan> | http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element has a may |
| 11:02 | <zcorpan> | and a must not |
| 11:04 | <zcorpan> | etc |
| 11:05 | <zcorpan> | though if people don't treat warnings as normative, i guess that's a problem |
| 11:05 | <annevk> | Velmont: fixed your CORS stuff |
| 11:05 | <annevk> | Velmont: found another potential issue because of it :/ |
| 11:06 | <annevk> | Velmont: the Access-Control-Allow-Origin syntax, but not going to fix that until HTTP is more stable |
| 11:06 | <jgraham> | zcorpan: I think warnings should, in general be statements of fact. |
| 11:07 | <jgraham> | Sometimes they seem to follow the fact/requirement to mitigate effect of fact pattern |
| 11:07 | <jgraham> | which is OK. Although it could be nice if the requirement was seperate from the warning |
| 11:07 | <jgraham> | But maybe that would be hard to read |
| 11:09 | <annevk> | i'm pretty happy the DOM spec does not have to deal with mutation events (for now) |
| 11:09 | <annevk> | (and hopefully forever) |
| 11:09 | <annevk> | sounds like that's complicated |
| 11:18 | <Velmont> | annevk: is http unstable? :P |
| 11:23 | <zcorpan> | priorities: photoshop supports really awesome and complex things like content aware move, but doesn't do basic stuff like proper alpha in PNG8 or optimizing PNG |
| 11:24 | <Velmont> | I always get totally set out when trying Photoshop again coming from Gimp, -- it lacks LOADS of basic stuff. |
| 11:27 | jgraham | has fallen into a parallel universe |
| 11:29 | <jgraham> | I don't use photoshop or GIMP much but when I did I was way more interested in non-destructive adjustment layers (super useful for photo editing) than PNG optimisation (useless for photo editing). |
| 11:30 | <jgraham> | So what is "basic" might depend on your task |
| 11:30 | <zcorpan> | i meant basic in terms of impl complexity |
| 11:31 | <annevk> | Velmont: httpbis is |
| 11:31 | <jgraham> | Possibly. Doesn't seem the best metric to use since easy to implement might also mean "easy to make as a plugin or third-party tool") |
| 11:31 | <Velmont> | jgraham: Well, -- the stuff I'm talking about is making a precise selection. Gimp allows you to change your selection. So you can zoom in, fix the selection, - zoom out, zoom in on new place, fix selection. -- Photoshop doesn't allow that. |
| 11:32 | <annevk> | and they don't do living standard at the IETF so it's taking fricking ages before I can update stuff |
| 11:40 | <zcorpan> | https://twitter.com/#!/glazou/status/182787715337691137 |
| 12:16 | <Velmont> | jgraham: BTW, any comments on the new pull request change? https://github.com/jgraham/testharness.js/pull/1 |
| 12:22 | <jgraham> | Does github really not let you see squashed commits when doing review? |
| 12:22 | <Velmont> | jgraham: Yes |
| 12:22 | <jgraham> | It really doesn't |
| 12:22 | <jgraham> | ? |
| 12:22 | <Velmont> | https://github.com/jgraham/testharness.js/pull/1/files << just click diff |
| 12:22 | <Velmont> | jgraham: Yes it does |
| 12:23 | <Velmont> | (allow you to see it squashed) |
| 12:23 | <Velmont> | I just want to squash it later so that the history is all nice. |
| 12:23 | <jgraham> | Oh I see you can see the whole thing squashed or one commit at a time |
| 12:32 | <jgraham> | Velmont: Made some comments |
| 12:32 | <Velmont> | ook ^^ :-) |
| 12:37 | <annevk> | meh |
| 12:37 | <annevk> | forgot hg pull |
| 12:39 | <annevk> | ms2ger: we still have multiple heads |
| 12:39 | <annevk> | ms2ger: some silly WD draft is there, dunno how to remove it from heads |
| 12:39 | <annevk> | ms2ger: because my knowledge of version control is limited to making changes :p |
| 12:40 | <Velmont> | jgraham: Hmm. Any idea on a better name? Thought about legacy, - but it's actually an legacy_to_new mapping, and we're getting the new name gotten from the legacy name. |
| 12:42 | <jgraham> | Velmont: I would use legacy_code and dom4_type or something rather than overloading the code variable |
| 12:43 | <jgraham> | Dunno that I like the "4" |
| 12:43 | <jgraham> | dom_ls_I_mean_living_standard_not_load_and_save_type is a bit long to type though |
| 12:45 | <jgraham> | Maybe just code and type is enough? |
| 12:46 | <annevk> | what does assert_throws look like today again? |
| 12:46 | <Velmont> | Hmmm. code is already NETWORK_ERR or NetworkError. |
| 12:47 | <Velmont> | I don't really want the tmp there at all, -- but I found no way to do it without it. |
| 12:48 | <jgraham> | Velmont: Right, that's what I'm saying. Can't you seperate out the two concepts entirely? |
| 12:48 | <jgraham> | Rather than having one variable that could be the old thing or could be the new thing |
| 12:48 | <Velmont> | I don't need the legacy mapping other than just getting the new one. |
| 13:01 | <annevk> | ok I think I hit my public-html quota for the month |
| 13:05 | <Velmont> | jgraham: if (newstyle_code !== undefined) code = newstyle_code; |
| 13:06 | <Ms3ger> | annevk: those heads are fine |
| 13:07 | <annevk> | Ms3ger-- |
| 13:07 | <annevk> | Ms3ger: it's annoying if I have to chose a head when merging (the -- was to fix your name btw) |
| 13:08 | <Ms3ger> | Remind me to look at closing them tonight? |
| 13:08 | <annevk> | sure |
| 13:09 | <annevk> | if I remember that is |
| 13:18 | <Velmont> | Ms3ger, jgraham: Just pushed a new try at adressing your review. Admittedly not radically changed :P But still very open to good variable names. |
| 13:19 | <Ms3ger> | Velmont: haven't looked yet, I may be able to tonight or tomorrow |
| 13:29 | <annevk> | removing the Issues section from DOM fwiw |
| 13:29 | <annevk> | I filed two bugs |
| 13:29 | <annevk> | likely both WONTFIX |
| 13:32 | <Velmont> | Bah bah. -- Anyone know why my test isn't working? http://test.s0.no/idb/extra/idbfactory_open-transaction-lifetime.htm -- IndexedDB, I'm getting the second onupgradeneeded event, but not the second onsuccess. Seems to maybe be a bug in Firefox. |
| 13:35 | <smaug____> | Velmont: trying to ping some moz IDB devs |
| 13:35 | <smaug____> | but bad time.. |
| 13:35 | <smaug____> | it is quite early in California |
| 13:35 | <Velmont> | smaug____: But it might be a bug in my test, -- but I've used so much time that I can't see clearly anymore. :P |
| 13:36 | <Velmont> | smaug____: Pulling up the console logs some debug information. |
| 13:45 | <Velmont> | OMG, so my fault. |
| 13:46 | <Velmont> | I had written openrq2.success instead of openrq2.onsuccess. Typical "stared too long at this" bug. |
| 13:47 | <Velmont> | Beautiful, it runs as expected. PHew. |
| 13:57 | <Velmont> | Oh, instead of using lots of time loading the respec.js version of the spec; I found a great solution, -- just save the page as html, and it's instant loading in all browsers. :] |
| 13:58 | <smaug____> | annevk: so transient variable just flags some observers to be transient |
| 13:58 | <smaug____> | do you use transient variable somewhere? |
| 14:02 | <smaug____> | annevk: I think I prefer transient observers over transient variable |
| 14:06 | <annevk> | smaug____: I don't use it explicitly anywhere indeed |
| 14:06 | <annevk> | smaug____: I think I prefer the same |
| 14:08 | <smaug____> | in my mind I still think observers and transient observers as a way to select a possibly expanding set of nodes, and listen mutations in that set |
| 14:09 | <annevk> | well that's what happens |
| 14:26 | <annevk> | I wonder if the ES6 work around classes can make stuff like EventReceiver unneeded... |
| 14:29 | <smaug____> | annevk: what you mean? |
| 14:29 | <smaug____> | EventTarget needs to be somewhere in the event target chain |
| 14:29 | <smaug____> | and I expect that EventTarget needs to be a host object because of that |
| 14:29 | <smaug____> | at least, I would prefer that |
| 14:33 | <annevk> | they have ideas about letting user objects inherit from host objects in some way |
| 14:33 | <annevk> | at least Alex Russell does |
| 14:33 | <annevk> | have to see how that goes I guess |
| 14:34 | <annevk> | anyway, got to go, my brother is about to present his CD |
| 15:23 | <EricPreisz> | Quick question...my background is in game development and specifically optimization of 3D game engines(~10 years)...I'm interested in canvas and I'm wondering if anyone can tell me if there is an open source project that is specifically focused on an optimized renderer. I'd like to help out if I can. |
| 15:24 | <jgraham> | There are several projects that aim to build game libraries on top of 2D/3D canvas. But I don't know much about them |
| 15:25 | <EricPreisz> | No, I'm not looking to build libraries on top, I'm looking to build the render piece that would execute those libraries. Seems like there are a lot of HTML5 game libraries out there. |
| 15:26 | <EricPreisz> | If anything...I'd do it just to set benchmarks for what sort of performance we can expect to be implemented. |
| 15:27 | <EricPreisz> | I found this big list of HTML5 game engiens/libs. https://github.com/bebraw/jswiki/wiki/Game-Engines |
| 15:27 | <jgraham> | Hmm, maybe I am revealing my ignorance about graphics programming then :) What level were you expecting to work at? The actual browser implementations? |
| 15:27 | <EricPreisz> | Yea |
| 15:28 | <jgraham> | Oh well in that case there is http://www.opera.com/company/jobs/opening/320/ or WebKit or Gecko to hack on. I think everyone is focused on making their implementations optimised since it has a big effect on some web sites |
| 15:29 | <jgraham> | I don't really know anything more sepcific than that |
| 15:29 | jgraham | probably isn't the right person to help |
| 15:30 | <EricPreisz> | I've put a lot of time into the topic ;) (shameless plug:http://www.amazon.com/Video-Game-Optimization-Eric-Preisz/dp/1598634356) |
| 15:30 | <EricPreisz> | But yea, I would like to work on a library that any browser implementation could use. |
| 15:32 | <EricPreisz> | I know very little about writing a browser or browswer engine...but I do know a lot about rendering. Thanks for the answer though! |
| 15:32 | <jgraham> | Hmm, I am having difficulty imagining what such a library would look like. AFAIK there isn't much shared code in this area |
| 15:32 | <jgraham> | Even different WebKit consumers use different gfx libraries |
| 15:33 | <jgraham> | (hence the myth of "-webkit" means "same code" — but that's an aside) |
| 15:35 | <EricPreisz> | On my quick searches, that's what I'm finding as well. But I think that there would be some value in a consolidated renderer. There's a popular open source renderer for the game industry and it's used by a lot of people for prototyping...it's not really to a professional standard for rendering though. |
| 15:37 | <Philip`> | High-performance browser-based games will probably want to use WebGL instead of 2D canvas, and then I don't think the browser itself will have much influence on rendering performance (since it's basically just passing calls through to the system's graphics drivers) |
| 15:38 | <Philip`> | The more important part is probably the JS code that people write to run on top of the browsers, and the browsers' JS engines and other related APIs (typed arrays etc) |
| 15:41 | <EricPreisz> | How you pass calls to the graphics driver is where all the performance is. Passing data one call at a time is what makes graphics slow. I'm sure that JS will be a bottleneck too, but if you think of a resolution that is 800x600...that's 480,000 pixels...that's a lot of work. Graphics will be a big consumer of resources. There's no reason that canvas couldn't be as fast as WebGL...plus the |
| 15:41 | <EricPreisz> | audience of developers for canvas will probably be many times bigger than WebGL. |
| 15:42 | <Philip`> | WebGL *is* canvas :-) |
| 15:42 | <Philip`> | (though independent from the older 2D canvas context) |
| 15:42 | <EricPreisz> | Is the older 2D canvas going to go away? |
| 15:43 | <jgraham> | No |
| 15:43 | <charlvn> | this i a really awesome job: http://www.opera.com/company/jobs/opening/239/ |
| 15:43 | <Philip`> | No, though people who care significantly about performance might migrate to JS libraries that are built on top of WebGL |
| 15:43 | <EricPreisz> | From what I understand, they both render to a canvas, no? I'm not sure if they both share a graphics device or not. |
| 15:43 | <charlvn> | (not like i am going to apply, am perfectly happy with my current job, but if that was not the case) |
| 15:44 | <jgraham> | charlvn: I can say with great confidence that it is indeed an awesome job |
| 15:44 | <Philip`> | Some implementations of the 2D context are software renderers (via Cairo, Skia, etc), but I think newer implementations do hardware acceleration (via Direct2D, custom libraries built on top of OpenGL, etc) |
| 15:45 | <zcorpan> | EricPreisz: ask emoller⊙oc (our game developer guy) |
| 15:47 | <EricPreisz> | Oh...small world...Erik actually reviewed my book on his real time rendering site...Thanks! |
| 15:47 | <EricPreisz> | I had no clue. |
| 15:47 | <zcorpan> | cool |
| 15:53 | <zcorpan> | EricPreisz: i think opera wants more gfx developers -- if this is something you want to work with, maybe apply for the job (and reference Simon Pieters and I'll get a candy if you get the job) :-) |
| 15:56 | <EricPreisz> | Hrm...that's tempting...I've been sucked into a business role for the past couple of years...I'm getting rusty. ;) I run a game engine company now and one of our biggest issues is a great browser solution for our engines. We did the plug-in thing starting back in '06 and we stopped in '09.... |
| 16:00 | <jgraham> | Well, at risk of turning this into #opera-jobs, we are always looking for top-quality developers and gfx is obviously a big growth area for browsers these days |
| 16:00 | <EricPreisz> | Oh...ops...I confused Erik Moller w/ Tomas Moller & Eric Haines...the authors of Real Time Rendering...I don't think I've met Erik M before... |
| 16:01 | <jgraham> | Heh |
| 16:57 | <dglazkov> | good morning, Whatwg! |
| 17:00 | <Philip`> | Good morning, dglazkov! |
| 17:26 | <AryehGregor> | So I guess now I should start on rewriting all my transforms reftests to meet CSSWG guidelines. |
| 17:27 | <AryehGregor> | That's about . . . 345 files. |
| 17:27 | <AryehGregor> | Sigh. |
| 17:27 | <AryehGregor> | I wish I could just do Gecko hacking instead. |
| 17:39 | AryehGregor | hates unnecessarily complicated tests |
| 17:40 | <AryehGregor> | I'm responsible for quite a few complicated tests myself, but not unnecessarily so. |
| 17:40 | <AryehGregor> | They just test a lot. |
| 17:49 | <Ms2ger> | Yay, CKEditor doesn't use element.all anymore |
| 17:56 | <AryehGregor> | Wait, so CSSWG tests need to be under the BSD *3*-clause license? |
| 17:56 | <AryehGregor> | Oh, wait. |
| 17:56 | <AryehGregor> | That's okay. |
| 17:56 | <AryehGregor> | It's the four-clause license that's evil. |
| 17:56 | <Ms2ger> | Yep |
| 18:00 | <AryehGregor> | Ms2ger, so what are some more bugs I should fix when I have time? |
| 18:03 | <Ms2ger> | Are you interested in canvas? :) |
| 18:03 | <Ms2ger> | Because Philip` doesn't seem to feel like updating his tests |
| 18:04 | Philip` | gets distracted too easily :-( |
| 18:08 | <AryehGregor> | No, I'm not really interested in graphics stuff. |
| 18:08 | <AryehGregor> | DOM stuff is more fun. |
| 18:09 | <Ms2ger> | A test suite for DOM4? ^.^ |
| 18:09 | <AryehGregor> | I was thinking more like Gecko bugs. A test suite for DOM4 would be pretty awesome, though. |
| 18:10 | <AryehGregor> | Maybe I'll ask to work on that once I'm done with transforms. |
| 18:10 | <AryehGregor> | That way I won't have to deal with the CSSWG more than necessary. \o/ |
| 18:12 | <zcorpan> | hmm, seems like webkit doesn't pollute the global scope in xhtml |
| 18:12 | <Ms2ger> | Hmm |
| 18:12 | <niloy> | I have a div with some checkbox, I want to close the div when user clicks outside the div, so I have put tabindex -1 on it and set focus on it, then attached a blur event which closes the div, the problem is blur is called even when user clicks on checkboxes inside the div, anyway to fix this in FF? chromes seems to handle it nicely |
| 18:13 | <Ms2ger> | AryehGregor, bug 578632 makes me think it's probably worthwhile to review the HTMLCollection implementations and namedItem("foo") / ["foo"], in case that's something you feel like doing |
| 18:18 | <AryehGregor> | Ms2ger, I was thinking of Gecko hacking, for the moment. |
| 18:19 | <AryehGregor> | Hmm, you know . . . |
| 18:19 | AryehGregor | looks back at his contract |
| 18:20 | <AryehGregor> | Actually, how about I try doing an editing patch or two? |
| 18:20 | <jgraham> | Oooh, I know this one |
| 18:20 | <jgraham> | AryehGregor: Down that path lies madness |
| 18:21 | <AryehGregor> | So everyone says! |
| 18:23 | <jgraham> | But you're not going to let the suspiciously-human-looking bones littering the path put you off? |
| 18:23 | <smaug____> | AryehGregor: you look at your contract what you should be doing o_O |
| 18:23 | <AryehGregor> | smaug____, ? |
| 18:23 | <AryehGregor> | My contract says various things. And I've spoken with my manager-person too. |
| 18:23 | smaug____ | has managed to do whatever he does for 6 years without looking what the contract says :) |
| 18:23 | <AryehGregor> | So I'm pretty sure I'm good. |
| 18:24 | <AryehGregor> | They seem not to care too much as long as I'm doing Gecko-y stuff. |
| 18:24 | <AryehGregor> | You're a contractor? |
| 18:24 | <smaug____> | yes |
| 18:24 | <Ms2ger> | smaug____, does your contract say something about reviewing already? :) |
| 18:24 | <smaug____> | Ms2ger: might be |
| 18:25 | <smaug____> | AryehGregor: just because some silly bureaucracy issues |
| 18:25 | <smaug____> | I would be an employee if I lived in Sweden |
| 18:27 | <zcorpan> | AryehGregor: i know, you could drop some quirks :-) |
| 18:27 | <AryehGregor> | Where do you live? |
| 18:27 | <jgraham> | Mozilla disagree with Monty Python about the merits of Finland? |
| 19:39 | <annevk> | aklein: my idea was to just say "A transient registered observer is a specific registered observer." and let the rest flow from how it's used |
| 19:40 | <annevk> | aklein: I'm also going to rename it to transient registered observer to make the relationship more clear (and set it more apart from just "observer" which is a property of it) |
| 19:40 | <annevk> | ideally we have a different name that does not have "observer" in it for "registered observer" but I have not been able to think of anything :/ |
| 19:47 | <smaug____> | annevk: what problem are you trying to solve ? |
| 19:48 | <annevk> | "the chairs have decided to defer the publication from Tuesday March 27th to Thursday March 29th" mwahahaha |
| 19:48 | <annevk> | smaug____: we have a concept called "registered observer" that consists of among other things an "observer" |
| 19:48 | <annevk> | smaug____: I'd rather they are named somewhat more distinct |
| 19:48 | <annevk> | have* |
| 20:05 | <annevk> | zcorpan: seems you were right |
| 20:06 | <annevk> | maybe we should start a pool on the publication date |
| 20:06 | <annevk> | I'll put 10 down for next month |
| 20:07 | <Ms2ger> | I bet we can publish DOM4 earlier |
| 20:21 | <annevk> | smaug____: aklein: I now inlined the appending and removed the transient variable: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node-remove |
| 21:10 | <sicking> | annevk: i believe the only way we can get rid of the global namespace polluter is to change the spec. I don't believe I can convince IE otherwise |
| 21:11 | <sicking> | annevk: OTOH, I haven't been successful in convincing hixie to change the spec, so here we are :( |
| 21:11 | <Ms2ger> | sicking, and Hixie won't change the spec before IE drops it |
| 21:11 | <sicking> | Ms2ger: your guess is as good as mine |
| 21:11 | <Ms2ger> | Well, he said so in the bug, didn't he? |
| 21:11 | <sicking> | not exactly that no |
| 21:15 | <annevk> | sicking: is there a bug report on WebKit? |
| 21:15 | <annevk> | did anyone file one on Opera? |
| 21:15 | <annevk> | I can't find one |
| 21:16 | <annevk> | my opinion has always been we should align with Gecko here, but I never actually followed through to see if we had a bug report and everything, it only comes up every so often |
| 21:17 | <Ms2ger> | Former Gecko, I suppose you mean |
| 21:18 | <annevk> | I guess I should have included the pedantic note I was thinking of in my had about excluding today... |
| 21:18 | <Ms2ger> | :) |
| 21:18 | <annevk> | head even* |
| 21:19 | <Hixie> | sicking: which bug is this? i'm usually all about doing what the implementors are doing. |
| 21:19 | <sicking> | Hixie: yup, you were here too |
| 21:20 | <Hixie> | k :-) |
| 21:20 | <sicking> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=11960 |
| 21:20 | <sicking> | Hixie: except you went with the implementations that does something that's IMO much worse for the web |
| 21:20 | <sicking> | i.e. much more likely to create buggy pages |
| 21:20 | <jgraham> | FWIW I think the global scope polluter is evil, but I would be against us removing it in Opera |
| 21:20 | <jgraham> | Because it would hurt compat |
| 21:21 | <Ms2ger> | jgraham, how about making it quirks-only? |
| 21:21 | <jgraham> | Ms2ger: Or making it quirks-only |
| 21:22 | <Ms2ger> | Boo |
| 21:22 | <Hixie> | sicking: i think what i wrote in comment 15 is reasonable. (in particular, i think you would ask no less of me if you were in microsoft's position and they in yours.) |
| 21:22 | <jgraham> | Yeah, it sucks, but so does breaking sites |
| 21:22 | <roc> | why would sites that aren't broken in Gecko break in Opera? |
| 21:22 | <jgraham> | roc: Sites are broken in gecko |
| 21:23 | <Ms2ger> | Google and Microsoft-sponsored demos are, mostly |
| 21:23 | <sicking> | Hixie: I just disagee with you. But now much I could do here beyond that. Reaching out to MS is clearly not fruitful if they are aware of the discussion |
| 21:23 | <roc> | what sites? This is not the breakage I've seen in any of the broken demos I've looked at |
| 21:24 | <jgraham> | Maybe, but people seem to think that demos are something other than marketing fluff carefully designed to break other browsers |
| 21:24 | <sicking> | Hixie: it's too long ago that I don't remember if webkit folks are aware of the issue. I imagine that I had talked to them at the time yes |
| 21:24 | <jgraham> | (note: I'm not actually cynical enough to think that all demos are like that) |
| 21:24 | <Ms2ger> | Of course not, Mozilla's aren't :) |
| 21:24 | <Hixie> | sicking: IE isn't the only browser here, it might well be easier to convince opera and webkit |
| 21:25 | <Hixie> | sicking: i'm not sure what you disagree with me on here, my opinion on the matter really isn't a driving factor here. |
| 21:25 | <sicking> | Hixie: anne was aware of the issue as he commented in the bug. I strongly suspect webkit was too |
| 21:25 | <sicking> | Hixie: that's the part i disagree with you about |
| 21:25 | <Hixie> | sicking: you disagree with my opinion that my opinion isn't a driving factor? :-) |
| 21:25 | <sicking> | Hixie: changing the spec would likely have changed both webkit and IE in the long term |
| 21:26 | <sicking> | Hixie: yes |
| 21:26 | <Hixie> | if my opinion was a driving factor we'd have removed the misfeature entirely |
| 21:26 | <annevk> | me being aware of it doesn't mean you should not file a bug on Opera btw |
| 21:26 | <Hixie> | i hate this namespace polution crap |
| 21:26 | <sicking> | Hixie: and yet the spec isn't changed |
| 21:26 | <Hixie> | like i said, the spec isn't driven by my opinion here |
| 21:26 | <sicking> | Hixie: so i don't know what factual basis you have for that statement |
| 21:27 | <sicking> | annevk: yeah, point taken |
| 21:27 | <sicking> | Hixie: like i said, i disagree |
| 21:27 | <sicking> | Hixie: well.. i disagree that you changing the spec wouldn't have changed the landscape here |
| 21:27 | <Hixie> | you disagree on with me about what my opinion is? o_O |
| 21:27 | <sicking> | Hixie: sorry, i put it poorly |
| 21:28 | <sicking> | Hixie: you seem to be of the opinion that changing the spec wouldn't have changed implementations. I disagree with that assertion |
| 21:28 | <annevk> | might Gecko still revert that change? |
| 21:29 | <sicking> | annevk: i imagine that if we can get word from google and opera that they will change, that we'd revert yes |
| 21:29 | <annevk> | ok, I'll file a bug on Opera |
| 21:29 | <Hixie> | sicking: ah, well, you could be right on that, sure. i don't think it's likely though. in my experience if a browser vendor says "we won't do that, it's too much of a compat cost" then me changing the spec anyway just leads to them dismissing the entire spec more. |
| 21:29 | <sicking> | annevk: ideally also from safari |
| 21:29 | <annevk> | see what happens |
| 21:35 | <annevk> | filed a bug on Opera |
| 21:35 | <annevk> | ref is CORE-45289 |
| 21:35 | <annevk> | is there one on WebKit? |
| 22:24 | <Hixie> | i keep writing "hit region list" as "region hit list" |
| 22:25 | <Hixie> | not the same thing. |
| 22:41 | <Hixie> | woot, hit addHitRegion() is now almost entirely specced. The only parts missing are the parts that make it useful. |
| 22:52 | <roc> | did we enable global scope pollution for standards-mode documents? |
| 22:55 | <roc> | oh, I see we did |