| 00:05 | <TabAtkins> | zcorpan: Since it looks like the quirks only need to be handled at the "top level" of a property, I was able to put together a much simpler version. Just made a small addition to the declaration-value mode, and then defined two variants of "consume a primitive" that do the quirky things. |
| 00:06 | <TabAtkins> | (Your version was slightly wrong anyway - it was written like there was only a single "quirks-function" flag, when you really need a stack to handle nested functions.) |
| 00:25 | <Hixie> | hsivonen: yt? |
| 00:31 | <smaug____> | I bit late for hsivonen, I guess |
| 00:35 | <Hixie> | yeah, but we can always hope :-) |
| 03:28 | <kennyluck> | hi, WHATWG! |
| 04:07 | <MikeSmith> | kennyluck: hey man |
| 04:08 | <MikeSmith> | kennyluck: we don't have component-watching support in the version of bugzilla we're running |
| 04:08 | <MikeSmith> | I think it's a bugzilla 4 feature |
| 04:09 | <MikeSmith> | Hixie (or anybody else who's awake): It's possible for a single assertion in the spec to have multiple test cases associated with it, right? |
| 04:09 | <kennyluck> | MikeSmith, hmm… ok. I won't be the person pushing for it. |
| 04:10 | <MikeSmith> | kennyluck: I'd love to have it too but I don't think we are going to be migrating to v4 any time soon |
| 04:13 | <MikeSmith> | about the test-case question, I'm working on a how-to that attempts to explain how to determine what to test in a spec |
| 04:53 | <Hixie> | MikeSmith: yeah, of course |
| 04:54 | <Hixie> | MikeSmith: e.g. "if the user agent receives a value between 25 and 30, it must show blue" would have at least a dozen tests |
| 04:54 | <MikeSmith> | Hixie: yeah sorry I was thinking out loud |
| 04:55 | <Hixie> | (-1, 0, 1, 24..31, an arbitrary number above 31, 2**31-1, 2**32, 2**63, not a number...) |
| 04:55 | <MikeSmith> | yeah |
| 04:55 | <MikeSmith> | I'm using "On setting, if the new value is one of “none”, “copy”, “link”, or “move”, then the attribute’s current value must be set to the new value" for dropEffect as an example |
| 04:56 | <Hixie> | that one has many test assertions in one since it applies to many modes, iirc |
| 04:58 | <MikeSmith> | ok |
| 05:00 | <Hixie> | honestly for most assertions one can come up with a near infinite number of tests |
| 05:00 | <Hixie> | the key is to only come up with as many as is required to keep the engineers busy :-) |
| 05:14 | <MikeSmith_> | Hixie: :-) |
| 06:57 | <jgraham> | MikeSmith: In HTML lots of the musts are "must run the following steps" followed by a multistep algorithm that invokes several other multistep algorithms |
| 06:57 | <jgraham> | In such cases it doesn't even make sense to say that you are testing the top-level "must: |
| 06:57 | <jgraham> | You are typically trying to test that a particular set of steps in the algorithm are correctly implemented |
| 06:58 | <MikeSmith> | jgraham: yeah, understood |
| 06:58 | <MikeSmith> | about those |
| 06:58 | <MikeSmith> | plh and I working on a W3C "Testing how-to" |
| 06:59 | <MikeSmith> | current source is at https://github.com/w3c/testing-how-to |
| 06:59 | <MikeSmith> | if you care to take a look and have any comments |
| 06:59 | <MikeSmith> | I'm going to be working on the rest of it in the next few hours |
| 07:00 | <jgraham> | OK |
| 07:04 | <jgraham> | MikeSmith: I think Hixie tries to write so that "foo is bar" statements are always just factual i.e. they fall out of some other part of the spec |
| 07:04 | <jgraham> | But others are not so careful |
| 07:04 | <MikeSmith> | yeah I know |
| 07:05 | <MikeSmith> | when I see that pattern in the HTML spec, I can be confident it's just stating a fact for which the actual requirements are stated elsewhere |
| 07:06 | <MikeSmith> | but no such confidence for most other specs |
| 07:06 | <jgraham> | Also, it's basically impossible to write tests that just test one thing. I mean as soon as you depend on the parser, or the DOM, or whatever that's making the assumption that many other things work |
| 07:07 | <jgraham> | The trick is to be clear about what is acceptable to assume and what is not |
| 07:08 | <jgraham> | You can probably assume that the parser works, as long as you are not doing anything funky. But you might have to be careful around less interoperable bits of the spec or bits more closely related to the subject of your test |
| 07:09 | <MikeSmith> | OK |
| 07:10 | <jgraham> | s/reading the entire spec/reading the spec/ |
| 07:10 | <jgraham> | There is *some* modularity, even in something like HTML ;) |
| 07:10 | <MikeSmith> | k :-) |
| 07:12 | <jgraham> | The testharness.js example with firstElementChild is horrible |
| 07:13 | <jgraham> | assert_true(!!something) is ugly because it's deliberately undermining the test harness |
| 07:14 | <jgraham> | The right tests to use there would be assert_idl_attribute |
| 07:14 | <jgraham> | But people don't like that because the interoperability on where the attributes go on the prototype chain is so poor |
| 07:16 | <Ms2ger> | I don't use assert_idl_attribute because I always forget it exists :) |
| 07:17 | <MikeSmith> | jgraham: I will pass that on to plh |
| 07:17 | <MikeSmith> | he wrote that part |
| 07:17 | <jgraham> | Also the link to the navigation timing tests is not optimal |
| 07:17 | Ms2ger | blames these tests being manual before |
| 07:17 | <MikeSmith> | why? |
| 07:18 | <jgraham> | Because they add a layer of indirection on top of the testing framework |
| 07:18 | <jgraham> | For some reason |
| 07:18 | <jgraham> | Hardly the most obvious example to lean from |
| 07:18 | <jgraham> | *learn |
| 07:19 | <MikeSmith> | ah OK |
| 07:20 | <jgraham> | I don't know what is the *best* example to use |
| 07:24 | <Ms2ger> | My tests, duh :) |
| 07:25 | <jgraham> | Something like Opera's classList tests or something |
| 07:26 | <jgraham> | Ms2ger: You submitted so many it was hard to find a nice self-contained example with > 1 test per page and not too much extraneous stuff |
| 07:26 | <jgraham> | Well I don't mean extraneous |
| 07:26 | <jgraham> | I mean "extra functions and stuff that are not just direct use of the test harness" |
| 07:27 | <Ms2ger> | And testing something you don't have to read four specs to understand? :) |
| 07:29 | <jgraham> | I wasn't so concerned with whether people would understand the pass condition ;) |
| 07:29 | <jgraham> | Maybe something from DOM? |
| 07:50 | <Ms2ger> | Hrm |
| 07:51 | <Ms2ger> | jgraham, is jl someone you can forward questions to? |
| 07:51 | <jgraham> | Ms2ger: Yes, in general. No now in specific (he is on vacation) |
| 07:52 | <Ms2ger> | Hm |
| 07:52 | <Ms2ger> | Then, do you know why new Event("foo").eventPhase is AT_TARGET in Opera? |
| 07:53 | <Ms2ger> | It's NONE in Chrome and Gecko |
| 07:53 | <Ms2ger> | And afaict in the spec |
| 07:53 | <jgraham> | It could just be a bug |
| 07:55 | <Ms2ger> | Also, I guess I shouldn't use assert_idl_attribute for methods |
| 07:57 | <Ms2ger> | Oh |
| 07:57 | <Ms2ger> | Opera doesn't have Event.NONE? |
| 07:58 | <odinho> | Ms2ger: Yeah, seem to remember something like that. |
| 07:59 | <odinho> | Ms2ger: sof just fixed `contains` on Node not Element, btw. Thanks for the heads up. :) |
| 07:59 | <Ms2ger> | Ah, nice |
| 08:03 | <odinho> | Ms2ger: So... Are you writing this test just now? |
| 08:04 | <Ms2ger> | Which? |
| 08:05 | <Ms2ger> | I'm adding a bit to http://localhost/tests/webapps/DOMCore/tests/submissions/Ms2ger/Event-constructors.html |
| 08:05 | <Ms2ger> | (With obvious substitution to get a URL you can access :)) |
| 08:07 | <Ms2ger> | odinho, so about those IDB tests... |
| 08:12 | <Ms2ger> | jgraham, dunno what you were looking at for the example, but maybe http://w3c-test.org/webapps/DOMCore/tests/submissions/Ms2ger/Event-constructors.html ? |
| 08:14 | <gsnedders> | Ms2ger: We simply never added support for Event.NONE, so no. |
| 08:14 | <Ms2ger> | gsnedders, do you have a bug? |
| 08:16 | <gsnedders> | Ms2ger: odinho claimed not |
| 08:17 | <odinho> | odinho was thinking about making it when having a test to add to it :P |
| 08:18 | <gsnedders> | odinho: Work quicker! |
| 08:18 | <Ms2ger> | http://w3c-test.org/webapps/DOMCore/tests/submissions/Ms2ger/Event-constants.html |
| 08:18 | <odinho> | gsnedders: Imma like multitasking, you might steal that task. |
| 08:19 | <odinho> | Ms2ger: What about those? |
| 08:21 | <Ms2ger> | odinho, are Microsoft's tests completely redundant? |
| 08:21 | <odinho> | Ms2ger: Yeah, -- and they're wrong. |
| 08:24 | <Ms2ger> | odinho, can we get rid of them? |
| 08:25 | <jgraham> | Microsoft? |
| 08:29 | <jgraham> | Ms2ger: Those tests might be OK, although the pattern of having multiple independent asserts in the same test is mildly troubling |
| 08:29 | <odinho> | (Some places) |
| 08:29 | <odinho> | They get 40% pass on my version of their own tests. While they get 100% on their own. |
| 08:29 | <odinho> | Or they're probably just not as strict. I should investigate why they get such a low score. Sshouldnt be like that. |
| 08:30 | <jgraham> | I mean it's not bad and I do it too, but it isn't the nicest bit of testharness.js |
| 08:31 | <odinho> | Ms2ger: Hmm. Well, it's Alex that's test facilitator for IDB, -- so guess there'll be hurt feelings etc if you just remove them :P |
| 08:31 | <odinho> | And I guess they're updating them some more behind the scenes. |
| 08:35 | <zcorpan> | TabAtkins: unitless needs to work in rect(10 10 10 10) |
| 08:44 | <jgraham> | gsnedders: http://packages.python.org/six/ |
| 08:49 | <gsnedders> | jgraham: Still not sure it helps me. |
| 08:49 | <gsnedders> | jgraham: Have looked before, etc |
| 10:42 | <Ms2ger> | zcorpan, it's only the terms defined in html.json that get into html-generated.json... Would be nice to get them pulled out of the spec somehow |
| 10:44 | <zcorpan> | yeah |
| 10:45 | <zcorpan> | maybe the spec splitter can output a json with all the terms and their urls? |
| 10:45 | <zcorpan> | or i guess the splitter doesn't care about terms |
| 10:46 | <zcorpan> | but anolis itself knows what the terms are when it generates the spec |
| 11:06 | <odinho> | Ms2ger: Heh, did you actually have AT_TARGET in the test before there? Why? Only tested in Opera ( ;-) ). |
| 11:07 | <Ms2ger> | odinho, I blame annevk / jl |
| 11:10 | <odinho> | lol, I wonder how that happened |
| 11:10 | <Ms2ger> | zcorpan, I guess jgraham runs that instance... |
| 11:11 | <Ms2ger> | odinho, "hey, let's test the initial values of some stuff" |
| 11:11 | <Ms2ger> | odinho, "let's check what Opera returns" |
| 11:11 | <Ms2ger> | (I assume) |
| 11:11 | <odinho> | Ms2ger: Ah, so you say you didn't write it. That makes it clearer :-) |
| 11:12 | <Ms2ger> | Yeah, my name in the URL is a lie |
| 14:12 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=18631 was filed on whatwg/html but is now moved to htmlwg/canvas. not that i understand the bug really and i'll be happy to not get emails for the spam he generates, but what's our story with bugs filed on the w3c specs? |
| 14:17 | <zcorpan> | i guess someone(tm) should keep an eye on the w3c bugs and clone the ones that are relevant |
| 14:19 | <zcorpan> | also, MikeSmith, can you ask that user to behave in bugzilla (not spam) |
| 14:33 | <Ms2ger> | zcorpan, fwiw, he also filed https://bugzilla.mozilla.org/show_bug.cgi?id=783942 |
| 14:33 | <zewt> | [Great Idea] |
| 14:34 | <zcorpan> | yeah, shows the same behavior |
| 14:38 | <zcorpan> | i'll just send him an email |
| 15:25 | <hober> | zcorpan: yeah, things shouldn't get moved from whatwg/html to an htmlwg component; they should be cloned. |
| 15:27 | <zcorpan> | hober: feel free to move it back and clone it (or say it should be cloned in a comment) |
| 15:28 | <zewt> | (cloning bugs is a pretty great way to fragment discussion and confuse everyone) |
| 15:30 | <jgraham> | Well yeah, but so is having two specs developing in parallel that are mostly the same but have subtle differences |
| 15:30 | <jgraham> | The only thing it's better than (in this case) is *not* doing that |
| 15:31 | <zewt> | doing two horrible things is generally considered worse than doing one horrible thing |
| 15:31 | <jgraham> | You have a proposal for how to organise the bugs so taht no cloning is needed but the specs aren't coupled in the way they were before? |
| 15:37 | <zewt> | you ask that as if cloning bugs is actually a "solution" |
| 17:17 | <TabAtkins> | zcorpan: Ah, you're right, I missed that. I'll add that in. |
| 17:27 | <smaug____> | abarth: ping |
| 17:27 | <abarth> | smaug____: hi |
| 17:27 | <smaug____> | abarth: just curious, how does webkit handle expandos on DOM nodes |
| 17:28 | <smaug____> | element.fooproperty = element; for example |
| 17:28 | smaug____ | is quite amazed that cycles are so hard for webkit |
| 17:29 | <abarth> | I'm not sure I understand your question |
| 17:29 | <abarth> | expandos are handled inside the javascript engine |
| 17:29 | <abarth> | and are not represented in C++ |
| 17:29 | <smaug____> | but C++ object doesn't keep the JS wrapper alive? |
| 17:30 | <abarth> | not directly |
| 17:31 | <abarth> | we use the C++ object graph to inform the JS engine about connections between the wrappers |
| 17:31 | <abarth> | the JS engine then decides whether those connections mean that the wrappers should be kept alive |
| 17:32 | <smaug____> | ah |
| 17:32 | <smaug____> | so there is mini cycle analyzer somewhere |
| 17:32 | <smaug____> | kind of |
| 17:33 | <smaug____> | cycle or connection analysis ... |
| 17:33 | <abarth> | https://docs.google.com/presentation/d/1OFG81taxgjOGU43sv9WHvPZkt5--KnM6gSijWN8NMcU/edit?disco=AAAAAECHbXY#slide=id.g16a516bb_1_53 |
| 17:33 | <abarth> | see slide 53 and onwards in that presentation |
| 17:33 | <abarth> | the JavaScript garbage collector can deal with cycles |
| 17:33 | <abarth> | because it uses mark-and-sweep |
| 17:33 | <abarth> | however, cycles cause leaks in the C++ heap |
| 17:33 | <abarth> | WebKit has a separate heap for C++ objects and for JavaScript objects |
| 17:34 | <smaug____> | sure, same with Gecko |
| 17:34 | <smaug____> | but Gecko just can deal with cycle in C++ too |
| 17:34 | <smaug____> | and C++->JS->C++ cycles |
| 17:35 | <smaug____> | and based on the comments, also Opera and IE can deal with C++->JS->C++ cycles easily |
| 17:35 | <smaug____> | so I'm rather reluctant to change APIs because of one engine |
| 17:35 | <abarth> | sadly, WebKit isn't that smart |
| 17:35 | <TabAtkins> | Yet. |
| 17:36 | <abarth> | well, then we won't be able to implement the API |
| 17:36 | <abarth> | its not possible to do without massive changes to the engine |
| 17:36 | <abarth> | or memory leaks |
| 17:36 | <smaug____> | TabAtkins: yeah, I assume webkit will have to be changed to handle cycles |
| 17:36 | <abarth> | that's not going to happen |
| 17:36 | <smaug____> | why not? |
| 17:36 | <TabAtkins> | Kentaro is investigating moving DOM to JS. |
| 17:37 | <abarth> | smaug____: are you volunteering to do the work? |
| 17:37 | <smaug____> | no :) |
| 17:37 | <abarth> | smaug____: because it's quite difficult |
| 17:37 | <smaug____> | I have enough fun with Gecko's cycle collector |
| 17:38 | <abarth> | TabAtkins: kentaro concluded that we shouldn't do it because it would be slower, at least based on current designs |
| 17:38 | <abarth> | smaug____: I don't intend to be a stick in the mud, it's just not something that's possible to implement in a feasible amount of time |
| 17:38 | <TabAtkins> | I don't believe Kentaro is set on that, and others in the thread are more optimistic about experimenting with this. |
| 17:39 | <abarth> | TabAtkins: well, blocking UndoManager on DOM-in-JS basically means UndoManager won't happen anytime soon |
| 17:39 | <TabAtkins> | Ah, I didn't know the context of this discussion. |
| 17:40 | <smaug____> | abarth: oh, sure, something like CC isn't a trivial task. Has taken ages to get performance to reasonable level in Gecko. |
| 17:43 | <smaug____> | but still, limiting Web APIs just because one engine hasn't been updated to have such a core memory management functionality would be odd |
| 17:44 | <abarth> | smaug____: You're welcome to have whatever opinion you like on that topic. The facts on the ground are that we cannot implement the API as specified. Therefore, if you'd like WebKit to implement the API, the specification needs to change. |
| 17:46 | <smaug____> | or someone needs to fix webkit to handle cycles and implement undomanager after that |
| 17:47 | <abarth> | smaug____: right, but the schedule for that is basically "not any time soon", so it's the same as not implementing it |
| 17:47 | smaug____ | doesn't agree :) |
| 17:48 | <abarth> | it's not a matter of opinion |
| 17:48 | <abarth> | what part don't you agree with? |
| 17:48 | <abarth> | you think someone is going to change WebKit's memory model sometime soon? |
| 17:48 | <smaug____> | "it's the same as not implementing it" |
| 17:48 | <smaug____> | you can implement UndoManager next year |
| 17:48 | <abarth> | it won't happen |
| 17:49 | <smaug____> | (there must be some huge pressure inside Google to get UndoManager to Chrome) |
| 17:50 | <abarth> | why do you say that? |
| 17:51 | <smaug____> | just wondering |
| 17:51 | <smaug____> | why you can't implement UndoManager later |
| 17:51 | <jamesr> | if you have to implement a cycle collector to implement UndoManager i can't imagine why we would ever do it |
| 17:51 | <smaug____> | and try to fix memory management first |
| 17:51 | <abarth> | smaug____: later => never |
| 17:51 | <jamesr> | if this is the only thing in the web platform that requires it, why would we do something so complicated and slow? |
| 17:51 | <abarth> | because it's unlikely we'll ever implement this new memory management model |
| 17:51 | <smaug____> | jamesr: I'm pretty sure there will be plenty of web APIs which will cause similar cycle issues |
| 17:52 | <abarth> | not that will be implemented in WebKit |
| 17:53 | <smaug____> | jamesr: cycle collector doesn't need to be slow |
| 17:53 | <jamesr> | but it is |
| 17:53 | <smaug____> | in normal cases it isn't |
| 17:53 | <smaug____> | when optimized |
| 17:54 | <abarth> | smaug____: please feel free to contribute a patch |
| 17:54 | <abarth> | smaug____: without code, I don't believe you |
| 17:54 | <abarth> | as far as I can tell, it requires at least one extra brach for every Node edge write |
| 17:54 | <abarth> | or at least, we haven't figured out a design that can avoid that branch |
| 17:55 | <abarth> | maybe one exists |
| 17:55 | <abarth> | now, it's possible we can get that speed back by removing an increment operation, but we've optimized out almost all of the increment operations |
| 17:57 | <othermaciej> | smaug____, abarth: I'm skeptical of multiple UndoManagers per document anyway |
| 17:58 | <smaug____> | Oh, that is different thing |
| 17:58 | <othermaciej> | the use case provided (vector graphics editor embedded in a rich text editor) doesn't work the way it's proposed in real apps |
| 17:58 | <smaug____> | we certainly need one UndoManager per input field |
| 17:58 | <othermaciej> | for example, Keynote lets you edit vector graphics and text in the same document |
| 17:58 | <othermaciej> | and it exposes a single undo list per window |
| 17:58 | <othermaciej> | in fact, it's the norm for all Mac apps to have a single undo list per window |
| 17:59 | <othermaciej> | even if the window holds a compound document, or multiple text fields |
| 17:59 | <othermaciej> | I don't know for sure about other platforms |
| 17:59 | <othermaciej> | but at least as proposed, the API would result in web apps violating the Mac HI guidelines |
| 17:59 | <zewt> | (mac UIs make me want to cut myself) |
| 17:59 | <smaug____> | :) |
| 18:00 | <othermaciej> | are there any platforms where native apps really do have separate modal undo lists? |
| 18:00 | <smaug____> | rniwa: you were testing this |
| 18:00 | <smaug____> | and yes, there are such apps |
| 18:01 | <othermaciej> | the use cases document that I looked at didn't seem to list real-world examples (but I may have overlooked it) |
| 18:01 | <othermaciej> | in any case, even if apps like that are the norm on Windows, you'd want to design the API so that you can have either modal undo lists or a single interleaved undo list depending on local platform conventions |
| 18:08 | <rniwa> | smaug____: testing what? |
| 18:09 | <smaug____> | native apps and undo handling |
| 18:10 | <rniwa> | othermaciej: even on Mac, each text field has its own undo maanger |
| 18:11 | <rniwa> | othermaciej: because each text field is implemented as a seprate view. |
| 18:11 | <rniwa> | othermaciej: i'm open to amend the spec if you have a concrete proposal. |
| 18:44 | <jgraham> | rniwa: What's the state of running testharness.js/W3C tests in webkit? |
| 18:44 | <rniwa> | jgraham: it runs :) |
| 18:45 | <rniwa> | jgraham: testharness.js has been imported to WebKit |
| 18:45 | <rniwa> | jgraham: and W3C reftests are supported to some extent. |
| 18:45 | <rniwa> | jgraham: we're still discussing the process by which we import tests |
| 18:45 | <rniwa> | jgraham: we've found that we have to make a bunch of imporvements to our testing infrastrucutre first |
| 18:45 | <rniwa> | jgraham: in order to import more tests. |
| 18:45 | <jgraham> | I see |
| 18:46 | <rniwa> | jgraham: you can see some tests for regions and undo manager written using testharness.js already |
| 18:46 | <rniwa> | jgraham: those can be upstreamed directly to W3C repository |
| 18:49 | <othermaciej> | rniwa: do you mean each text field has its own undo manager in reality, or in your proposal? |
| 18:49 | <rniwa> | othermaciej: yes. |
| 18:50 | <rniwa> | othermaciej: in realitiy on mac |
| 18:50 | <othermaciej> | rniwa: when I open a test document with two <input type=text>, I get a single unified undo list |
| 18:50 | <rniwa> | othermaciej: on native Mac apps |
| 18:50 | <rniwa> | othermaciej: not on WebKit |
| 18:52 | <rniwa> | othermaciej: if you have text fields on Mac app, undos in each text field aren't usually put int a single undo stack. |
| 18:53 | <othermaciej> | rniwa: ok, I can repro that sort of, but what I actually see is that changing focus from one text field to another (e.g. in Mail prefs) wipes the undo stack |
| 18:53 | <othermaciej> | rniwa: in other words, switching focus back doesn't get you the old undo list |
| 18:54 | <rniwa> | othermaciej: that's a good point. |
| 18:54 | <othermaciej> | I don't know of any app where you truly have multiple independent undo lists in one window |
| 18:55 | <othermaciej> | I think the text field behavior may not be fully intended, I think it is an artifact of the fact that the real editable text field only exists temporarily while you have focus, and gets recycled when you change focus |
| 18:55 | <othermaciej> | WebKit doesn't have that issue which is why actually we let you undo across multiple fields |
| 18:55 | <rniwa> | othermaciej: possibly. |
| 18:56 | <rniwa> | othermaciej: but we can't have one undo manager per page |
| 18:56 | <rniwa> | othermaciej: that'll lead to the said cross-origin problem |
| 18:56 | <rniwa> | othermaciej: so we need to have at least one undo manager per document. |
| 18:56 | <othermaciej> | you pointed me to a security bug that said it might be a problem, but it didn't identify an actual problem |
| 18:57 | <othermaciej> | that being said, one per document is much closer to reasonable UI, and much saner to implement |
| 18:57 | <othermaciej> | so it would still be a big improvement |
| 18:57 | <rniwa> | othermaciej: the problem is that you can trigger undo/redo on a cross-origin document |
| 18:58 | <rniwa> | othermaciej: given that we have seamless iframe |
| 18:58 | <rniwa> | othermaciej: it might be okay. |
| 18:58 | <othermaciej> | right, and that seems bad in theory, but I'm not totally sure what the real danger of that is |
| 18:58 | <rniwa> | othermaciej: restricting undo manager to be per-document will solve a whole bunch of problems we've had. |
| 18:59 | <othermaciej> | security problems? or implementation problems? |
| 18:59 | <rniwa> | othermaciej: what is? |
| 18:59 | <othermaciej> | "restricting undo manager to be per-document will solve a whole bunch of problems we've had" |
| 18:59 | <othermaciej> | what kind of problems? |
| 18:59 | <rniwa> | othermaciej: reference cycle problem |
| 18:59 | <rniwa> | othermaciej: having to "disconnect" undo manager when the node moves from one place to another in the same document |
| 19:00 | <rniwa> | othermaciej: or having to adopt an undo manager from one document to another |
| 19:00 | <rniwa> | othermaciej: undoscope also depends on contenteditable because it doesn't make any sense to have multiple undo managers in the same editable region |
| 19:00 | <othermaciej> | oh, you mean relative to per-node |
| 19:00 | <rniwa> | othermaciej: that also adds a lot of complications for us because content-editability is specified by CSS in WebKit |
| 19:00 | <othermaciej> | I thought you meant per-document relative to per-top-level |
| 19:00 | <rniwa> | othermaciej: yeah. |
| 19:01 | <rniwa> | othermaciej: I'm saying that per-document is much better implementation wise |
| 19:01 | <rniwa> | othermaciej: it'll solve all sorts of problems we face |
| 19:01 | <othermaciej> | yeah, it's simpler to implement, and probably better in terms of user experience |
| 19:01 | <rniwa> | othermaciej: potentially. |
| 19:11 | <rniwa> | othermaciej: could you reply to the public-webapps thread we have? |
| 19:11 | <rniwa> | othermaciej: i breifly talked with ojan about this |
| 19:12 | <rniwa> | othermaciej: and we both agreed that we can just get rid of undoscope attribute |
| 19:12 | <othermaciej> | yeah, I can |
| 19:12 | othermaciej | adds a TODO item |
| 19:12 | <rniwa> | othermaciej: it simplieis a lot of thigns, and it seems like an overall win. |
| 19:31 | <TabAtkins> | D'oh, I hate responding to a very long well-intentioned suggestion email with "You're wrong in every way. Sorry.". |
| 19:33 | <Hixie> | welcome to my life |
| 19:34 | <Hixie> | you start to get a large portfolio of ways to say "no" |
| 19:37 | <Hixie> | still no hsivonen about? is he on vacation or something? anyone know? |
| 19:41 | <jgraham> | Hixie: Pretty sure he is never here at this time even when he is about |
| 19:43 | <jgraham> | (the stats page confirms this) |
| 19:46 | <Hixie> | he's been idle for four days |
| 19:46 | <Hixie> | so i'm not sure regular hours apply :-) |
| 20:40 | <hober> | note to self: don't use *scratch* when generating editor boilerplate replies. |
| 20:42 | <jgraham> | You didn't manage to make the editor bilerplate valid elisp? |
| 20:42 | <jgraham> | +o |
| 21:31 | <Hixie> | TabAtkins: fallback leads to authors not noticing the problem which leads to more network traffic for lower quality results than the ideal result the author wanted |
| 21:31 | <TabAtkins> | Yeah, but lack of fallback means the user is punished by not having an image when a less-good substitute is available. |
| 21:32 | <TabAtkins> | (I'm for dropping the fallback, but the CSSWG wanted me to pursue requesting a change to HTML first.) |
| 21:32 | <TabAtkins> | These two positions appear to be the fundamental argument. |
| 21:32 | <TabAtkins> | It's what we settled into at the f2f. |
| 21:33 | <Hixie> | if the author sees the problem, they'll likely fix it, so the user will get the high quality image |
| 21:33 | <Hixie> | so no fallback seems net better for the user in the longer term |
| 21:33 | <TabAtkins> | Fallback = better user experience when there's a minor problem, No Fallback = less network traffic and better chance of noticing the problem. |
| 21:37 | <zewt> | are there script-visible effects from srcset that might change asynchronously if a fallback happens? (if so, that would be a significant complication) |
| 21:37 | <Hixie> | zewt: sure, the image dimensions would change |
| 21:37 | <Hixie> | technically btw the html spec allows fallback today, iirc |
| 21:38 | <zewt> | that would be very bad, I think (since it's one of those rare things that nobody would ever handle, even if we gave them a way) |
| 21:38 | <Hixie> | since you can arbitrarily decide to rerun the algorithm and arbitrarily pick anything from the list |
| 21:38 | <Hixie> | but that's just like technically the spec allows the UA to not show the image inline at all but to project it onto a second monitor with the colours reversed, or whatnot |
| 22:27 | <TabAtkins> | zcorpan: Added the rect() quirk to the doc as well. |
| 23:00 | <Hixie> | so svn blame tells me what revision a line was added in |
| 23:00 | <Hixie> | is there some way to find out when it was removed? |
| 23:00 | <Hixie> | a kind of reverse blame? |
| 23:16 | <TabAtkins> | Oh jeez, view this in WebKit: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1706 |
| 23:16 | <TabAtkins> | Uninitialized memory reads ahoy! |
| 23:30 | <hober> | TabAtkins: ooof. what's the bug #? |
| 23:31 | <TabAtkins> | esprehn is working on it already, I think. |
| 23:31 | <TabAtkins> | He showed me the problem a few minutes ago. |
| 23:43 | gavinc | boggles, "Anyone every heard of chrome consolidating ajax POST requests?" |
| 23:58 | <gavinc> | Click 10 times, 10 events fired, only 3 requests really made. Now THAT in unexpected. |