| 00:01 | <Hixie> | heycam: also, "caller" needs to be specifiable with the other specials |
| 01:06 | <Samer> | word |
| 01:18 | <heycam> | Hixie, will do |
| 01:18 | <heycam> | i'll make it use the same overload resolution as regular operations |
| 01:18 | <Hixie> | sweet |
| 01:19 | <Hixie> | i'm sending something about [Supplemental] also |
| 01:19 | <heycam> | ok, still haven't thought more about that |
| 01:19 | <Hixie> | html5 is now up to date as far as i can tell |
| 01:19 | <heycam> | ah ok cool |
| 01:19 | <Hixie> | i'm sure i made lots of mistakes :-) |
| 01:19 | <heycam> | it'd be good to extend dom's webidl checker to look for non-syntactic mistakes too |
| 01:21 | heycam | heads out to get some breakfast |
| 01:32 | <Hixie> | heycam: do you have an opinion on the issue about security for prototypes visible cross-origin? |
| 01:32 | <Hixie> | heycam: e.g. window.location's prototype is visible cross-origin, which might be a problem |
| 01:33 | <Hixie> | specifically regarding http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0269.html |
| 01:55 | <othermaciej> | Hixie: I saw your email, I was planning to ask abarth for advice |
| 01:56 | <Hixie> | k |
| 01:56 | <Hixie> | let me know if i need to change anything |
| 01:59 | <othermaciej> | Hixie: abarth had a suggestion for how this should work on #webkit, which I agree is sound |
| 01:59 | <othermaciej> | (maybe he wants to suggest it himself though) |
| 01:59 | <abarth> | i can write it up in an email if you like |
| 01:59 | <Hixie> | yeah if it could be in e-mail form that would be fantastic |
| 02:00 | <abarth> | ok, i should get cracking on my emails then |
| 02:00 | <othermaciej> | short version is, expose the real value same-origin, make a new object per-window with the accessing window's appropriate prototype chain cross-origin |
| 02:00 | <othermaciej> | (doing this for location itself would probably handle its cross-origin-accessible function properties too, though the cross-origin version would need to expose only a limited set of properties) |
| 02:01 | <othermaciej> | abarth: it might almost need to be a different interface when exposed cross-origin, now that I think about it |
| 02:01 | <abarth> | there are subtlies, like what happens if the same-origin guy changes the replace function |
| 02:02 | <abarth> | the cross-origin viewers want to see a prisine version |
| 02:02 | <othermaciej> | right, you can't expose that cross-origin |
| 02:02 | <Hixie> | currently the spec disallows doing that (changing replace()) |
| 02:02 | <othermaciej> | but making a fresh JS wrapper with a fresh prototype will cover that |
| 02:02 | <abarth> | in some sense, it could just be an entirely different object |
| 02:02 | <Hixie> | but having a new object would neatly fix that, yes |
| 02:02 | <abarth> | at the c++ layer |
| 02:02 | <Hixie> | how about Window? |
| 02:03 | <abarth> | window has a reference monitor |
| 02:03 | <Hixie> | wait, this won't work |
| 02:03 | <abarth> | so it doesn't really matter |
| 02:03 | <Hixie> | if two windows grab each others' Location objects |
| 02:03 | <abarth> | you can't see the properties added to he prototyp |
| 02:03 | <Hixie> | and then set document.domain so that they can talk |
| 02:03 | <Hixie> | their objects need to complare === |
| 02:03 | <Hixie> | compare, even |
| 02:03 | <Hixie> | "reference monitor"? |
| 02:03 | <abarth> | i don't think that is very important |
| 02:03 | <abarth> | if they aren't === |
| 02:04 | <othermaciej> | window is an even more special case than widow's cross-origin-accessible properties |
| 02:04 | <othermaciej> | I agree with abarth, I doubt the === condition is relevant to web compat |
| 02:04 | <Hixie> | for .window I'm sure it is important that they be ===, so it has to be the same WindowProxy object |
| 02:04 | <Hixie> | and i don't really see how to do that safely |
| 02:04 | <othermaciej> | for window, yes |
| 02:04 | <Hixie> | anyway send mail |
| 02:04 | <Hixie> | i'll do whatever you say :-) |
| 02:04 | <Hixie> | assuming it works |
| 02:04 | <othermaciej> | the window object needs more complex behavior than Web IDL can really express |
| 02:05 | <Hixie> | oh we're well past Web IDL for indow |
| 02:05 | <abarth> | window.window and window.frames are just self loops |
| 02:05 | <Hixie> | Window |
| 02:05 | <abarth> | they don't need anything fancy done to them |
| 02:05 | <Hixie> | abarth: i meant for that object, not for the accessor |
| 02:06 | <othermaciej> | WebKit has a handful of Window properties and attributes marked as DoNotCheckDomainSecurity |
| 02:06 | <othermaciej> | though maybe that would better be termed AllowCrossOriginAccess or something |
| 02:06 | <othermaciej> | the question isn't really about window but about what happens when you access those properties or methods of Window cross-origin |
| 02:07 | <Hixie> | the question seems to me to be the same for Window as for Location |
| 02:07 | heycam | is happy to leave security discussions to others |
| 02:07 | <othermaciej> | window has no prototype chain, and has an object identity requirement for wrappers |
| 02:08 | <abarth> | window does have a prototype chain |
| 02:08 | <othermaciej> | so it's not quite the same |
| 02:08 | <Hixie> | no prototype chain? |
| 02:08 | <abarth> | if you add stuff to Object.prototype, they show up a properties of window |
| 02:08 | <othermaciej> | ok, right, it doesn't expose any properties that are on the prototype chain |
| 02:08 | <othermaciej> | the function properties are on Window itself and the prototype is not directly exposed cross-origin |
| 02:09 | <Hixie> | i should specify that somewhere! |
| 02:09 | <Hixie> | please send an e-mail about that :-) |
| 02:09 | <Hixie> | god only knows how i'm gonna make that work with webidl |
| 02:09 | <abarth> | i bet you can make it work by using different objects |
| 02:09 | <abarth> | when viewing cross origin |
| 02:09 | <othermaciej> | Window? |
| 02:10 | <abarth> | i'm thinking about focus() right now |
| 02:10 | <othermaciej> | you'd have to hack === comparison probably, and switch object types when transferring it cross-origin |
| 02:10 | <abarth> | because it's the simplest case |
| 02:10 | <othermaciej> | (like you can vend window cross-origin and hand it back to something same-origin with the window itself and all methods still work) |
| 02:11 | <abarth> | window is super special |
| 02:11 | <othermaciej> | I think this would be more complicated than the way it works now |
| 02:11 | <othermaciej> | it is |
| 02:11 | <abarth> | can we think about the focus function for a minute? |
| 02:11 | <othermaciej> | sure |
| 02:11 | <othermaciej> | I think same-origin accessors should see the real focus function |
| 02:11 | <abarth> | yes |
| 02:12 | <othermaciej> | cross-origin accessors should see a fresh value made with the accessor's version of the Function prototype chain |
| 02:12 | <othermaciej> | I think this might even be what WebKit already does |
| 02:12 | <abarth> | ok |
| 02:12 | <abarth> | and the object doesn't have a reference monitor |
| 02:12 | <abarth> | it's just a plain JS object |
| 02:12 | <othermaciej> | I'm not sure what you mean by reference monitor |
| 02:12 | <abarth> | in webkit terms |
| 02:13 | <abarth> | someone overrides getProperty or whatever |
| 02:13 | <abarth> | and calls SecurityOrigin::canAccess |
| 02:13 | <abarth> | to make some decisions |
| 02:14 | <othermaciej> | I think once you have the actual function object for window.focus, there are no more security checks involved when calling it or accessing its properties or prototype properties |
| 02:14 | <abarth> | window calls canAccess a lot |
| 02:14 | <abarth> | right |
| 02:14 | <abarth> | ok, that all makes sense to me |
| 02:14 | <abarth> | now, window.location |
| 02:14 | <abarth> | currently, in webkit, window.location is implemented like window in the sense that |
| 02:15 | <abarth> | getProperty calls canAccess |
| 02:15 | <abarth> | another way to think about what's going on |
| 02:15 | <abarth> | is that there's a different object that cross-origin viewers see |
| 02:15 | <othermaciej> | (I should also mention if you access window.focus cross-origin, you always get the original version, even if in the real window object it has been replaced) |
| 02:15 | <abarth> | that simply lacks the properties that canAccess woudl return false for |
| 02:16 | <abarth> | this account of window.location has two virtues: |
| 02:16 | <abarth> | 1) it explains why you get the origin methods if they've been changed |
| 02:16 | <Hixie> | 2) it's faster |
| 02:16 | <abarth> | 2) the location object becomes less magical and more like a normal JS object |
| 02:16 | <othermaciej> | I think actually implementing it that way could be easier to implement and might be reasonably secure |
| 02:17 | <othermaciej> | but then at the time you access window.location, you get a different kind of object depending on whether you are doing same-origin or cross-origin access |
| 02:17 | <abarth> | right |
| 02:17 | <Hixie> | in that case all the magic ends up on Window, which is fine by me, and I have to spec two Location objects, which I can live with |
| 02:17 | <othermaciej> | I believe Location will actually throw when trying to access properties cross-origin that you are not allowed to |
| 02:17 | <Hixie> | someone's gonna have to describe what all the magic on Window is, though |
| 02:18 | <Hixie> | othermaciej: correct |
| 02:18 | <othermaciej> | I would expect this is incidental rather than required |
| 02:18 | <Hixie> | othermaciej: i would just define it as two implementations of the same Location interface, fwiw |
| 02:19 | <abarth> | the location property of window is then something like a factory |
| 02:19 | <abarth> | in that it produces lots of objects |
| 02:19 | <othermaciej> | Hixie: the cross-origin version would have to throw even when getting or setting unknown properties, to totally match current behavior |
| 02:19 | <Hixie> | othermaciej: yes |
| 02:20 | <othermaciej> | but in principle, yes, there could be one interface that's general enough that either implementation would fulfill it |
| 02:20 | <othermaciej> | the alternative to multiple objects would be a single object that simply has different property access behavior depending on who's asking, like Window does |
| 02:21 | <othermaciej> | I wonder if it's possible to spec it to allow either implementation strategy, and if such a spec would enforce enough of the needed security constraints |
| 02:21 | <abarth> | if it throws for novel properties, you're probably ok |
| 02:22 | <abarth> | the main difference in observable behavior would be === |
| 02:22 | <othermaciej> | the other difference would be if you transfer it cross-origin and somehow manage to transfer it back |
| 02:23 | <abarth> | there's also the issue of uber powerful viewers |
| 02:23 | <abarth> | like file URLs in webkit |
| 02:23 | <abarth> | who can see past your canAccess blocks |
| 02:24 | <abarth> | but they're completely insecure, so i'm not sure what we can do for them |
| 02:24 | <othermaciej> | that is true, though our file: URL handling is not needed for interoperability and in fact should probably be changed, at least by default when used in browsers |
| 02:24 | <abarth> | i'm pretty sure i added a setting for that :) |
| 02:24 | <othermaciej> | the current WebKit model amounts to treating file: as same-origin to everything whenever anyone asks, so in either model it would get the real Location object |
| 02:25 | <abarth> | right |
| 02:25 | <abarth> | but he could see what another page got if they grabbed the location object of a third page |
| 02:25 | <abarth> | or of the file page |
| 02:25 | <othermaciej> | that is true |
| 02:26 | <othermaciej> | it's an observable difference in behavior depending on the spec model, even if it's very unlikely to matter in practice |
| 03:25 | Hixie | upgrades http://www.whatwg.org/issues/data.html a little |
| 03:26 | othermaciej | wonders what the corresponding graph would look like for the HTML WG issue tracker |
| 03:27 | <Hixie> | i include the bugzilla count now, but you can't see it cos i've only got one number so far |
| 07:53 | <Lachy> | Hixie, is the buzilla count that small purple dot at the bottom right corner? |
| 07:56 | <Lachy> | Hixie, would be useful if you replaced that long description following the table with a simple key that illustrates each type of line and assigns a label |
| 07:58 | <Hixie> | Lachy: navy, not purple, but yes |
| 07:58 | <Hixie> | and yeah, i should probably add a key |
| 08:04 | <annevk42> | DOMSettableTokenList no longer stringifies due to the Web IDL change |
| 08:14 | <Hixie> | oh? |
| 08:14 | <annevk42> | you removed Stringifies but did not add stringifier before value |
| 08:14 | <annevk42> | afaics |
| 08:14 | <Hixie> | it's inherited |
| 08:14 | <annevk42> | aah |
| 08:16 | <annevk42> | abarth++ -- http://tools.ietf.org/html/draft-abarth-cookie |
| 08:19 | <annevk42> | abarth, having said that, shouldn't you aim to obsolete all existing cookie specs and also define cookie2 and set-cookie2 in the same document? |
| 08:32 | <Hixie> | can't we just drop cookie2? |
| 08:32 | <Hixie> | who uses it? |
| 08:34 | <annevk42> | that's cool too |
| 08:36 | <Hixie> | annevk42: i added legends http://www.whatwg.org/issues/data.html |
| 08:41 | <annevk42> | not sure I was the one who asked, or are you telling me because it does not work in Opera?!!!11! |
| 08:41 | <Hixie> | oh, sorry, it was lachy |
| 08:42 | <annevk42> | ;) |
| 08:42 | <Hixie> | lachy: i added legends http://www.whatwg.org/issues/data.html |
| 08:42 | <annevk42> | nice trend |
| 08:42 | <Hixie> | october baby |
| 08:51 | <annevk42> | cool, feedback from Microsoft |
| 08:51 | <Hixie> | is it good feedback? i haven't had a chance to read it yet |
| 09:00 | <Philip`> | http://games.slashdot.org/article.pl?sid=09/08/07/2013243 "Several sources are reporting that while native audio/video support has been dropped from the HTML 5 spec ..." |
| 09:03 | <annevk42> | Hixie, it seems valid to me |
| 09:03 | <Hixie> | cool |
| 09:09 | <annevk42> | geopriv wtf |
| 09:09 | <othermaciej> | it looks like they are not big fans of a lot of the new elements |
| 09:11 | <Hixie> | gsnedders: yt? |
| 09:14 | <annevk42> | othermaciej, it seems they're mostly critical of those where the benefit/use case is not clear |
| 09:15 | <othermaciej> | I suppose they probably just skipped mentioning the ones they do like |
| 09:16 | <annevk42> | http://www.w3.org/mid/8B62A039C620904E92F1233570534C9B0118D8250546⊙ncac -- are we supposed to take this serious? |
| 09:17 | <annevk42> | othermaciej, like <video>? o_O |
| 09:17 | <othermaciej> | annevk42: I am guessing their review is not nearly done yet |
| 09:17 | <othermaciej> | the sectioning elements seem to have low potential benefit but are also trivial in terms of implementation effort |
| 09:17 | <othermaciej> | it seems like the main likely effect is to make blog markup look a little prettier, with less <div> soup |
| 09:18 | <othermaciej> | I guess they are only really good if one is against <div> soup |
| 09:18 | <annevk42> | yeah, though most blogs need something like <main> or <content> which is lacking |
| 09:18 | <othermaciej> | <time> solves a very specific problem with microformats |
| 09:18 | <othermaciej> | annevk42: good point - I guess arguably everything not in <header>, <footer>, <nav> or <aside> is the main content |
| 09:19 | <annevk42> | (and there is a plan to specify access details for the sectioning elements I believe once other things are in order; mapping to AT and such) |
| 09:19 | <othermaciej> | progress/meter seem useful but they need both default native look and defined custom css styling for sites to use them IMO |
| 09:19 | <othermaciej> | keygen I am not surprised they hate |
| 09:19 | <annevk42> | I wholeheartedly agree with MS that we need a styling story for menu/progress/meter |
| 09:19 | <othermaciej> | because they are the one browser that has no real reason to do it |
| 09:20 | <annevk42> | hyatt completely dislikes the current menu design too, fwiw |
| 09:20 | <othermaciej> | we have ended up making pretty much every single form control stylable in webkit because authors demand it |
| 09:20 | <othermaciej> | hyatt also doesn't like the current <datagrid> design |
| 09:20 | <annevk42> | it's commented out now ;) |
| 09:20 | <othermaciej> | we should probably cut it IMO |
| 09:21 | <othermaciej> | it's an important feature but it's too late to completely redesign it |
| 09:21 | <annevk42> | Hixie cut it |
| 09:21 | <annevk42> | I really like the form control styling thing in WebKit btw |
| 09:21 | <othermaciej> | I think Firefox and IE have various degrees of form control stylability |
| 09:21 | <annevk42> | I'd be great if you could get css3-ui to be more clear on the details one day and introduce all the new pseudo-elements |
| 09:22 | <othermaciej> | but I like the way some of the details of ours work |
| 09:22 | <othermaciej> | pseudo-elements seem like a good approach for styling compound controls that are more than one box |
| 09:22 | <othermaciej> | a lot of div soup is simply because form controls have not been reliably and interoperably stylable |
| 09:23 | <othermaciej> | it's dumb to need to pile up DIVs and JavaScript just to get a custom looking checkbox |
| 09:23 | <othermaciej> | and then to have to add ARIA so it can be accessible |
| 09:23 | <annevk42> | on top of that you need to learn about ARIA and not make mistakes |
| 09:23 | <annevk42> | right |
| 09:23 | <othermaciej> | basically reimplementing all the functionality of a checkbox just to change the look |
| 09:23 | <annevk42> | I've been telling this to the PFWG since 2006 |
| 09:24 | <othermaciej> | interoperable form control styling seems to be an important thing to specify and I guess no one is really actively pursuing it |
| 09:24 | <annevk42> | well, not all the time, but I said it quite firmly back then in some meeting and after that a few more times until it became clear that ARIA was going to happen anyway because it landed in Firefox, etc. |
| 09:25 | <othermaciej> | I think even if that was done, it wouldn't completely remove the need for ARIA |
| 09:25 | <othermaciej> | because of the transition period |
| 09:25 | <othermaciej> | authors would probably be more prepared to accept broken accessibility in some/older browsers than broken appearance in older browsers |
| 09:26 | <othermaciej> | so it's probably easier to get people to use ARIA before it's 100% deployed in every browser |
| 09:26 | <annevk42> | yeah, fair enough |
| 09:26 | <annevk42> | that's been their argument too fwiw |
| 09:27 | <othermaciej> | it's surprisingly pragmatic, you'd think they wouldn't be ok with doing stuff that breaks accessibility at all |
| 09:27 | <othermaciej> | but also I guess they have more competency in designing accessibility features than styling features |
| 09:29 | <annevk42> | on the one it was very pragmatic, on the other hand they're still working with some XHTML2 design at the time :) |
| 09:29 | <annevk42> | on the one hand* |
| 09:30 | <othermaciej> | annevk42: when I saw the message you linked, I was not sure if it was intended seriously or sarcastically, but I decided not to ask |
| 09:36 | <annevk42> | Hixie, Gregg from Google is suggesting that XMLHttpRequest should take filedata URLs. I have a hard time deciding whether that is a good idea given how much functionality of XMLHttpRequest would not be used at all... |
| 09:40 | <Hixie> | what's his use case? |
| 09:42 | <annevk42> | your system supports RTF documents; user selects RTF document one way or another; you get a URL out of that; with XHR you can have a single code path for loading the data |
| 09:44 | <Lachy> | Hixie, I don't see any legend on the graph, and now neither the thin teal line, green line or navy dot appear. |
| 09:45 | <Hixie> | Lachy: whatever browser you are using doesn't support fillText() -- upgrade to a newer browser |
| 09:45 | <Lachy> | Error: context.measureText is not a function, Source File: http://www.whatwg.org/issues/data.html |
| 09:46 | <Hixie> | Lachy: whatever browser you are using doesn't support measureText() -- upgrade to a newer browser |
| 09:46 | <Lachy> | that's in Firefox 3.5 |
| 09:46 | <Lachy> | it worked before without any problems |
| 09:46 | <Lachy> | oh, no, this machine still has 3.0 :-( |
| 09:46 | <Lachy> | I will upgrade. |
| 09:47 | <Hixie> | annevk42: seems like that use case would be handled by the File APIs and moving the layer of abstraction down one level, which doesn't seem unduly problematic |
| 09:48 | <Hixie> | ok i gotta sleep |
| 09:48 | <Hixie> | nn |
| 10:01 | <annevk42> | got to love this: http://windowsteamblog.com/blogs/developers/archive/2009/08/05/version-checking-just-don-t-do-it.aspx |
| 10:05 | <Lachy> | heh |
| 10:05 | <Lachy> | seems conceptually relevant to the versioning issue in the HTMLWG |
| 14:44 | <annevk42> | http://www.mediawiki.org/wiki/Special:Code/MediaWiki/54567 |
| 16:54 | <abarth> | annevk42: if you're interested in the cookie stuff, you should join the mailing list and comment on the charter |
| 16:54 | <abarth> | annevk42: in general, i'm trying to keep the focus narrow |
| 16:55 | <abarth> | annevk42: speccing cookie2 is going to take a lot more work and a lot more time than speccing cookie0 |
| 17:10 | <annevk2> | abarth, if you're going to spec cookies as implemented set-cookie2 is relevant, no? |
| 17:10 | <abarth> | annevk2: depends how widely its used |
| 17:10 | <abarth> | there was a recent message to the list |
| 17:11 | <abarth> | that suggested very few sites use it |
| 17:11 | <abarth> | i'm not sure we want to lock down the behavior of cookie2 |
| 17:11 | <annevk2> | hmm, if we could actually get impl to remove support for it that'd be cool |
| 17:11 | <abarth> | which user agents implement it? |
| 17:12 | <annevk2> | I thougt set-cookie2, not cookie2, was implemented, but maybe not |
| 17:12 | <abarth> | i know they're in opera |
| 17:12 | <abarth> | but i'm not sure where else |
| 17:12 | <annevk2> | interesting |
| 17:14 | <annevk2> | if we're the only ones by all means don't spec it or simply say it's obsolete |
| 17:15 | <annevk2> | if we need extensions we can prolly extend cookie0 somehow once the processing model is written down |
| 17:15 | <abarth> | i don't think we want to say it's obsolete. cookie suck in a number of ways. it would be good to have a long term plan for how to dig ourselves out of the mess |
| 17:15 | <abarth> | yeah, that's a good point |
| 17:15 | <abarth> | that's what 2109 originally tried to do with Version=1 |
| 17:16 | <abarth> | but i think they put the cart a bit in front of the horse |
| 17:16 | <annevk2> | besides rough consensus you need running code :p |
| 17:16 | <annevk2> | (also, versioning sucks :)) |
| 17:40 | <Lachy> | Wow! I guess Microsoft finally providing feedback about HTML5 was bigger news than I thought. http://tech.slashdot.org/story/09/08/08/1231231/Microsoft-Finally-Joins-HTML-5-Standard-Efforts?from=rss |
| 18:17 | <gsnedders> | Lachy: I know! Microsoft doing what they said they would! It's unbelievable! |
| 18:19 | <annevk2> | I see that /. is still up to their high standards |
| 18:29 | <Philip`> | Hmm, are people wondering how much set-cookie2 is used? |
| 18:29 | Philip` | sees it in the headers of loads of pages, particularly JSP ones |
| 20:59 | <annevk2> | twitter still under attack? |
| 20:59 | <zcorpan_> | so now is the time to try to delay last call |
| 20:59 | <annevk2> | neh, that'd be around the end of September |
| 21:00 | <zcorpan_> | although i agree with the contenteditable feedback |
| 21:01 | <zcorpan_> | ah, so they're being generous and being one month early instead of two years as they first promised |
| 21:03 | <annevk2> | I'm happy they're sending something |
| 21:03 | <zcorpan_> | me too |
| 21:04 | <zcorpan_> | i hope they continue to send feedback |
| 21:05 | zcorpan_ | will be offline next week btw |
| 21:06 | <annevk2> | I particularly like that the feedback is constructive |
| 21:06 | <annevk2> | short vacation? |
| 21:06 | <zcorpan_> | yes |
| 21:07 | <annevk2> | nice |
| 21:07 | annevk2 | will be working from somewhere in France next week |
| 21:28 | gsnedders | laughs |
| 21:28 | <gsnedders> | Of course, being in the same room as zcorpan, this was the first I heard of this vacation :P |
| 21:28 | <gsnedders> | (same room at work, that is) |