| 00:00 | <sicking> | erlehmann: so you do what you think is correct in comments.cgi, but remove *all* markup in strictly_filtered_comments.cgi |
| 00:00 | <erlehmann> | intredasting. |
| 00:00 | <sicking> | erlehmann: or say that you're hosting widgets on your site |
| 00:01 | <sicking> | erlehmann: you want the widgets to be able to run script |
| 00:01 | <erlehmann> | i'll still just use html5lib and think i am filtering absolutely, entirely correctly in that case. |
| 00:01 | <sicking> | erlehmann: but not if you can't sandbox them |
| 00:01 | <erlehmann> | that i understand. |
| 00:01 | <sicking> | erlehmann: then you'd let the first src filter out all scripts, but the second would be allowed to run scripts |
| 00:02 | <sicking> | erlehmann: if you're trusting your filtering, then would you ever need sandbox at all? |
| 00:02 | <sicking> | erlehmann: i.e. isn't HTML4 working fine for you? |
| 00:02 | <erlehmann> | still, that's not the graceful degradation i know. it is … something else. i hope i'll never need it. |
| 00:02 | <erlehmann> | last i checked, there was no html4lib ;) |
| 00:02 | <erlehmann> | but yes. |
| 00:03 | <sicking> | erlehmann: well then, if what exists already is good enough for you, then i think we're done here :) |
| 00:03 | <erlehmann> | we are. but now i understand why you did not just filter damn everything. |
| 00:04 | <erlehmann> | (which i, for the record, would do, if i were that unsure of my filtering capabilities.) |
| 00:04 | <erlehmann> | a friend made a wiki and is so paranoid, even internal functions check their assertions about the arguments. |
| 00:04 | <erlehmann> | that is properly paranoid. |
| 00:06 | <Hixie> | sicking: sure, in that use case you'd want to use something different in both cases. But most use cases will be <iframe sandbox src="something-i-think-is-safe-regardless"></iframe> |
| 00:06 | <Hixie> | (s/most/many/, certainly) |
| 00:08 | <sicking> | Hixie: then put the same url in both attributes |
| 00:08 | <Hixie> | sicking: as soon as we do that you're back to your original problem |
| 00:09 | <abarth> | the default-closed behavior is really hard to get for on-domain resources |
| 00:09 | <Hixie> | sicking: i.e. that it is easy to write markup that looks fine, until you start thinking about browsers that don't implement @sandbox |
| 00:09 | <Hixie> | how do you mean? |
| 00:09 | <abarth> | its really hard to host things on-domain and not have them be used against you |
| 00:09 | <abarth> | e.g., by Java or Flash |
| 00:10 | <abarth> | one thing you can do is to set a Content-Disposition: attachment |
| 00:10 | <abarth> | Flash will respect that |
| 00:10 | <abarth> | i haven't tested Flash recently |
| 00:10 | <abarth> | it turns out that sandbox is pretty useful even without text/html-sandbox |
| 00:11 | <Hixie> | well if we are assuming that anything same-domain is guaranteed to be unsandboxable when viewed directly, we might as well require that src="" be cross-origin if sandbox="" is specified |
| 00:11 | <Hixie> | but then that makes a lot of sandbox="" rather pointless |
| 00:11 | <abarth> | a very common way to use it is with an about:blank iframe |
| 00:11 | <abarth> | which you sandbox |
| 00:12 | <abarth> | and then fill up with stuff |
| 00:12 | <Hixie> | ok. so on the short-term, what i'm hearing is that we shoudl drop text/html-sandboxed like microsoft suggests |
| 00:13 | <Hixie> | and on the medium term there might be additional changes that would be useful? |
| 00:15 | <abarth> | in the medium term, i want to convince someone to implement seamless |
| 00:15 | <abarth> | ;) |
| 00:20 | <sicking> | Hixie: and disable the ability to have same-origin sandboxes? |
| 00:20 | <Hixie> | that's the medium term question |
| 00:21 | <Hixie> | i recommend posting on the whatwg list about it |
| 00:21 | <sicking> | so what are the use cases when sandbox is useful? Assuming the aweful fallback in older browsers? |
| 00:21 | <Hixie> | (we'd have to drop allow-same-origin if we did that) |
| 00:22 | <Hixie> | well like i said, defense-in-depth is a huge use case |
| 00:22 | <sicking> | wouldn't that make it cover the same usecases as CSP then? |
| 00:23 | <Hixie> | CSP is far too complex for most authors who have just one domain to use, imho |
| 00:23 | <sicking> | CSP lets you completely disable scripting |
| 00:23 | <sicking> | which would seem like the main usecase for sandbox |
| 00:24 | <sicking> | if we're only talking about defence in depth |
| 00:24 | <Hixie> | i dunno that i'd say it's the main use case |
| 00:24 | <Hixie> | might be an important use case in the defence in depth subset of the use cases |
| 00:24 | <Hixie> | but then so's preventing form submission |
| 00:24 | <Hixie> | and disallowing frame navigation |
| 00:24 | <Hixie> | and blocking plugins... |
| 00:25 | <Hixie> | CSP is so complex that i see abarth asking about it :-P |
| 00:25 | <sicking> | ok, so assume a world where browsers implement CSP, convince me as a browser author what additional use cases would be covered by @sandbox |
| 00:26 | <abarth> | Hixie: CSP is crazy complex |
| 00:26 | <abarth> | its very hard for authors to use |
| 00:26 | <abarth> | i've been spending a bunch of time with early adopters to understand the snags they run into |
| 00:26 | <abarth> | sicking: oh, the use cases are really different |
| 00:26 | <Hixie> | sicking: if CSP was implemented and easy to use, it might obviate many use cases for same-origin sandbox="" |
| 00:26 | <Hixie> | sicking: though not any of the cross-origin ones |
| 00:27 | <abarth> | sicking: CSP is for restricting your own content. sandbox is for restricting other people's content |
| 00:27 | <sicking> | abarth: i'm listening... |
| 00:27 | <Hixie> | sicking: but so far it does not seem that CSP is going to be easy to use, so... |
| 00:27 | <abarth> | sicking: here's a real example |
| 00:27 | <sicking> | yay |
| 00:27 | <abarth> | you've got a RSS feed that you've fetched via CORS |
| 00:28 | <abarth> | and you want to show it to the user in a nice pretty form |
| 00:28 | <abarth> | you send it into a sandboxed iframe |
| 00:28 | <abarth> | and make a nice presentation of it |
| 00:28 | <Hixie> | i love that microsoft's suggestion regarding what to do with the warning is just 'In section 4.8.2 "The iframe element," remove the text "Warning! It is important that the server serve the user-provided HTML using the text/html-sandboxed MIME type so that if the attacker convinces the user to visit that page directly, the page doesn't run in the context of the site's origin, which would make the user vulnerable to any attack found in the page."' |
| 00:28 | <abarth> | that works really well with @sandbox and isn't really doable with CSP |
| 00:28 | <Hixie> | they don't suggest changing it or anything, just removing it |
| 00:28 | <sicking> | abarth: what's the fallback story for old browsers? |
| 00:29 | <abarth> | in the actual case, it didn't matter because it's a browser extension that does this |
| 00:29 | <abarth> | in the case of a web site, you can probably have a lower fidelity rendering of the RSS feed |
| 00:29 | <abarth> | or take some security risks |
| 00:30 | <Hixie> | or wait a few years and then tell the 1% of legacy UAs that they're screwed |
| 00:30 | <sicking> | abarth: i'm much more interested in building features for websites than extensions |
| 00:30 | <abarth> | sure, i just mentioned that case |
| 00:30 | <abarth> | because its a place where this got used this past week |
| 00:31 | <sicking> | abarth: so the concern is that the RSS markup would contain onclick attributes or <script> elements |
| 00:32 | <sicking> | abarth: ? |
| 00:32 | <abarth> | the RSS feed contains HTML |
| 00:32 | <abarth> | e.g., the contents of the posts |
| 00:32 | <sicking> | right |
| 00:32 | <abarth> | and you don't want the content to call alert() |
| 00:33 | <abarth> | for example |
| 00:33 | <abarth> | because that's annoying |
| 00:33 | <sicking> | so it seems you're screwed if you inject that into a about:blank iframe |
| 00:33 | <abarth> | so you don't want script to run |
| 00:33 | <sicking> | since that can run any script |
| 00:33 | <abarth> | what this guy was actually doing |
| 00:33 | <abarth> | was using a data URL |
| 00:34 | <abarth> | and i advised him to just add the sandbox attribute |
| 00:34 | <abarth> | to his iframe |
| 00:34 | <abarth> | and everything worked great |
| 00:34 | <abarth> | he was a very happy customer :) |
| 00:34 | <sicking> | i don't understand how it would work great in the fallback situation |
| 00:34 | <sicking> | i.e. when the browser doesn't support sandbox |
| 00:35 | <sicking> | let me phrase it this way: it seems to me that @sandbox has such a terrible fallback story for browsers that don't support @sandbox, that I'm not sure that we'll want to implement it in firefox and thus encourage it's usage on the web |
| 00:35 | <abarth> | well, for example, we could just how the text of the posts |
| 00:35 | <abarth> | instead of the HTML formating |
| 00:36 | <sicking> | i think there's a word missing there? |
| 00:36 | <abarth> | s/how/show |
| 00:36 | <sicking> | ah |
| 00:37 | <abarth> | its seems like you could make the same argument about CSP |
| 00:37 | <sicking> | abarth: so the idea is that webdevelopers are responsible for checking that @sandbox is supported, and use a completely different codepath if it's not |
| 00:37 | <sicking> | abarth: certainly |
| 00:37 | <sicking> | abarth: CSP is explicitly a defence-in-depth mechanism |
| 00:37 | <abarth> | there are two choices |
| 00:37 | <abarth> | 1) proceed as before and live with any additional risk |
| 00:37 | <sicking> | abarth: i was under the impression that @sandbox wasn't intended to be just defence-in-depth |
| 00:37 | <abarth> | 2) check if its supported and do something else if its not |
| 00:38 | <sicking> | this discussion has made me more confused about whether it is or not :) |
| 00:38 | <abarth> | that's option (2), but option (1) exists too |
| 00:38 | <abarth> | well, consider the Secure attribute on cookies |
| 00:38 | <abarth> | is that defense in depth or is that a security measure? |
| 00:38 | <abarth> | what about browsers that don't support the Secure attribute? |
| 00:39 | <sicking> | are there any such browsers? |
| 00:39 | <abarth> | there were at one point in time |
| 00:39 | <abarth> | we'll be asking the same question about @sandbox in a few years |
| 00:39 | <sicking> | i'm not sure we made good decisions at that point in time :) |
| 00:39 | <abarth> | put another way, |
| 00:40 | <abarth> | what's a site supposed to do with browsers that don't support WebGL ? |
| 00:40 | <abarth> | use a different code path? |
| 00:40 | <Hixie> | sicking: sandbox="" is intended exclusively for defence in depth for now. It will eventually be usable for other things as well. |
| 00:40 | <abarth> | just because this is a security feature doesn't mean all the hard things about introducing new features go away |
| 00:40 | <sicking> | but yes, in a sense the Secure attribute is defense-in-depth. Though we know that MITM is easier than what was thought |
| 00:41 | <abarth> | ok, then you probably believe that every security feature is defense-in-depth |
| 00:41 | <Hixie> | except maybe TLS :-) |
| 00:42 | <Hixie> | what's teh fallback for https:// ? :-) |
| 00:42 | <sicking> | possibly. I'm a not huge fan of "security features" since most of them are patching mistakes of the past |
| 00:42 | <sicking> | but they are obviously needed |
| 00:43 | <Hixie> | "firefox developer not fan of security features" :-P |
| 00:43 | <sicking> | abarth: i'd just much rather that we fell back to a closed situation than an open situation |
| 00:43 | <Hixie> | sicking: falling back to a closed situation would be great, but falling back to nothing is not fallback, it's just the feature not being supported and the site being broken in old UAs |
| 00:44 | <sicking> | abarth: it seems very likely to me that people will do <iframe src="completely_untrusted_contents.cgi" sandbox> |
| 00:44 | <abarth> | i don't think there's any way to do that securely |
| 00:44 | <abarth> | regardless of the design |
| 00:44 | <Hixie> | if a site does <iframe src="completely_untrusted_contents.cgi" sandbox> they have far better problems than fallback |
| 00:44 | <Hixie> | even in completely compliant UAs they'll still get owned |
| 00:45 | <Hixie> | since you can just point a user to a page on another domain with that same iframe without sandbox="" |
| 00:45 | <Hixie> | and boom, you run script on the victim origin |
| 00:45 | <Hixie> | that was the idea behind text/html-sandboxed, which i've just removed from the spec and replaced with warnings saying to use a different origin for untrusted content |
| 00:49 | <sicking> | Hixie: so it seems to make sense to me to make <iframe src="same-origin/comments.cgi" sandbox="..."> refuse to load the iframe? |
| 00:49 | <Hixie> | would you block src="about:blank" too? |
| 00:50 | <sicking> | good question |
| 00:52 | <sicking> | i'd say no |
| 00:52 | <sicking> | since you can't do the thing of "use another site to navigate the user directly to the url thus avoiding the sandbox" |
| 00:55 | <Hixie> | sicking: if you block that then you completely prevent the use case adam brought up earlier |
| 00:55 | <Hixie> | sicking: of being able to generate a file on the fly that has scripting disabled |
| 00:55 | <sicking> | Hixie: yup |
| 00:56 | <Hixie> | ok so... that's bad |
| 00:56 | <sicking> | Hixie: you'll note that I said "no" above |
| 00:56 | <Hixie> | oh, sorry, i misunderstood |
| 00:56 | <Hixie> | i thought you meant no, it wouldn't work :-) |
| 00:56 | <TabAtkins> | Hixie: Random sidenote - we found a better term than "superior parent": "originating element" |
| 00:57 | <Hixie> | sicking: if you don't block it, then what stops someone from just redirecting the page to a same-origin url? |
| 00:57 | <sicking> | Hixie: redirecting about:blank? |
| 00:57 | <Hixie> | TabAtkins: i have no idea what either of those terms mean :-) are they xbl-related things? |
| 00:57 | <Hixie> | TabAtkins: "originating element" sounds like something to do with the origin policy? |
| 00:58 | <Hixie> | sicking: as in, you insert an <iframe sandbox> then you document.write() into it a "<meta http-equiv=refresh content=0;URL=local.html"> |
| 00:58 | <Hixie> | but with my quotes not screwed up |
| 00:58 | <sicking> | Hixie: then it's a new load, so you'd block that |
| 00:59 | <Hixie> | ew |
| 00:59 | <TabAtkins> | Hixie: Dude, "superior parent" comes from css3-content, to refer to a pseudo-elements "parent". |
| 00:59 | <Hixie> | brb need to find power |
| 00:59 | <sicking> | you want different policies depending on if it's the first document or the second document to be loaded in an iframe? |
| 01:05 | <Hixie> | sicking: the current mechanism (not sandbox-specific) handles src="" differently than normal in-frame page loads |
| 01:06 | <sicking> | Hixie: huh?? |
| 01:06 | <sicking> | Hixie: in what way? |
| 01:07 | <Hixie> | sicking: the src="" attribute loads go through the "process the iframe attributes" algorithm first |
| 01:07 | <Hixie> | sicking: the normal loads don't do anything iframe-specific |
| 01:08 | <sicking> | Hixie: so you can have an <iframe sandbox src="...> which contains a document that isn't sandboxed? |
| 01:08 | <sicking> | with proper quotes :) |
| 01:08 | <Hixie> | sicking: maybe i didn't understand you proposal though; are you saying that we should block any page loads that have the same origin if the browsing context's sandboxed origin browsing context flag is set? |
| 01:08 | <Hixie> | sicking: no |
| 01:08 | <Hixie> | sicking: the sandboxing is a feature of the browsing context |
| 01:09 | <Hixie> | TabAtkins: aaah |
| 01:09 | <Hixie> | TabAtkins: not sure "originating element" works since it's not necessarily an element, is it? |
| 01:09 | <Hixie> | TabAtkins: as someone who had forgotten what either term meant, i have to say, both terms seemed equally opaque to me just now |
| 01:10 | <sicking> | Hixie: the way it seems to me, we should block any same-origin loads if the browsing context is sandboxed |
| 01:10 | <sicking> | Hixie: or let me rephrase |
| 01:10 | <sicking> | Hixie: the way it seems to me, we should block any loads where the loaded document is same-origin with the parent document, if the browsing context is sandboxed |
| 01:14 | <Hixie> | sicking: that would block about:blank. |
| 01:15 | <Hixie> | (i assume by "is sandboxed" you mean specifically the case of it having the sandboxed origin browsing context flag, not all sandboxing) |
| 01:32 | <sicking> | Hixie: no, i meant all sandboxing, per the discussion we just had it seems that sandboxing is useless for same-origin loads |
| 01:33 | <sicking> | Hixie: i guess i don't consider about:blank as a "load". But if it is considered a load then add an exception for that |
| 01:35 | <Hixie> | well like i said, there's a difference in handling for initial loads and subsequent loads |
| 01:35 | <Hixie> | the initial load of src="" (empty) and src="about:blank" (normalised) is handled specially in the "process the iframe attributes" algorithm |
| 01:35 | <Hixie> | subsequent loads of about:blank are handled in the navigation algorithm |
| 01:36 | <Hixie> | but it would seem crazy to not allow about:blank to navigate to about:blank, say |
| 01:37 | <sicking> | sure, so exclude all about:blank loads |
| 01:40 | <Hixie> | i just said that would be crazy :-P |
| 01:40 | <Hixie> | oh by exlude you mean allow? |
| 01:40 | <Hixie> | man i'm confused |
| 01:41 | <Hixie> | this really seems like adding really obscure complexity to the platform to me |
| 01:41 | <Hixie> | are we going to do the same for CSP? |
| 01:41 | <Hixie> | i don't see the difference |
| 01:48 | <sicking> | CSP is totally different |
| 01:48 | <sicking> | it applies to all loads, no matter how they happen |
| 01:48 | <Hixie> | how is that different? |
| 01:48 | <sicking> | via sandboxed iframes, non-sandboxed iframes or page navigation |
| 01:48 | <Hixie> | only in new UAs |
| 01:49 | <Hixie> | just like text/html-sandboxed |
| 01:51 | <sicking> | yes, CSP is strictly defense-in-depth |
| 01:51 | <sicking> | that's different from the same-origin issue with sandboxes though |
| 01:51 | <Hixie> | sanbdox is strictly defense-in-depth too. |
| 01:52 | <Hixie> | but i have to go now. ttyl :-) |
| 01:52 | <sicking> | ok, ttyl |
| 01:52 | <Hixie> | i recommend e-mailing the whatwg list to get others in the loop |
| 02:01 | <TabAtkins> | Hixie or abarth: What should we reference for the definition of URL in CSS? We're currently referring to RFC 3986. |
| 02:04 | <TabAtkins> | Hixie or abarth: Our current definition is at http://dev.w3.org/csswg/css3-values/#urls |
| 02:12 | <rniwa> | Hixie, sicking: yt? |
| 04:13 | <annevk> | TabAtkins, CSS URL values are parsed the same as in HTML |
| 04:14 | <annevk> | TabAtkins, though UTF-8 is enforced, just like in XMLHttpRequest |
| 04:14 | <annevk> | TabAtkins, 3986 is wrong, but there's not really a good replacement at the moment |
| 04:14 | <annevk> | I think we should just put everything into the URL specification |
| 04:14 | <annevk> | API, syntax, etc. |
| 04:58 | <sicking> | annevk: ping |
| 04:59 | <annevk> | hey sicking |
| 04:59 | <sicking> | annevk: i don't understand your email regarding the CORS change |
| 04:59 | <sicking> | annevk: can you give an example scenario which you're proposing should change |
| 05:00 | <annevk> | you xhr to from a to b |
| 05:00 | <annevk> | b doe set-cookie |
| 05:00 | <annevk> | withCredentials is true |
| 05:00 | <annevk> | does* |
| 05:00 | <annevk> | b also fails the sharing check |
| 05:00 | <annevk> | Gecko/WebKit set the cookie |
| 05:01 | <sicking> | "fails the sharing check" === "doesn't set access-control-allow-origin to the 'correct' value"? |
| 05:01 | <annevk> | a similar situation with <img crossorigin> is not supposed to set a cookie |
| 05:01 | <annevk> | sicking, for instance, or does not include the header |
| 05:01 | <annevk> | sicking, does not include the credentials header |
| 05:01 | <sicking> | ok |
| 05:02 | <sicking> | hmm.. why doesn't HTML5 simply defer to CORS on this? |
| 05:02 | <sicking> | i'm not sure how to implement this in Gecko... |
| 05:02 | <sicking> | by the time the response gets to the CORS code, the networking library has already set the cookie |
| 05:02 | <sicking> | so i guess we don't follow the HTML5 spec on this, if it indeed demands that behavior |
| 05:03 | <annevk> | HTML says |
| 05:03 | <annevk> | "For the purposes of the calling algorithm, the user agent must act as if there was a fatal network error and no resource was obtained." |
| 05:03 | <annevk> | no resource obtained means no cookie |
| 05:03 | <sicking> | depends on what "the calling algorithm" refers to |
| 05:04 | <sicking> | does it refer to the <img> algorithm which downloads and parses an image? |
| 05:04 | <annevk> | fetch |
| 05:05 | <annevk> | we could also change HTML I suppose |
| 05:05 | <sicking> | which layers of the ISO layer model does "fetch" include? |
| 05:05 | <annevk> | it just seems slightly saner to not alter cookies |
| 05:05 | <annevk> | ISO? |
| 05:06 | <sicking> | OSI |
| 05:07 | <annevk> | still no clue :) |
| 05:07 | <sicking> | annevk: so the algorithm defined in the HTML spec also never sets the UAs cookies. So aborting the algorithm wouldn't seem to affect whether cookies are set |
| 05:07 | <sicking> | http://en.wikipedia.org/wiki/OSI_model |
| 05:07 | <annevk> | fetch sets cookies |
| 05:08 | <annevk> | we should define CORS and fetch in one spec really |
| 05:08 | <annevk> | but you know, lots of work refactoring those two |
| 05:09 | <sicking> | ah, yes |
| 05:09 | <sicking> | it'll still be hard to implement this, since it means violating the HTTP layer model |
| 05:10 | <sicking> | i.e. you can't use a plain HTTP library to do the load |
| 05:10 | <sicking> | i do sort of understand/like the idea. It'll just be very hacky to implement |
| 05:10 | <annevk> | a plain HTTP library does not do cookies |
| 05:11 | <sicking> | annevk: well.. i guess that's a matter of definition |
| 05:11 | <sicking> | ours does |
| 05:11 | <annevk> | if cookies are part of HTTP, so is CORS |
| 05:11 | <annevk> | aaah, so whatever Gecko's HTTP library does is plain :) |
| 05:12 | <sicking> | i don't expect we're the only ones to put cookies into the http library |
| 05:12 | <annevk> | for Opera it's no problem either way |
| 05:12 | <sicking> | for any browser it makes a lot of sense to have a layer that you can call into which does http including cookies and cache |
| 05:13 | <annevk> | that same library should prolly do CORS though |
| 05:13 | <annevk> | given the potentially CORS-enabled fetching stuff |
| 05:13 | <sicking> | annevk: arguably, but that'll require more refactoring than spec changes ;-) |
| 05:13 | <sicking> | annevk: i guess I'm fine with it if other browsers agree. Would be nice to have a more understandable email to the group though. |
| 05:18 | <annevk> | sicking, I emailed a reply to myself explaining it more clearly (hopefully) |
| 05:26 | <heycam> | hmm, 1323 unread public-html mails. wonder if there's anything worth reading in there... |
| 05:27 | <annevk> | hey |
| 05:27 | <annevk> | look who's back |
| 05:29 | <Hixie> | here now |
| 05:29 | <Hixie> | what's up |
| 05:30 | <heycam> | hi annevk |
| 05:30 | <heycam> | (and sicking, from before!) |
| 05:31 | <sicking> | annevk: thanks! I sent a reply. I generally think I agree with the change, though I have no idea when we'd be able to implement :( |
| 05:31 | <sicking> | annevk: our network library has this very silly policy of not having any security code in it. |
| 05:32 | <sicking> | annevk: We've abandoned the policy, but it's a slow process to change |
| 05:32 | <annevk> | Hixie, HTML applies a slightly stricter set of rules to CORS with respect to cookies |
| 05:32 | <Hixie> | that is unintentional if so |
| 05:33 | <Hixie> | let me check |
| 05:33 | <annevk> | Hixie, but we like it |
| 05:33 | sicking | wonders if darin actually made a bad decision!?! |
| 05:33 | <annevk> | Hixie, it's the bit about completely ignoring the response resource if the resource sharing check fails |
| 05:33 | <Hixie> | cookies get set in step 6.3 of the fetch algorithm |
| 05:34 | <annevk> | "For the purposes of the calling algorithm, the user agent must act as if there was a fatal network error and no resource was obtained." |
| 05:34 | <annevk> | if there's no resource, there's no cookies |
| 05:34 | <Hixie> | that happnes long after the cookies are set |
| 05:35 | <annevk> | oh really? |
| 05:35 | <Hixie> | i'm assuming you're talking about a potentially CORS-enabled fetch right? |
| 05:35 | <annevk> | no |
| 05:35 | <Hixie> | oh |
| 05:35 | <Hixie> | which case do you mean then |
| 05:35 | <annevk> | oh yes |
| 05:35 | <Hixie> | ok |
| 05:35 | <annevk> | <img crossorigin> for instance |
| 05:35 | <Hixie> | so assume mode = Use Credentials |
| 05:35 | <Hixie> | we start the algorithm |
| 05:36 | <Hixie> | step 1 calls CORS "cross-origin request", section 7.1 of CORS |
| 05:36 | <Hixie> | step 2 of that calls the "simple cross-origin request" |
| 05:36 | <Hixie> | section 7.1.4 of CORS |
| 05:36 | <Hixie> | step 1 of that calls "make a request steps" |
| 05:36 | <Hixie> | in section 7.1.7 of CORS |
| 05:37 | <Hixie> | that calls "fetch" in HTML |
| 05:37 | <Hixie> | oh but it has the block cookies flag set |
| 05:37 | <Hixie> | interesting |
| 05:37 | <Hixie> | ok then <img crossorigin> never sets cookies one way or the other currently |
| 05:37 | <Hixie> | oops |
| 05:39 | <Hixie> | annevk: when does XHR set cookies? |
| 05:42 | <annevk> | block cookies is only set if credentials is false |
| 05:42 | <annevk> | but credentials is true here |
| 05:42 | <annevk> | you said assume mode = Use Credentials |
| 05:42 | <annevk> | XHR sets cookies whenever "fetch" does |
| 05:43 | <annevk> | really need to merge CORS and fetch and I really do not want to |
| 05:43 | <annevk> | can't we have some Google code projects on specs next time that is up? |
| 05:43 | <annevk> | Google Summer of Code I meant |
| 05:45 | <heycam> | or a NaNo(WebSpec)Mo |
| 05:45 | <Hixie> | oh well |
| 05:45 | <Hixie> | ok |
| 05:45 | <Hixie> | so if credentials is true |
| 05:45 | <Hixie> | then let me continue: |
| 05:45 | <Hixie> | that calls "fetch" in HTML |
| 05:45 | <Hixie> | "fetch" then does the stuff, gets to step 6 |
| 05:46 | <Hixie> | step 6.3 sets cookies |
| 05:46 | <Hixie> | then fetch starts firing tasks |
| 05:47 | <Hixie> | looks like you should be calling "fetch" with the synchronous flag set btw |
| 05:47 | <Hixie> | either that or talk about getting the data from the tasks it fires |
| 05:47 | <Hixie> | but anyway |
| 05:47 | <Hixie> | ignoring that |
| 05:47 | <Hixie> | back to "simple cross-origin request" |
| 05:47 | <Hixie> | it goes into the "otherwise" branch, which calls "resource sharing check" |
| 05:48 | <Hixie> | section 7.2 of CORS |
| 05:48 | <Hixie> | step 1 sees no Access-Control-Allow-Origin header values so it returns fail |
| 05:48 | <Hixie> | so back to "simple cross-origin request"; it calls the "network error steps" |
| 05:48 | <Hixie> | in 7.1.7 |
| 05:48 | <Hixie> | that sets cross-origin request status to /network error/ |
| 05:49 | <Hixie> | and aborts "simple cross-origin request" |
| 05:49 | <Hixie> | so we're back to "cross-origin request", which just returns since it's finished too |
| 05:50 | <Hixie> | so, we're back to the HTML spec's "potentially CORS-enabled fetch" |
| 05:50 | <Hixie> | second branch, step 2. That waits for the CORS cross-origin request status to have a value, which it does |
| 05:50 | <Hixie> | so then step 3 |
| 05:50 | <Hixie> | goes through the first branch, since it's not "success" |
| 05:50 | <Hixie> | all the tasks are discarded, and it returns a fatal network error |
| 05:50 | <Hixie> | but the cookies are already set |
| 05:51 | <Hixie> | since they were set way back when before CORS was checked |
| 05:51 | <Hixie> | here ends my story |
| 05:56 | <annevk> | o_O |
| 05:57 | <Hixie> | why o_O? |
| 06:00 | <annevk> | complicated :) |
| 06:00 | <Hixie> | you wrote most of it! :-P |
| 06:37 | <annevk> | yeah I guess we should do new Text() |
| 06:38 | <annevk> | prolly should revert the overloading change and start with that |
| 06:38 | <annevk> | still not really sure of the new EVERYTHING() plan |
| 06:38 | <annevk> | new HTMLDivElement() is so ugly |
| 06:38 | <annevk> | new Div() would be kind of neat |
| 06:38 | <Hixie> | new HTMLUnknownElement() |
| 06:38 | <Hixie> | new HTML*Element() in general just doesn't work |
| 06:39 | <annevk> | so alex thinks it should work and should just result in a useless object |
| 06:40 | <annevk> | but I'm not sure what the point of that is |
| 06:40 | <Hixie> | yeah i pretty strongly disagree with alex on this issue |
| 06:43 | <heycam> | new HTMLDivElement() is indeed ugly |
| 06:43 | <heycam> | I would like new Element("div") |
| 06:44 | <annevk> | that returns a non-Element object? |
| 06:44 | <heycam> | don't think it matters too much that the return type is something more specific than Element -- it at least is a kind of Element |
| 06:44 | <annevk> | hmm |
| 06:44 | <heycam> | I think "Element" is nice and short enough |
| 06:44 | <annevk> | Element.create is pretty short too |
| 06:44 | <heycam> | but not as :) |
| 06:45 | <annevk> | node.append(["div"]) would be even shorter |
| 06:45 | <annevk> | see some emails on www-dom |
| 06:45 | <heycam> | so I agree with Alex that we should encourage constructors where possible, it's just that I don't know that forcing spec writers to specify constructor behaviour on everything is the best (or most polite) way to do that |
| 06:46 | <annevk> | we can just add [NoConstructor] everywhere until the concrete proposals arrive |
| 06:46 | <heycam> | guess so |
| 06:46 | <annevk> | or we can skip the make work and wait for the latter |
| 06:46 | <heycam> | still seems kinda rude for webidl to force that |
| 06:46 | <annevk> | I was being sarcastic |
| 06:47 | <annevk> | I think what we have now is good and people should make concrete proposals for constructors where they are needed |
| 06:47 | <heycam> | sarcasm with no indicating punctuation! |
| 06:47 | <annevk> | if we end up with constructors everywhere, we can make them optional |
| 06:48 | <annevk> | heycam, the horror! |
| 06:48 | <annevk> | next you claim it's inaccessible |
| 06:48 | <Hixie> | i think the json-like description of elements is kinda crazy, personally |
| 06:48 | <annevk> | crazy-neat? |
| 06:49 | <heycam> | many people write helper functions to do that json-like thing |
| 06:50 | <Hixie> | crazy ugly and incomprehensible |
| 06:50 | <heycam> | i'm a bit wary of potential confusion over whether it sets js properties, dom attributes, magic with onfoo handlers, etc. |
| 06:50 | <Hixie> | if we're going that route, please for the love of kittens just use E4X or something similar |
| 06:50 | <heycam> | ha |
| 06:53 | <annevk> | E4X yeah right |
| 06:53 | <annevk> | heycam, ah yeah, guess we'll end up with attributes and on* as event handlers |
| 06:53 | <annevk> | if we do it |
| 06:53 | <heycam> | :/ |
| 06:54 | <heycam> | hopefully as separate arguments? |
| 06:54 | <heycam> | i.e. not intermingled on the one object passed in? |
| 06:54 | <annevk> | that was the idea initially, but is that really worth it? |
| 06:55 | <heycam> | dunno, it just rubs me the wrong way somehow, treating /^on/ attributes differently |
| 06:55 | <heycam> | (do we have any non event listener attributes that begin with "on"?) |
| 06:56 | <annevk> | don't think so |
| 06:57 | <heycam> | even if we don't, I wouldn't like to rule out such attributes because Element.create or whatever would treat them as event names after the "on" |
| 06:58 | <heycam> | "1emu = 1pt/12700" |
| 06:58 | <heycam> | I would've expected an emu to be a kind of large unit |
| 07:02 | <annevk> | heycam, given that X is going to be optimized for web platform elements I do not think that's a problem |
| 07:04 | <annevk> | but then I'm still not sure whether we should do X (e.g. Element.create) at all, plus all the other various DOM methods ojan is proposing |
| 07:05 | heycam | probably skimmed past that email |
| 07:05 | <annevk> | "modifying the DOM WAS: Node append" |
| 07:15 | <annevk> | heycam, so the one thing we need for that is unbounded dictionaries |
| 07:16 | <heycam> | yeah |
| 07:16 | <annevk> | heycam, so there's still a defined processing order and everything |
| 07:16 | <heycam> | I just avoided adding that until there were concrete needs for it |
| 07:16 | <annevk> | okay |
| 07:18 | <annevk> | it would be great if we could discuss these proposals with various implementors |
| 07:18 | <annevk> | it seems pretty clear authors want some simplified way of doing things |
| 07:18 | <heycam> | (is that not what the www-dom discussion is achieving?) |
| 07:18 | <annevk> | everyone has their own convenience method / templating system |
| 07:18 | <annevk> | yeah, though I'm missing sicking / othermaciej |
| 07:18 | <heycam> | yeah, it is tough to standardise a templating system -- it's almost entirely a syntax debate |
| 07:19 | <annevk> | actually, not sicking |
| 07:19 | <annevk> | I do think that if we want to simplify the DOM having element templates would be huge step |
| 07:20 | <annevk> | and keeps people from using innerHTML which has all the badness of string concatenation |
| 07:20 | <annevk> | well hopefully keeps them away from it, no guarantees |
| 07:20 | <heycam> | sprintf |
| 07:20 | <Hixie> | the biggest problem with innerHTML is the lack of compile-time syntax checking |
| 07:23 | <annevk> | the array stuff gives you that to some extent |
| 07:23 | <annevk> | prolly about as far as E4X |
| 07:23 | <Hixie> | yes but it's 10x as verbose |
| 07:23 | <Hixie> | and uglier than Element.create() |
| 07:23 | <annevk> | hmm |
| 07:24 | <annevk> | <div class="test"/> |
| 07:24 | <annevk> | ["div", {class:"test"}] |
| 07:24 | <annevk> | not too bad |
| 07:24 | <Hixie> | uh huh |
| 07:25 | <heycam> | I just some more sarcasm without punctuation :) |
| 07:25 | <heycam> | *detected some |
| 07:25 | <Hixie> | :-) |
| 07:25 | <annevk> | if you write </div> instead you even save a character |
| 07:26 | <Hixie> | what's <div><p><span>TEST</span></p></div> in your syntax? |
| 07:26 | <heycam> | I find the purely arrays/strings/object literals too hard to read |
| 07:26 | <Hixie> | yes |
| 07:26 | <heycam> | even though I'm guilty of writing functions like that for my own purposes |
| 07:26 | <heycam> | because I hate to use so many method calls :) |
| 07:27 | <Hixie> | i use duct tape for private use, too. i wouldn't try to sell a product made with duct tape. |
| 07:27 | <heycam> | so I wonder, without having written out an example, if a small amount of verbosity like requiring new Element("div", { class: "test" }) rather than just using an array with a string in first position to mean the tag name, would help make it more readable |
| 07:27 | <annevk> | ["div", ["p", ["span", "TEST"]]] |
| 07:28 | <annevk> | it wins again |
| 07:28 | <Hixie> | wow |
| 07:28 | <Hixie> | wins is so not the word i was going to use |
| 07:28 | <heycam> | lol |
| 07:36 | <jacobolu_> | burn |
| 07:37 | <annevk> | I'm not sure |
| 07:37 | <jacobolus> | Hixie: you don't think having some kind of structured way to write these that's not a string would be helpful? |
| 07:37 | <annevk> | I'm not the one who claimed "10x as verbose" |
| 07:37 | <Hixie> | jacobolus: i absolutely think it would be helpful |
| 07:37 | <Hixie> | jacobolus: i think E4X would be the way to go |
| 07:37 | <Hixie> | jacobolus: or, within JS itself, nested Element.create() calls |
| 07:37 | <jacobolus> | oh. I'm not very familiar w/ e4x |
| 07:38 | <jacobolus> | wait, you just write xml inline w/ the javascript? |
| 07:38 | <Hixie> | annevk: not 10x longer, just 10x more verbose |
| 07:38 | <jacobolus> | ick |
| 07:38 | <heycam> | I think a structured way to write these things is good, it's just that using only [] and {} as the delimiters makes it far from readable |
| 07:38 | <heycam> | I would happily sacrifice some conciseness for readability |
| 07:38 | <Hixie> | annevk: there's way more punctuation going on in ways that really make it very hard to work out what's going on |
| 07:39 | <Hixie> | annevk: e.g. "foo", "foo" should never be able to represent an element containing a text node |
| 07:39 | <Hixie> | annevk: that's just batty |
| 07:39 | heycam | easily envisages calls to this Element.create ending with ]]]}]]]}]}); |
| 07:40 | <annevk> | Hixie, hmm, at the end of the array you have either other elements or text nodes; I don't think it's too bad |
| 07:40 | <heycam> | would be nice if the whatwg mailing list software included an Archived-At header (probably someone has requested this before) |
| 07:40 | <annevk> | Hixie, you do have to know the model of course, otherwise it is indeed kind of hard |
| 07:40 | <annevk> | heycam, lots of people have |
| 07:41 | <annevk> | heycam, I was planning on writing some intermediary script at one point, but never did |
| 07:42 | <annevk> | my idea was passing he Message-ID after some URL that would have some kind of lookup and do redirects |
| 07:42 | <annevk> | the* |
| 07:43 | <Hixie> | heycam: tell dreamhost :-( |
| 07:43 | <heycam> | annevk, oh yeah, like w3.org/mid/... |
| 07:43 | <Hixie> | annevk: good APIs are intuitive |
| 07:44 | <annevk> | it's not exactly less or more intuitive than the Element.create proposal |
| 07:44 | <annevk> | or new Event() |
| 07:46 | <jacobolus> | Hixie: what's an intuitive DOM creation/query/manipulation API in your view? |
| 07:46 | <Hixie> | annevk: as an extreme example, I would say Element.create("div", {title: "bar"}, ["Hello"]); is more intuitive than Element.create(["div", {title: "bar"}, ["Hello"]]);, because in the latter one there's one argument, and it's not clear that one array's values mean different things, whereas in the former it's clear that the arguments mean different things, and it seems obvious that an element creation method would start with an element name, and you can work out the |
| 07:46 | <Hixie> | jacobolus: well, an intuitive creation one would be: var mydiv = <div/>; |
| 07:47 | <jacobolus> | but just making that a string in a simple function is just as good at that point, ISTM |
| 07:47 | <Hixie> | (i wouldn't take anything from E4X other than the element literals, fwiw) |
| 07:47 | <Hixie> | jacobolus: strings aren't syntax-checked |
| 07:47 | <jacobolus> | syntax-checked by whom? |
| 07:47 | <Hixie> | the compiler |
| 07:48 | <Hixie> | jacobolus: consider the difference between var mytree = <p><i>hello</b> world</p>; and var mytree = "<p><i>hello</b> world</p>"; |
| 07:48 | <Hixie> | jacobolus: how long do you think it would take to catch those two errors? |
| 07:48 | <jacobolus> | so then a question... how do you make it dynamic? |
| 07:48 | <jacobolus> | i.e. if I want to stick some custom stuff in halfway through |
| 07:48 | <Hixie> | for the first one, i'd say about 1 second to catch it, and about 3 seconds to fix it. for the second, it might never get caught, but it's probably measured in weeks or months. |
| 07:49 | <Hixie> | E4X had a mechanism for that |
| 07:49 | <Hixie> | something like var name = 'jacobolus'; var mydiv = <div>Hello {name}</div>; |
| 07:49 | <jacobolus> | hm |
| 07:50 | <jacobolus> | so why couldn't you just make it a function w/ some name |
| 07:50 | <Hixie> | (you can test it in mozilla, it ships with e4x) |
| 07:50 | <Hixie> | a function? |
| 07:50 | <jacobolus> | and pass in a string |
| 07:50 | <jacobolus> | and then have tooling |
| 07:50 | <Hixie> | strings aren't syntax checked |
| 07:50 | <jacobolus> | that would do the syntax checing |
| 07:50 | <jacobolus> | *checking |
| 07:50 | <jacobolus> | that could easily be done in e.g. a text editor, linter, etc. |
| 07:51 | <Hixie> | not as easily as "the compiler won't run the code while it's broken" |
| 07:51 | <Hixie> | and the difference is enough that nobody does what you're suggesting |
| 07:51 | <jacobolus> | they do for regexps in python, as one example |
| 07:52 | <Hixie> | maybe python developers are better than js developers? |
| 07:52 | <jacobolus> | heh |
| 07:53 | <jacobolus> | are there any people who have written descriptive praises of E4X? |
| 07:53 | <Hixie> | descriptive praises? |
| 07:53 | <jacobolus> | i.e. is there some testimonial I can read about how nice it was to deal with? |
| 07:53 | <jacobolus> | with like, specific problems it solved and so forth? |
| 07:53 | <Hixie> | i dunno, probably |
| 07:54 | <Hixie> | most commentary was about how it sucks |
| 07:54 | <jacobolus> | because just at first glance my guess is that I sort of wouldn't like it |
| 07:54 | <Hixie> | the suckitude being mostly related to the bits i haven't talked about :-) |
| 07:54 | <Hixie> | (it tried to solve too much imho) |
| 07:54 | <Hixie> | anyway, i gotta go |
| 07:54 | <Hixie> | bed time |
| 07:54 | <jacobolus> | cheers |
| 07:55 | <jacobolus> | I wonder if there are any DSLs embedded in other languages for XML manipulation that are particularly elegant |
| 07:55 | <jacobolus> | some lisp macros or some such |
| 07:56 | <jacobolus> | or I guess just for creating complex structured data with attributes and descendants at each level |
| 07:56 | <jacobolus> | wouldn't necessarily have to be based around xml |
| 07:57 | <jacobolus> | annevk: FWIW, I like your thing :) |
| 08:45 | <hsivonen> | Is webcam support in Opera 12 going to be WebRTC or something else? |
| 09:21 | <hsivonen> | hmm. Opera 12 doesn't have license legal stuff for Google's WebRTC code on the about page at least |
| 09:22 | <hsivonen> | is there some documentation about what kind of webcam integration Opera 12 has? |
| 09:25 | <hsivonen> | considering how portable Opera is, I'm a bit surprised Opera isn't using clang already on Mac: http://my.opera.com/desktopteam/blog/2011/09/28/mac-compiler-js-performance |
| 09:34 | <foolip> | hsivonen, it's not Google code |
| 09:41 | <doublec> | opera 12 has webrtc support? |
| 09:42 | <hsivonen> | foolip: what's the feature? |
| 09:42 | <hsivonen> | foolip: that is, what's the webcam integration feature? still upload via <input type=file>? WebRTC? something else? |
| 09:44 | <foolip> | hsivonen, I really don't know, but I assume it's in anticipation of future features that need it (WebRTC) |
| 09:45 | <hsivonen> | foolip: ok. I was wondering about https://twitter.com/#!/ComputerActive/status/123663408133451776 which was retweeted by @opera |
| 09:46 | <foolip> | hmm, yeah, I'm not sure what the sales pitch is, AFAICT you can do things like "augmented reality" now, for what it's worth |
| 09:46 | <foolip> | on mobile at least, on desktop I don't think we have device orientation events :) |
| 09:47 | <hsivonen> | I haven't verified, but IIRC, Firefox has device orientation events on laptops |
| 09:48 | <hsivonen> | though having to tilt the whole laptop might not be as good UI as tilting a phone |
| 09:48 | <foolip> | I'm just guessing though |
| 09:48 | <zcorpan> | orientation events worked for me in firefox on my macbook |
| 09:49 | <hsivonen> | http://news.ycombinator.com/item?id=3096398 is interesting. especially Brendan's follow-up at the bottom of the page |
| 09:59 | <MikeSmith> | hsivonen: indeed |
| 10:01 | <annevk> | what blog post of alex does Brendan mean? |
| 10:02 | <hsivonen> | annevk: I don't know. I'm guessing http://infrequently.org/2011/09/google-the-future-of-javascript/ |
| 10:10 | <annevk> | hsivonen, afaik Opera 12 allows displaying the feed of a device camera via <video> (which you can then manipulate using <canvas>) |
| 10:11 | <hsivonen> | annevk: ok. |
| 10:11 | <hsivonen> | annevk: are there docs on how to do that from Web content? |
| 10:12 | <annevk> | I think we implemented getUserMedia() |
| 10:12 | <annevk> | there was a labs build with that a while ago |
| 10:12 | <annevk> | http://my.opera.com/core/blog/2011/03/23/webcam-orientation-preview |
| 10:13 | <annevk> | instead of URL.createObjectURL() we currently allow directly assigning a Stream object to <video>.src instead; I think that's the only deviation |
| 10:13 | <annevk> | it's just to let people play around a little bit |
| 10:19 | <hsivonen> | annevk: thanks |
| 10:24 | <hsivonen> | the new features in http://www.w3.org/2011/09/games/ look rather reasonable except for the hardware performance score |
| 10:25 | <hsivonen> | surely each per-sensitive app needs to run its own benchmark to find out the perf that's relevant to the app |
| 10:26 | <jgraham> | Yeah, that sounds like a bad idea |
| 10:29 | <hsivonen> | if the app uses requestAnimationFrame, it should be able to detect if the fps is bad and try throttle down whatever slow stuff it does |
| 10:30 | <hsivonen> | though that might not help. I tried the WebGL aquarium in Firefox on Galaxy S II and the level of detail had no bearing on the frame rate |
| 10:30 | <hsivonen> | I'm guessing the frame rate was terrible due to something like readbacks from the GPU |
| 12:44 | <smaug____> | where is Ms2ger |
| 12:45 | <smaug____> | annevk5: is the plan to move onfoo idl properties to DOM[4/web/Core/Math.random()] ? |
| 13:06 | <Ms3ger> | smaug____: you called? |
| 13:07 | <annevk> | Ms3ger-- |
| 13:07 | <Ms3ger> | Postfix, so it would still return Ms3ger |
| 13:08 | <Ms3ger> | (I should note that I stole that joke from someone in #jsapi) |
| 13:09 | <smaug____> | Ms3ger: just about the thing I asked from annevk5 |
| 13:09 | <smaug____> | onfoo properties |
| 13:09 | <smaug____> | whether those are going to DOM[4/web/Core/Math.random()] |
| 13:10 | <annevk> | it's been argued they should be |
| 13:10 | <Ms3ger> | Hmm, DOMWeb |
| 13:10 | <annevk> | makes a lot of sense in Dutch |
| 13:10 | <annevk> | so probably not a good name |
| 13:10 | <Ms3ger> | annevk++ |
| 13:11 | <Ms3ger> | Anyway, not sure about the specific attributes |
| 13:11 | <Ms3ger> | It might be good to move the infrastructure to DOM4, though |
| 13:15 | <smaug____> | annevk: Ms3ger: I was just wondering the right component for http://www.w3.org/Bugs/Public/show_bug.cgi?id=14428 It could be DOM or HTML or WebIDL, I guess. I picked up the last one |
| 13:16 | Ms3ger | is happy to let heycam figure out what to do |
| 13:16 | <Ms3ger> | Also, welcome back, heycam! |
| 13:17 | Ms3ger | goes off again |
| 13:17 | <Ms3ger> | ttyl |
| 13:17 | <annevk> | yeah, I'm pretty happy for other people to figure out how event handlers should work before we include them |
| 14:51 | <jgraham> | So, why can't I find the spec for innerHTML anymore? |
| 14:53 | <annevk> | you're not looking carefully? http://html5.org/specs/dom-parsing.html |
| 14:54 | <jgraham> | Oh you made a whole new spec for it. You know that will confuse the hell out of people, right? |
| 14:55 | <annevk> | you always predict doom |
| 14:55 | <annevk> | ;) |
| 16:28 | <hsivonen> | I wonder where this person gets his ideas about Mozilla http://news.ycombinator.com/item?id=3094880 |
| 16:29 | <bga_> | open bytecode stantard is ok |
| 16:31 | <bga_> | i remeber http://code.google.com/p/chromium/issues/detail?id=64290 |
| 16:33 | <jgraham> | hsivonen: Cynicism untempered by reality? |
| 16:34 | <dglazkov> | good morning, Whatwg! |
| 16:37 | <divya> | GOOD MORNING DGLAZKOV |
| 16:38 | <dglazkov> | all caps. Excellent choice. |
| 16:38 | <divya> | i really put in the effort for the cause of html5 |
| 16:39 | <hsivonen> | I wonder if I'm reading too much into Opera's PR language when I observe that they don't say "Flash" when they've added Flash support |
| 16:39 | <hsivonen> | it looks like an attempt to downplay Flash as something that users are aware of |
| 16:39 | <timeless> | hsivonen: are they bundling flash now? |
| 16:40 | <hsivonen> | timeless: no, but on desktop, they are automating installation at least on Windows, IIRC |
| 16:40 | <hsivonen> | timeless: this is about the latest Opera Mobile release, though, which added Flash support on Honeycomb |
| 16:41 | <hsivonen> | apparently the way Flash presents itself to NPAPI is different in Android 2.x and 3.x |
| 16:42 | <timeless> | sandboxing related perhaps? |
| 16:43 | <hsivonen> | dunno |
| 16:43 | <hasather> | hsivonen: the guy writing that blog post is not an Opera employee btw (but I think the blog is official) |
| 16:45 | <jgraham> | We get random strangers to write our PR stuff? :) |
| 16:45 | <hasather> | jgraham: neither random nor stranger I think, but yea... :D |
| 16:46 | <beverloo> | I agree that it's hard to see which posts are and which posts aren't official at Opera's |
| 16:46 | <timeless> | jgraham: nokia did |
| 16:46 | <timeless> | we had contractors responsible for the official nokia connections or whatever it was blog |
| 17:09 | <hsivonen> | is the XHR error flag exposed to scripts? |
| 17:12 | <hsivonen> | looks like Gecko returns xhr.status == 0 for non-HTTP requests :-( |
| 17:21 | <smaug____> | Should http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#fetch say something about caching |
| 17:23 | <smaug____> | especially, in which case is loading from browser cache ok, and in which case it isn't |
| 17:26 | <AryehGregor> | What's the story with '? What's the newest browser that doesn't support it? |
| 17:27 | <AryehGregor> | IE6, at least? |
| 17:27 | <AryehGregor> | Apparently IE7 also? |
| 17:28 | AryehGregor | uses ' instead |
| 17:29 | <AryehGregor> | jgraham, I pushed the innerHTML change, with a single escaping function defined as you requested. |
| 17:30 | <AryehGregor> | (am also looking at pushing other changes) |
| 17:33 | <gsnedders> | hasather: What blog post? |
| 17:37 | <gsnedders> | Oh, that one.~ |
| 17:37 | AryehGregor | finds that 50% of total time in Chrome is in format_value now |
| 17:43 | gsnedders | is increasingly doubting the open-web nature of even the Dart to JS compiler. |
| 17:44 | <AryehGregor> | Is it any worse than GWT? |
| 17:45 | <gsnedders> | At a high-level it appears better, but looking into it it seems worse. |
| 17:45 | AryehGregor | hasn't looked into it |
| 17:45 | AryehGregor | doubts the utility of "let's introduce yet another language", though |
| 17:46 | <gsnedders> | Oh, yeah. Sure. But it's really a bit too late for me to start bitching about that now… |
| 17:47 | <gsnedders> | AryehGregor: It avoids the browser sniffing, but is supported on fewer browsers, and without any given reason (or bug reports)… |
| 17:47 | <AryehGregor> | "supported on" meaning "actually works on" or "is tested on"? |
| 17:48 | <gsnedders> | I believe the latter. Though it makes me the doubt the former. |
| 17:48 | <gsnedders> | Testing is hardly that expensive. |
| 17:48 | <AryehGregor> | Testing is very expensive if you do enough of it. |
| 17:48 | <AryehGregor> | If there's no browser-sniffing of any kind, all browsers should be able to work just by making sure they follow what other browsers do, right? |
| 17:48 | <gsnedders> | For a company like Google, with the amount of resources already thrown at Dart, it's cheap. |
| 17:49 | <AryehGregor> | Even compared to the benefit, taking market shares into account? |
| 17:49 | <gsnedders> | AryehGregor: Except that at least the Dart website (haven't looked to see if that uses Dart though, FWIW) breaks if we fix DOM 3 Events compliance bug to move inline with Fx/WebKit. |
| 17:50 | <gsnedders> | AryehGregor: IE has a non-negilable marketshare. We have enough marketshare that they care about us enough in GWT. |
| 17:50 | <gsnedders> | And our JS impl really should be good enough that it should work fine. |
| 17:50 | <gsnedders> | So the cost of supporting Carakan should be ~0. |
| 17:51 | <gsnedders> | Provided they actually follow ES5 in their impl and don't rely upon things where V8/SM intend on changing behaviour for it. |
| 17:52 | <gsnedders> | Same with Chakra, really. |
| 17:52 | <gsnedders> | Omitting the two JS engines that nowadays probably have the best support for ES5 is… odd. |
| 17:52 | <gsnedders> | To say the least. |
| 17:53 | <AryehGregor> | Well, supporting an extra browser is cheap if all your tests are automated. |
| 17:53 | <gsnedders> | And I'd hope they are. |
| 17:54 | <AryehGregor> | For a language converter, yeah. |
| 18:04 | <hsivonen> | what's the deal with WebM support in Opera Mobile for Android? Earlier, I was told Opera Mobile supported WebM from 2.3 onwards |
| 18:05 | <hsivonen> | I just tested the latest release on Android 3.1 and it supported H.264 but not WebM |
| 18:12 | <AryehGregor> | Is it possible for window.parent to change? |
| 18:12 | <gsnedders> | hsivonen: I believe we just use the system video decoder, so whatever that supports. |
| 18:12 | <AryehGregor> | I mean, for the same script to see different values at different times? |
| 18:12 | <AryehGregor> | For the same window object? |
| 18:12 | <timeless> | AryehGregor: hrm |
| 18:13 | <AryehGregor> | I'd think it should be impossible, but I wanted to check. |
| 18:13 | <timeless> | if a browser implements a user friendly version of <pop-frame-out-as-window-out |
| 18:13 | <timeless> | but i don't think that exists anywhere |
| 18:14 | <hsivonen> | gsnedders: maybe I should remove the advice that Opera Mobile supports WebM on Android, then |
| 18:15 | <hsivonen> | gsnedders: because it sucks to tell people it does if it doesn't |
| 18:15 | <gsnedders> | hsivonen: We should support it. |
| 18:15 | <hsivonen> | at least Firefox supports it consistently even if performance is unusable |
| 18:15 | gsnedders | has no Android 2.3.3+ device to test on |
| 18:16 | <AryehGregor> | Is it worthwhile to support it if performance is unusable? |
| 18:17 | <hsivonen> | well, at least I should edit the page not to suggest Opera 11+ users to install Opera as a remedy to WebM non-support |
| 18:17 | <AryehGregor> | Isn't it better in that case to fall back to the next source, if any? |
| 18:17 | <hsivonen> | AryehGregor: unclear |
| 18:17 | <hsivonen> | hmm. which reminds me that I haven't tested it with layers acceleration |
| 18:18 | <gsnedders> | hsivonen: I saw someone saying Mobile 11.5 at least had better WebM perf than Firefox on some Android device. |
| 18:18 | <timeless> | gsnedders: do you have an n900? |
| 18:19 | timeless | wonders which version Android is used for Nitdroid |
| 18:19 | <gsnedders> | timeless: No. HTC Legend. |
| 18:20 | <hsivonen> | the perf sucks even with layers acceleration enabled :-( |
| 18:21 | <gsnedders> | hsivonen: What device are you testing on, and on what Android version? |
| 18:21 | <gsnedders> | And what version of Mobile? |
| 18:22 | <hsivonen> | gsnedders: Samsung Galaxy Tab 10.1, Android 3.1 (latest build available), Opera Mobile 11.50 (the one released today) |
| 18:22 | <dglazkov> | AryehGregor: re window.parent, you should talk with dimich on #webkit about this. There's a thing called "magic iframe" in WebKit, which _may_ make window.parent change |
| 18:23 | <AryehGregor> | dglazkov, I suspect that for my use-case it's not the end of the world if it changes in crazy circumstances. |
| 18:23 | <gsnedders> | hsivonen: What page were you using for testing? |
| 18:23 | <dglazkov> | AryehGregor: k |
| 18:23 | <hsivonen> | gsnedders: http://webm.html5.org/ |
| 18:23 | <gsnedders> | hsivonen: eh, we appear to have https://bugs.opera.com/wizard/mobile now, so can you just file a bug? |
| 18:23 | <hsivonen> | a friend on another channel reports that WebM doesn't work in GSII in Opera Mobile 11.x |
| 18:24 | <hsivonen> | gsnedders: ok |
| 18:24 | <gsnedders> | I'll make sure it gets attention, because that is /bad/ it doesn't work. |
| 18:26 | <hsivonen> | gsnedders: oh, the playback support is there. canPlayType is wrong |
| 18:26 | <hsivonen> | FAIL |
| 18:26 | <gsnedders> | hsivonen: That may be down to YouTube breaking if canPlayType is right, AIUI |
| 18:27 | <gsnedders> | (I wish I was joking) |
| 18:28 | <hsivonen> | even worse |
| 18:29 | <hsivonen> | gsnedders: ANDMEX-3236 |
| 18:29 | <gsnedders> | "Enabling only webM audio for Android 2.3.3+ Video doesn't work well and causes Android media server to crash." |
| 18:30 | <AryehGregor> | Does anyone have any tips on how to speed up layout of a 40,000-row table? |
| 18:30 | <gsnedders> | So, uh, we seem to have it disabled because Android's WebM impl is unstable |
| 18:41 | <gsnedders> | Heheh, I like how in response to Dart people are again saying there should be a generic bytecode, "to avoid the cost of parsing", totally ignoring a large part of the cost is validating it, which will remain true for any bytecode. |
| 18:41 | <gsnedders> | The only real gain is a few fewer bytes to process, but the same number of tokens, pretty much… |
| 18:43 | <gsnedders> | AryehGregor: Also, Dart->JS compiler's output does UA sniff and blocks everything that isn't Chrome, Safari, or Firefox. |
| 18:43 | <gsnedders> | AryehGregor: They only talk about removing the UA block on IE9. |
| 18:43 | <AryehGregor> | Seriously? That's massively lame. |
| 18:43 | <gsnedders> | AryehGregor: So Opera is totally fucked. |
| 18:44 | <AryehGregor> | Along with every other minor browser that uses WebKit or whatever but happens not to look like one of the major browsers. |
| 18:44 | <AryehGregor> | (although probably all of those pretend to be a major browser) |
| 18:45 | <gsnedders> | So Google care enough about us to give us however-many-million-dollars per year, but not enough to actually support us. |
| 18:45 | <AryehGregor> | It's independent people making different decisions. |
| 18:53 | <timeless> | AryehGregor: um |
| 18:54 | <AryehGregor> | ? |
| 18:54 | <timeless> | i don't think we pretend to be a major browser |
| 18:54 | timeless | seems to recall getting crappy content |
| 18:54 | <AryehGregor> | You probably just get broken content in sites that whitelist browsers, then. |
| 18:56 | <timeless> | oh cute |
| 18:56 | <timeless> | we claim to be Safari :) |
| 18:56 | <AryehGregor> | So does Chrome, kind of. |
| 18:56 | <AryehGregor> | And Safari claims to be Mozilla, as does everyone else. |
| 18:56 | <AryehGregor> | UA strings are fun. |
| 18:56 | <timeless> | i thought Opera or IE stopped claiming to be Gecko |
| 18:57 | <TabAtkins> | annevk5 heycam|away: If HTMLDivElement is really ugly, but "new Div()" is probably too short, what about semi-namespacing? "new HTML.Div()"? |
| 18:57 | <timeless> | HTMLDivElement is really ugly |
| 18:57 | <AryehGregor> | It still claims to be Mozilla, right? |
| 18:57 | <TabAtkins> | I think that might be a good way to expose CSS value constructors in a short manner as well. |
| 19:00 | <dglazkov> | HTML.Div() sounds nice. |
| 19:00 | <dglazkov> | maybe html.Div()? |
| 19:00 | dglazkov | breaks out his shed painting overalls |
| 19:00 | <timeless> | darn, ie9 still claims to be mozilla/5 |
| 19:00 | timeless | sobs |
| 19:09 | <rniwa> | who knows about microdata well? |
| 19:10 | <AryehGregor> | rniwa, well, Hixie designed it . . . but a bunch of other people here know about it too. |
| 19:10 | <AryehGregor> | If you ask your question, it will probably be answered. |
| 19:10 | <rniwa> | okay |
| 19:11 | <rniwa> | would an element with itemscope and itemtype considered to be an top-level item even if there are some item-scope element that refers to that element via itemref? |
| 19:19 | <cygri> | rniwa: the spec says "An item is a top-level microdata item if its element does not have an itemprop attribute." |
| 19:20 | <rniwa> | cygri: on the other hand, it also says "Items that are not part of others are called top-level microdata items." |
| 19:20 | <AryehGregor> | The latter sounds non-normative. |
| 19:20 | <cygri> | note that itemref doesn't actually refer to items, despite its name. it just imports any property-value pairs on the target or its descendants |
| 19:20 | <AryehGregor> | Is it in a normative section? |
| 19:20 | <rniwa> | cygri: ah, that's good point. |
| 19:21 | <rniwa> | cygri: but what if we had an ancestor with itemscope? |
| 19:21 | <cygri> | yeah. it also sounds slighly wrong |
| 19:21 | <rniwa> | cygri: e.g. <div itemscope>hello<span itemscope itemtype="~~"> |
| 19:21 | <rniwa> | I don't think span should be considered as the top-level microdata items in this case |
| 19:22 | <rniwa> | or maybe top-level isn't really top-level |
| 19:22 | <cygri> | according to the spec it is top-level |
| 19:22 | <rniwa> | huh... |
| 19:22 | <rniwa> | even if we had <div itemscope itemtype="~~">hello<span itemscope itemtype="~~"><b itemprop="~~"> ? |
| 19:22 | <cygri> | as AryehGregor said, the section you quoted is non-normative |
| 19:23 | <rniwa> | cygri: but in this case, div's item will contain b's content, right? |
| 19:23 | <rniwa> | cygri: so we'll have two top-level items in this case? |
| 19:26 | <rniwa> | cygri_: ? |
| 19:26 | <cygri_> | what? |
| 19:27 | <rniwa> | cygri: did you get my last question? |
| 19:27 | <rniwa> | cygri: if we had <div itemscope itemtype="~~">hello<span itemscope itemtype="~~"><b itemprop="~~"> |
| 19:27 | <rniwa> | cygri: would we have two top-level items? |
| 19:27 | cygri | is on a bus. internet not good |
| 19:28 | <cygri> | that looks like two top-level items to me |
| 19:28 | <rniwa> | cygri: ok, thanks |
| 19:28 | <cygri> | yw! |
| 20:31 | <rniwa> | AryehGregor: regarding the -webkit-user-modify, the most important users are AIR and Inspector |
| 20:32 | <AryehGregor> | What's AIR? |
| 20:32 | <rniwa> | AryehGregor: but I've seen some users in the public Web |
| 20:32 | <rniwa> | AryehGregor: Adobe's new Web authoring tool |
| 20:32 | <rniwa> | AryehGregor: http://www.adobe.com/products/air.html |
| 20:32 | <AryehGregor> | Hmm. |
| 20:32 | <rniwa> | AryehGregor: we can probably ask them to use contenteditable instead |
| 20:32 | <AryehGregor> | Well, I don't like all these features being exposed permanently with vendor prefixes, but I guess there are more important things to worry about. |
| 20:33 | <rniwa> | AryehGregor: well, at least we don't expose user-modify :) |
| 20:33 | <rniwa> | in fact, that's the whole point of vendor-prefixing it, right? |
| 20:33 | <rniwa> | so that we can kill the feature from the standard |
| 20:33 | <AryehGregor> | Well, it's much better than non-vendor-prefixed, yes. |
| 20:33 | <rniwa> | without breaking the whole web |
| 20:43 | <jgraham> | Hixie: tables in email++ |
| 20:47 | <Hixie> | heh |
| 20:47 | <Hixie> | i'm sure i'll get told it's inaccessible |
| 20:47 | <Hixie> | or i would if it was in public-html |
| 20:48 | <Hixie> | you'd be surprised how often i got told that my ascii art sig was a travesty and an insult to accessibility tool users everywhere |
| 20:49 | <TabAtkins> | Hixie: It would be less confusing to me if you didn't try to conflate the term "binding" and "component". We've been trying to distinguish the terms for ease of discussion such that "component" implies permanence and "binding" implies decoration. |
| 20:49 | <Hixie> | the terms mean the same thing, and have since 1997 or so |
| 20:49 | <jgraham> | I'm not surprised. It wouldn't be so funny if accessibility advocates hadn't been responsible for the most confusing, inaccessible email I have ever received on a standards mailing list |
| 20:49 | <Hixie> | jgraham: yeah, tell me about it |
| 20:50 | <TabAtkins> | Hixie: Which is why we've been trying to distinguish them. ^_^ |
| 20:50 | <Hixie> | TabAtkins: trying to take terms that mean the same thing and distinguish them after more than 15 years of them meaning the same thing is pointless. use new terms. :-) |
| 20:50 | <jgraham> | TabAtkins: Those implications aren't at all clear from the names, so I wouldn't try that |
| 20:51 | <Hixie> | TabAtkins: "presentation transient binding" and "semantic API-defining binding", for instance |
| 20:51 | <TabAtkins> | Hixie: Those are horrible! |
| 20:51 | <AryehGregor> | They're long, is all. |
| 20:52 | <TabAtkins> | That's what I said. |
| 20:52 | <AryehGregor> | You can kill either of the two modifiers on both. |
| 20:52 | <Hixie> | TabAtkins: (i wasn't even aware that there were two concepts until i suggested there were a few e-mails ago, btw, and i'd no idea that there was any attempt to redefine the terms until today) |
| 20:52 | <TabAtkins> | Hixie: No wonder you've been so confused, then. We've been talking solely about permanent bindings forever. |
| 20:53 | <Hixie> | TabAtkins: yeah stop that. |
| 20:53 | <TabAtkins> | What? Why? |
| 20:53 | <Hixie> | because the two problems have almost identical solution spaces and it is pointless to ignore one of the two problems when designing the solution |
| 20:53 | <TabAtkins> | But they dont'! They're so different! |
| 20:53 | <Hixie> | they're almost identical |
| 20:54 | <Hixie> | there's two differences |
| 20:54 | <Hixie> | see my most recent e-mail with the table |
| 20:54 | <TabAtkins> | One changes the prototype chain, exposes public API. One can be swapped on-and-off because it makes no lasting changes. |
| 20:54 | <Hixie> | that's it |
| 20:54 | <Hixie> | that's the changes |
| 20:54 | <TabAtkins> | "Two" differences underscores the magnitude of the differences. |
| 20:54 | <Hixie> | i don't think you mean "underscores" but i agree with what you actually said, even if it's not what you meant :-) |
| 20:55 | <TabAtkins> | s/underscores/understates/ |
| 20:55 | <Hixie> | the differences are nearly trivial. XBL2 could be adopted to separating them with barely a dozen edits. |
| 20:55 | <TabAtkins> | I... don't know how to respond to that, except by saying "No". |
| 20:56 | <Hixie> | let me know when you have a more coherent answer :-) |
| 20:56 | <TabAtkins> | "You're wrong"? |
| 20:56 | <Hixie> | maybe you can explain how? |
| 20:57 | <TabAtkins> | The ideal API for permanently changing something is a decent bit different from the ideal API for adding a swappable decorator. |
| 20:57 | <Hixie> | sure. One is is="foo" and the other is binding: foo; |
| 20:58 | <Hixie> | you're not suggesting that shadow trees would need to be defined differently, or that event handlers for one would look different than for the other, right? |
| 20:59 | <TabAtkins> | Shadow trees should use the same definition mechanism, obviously. Binding event listeners may look different. Exposing further API beyond that would definitely look different, since you can't do it at all in the decorator case. |
| 21:08 | <Hixie> | TabAtkins: just excluding certain features in one case doesn't make it look different, just excludes certain features |
| 21:08 | <Hixie> | bbiab lunch |
| 22:04 | AryehGregor | ponders the philosophy of testing features that depend on one another |
| 22:04 | <AryehGregor> | If you can't test one feature because an unrelated feature is buggy or unsupported, should the test pass or fail? |
| 22:04 | <AryehGregor> | If it fails, you're putting a lot of weight on possibly minor bugs in features that other features happen to depend on. |
| 22:05 | <AryehGregor> | If it passes, that takes more effort to handle, and also you penalize browsers for fixing bugs in features that other features depend on (because their score can only go down). |
| 22:05 | <AryehGregor> | (for the dependent tests, that is) |
| 22:06 | <gsnedders> | It's a failure, because you've failed to run the test. |
| 22:06 | <AryehGregor> | I guess it should generally fail, unless there's some way to avoid the bug in the underlying feature. |
| 22:06 | <gsnedders> | Unless the test is simply not applicable. |
| 22:07 | <AryehGregor> | Well, if you can easily work around the underlying bug, I think you should. |
| 22:07 | <AryehGregor> | Like WebKit throws WrongDocumentError if you try to set a range's endpoint to a node that's in another document from the one you created the range in. |
| 22:08 | <AryehGregor> | So when creating ranges for tests, other than in setStart/setEnd tests, I make sure that I call createRange() on the ownerDocument of the intended endpoints. |
| 22:08 | <AryehGregor> | Otherwise that one minor bug would create zillions of spurious failures in unrelated features. |
| 22:09 | <gsnedders> | You can always have it as a separate prereq function, and group results into pass, fail, prereq failed |
| 22:10 | <AryehGregor> | That doesn't really solve the problem. It just obscures it. |
| 22:10 | AryehGregor | discovers that the Range tests all seem to be broken, since no one adjusted the relative URLs to testharness.js |
| 22:10 | AryehGregor | goes to fix |
| 22:16 | <jgraham> | AryehGregor: You should avoid unnecessarily depending on features that you aren't explicitly trying to test |
| 22:16 | <AryehGregor> | On the other hand, IE seemingly doesn't let you create Ranges whose boundary points don't descend from a Document. |
| 22:17 | <jgraham> | But you should always be conservative about handing out "pass" |
| 22:17 | <AryehGregor> | So if I have a test that starts by creating such a range, what am I supposed to do? |
| 22:17 | <AryehGregor> | In that case, I have to fail it. |
| 22:17 | <jgraham> | AryehGregor: Yes. They have a bug. They will fix the bug and the test will pass |
| 22:18 | <jgraham> | there isn't a problem unless you are creating unnecessary dependencies |
| 22:19 | <AryehGregor> | Now, WebKit/Opera mangle ranges when you do addRange(), so the range that winds up in the actual selection might not have the same boundary points as the one you gave to addRange(). In that case, when testing collapseToStart(), do I just test that whatever range ends up there gets collapsed to the start? Or do I decide that's not really what I'm testing, if the range is substantially different from the one I put in, so I fail them? |
| 22:19 | <jgraham> | Judgement call |
| 22:19 | <AryehGregor> | What if they don't put any range in at all, so they wind up with a Selection that has no ranges? Do I just test that they throw an exception, or do I fail them because that has no relationship to what I'm supposed to be testing? |
| 22:19 | AryehGregor | is ambivalent about this one |
| 22:20 | <jgraham> | I think I would prefer to be a bit conservative and always check that you have the right range |
| 22:20 | AryehGregor | thinks he'll let it slide if there winds up being some Range present, but not if there's no Range, because then you could pass all the tests if addRange() and collapseToStart() were both no-ops |
| 22:20 | <AryehGregor> | jgraham, that means WebKit fails almost every single test, even though its collapseToStart() implementation seems to be almost completely correct. |
| 22:21 | <jgraham> | AryehGregor: Well that doesn't seem ideal |
| 22:21 | <AryehGregor> | (Opera fails every test anyway, because its Selection implementation is broken beyond comprehension) |
| 22:21 | <jgraham> | But maybe it will motivate them to fix the bug :) |
| 22:21 | <gsnedders> | AryehGregor: But if you can't construct an environment to test that in, then how do you know it's almost completely correct? |
| 22:22 | <AryehGregor> | gsnedders, because it does add a range, just not the one I specified. And then it collapses the range it did add correctly. |
| 22:23 | <gsnedders> | AryehGregor: Then should you not assert that it adds the range it does add correctly, regardless of what that is? |
| 22:23 | <AryehGregor> | gsnedders, yeah, that's what I'm doing. |
| 22:23 | <gsnedders> | Which means WebKit should pass? |
| 22:23 | <AryehGregor> | Yes. |
| 22:24 | <gsnedders> | Then I'm confused. |
| 22:26 | <AryehGregor> | Okay, so now Gecko passes everything because it's actually correct, Opera fails everything because it's actually completely broken, WebKit fails about half the tests because it doesn't add any range at all in some cases, and IE fails almost all the tests because it genuinely has a bug in collapseToStart/End. |
| 22:26 | <AryehGregor> | Seems good to me. |
| 22:32 | <gsnedders> | Are we actually that broken? The fact we manage to work with most sites tends to suggest we're not /that/ broken. |
| 22:33 | <AryehGregor> | gsnedders, it could be some artifact of my test setup. I tend to find that addRange() routinely does nothing in Opera. |
| 22:33 | <AryehGregor> | So the selection remains empty. |
| 22:33 | <AryehGregor> | I suspect it has something to do with Opera deciding the range I give it isn't visible or something. |
| 22:34 | <AryehGregor> | Also, authors in real life commonly deal with user-created selections and don't use addRange at all. |
| 22:34 | <AryehGregor> | But obviously tests can't do that. |
| 22:34 | <rniwa> | AryehGregor: what is this range bug you're describing? |
| 22:34 | <AryehGregor> | rniwa, WebKit fails lots of Selection tests because addRange() doesn't add the same range it's given, it normalizes it. As we've discussed. |
| 22:35 | <rniwa> | AryehGregor: ah I see. |
| 22:35 | <AryehGregor> | gsnedders, http://dvcs.w3.org/hg/editing/raw-file/tip/selecttest/collapseToStartEnd.html |
| 22:36 | <AryehGregor> | rniwa, but there are two other tests here that fail for a different reason (not "Sanity check"), didn't look into it closely: http://dvcs.w3.org/hg/editing/raw-file/tip/selecttest/collapseToStartEnd.html |
| 22:43 | <gsnedders> | AryehGregor: Where's the spec, again? |
| 22:43 | <AryehGregor> | gsnedders, it's wandered around a bit, but is now part of the editing spec. http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#selections |
| 22:45 | <gsnedders> | AryehGregor: Okay, so addRange only does something if the range is not detached (in the DOM) and is collapsed. |
| 22:46 | <AryehGregor> | It only works if the range is collapsed? |
| 22:46 | <AryehGregor> | Wha? |
| 22:46 | <AryehGregor> | Not detached I understand, although it's not per spec. |
| 22:46 | <AryehGregor> | But collapsed? |
| 22:46 | <AryehGregor> | How are you supposed to create non-collapsed selections, then? |
| 22:46 | <gsnedders> | Don't ask me. I'm just reading the code. :) |
| 22:48 | <gsnedders> | Do you have tests for isCollapsed? That may help… |
| 22:48 | <AryehGregor> | Well, if you can suggest a sane way to create non-collapsed selections, I'm willing to add the workaround to my selection tests. |
| 22:49 | <AryehGregor> | I haven't tested isCollapsed yet, but if I did, it would consist of making a bunch of selections with addRange() and then checking isCollapsed, so it would still break in Opera. |
| 22:49 | <AryehGregor> | Also, Opera seems to not be adding even collapsed non-detached selections when I do addRange(), in my collapseToStart/End tests. |
| 22:50 | <AryehGregor> | All the nodes that are detached are named detached* in the test names, or foreign* for a foreign document, or xml* for a foreign XML document. |
| 22:55 | <rniwa> | AryehGregor: webkit supports setPosition |
| 22:55 | <rniwa> | AryehGregor: and setBaseAndExtent methods |
| 22:55 | <rniwa> | AryehGregor: perhaps you may want to standardize either |
| 22:56 | <gsnedders> | AryehGregor: Hmm. |
| 23:36 | <gsnedders> | AryehGregor: I'm fairly certain you're hitting some weird edge-case bug. |
| 23:36 | <gsnedders> | Or at least, I'm utterly confused. :) |
| 23:41 | <AryehGregor> | rniwa, those are totally redundant with collapse()/extend(). WebKit should get rid of them, IMO. |
| 23:42 | <AryehGregor> | I don't want to standardize them when they're not useful at all and just clutter an API that's already redundant. |
| 23:42 | <rniwa> | AryehGregor: not sure. setPosition seems useful when you want to set a collapsed selection |
| 23:42 | <AryehGregor> | rniwa, how does it differ from collapse()? |
| 23:42 | <rniwa> | AryehGregor: it seems too verbose to create a range and then remove all ranges and then add new range |
| 23:43 | <rniwa> | AryehGregor: hm... collapse takes node and index? |
| 23:43 | <AryehGregor> | rniwa, yes, but I only do that because IE doesn't support extend(). collapse()+extend() is only two lines. |
| 23:43 | <AryehGregor> | rniwa, Selection.collapse does. Not to be confused with the totally different Range.collapse. |
| 23:44 | <AryehGregor> | gsnedders, yeah, my tests are probably hitting some kind of edge case. I remember once before I tried debugging Opera test failures and found that moving the nodes I was selecting to the top of the document somehow fixed it. |
| 23:45 | <AryehGregor> | Could it have something to do with the fact that the nodes are created and then selected without any repaints/event loop spins in between? |
| 23:45 | <AryehGregor> | Since selections in Opera are somewhat visual. |
| 23:45 | <AryehGregor> | No, doesn't seem to be it. |
| 23:45 | <AryehGregor> | Well, if you find an explanation, let me know. |
| 23:46 | <AryehGregor> | I'd be happy to work around the bugs, since sometimes it's useful to see what Opera does. |
| 23:46 | <AryehGregor> | (although I'm unlikely to change the spec solely because Opera does something, given the relevant market shares, it can still sometimes provide useful insight) |
| 23:46 | <gsnedders> | AryehGregor: I know vaguely what's going on in the code, but no idea how it gets into that state |
| 23:47 | <AryehGregor> | I don't think it's just one issue, though. I get the impression that Opera's Selection implementation is sulky and likes to throw its hands in the air and give up if it gets slightly confused. |
| 23:48 | <gsnedders> | The thing that's making addRange a no-op has nothing to do with the selection impl, though |
| 23:48 | <AryehGregor> | What does it have to do with? The Range implementation? |
| 23:49 | <gsnedders> | Far lower-level window management stuff. |
| 23:49 | <AryehGregor> | Oh. |
| 23:49 | <AryehGregor> | So it's tied to display and not just the DOM? |
| 23:49 | <AryehGregor> | WebKit seems to be like that too. |
| 23:49 | <gsnedders> | No. |
| 23:49 | <AryehGregor> | Hmm. |
| 23:49 | <gsnedders> | (Or at least I don't think so.) |
| 23:50 | gsnedders | asks on IRC as to why it's in that state bug expects no answer until tomorrow |
| 23:51 | <gsnedders> | AryehGregor: Possibly because the tests run on load and before the document is visible. |
| 23:51 | <AryehGregor> | gsnedders, they run before load. |
| 23:51 | <AryehGregor> | But so does my minimal test case, which works. |
| 23:52 | <gsnedders> | s/on load/while loading/ was what I meant, really |
| 23:52 | <gsnedders> | AryehGregor: Possibly a race-condition as to when it first displays the frame. |
| 23:52 | <AryehGregor> | Would make sense. |
| 23:55 | <gsnedders> | (As for what's visible, well, I'd say ask the person why wrote that comment, but I don't know how you can ask someone who is dead (Geir). :)) |
| 23:55 | <gsnedders> | I'm guessing it means the obvious thing. |
| 23:55 | <AryehGregor> | :( |
| 23:58 | <gsnedders> | (Nothing apart from the obvious thing really makes sense) |