| 00:15 | <a-ja> | someone mess with mime types on tracker ? |
| 00:16 | <a-ja> | vendor icons appear to be borked |
| 01:05 | <zewt> | heh, are people still holding their breath expecting history api to make hash urls go away |
| 01:05 | <Hixie> | you mean pushState()? |
| 01:05 | <zewt> | because i've found it seriously convenient that I can say <a href=#profile> and have it hook into onpopstate without having to do anything else to the link |
| 01:06 | <Hixie> | pushState() won't be used to make fragids disappear except for cases where the server knows how to generate pages for each url (e.g. how g+ does) |
| 01:06 | <zewt> | yeah, but at least earlier on people were going "finally! now evil hash urls can die!" which just isn't going to happen |
| 01:07 | <zewt> | (not that you don't know this :) |
| 01:08 | <Hixie> | what's wrong with fragids when all the parts are defined in the page? |
| 01:08 | <zewt> | i say nothing's wrong with it, some people seemed on the religious side in claiming they should only ever be used for their original purpose (which I found a bit silly) |
| 01:09 | <mkanat_> | Well, it does make server-side analysis more difficult if you're looking at web logs. |
| 01:09 | <zewt> | i guess that'll always happen whenever something old is repurposed to do something new |
| 01:13 | <Hixie> | mkanat_: that's gonna happen regardless if you don't hit the server ;-) |
| 01:14 | <Hixie> | btw can anyone explain to me what all the fuss over app.net is? i can't work out what it does that's useful. |
| 01:14 | <mkanat_> | Hixie: Yeah, that's true. :-) |
| 01:14 | <zewt> | it's a three-letter domain, it's got to be useful! (no idea) |
| 01:21 | <zewt> | rather not nice that the spec allows ignoring pushState for non-user-actions |
| 01:21 | <zewt> | would break some of my own stuff if they actually did that |
| 01:25 | <Hixie> | the alternative is that pages could stuff the history with a thousand BS entries |
| 01:26 | <zewt> | not if implementations limit the number of history entries per document |
| 01:26 | <zewt> | it'd just cycle out old ones, without breaking things depending on the new one happening |
| 01:26 | <Hixie> | as a user i'd rather hate that |
| 01:27 | <zewt> | i have pages that eg. show a login prompt, on click send an XHR login request, and don't pushState until the login request succeeds |
| 01:27 | <zewt> | which could be outside the "user interaction" threshold, depending on the heuristic |
| 01:29 | <Hixie> | you should push on the login button click, so that if the user reloads while it's logging in, it still tries to login |
| 01:29 | <Hixie> | same as with a regular form load |
| 01:30 | <zewt> | the new state has nothing to do with login |
| 01:30 | <zewt> | (if I want to make that work I'd replaceState before the request to store the "sending a request" status, but I'd keep it in the same overall "showing the login page" state) |
| 01:33 | <zewt> | (doing it the other way just doesn't fit the rest of the stuff the site has built around history) |
| 01:41 | <Hixie> | sounds like a weird setup |
| 01:45 | <zewt> | seems natural to me :) |
| 01:45 | <Hixie> | hopefully authors don't abuse it and you'll not have to worry :-) |
| 01:48 | <zewt> | if browsers decide to be obnoxious i'll probably just sidestep it by using replaceState in the instances that do that; at least for login forms it's probably okay anyway (since going back to the login page when logged in will redirect elsewhere anyway) |
| 01:50 | <zewt> | but it's not great to have to worry about web apis that might some day lose interop and break sites |
| 01:51 | <Hixie> | yeah using pushstate and then replacestate later seems like the best option |
| 01:51 | <Hixie> | all apis have the risk of breaking |
| 01:51 | <Hixie> | all it takes is that the pressures to have some other behaviour be higher than the pressure to keep the current one |
| 01:51 | <Hixie> | e.g. a browser ships broken behaviour that a big site depends on |
| 01:51 | <zewt> | that's very far from the breakage being designed in from the outset :) |
| 01:52 | <Hixie> | use replaceState, it seems better to me in all ways :-) |
| 02:12 | <zewt> | event.state and history.state ever being different at the start of onpopstate is a bug, right? |
| 02:14 | <zewt> | damn, firefox gets confused if you replaceState from within onpopstate |
| 02:34 | <zewt> | heh, managed to make a decent guess of whether onpopstate is a forward or back ... but the code triggers history bugs in both webkit and ff |
| 02:38 | <Hixie> | oh i remember why we don't tell you if it's back or forward |
| 02:38 | <Hixie> | it can be both at the same time |
| 02:38 | <zewt> | another spec question--should clicking <a href=#a> repeatedly cause onpopstate each time, or only if it actually changes the hash? (webkit does, firefox doesn't) |
| 02:38 | <Hixie> | e.g. if you are in state 3 of 9, then the user jumps to the next page entirely in the history, and then goes back to state 6 of 9 in your app |
| 02:39 | <Hixie> | you just see a popstate for state 6 while in state 3 |
| 02:39 | <Hixie> | but the user went back |
| 02:39 | <Hixie> | dunno off-hand, you'd have to see the spec |
| 02:39 | <Hixie> | pretty sure that's unambiguously defined though |
| 02:40 | <zewt> | my particular use case only really cares about in-document navigation; i have some code that sticks a sequence in the history state and (browser bugs aside) seems to at least make a usable guess |
| 02:40 | <zewt> | afk, food |
| 03:11 | <zewt> | sigh, history bugs in opera too (onpopstate isn't fired at all on <a href=#foo>) |
| 03:11 | <zewt> | discouraging to hit three bugs in three browsers in one night |
| 03:19 | <zewt> | hmm, could be two bugs in webkit rather than one in firefox and one in webkit (looks like the onpopstate that happens on initial load should happen before scripts run, so it's not actually visible) |
| 06:24 | <jgraham> | zewt: Got testcases (not even real ones, just things I could turn into real testcases)? |
| 06:24 | <jgraham> | Not just for the Opera bug, also for the Gecko + WebKit bugs |
| 07:54 | <odinho> | Someone is constantly breaking the formal objection thread. It's really irritating, it's not like I really want to read that thread anyway, although I find it a bit interesting at times, but when it keeps breaking all over the place and take lots of space it irritates me. Hrmf |
| 07:55 | <odinho> | I think it is apple's mail client, because it's David Singer, Maciej Stachowiak who have broken it. And also John Foliot keeps doing it. |
| 07:56 | <odinho> | Hmm, Benjamin Hawkes-Lewis once as well. |
| 07:58 | <odinho> | Hmm, it's because the discussion is going over several lists. |
| 07:58 | <odinho> | Hmmm, my email client should get a better and less strict threading algo I guess. |
| 08:59 | <AryehGregor> | Ms2ger, jgraham, etc.: I think I'm going to make a post now to dev.platform requesting that Mozilla institute a new policy saying that for all bugs where behavior is covered by a standard, we make it mandatory that the test is written in testharness.js format and put in a special directory in m-c for tests to be submitted. |
| 08:59 | <AryehGregor> | Rather than with regular mochitests. |
| 08:59 | <Ms2ger> | Sounds good to me :) |
| 08:59 | <AryehGregor> | Then Ms2ger or I or someone can periodically look through all such tests and submit them to the right places. |
| 08:59 | <jgraham> | AryehGregor: If you get that through I will hero worship you |
| 08:59 | <jgraham> | At least for a short while |
| 09:00 | <AryehGregor> | I mean, I've fixed bugs regularly that were relevant to standards, but I would always just write the tests in our standard mochitest format, because that was just regular procedure. |
| 09:22 | <jgraham> | Right, we are relatively good at writing *testsuites* as testharness.js tests and relatively bad at writing one-off testcases as testharness.js tests (and worse at contributing them) |
| 09:22 | <jgraham> | So we have room to improve for sure |
| 09:23 | <jgraham> | Maybe I could grep the test repo for testharness.js tests that haven't been submitted or something |
| 09:31 | <AryehGregor> | jgraham, https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/AUJaVnuGFKI%5B1-25%5D |
| 09:36 | <jgraham> | AryehGregor: That sounds both pragmatic and hugely beneficial to the web to me. I hope that others agree :) |
| 09:39 | AryehGregor | restarts to install shiny new SSDs |
| 09:40 | <hsivonen> | are testharness.js tests as easy to write as mochitests these days? |
| 09:40 | <hsivonen> | can I do |
| 09:40 | <hsivonen> | start(); is(...); finish(); |
| 09:40 | <hsivonen> | do I need more boilerplate? |
| 09:41 | <Ms2ger> | You don't need start() and finish(), just test(function() { // asserts }); |
| 09:41 | <jgraham> | The minimal test is something like test(function() {assert_true(true)}) |
| 09:41 | <hsivonen> | ok. so still harder to grok :-( |
| 09:43 | <hsivonen> | what if asserts need to be spead over a bunch of event queue tasks? |
| 09:43 | <jgraham> | Well all I can say is that the API complaints have all come from people that haven't used it |
| 09:43 | <jgraham> | Which doesn't mean it's perfect of course |
| 09:44 | <hsivonen> | I've tried it twice |
| 09:44 | <jgraham> | But you may be making a bigger deal of this than it actually warrants |
| 09:44 | <hsivonen> | ok |
| 09:45 | <jgraham> | For tests that are async you do var t = async_test(); t.step(function(){}); t.done() |
| 09:45 | <Ms2ger> | Well, async tests are somewhat harder, that's true |
| 09:47 | <jgraham> | Personally I usually find it takes much longer to work out what the right behaviour to test is than it does to type the boilerplate |
| 09:47 | <Ms2ger> | You're used to the boilerplate :) |
| 09:48 | <jgraham> | But yes, I agree that this is one area in which compromises were made in the design |
| 09:48 | <Ms2ger> | I don't think it's terribly hard, but it takes some getting used to |
| 09:49 | <Ms2ger> | And because mochitests have always used window.onerror, wrapping everything in functions looks somewhat foreign |
| 09:51 | <jgraham> | Make the JS people add macros, then you have have a shorter syntax and the same properties ;) |
| 09:51 | <Ms2ger> | Heh |
| 09:51 | <odinho> | if I write tsf<tab> it becomes t.step_func(function(e) {<cursor>}); and ts<tab> becomes t.step(function() {<cursor>}); |
| 09:51 | <jgraham> | odinho: That's pretty cool |
| 09:52 | <Ms2ger> | What do you use? |
| 09:52 | <odinho> | vim |
| 09:52 | <Ms2ger> | Ugh :) |
| 09:53 | <odinho> | Ms2ger: It's possible in almost all editors :P |
| 09:56 | <jgraham> | odinho: Dammit now you nerd-sniped me into working out how to do it in yasnippet mode in emacs :) |
| 09:56 | <odinho> | jgraham: lol. nerd-sniping :D |
| 09:57 | <odinho> | I was actually thinking of changing/add another one for this.step_func(function(e) {}) I've found that I sometimes like to write tests like that, not having any variables pointing to the async test. |
| 09:59 | <odinho> | Then I just do. async_test(document.title + " - doThis").step(function() { doThis().onsuccess = this.step_func(function() { assert_true(bla); }); }) |
| 12:04 | <odinho> | I like your email AryehGregor :] |
| 12:05 | <AryehGregor> | odinho, which, to public-html? |
| 12:05 | <odinho> | AryehGregor: Yea, meant that, although the test-one to Mozilla as well though ;-) |
| 12:05 | <odinho> | s/ though// |
| 12:06 | <Ms2ger> | You read public-html? |
| 12:06 | <odinho> | Oh shi-, my dirty secret revealed! |
| 12:07 | <odinho> | What will people think of me now? :-S |
| 12:09 | <AryehGregor> | I don't, generally, but I saw the subject line about moving to REC and thought it was significant enough to look at. |
| 12:10 | <Ms2ger> | I would have the exact opposite reaction :) |
| 12:11 | <jgraham> | AryehGregor: +1 both to your message and to your public-html policy :) |
| 12:11 | <jgraham> | Although I think that bz has a point that Microsoft will stop contributing tests |
| 12:11 | <Ms2ger> | Then again, have you looked at their tests? |
| 12:11 | <AryehGregor> | Doubtful. They contribute tests mostly so they look good, don't they? |
| 12:12 | <AryehGregor> | Also, yeah. |
| 12:12 | <Ms2ger> | The quality of their tests is at the same level as the quality of their spec feedback |
| 12:12 | <odinho> | Oh, I haven't said this here yet. |
| 12:12 | <odinho> | I rewrote the MS idb testsuite, and now IE is at 40% pass(!) (from being at 100%). |
| 12:12 | <odinho> | lol |
| 12:13 | <Ms2ger> | Heh |
| 12:13 | <jgraham> | Yeah, but there is some value in them submitting a testsuite for you to start from |
| 12:13 | <jgraham> | Even if it needed work |
| 12:13 | <odinho> | Yes, it was great. |
| 12:14 | <odinho> | I'm not good at getting a super big assignment and start working. I'm just sitting there being overwhelmed and unable to start :P |
| 12:14 | <odinho> | Now I could just go through their list of tests with assertions, and make sure it followed spec. |
| 12:16 | <zcorpan> | odinho: just pretend that you have an invisible list of tests with assertions, then make sure it follows spec, but then make the tests and assertions as you go :-) |
| 12:17 | <Ms2ger> | What do you guys think of an assert_class_name() that checks {}.toString.call(object) === "[object Class]"? |
| 12:17 | <odinho> | zcorpan: You so have to give me a master class |
| 12:18 | <jgraham> | Ms2ger: For Chekcing [[Class]] |
| 12:18 | <Ms2ger> | Also, did someone move DSK-372132 already? |
| 12:18 | <jgraham> | *checking |
| 12:18 | <jgraham> | I suppose it's not a bad idea, but I wouldn't call it class_name |
| 12:18 | <odinho> | Ms2ger: I have a few assert_equals(""+object, "[object Class]", "object is Class") that could be replaced, -- but is there more to it? And is it very common? |
| 12:18 | <Ms2ger> | Well, WebIDL calls it a "class string" now |
| 12:19 | <jgraham> | Seems like it could be part of idlharness.js? |
| 12:19 | <Ms2ger> | idlharness has a lot of those, but I think I've wanted to use it in another test too |
| 12:19 | <Ms2ger> | odinho, that doesn't work if there's a stringifier somewhere, btw |
| 12:19 | <jgraham> | assert_class_string soulds fine to me |
| 12:21 | <zcorpan> | Ms2ger: here's a secret: navigating to https://bugs.opera.com/browse/DSK-372132 will redirect to the new bug if it has been moved even if you're not logged in |
| 12:22 | <Ms2ger> | Ah, yes, I seem to remember someone mentioned that |
| 12:22 | <zcorpan> | (i think matjas noticed that one) |
| 12:23 | <odinho> | Hmm. It's an API still though, so I don't think we should add stuff to it too lightly. It has to be maintained, it's extra documentation, making the whole thing more complex. It has to have some real benefits. :-) |
| 12:24 | <odinho> | Ms2ger: So, yes, it's been moved to core. And I can tell you relevant people is on CC list. |
| 12:24 | <Ms2ger> | Thanks :) |
| 12:26 | <Ms2ger> | Oh hey, Baidu's submitted a few tests |
| 12:27 | <jgraham> | odinho: Not really :p |
| 12:27 | <odinho> | jgraham: Not relevant people? :P I should put you there. |
| 12:28 | <jgraham> | odinho: Well you have someone from GFX and a random docxs QA. CCing yourself would have improved things :p |
| 12:28 | <odinho> | Well, GFX dev does lots of docxs stuff :P |
| 12:29 | <Ms2ger> | docxs? Is that something to do with Microsoft Word's XML format? |
| 12:30 | <odinho> | Ms2ger: Document parsing, HTML, XML, Javascript, DOM blabla. We have t-shirts! :D |
| 12:30 | <zcorpan> | yes. Presto is built on top of Word. |
| 12:30 | <odinho> | zcorpan: Shhhh! NDA'd info!111 |
| 12:30 | <zcorpan> | oops. strike the above. |
| 12:39 | <jgraham> | Quick! Out with the official cover up! |
| 12:39 | <jgraham> | It stands for "Documents XML and Scripting" |
| 12:39 | <jgraham> | But with one extra comma |
| 12:45 | <AryehGregor> | Ms2ger, why does Mozilla only run Mozilla/Opera tests from the HTML test suite, instead of everything? |
| 12:46 | <AryehGregor> | (at least, all submitted/approved) |
| 12:46 | <AryehGregor> | Oh, not even all Opera tests. |
| 12:48 | <AryehGregor> | Actually, why don't we run all webapps tests why we're at it? |
| 12:48 | <AryehGregor> | Even if the tests are broken, nothing wrong with checking if we regress on broken tests. |
| 12:48 | <AryehGregor> | (and yes, this was meant to be in #whatwg, not #developers) |
| 12:50 | <odinho> | ^_^ I agree. I've imported all of webapps/ and webappsec/ tests to Opera's system at least. |
| 12:50 | <zcorpan> | but we don't have html/ right? |
| 12:50 | <AryehGregor> | Some of html/ is useful. |
| 12:50 | <jgraham> | We have bits and pieces of /html/ |
| 12:50 | <AryehGregor> | My base64 tests, if nothing else. |
| 12:51 | <jgraham> | But really we need one more piece of infrastructure so that we can mimic the w3c-test.org server |
| 12:51 | <jgraham> | Rather than having a whole general mish mash of tests, like today |
| 12:52 | <jgraham> | (the WGMM appraoch will also require local patches to some tests, which is the main reason it's bad) |
| 12:52 | <AryehGregor> | I'm not sure we actually support the w3c-test.org server. |
| 12:52 | <jgraham> | We obviosuly don't load tests off that server |
| 12:53 | <jgraham> | But we want our local server to look like that server in terms of paths, subdomains, etc. |
| 12:59 | <AryehGregor> | Can you still run the tests on some random localhost that way? |
| 13:01 | <zcorpan> | we generally don't run tests on random localhosts |
| 13:02 | <jgraham> | Unlike Mozilla we have a central server taht is used to store tests |
| 13:02 | <jgraham> | I'm not sure this is the best possible setup, but it would be a huge undertaking to redesign it |
| 13:06 | <jgraham> | Of course being able to run tests on localhost is a big win |
| 13:06 | <jgraham> | But I generally just set up my localhost to be like the main server |
| 13:10 | <odinho> | pacman -S nginx; cd /var/www/htdocs; git clone the-tests; opera http://localhost/ |
| 13:10 | <odinho> | Not that hard ;-) |
| 13:12 | <jgraham> | odinho: As long as you don't depend on the specific subdomains or server config |
| 13:13 | <odinho> | Well then any random localhost wouldn't work anyway. I guess. |
| 13:13 | <jgraham> | I think the Mozilla setup involves a custom web server |
| 13:14 | <jgraham> | So I assume AryehGregor isn't comparing to "a random localhost" |
| 13:14 | <AryehGregor> | jgraham, in general, anyone with a checkout of Mozilla source code is supposed to be able to run tests. |
| 13:15 | <AryehGregor> | I believe a copy of lighttpd is set up on localhost, and various magic protocols and such are enabled. |
| 13:15 | <AryehGregor> | So perhaps we could fake w3c-test.org if we wanted. |
| 13:15 | <AryehGregor> | Although AFAIK, so far we don't. |
| 13:42 | <darobin> | jgraham, AryehGregor: if you could put together your requirements for just cloning w3c-test.org locally and send them to public-test-infra it would be sweet |
| 13:43 | <darobin> | I'm sure there's something that we can do there |
| 13:43 | <AryehGregor> | darobin, what requirements? |
| 13:43 | <AryehGregor> | And whose? |
| 13:43 | <darobin> | AryehGregor: reading the logs I got the impression that you wanted to run all the w3c-test.org tests in one bundle, pulled locally |
| 13:43 | <darobin> | maybe I read too fast :) |
| 13:44 | <AryehGregor> | Nope, not particularly. |
| 13:44 | <darobin> | ok, well that's even easier to make happen :) |
| 13:45 | <AryehGregor> | jgraham, why is the name argument to test() optional? It encourages people to omit it, probably because they don't know it exists. |
| 13:46 | <jgraham> | AryehGregor: Because it uses the document title if there is no argument |
| 13:46 | <odinho> | For cases where you have one test. |
| 13:47 | <AryehGregor> | jgraham, yes, which is almost never what you want. |
| 13:47 | <gsnedders> | Bloody hell, Oracle makes useless software. |
| 13:47 | <AryehGregor> | Okay, if there's only one test. |
| 13:47 | <AryehGregor> | Granted. |
| 13:47 | <jgraham> | AryehGregor: It is often what I want :) |
| 13:47 | <AryehGregor> | But it should fail if you try to do it with more than one test. |
| 13:47 | <AryehGregor> | Really? |
| 13:47 | <AryehGregor> | You want them to just be named sequentially? |
| 13:47 | <gsnedders> | (Trying to enroll for universities courses. Failing.) |
| 13:47 | <jgraham> | Well I am often writing things with one test per file |
| 13:47 | <jgraham> | At the moment |
| 13:48 | <darobin> | failing would kill a number of existing suites — warning might be better, at least temporarily |
| 13:48 | <AryehGregor> | jgraham, that's fine, but not if there's more than one test in the file. |
| 13:50 | <jgraham> | AryehGregor: It isn't *that* bad (tests get unique numbers) |
| 13:50 | <AryehGregor> | jgraham, it's incomprehensible to human readers. |
| 13:50 | <jgraham> | But I guess I wouldn't oppose warning for this |
| 13:51 | <Ms2ger> | AryehGregor, because it takes some effort to pull them in and add the expectation JSONs |
| 13:51 | <Ms2ger> | Especially before I had this script to do it for me |
| 13:51 | <AryehGregor> | Ms2ger, okay, makes sense. |
| 13:51 | <Ms2ger> | And I think I already landed the patch that makes w3c-test.org to localhost on the mochitest server |
| 13:52 | <Ms2ger> | Also, not lighttpd but something based on xpcshell, I think |
| 13:53 | <AryehGregor> | Baidu's tests are actually valid, interestingly, albeit very simple. |
| 13:53 | <AryehGregor> | They catch some WebKit bugs. |
| 13:54 | <AryehGregor> | Oh, of course. |
| 13:54 | <AryehGregor> | WebKit will fail all these isContentEditable checks because it implements editability as a CSS property, and the element is detached, so it doesn't compute style. |
| 13:54 | <AryehGregor> | Hah. |
| 13:55 | <odinho> | AryehGregor: There is already a warning in the default w3c-test report. |
| 14:00 | <darobin> | AryehGregor: irrespective of how it's implemented, should a detached element actually be editable anyway? |
| 14:02 | <Stevef_> | gsnedders: Opera makes useless software (for AT users) ;-) |
| 14:02 | <Ms2ger> | Objection! |
| 14:02 | <Ms2ger> | It's useless to me too :) |
| 14:03 | <Stevef_> | Ms2ger: did you mean FORMAL OBJECTION/ |
| 14:03 | <Stevef_> | ? |
| 14:04 | <Ms2ger> | I don't do those... |
| 14:04 | <Ms2ger> | Often |
| 14:05 | <odinho> | I lol'd. |
| 14:05 | Ms2ger | eats cake instead |
| 14:05 | <odinho> | Hm, me as well. Screw you guys, I'm going to a party (only problem, it just started raining :/ ). |
| 14:09 | <darobin> | Ms2ger: is this the manifest to use for the HTML5 tests? http://w3c-test.org/html/tests/approved/html5_approvedtests.txt |
| 14:09 | darobin | is trying to fix the problem with running those tests you noticed a week or two back |
| 14:11 | <Ms2ger> | Dunno |
| 14:11 | <darobin> | in either case the DB currently has 188 tests which matches none of those manifests — I reckon it's a classic case of the import being out of date with the repo |
| 14:11 | darobin | wishes this architecture were less broken... |
| 14:12 | Ms2ger | would suggest loading the manifest straight out of the repo |
| 14:12 | <darobin> | I think there should be no manifest |
| 14:12 | <darobin> | the TF should spider the repos and just grab anything that has test metadata |
| 14:14 | <darobin> | Ms2ger: yeah, reimporting fixes the 500 — BROKENARCH WONTFIX |
| 14:14 | <Ms2ger> | Heh, test metadata |
| 14:15 | <darobin> | I don't care if it's just something that says "I'm a test" — that's all I'd need :) |
| 14:16 | <darobin> | but anyway, since that works I can move on to break something else |
| 14:23 | <AryehGregor> | darobin, editing commands shouldn't do anything to it, no, because it shouldn't have a selection in it. Per current spec, though, isContentEditable should still return true. |
| 14:23 | <AryehGregor> | darobin, what's "test metadata"? |
| 14:23 | <AryehGregor> | How do you exclude support files? |
| 14:24 | <AryehGregor> | We should have a script that refuses pushes if there's a file that's not found in a manifest, or something like that. |
| 14:24 | <darobin> | AryehGregor: there's a bunch of stuff you can put in a test file that says things like who is to blame for this stupid test, what section of the spec it maps to, which assertion it's testing, etc. |
| 14:25 | <AryehGregor> | Okay. |
| 14:25 | <AryehGregor> | Do all test files have such metadata? |
| 14:25 | <darobin> | muahahaha |
| 14:25 | <darobin> | well |
| 14:25 | <darobin> | in the CSS WG they tend to have decent metadata |
| 14:25 | <AryehGregor> | Also, what about if you have stupid things lying around in the checkout like vim swap files or something? |
| 14:25 | <darobin> | elsewhere it's much more random |
| 14:26 | <darobin> | you grab whoever checked in their swap file and slam their heads repeatedly against hardened ox dung until they stop doing it |
| 14:27 | <darobin> | there's a reason I have a travel budgetr |
| 14:28 | <darobin> | we could indeed do something with commit hooks that check manifests, but you'd still have to detect which files are test files and which aren't |
| 14:28 | <darobin> | which is doable with a few simple conventions though |
| 14:29 | <darobin> | it would be a little bit hairy to handle repos that have multiple manifests, e.g. the HTML tests |
| 14:30 | <jgraham> | How would you even defer session history to HTML.next? That doesn't make any sense… |
| 14:33 | <jgraham> | Also there is no good way to do test metadata. In band, out of band, it all sucks |
| 14:39 | <darobin> | jgraham: yeah, but it's pretty useful all the same |
| 14:41 | <darobin> | unlike, say, my good friend the Opera Mobile Emulator |
| 14:41 | <Ms2ger> | darobin, metadata in html files is feasible, but I'm not sure how you want it to look in JS |
| 14:42 | <darobin> | Ms2ger: Peter added support for individual testharness tests to carry their own metadata beyond name |
| 14:42 | <darobin> | though I'm not sure how much sense that makes to me, yet |
| 14:43 | <darobin> | beyond that, you can have magic comments, a sidecar file, whatever |
| 14:43 | <Ms2ger> | Yeah, Peter wants to duplicate all the metadata, though :( |
| 14:43 | <darobin> | none of it is nice — but short of putting it in another layer (e.g. a Web UI that just looks at the files and that you can annotate) I'm not sure what would work best |
| 14:43 | <darobin> | well, yeah, don't get me started on that... |
| 14:44 | <darobin> | I'm not sure that starting off the CSS WG's input was the best move here |
| 14:44 | <Ms2ger> | I'm not sure what the use case is for per-test() metadata is, fwiw |
| 14:44 | <jgraham> | FWIW just having a way to say "this file is a test" is all we need |
| 14:44 | <darobin> | I'd like to know which tests are automated and which aren't |
| 14:44 | <jgraham> | Sure and the test type |
| 14:45 | <jgraham> | But actually I want "this URL is a test" |
| 14:45 | <darobin> | so that you can tell someone "go to this URI and run all the automated tests we have, it'll cost you no time" |
| 14:45 | <darobin> | yes! |
| 14:45 | <darobin> | FFS |
| 14:45 | <jgraham> | Because files aren't tests |
| 14:45 | <Ms2ger> | *It'll only cost you a lot of CPU time |
| 14:45 | <darobin> | last time I brought that up Peter wrote the idea off immediately |
| 14:45 | <darobin> | in the current system, the file name uniquely identifies a test across all the suites |
| 14:45 | <darobin> | *yay* |
| 14:46 | <Ms2ger> | Yeah, that sucks |
| 14:46 | <darobin> | if I had more than two weeks left on this project, I'd rewrite it from the ground up |
| 14:47 | <jgraham> | Oh if it assumes that, it's doomed |
| 14:47 | <jgraham> | We have a system that tries to make believe that files are testcases |
| 14:48 | <jgraham> | It is very bad |
| 14:49 | <Ms2ger> | The csswg install of the framework likes to tell me I've got unreviewed tests |
| 14:49 | <Ms2ger> | ... the index.html |
| 14:50 | <darobin> | hahaha |
| 14:56 | Ms2ger | wishes howcome would stop indenting his >'s |
| 15:16 | <SimonSapin> | 1in is 96px in CSS, but 90px in SVG: http://www.w3.org/TR/SVG/coords.html#Units … but browsers use 96 anyway. (But not non-brower SVG engines.) |
| 15:35 | <Ms2ger> | "For example, suppose that the user agent can determine from its environment that "1px" corresponds to "0.2822222mm" (i.e., 90dpi)." |
| 15:36 | <Ms2ger> | That doesn't seem to require using 90dpi |
| 15:39 | <dglazkov> | good morning, Whatwg! |
| 15:39 | <Ms2ger> | Good day |
| 15:43 | <smaug____> | dglazkov: what on earth are "Web Components standard spec meetings"? |
| 15:44 | smaug____ | thinks he hasn't got all the information |
| 15:44 | <smaug____> | nor most of the Mozillians in WebApps wg |
| 15:44 | <dglazkov> | I am excited to learn that there are now meetings! Are you guys meeting? |
| 15:45 | <dglazkov> | what's the context, btw? |
| 15:45 | jgraham | doesn't even know what smaug____ is talking about so is the most out of the loop :( |
| 15:45 | <smaug____> | dglazkov: https://bugzilla.mozilla.org/show_bug.cgi?id=783129#c9 |
| 15:45 | <dglazkov> | ah. let me read |
| 15:46 | <jgraham> | OTOH that means I am the winner! |
| 15:48 | <smaug____> | dglazkov: is dbuc not talking about some web apps wg conf calls? nor Google+Mozilla meetings? |
| 15:48 | <smaug____> | but something else |
| 15:48 | <dglazkov> | ah yes. I met with Daniel a bunch of times now. Also with Blake, and before that with Neil and Jonas. I wouldn't qualify them as "standard spec meetings", rather discussions around Web Components. |
| 15:49 | <dglazkov> | You guys are too mean to Daniel. I think he's being defensive. |
| 15:49 | <jgraham> | Now I *know* I am the most out of the loop :p |
| 15:49 | <Ms2ger> | Anyway, Hixie is speccing it all now, so we're good |
| 15:51 | <smaug____> | dglazkov: well, seems like he doesn't quite know how standardization works |
| 15:52 | <smaug____> | dglazkov: also, I don't want to use Mozilla's bugzilla to fix spec issues |
| 15:52 | <smaug____> | W3C has a bugzilla for that |
| 15:52 | <dglazkov> | smaug____: yes and yes. |
| 15:52 | <dglazkov> | smaug____: let me respond in bug and take discussion over to w3c bugzilla |
| 15:53 | <smaug____> | dglazkov: anyhow, I hope you can pick up my comments and fix those issues in the spec :) |
| 15:55 | <dglazkov> | smaug____: yes sir! |
| 15:55 | dglazkov | saluts |
| 15:55 | <dglazkov> | smaug____: heeey, I was wonderin' |
| 15:55 | <dglazkov> | smaug____: got some spare cycles to work on that stuff? :) |
| 15:56 | <smaug____> | dglazkov: btw, I was wondering if using "prototype" in the dictionary might cause some problems |
| 15:56 | <smaug____> | dglazkov: I actually might have some time for this |
| 15:56 | <dglazkov> | yaaaay |
| 15:57 | <smaug____> | dglazkov: I'm going to be in MV next week... and will figure out there what all I'll do in the near future |
| 15:57 | <dglazkov> | smaug____: let's meet! I'll buy you lunch. |
| 15:57 | <dglazkov> | well, technically, it'll just be free food at Google :P |
| 15:57 | <smaug____> | :p |
| 16:02 | <dglazkov> | jgraham: are you also interested in Web Components or did I catch the tail of another thread? |
| 16:02 | <jgraham> | dglazkov: Interested, yes |
| 16:03 | <jgraham> | Although I don't have as much time to work on it as I would like |
| 16:03 | <jgraham> | And the Googleplex is so far away |
| 16:03 | <dglazkov> | well, there's the VC of various sorts. |
| 16:03 | <dglazkov> | and I don't mean venture capitalist here. |
| 16:04 | <jgraham> | Dammit, I thought you were going to offer me a few million $ to build a social media website for web components |
| 16:05 | <gsnedders> | jgraham: What? Opera hasn't got a teleportation device yet? |
| 16:05 | <gsnedders> | jgraham: Or has Opera done it first and simply you don't have the recieving end at Google? |
| 16:05 | <dglazkov> | jgraham: Instagraham |
| 16:06 | <smaug____> | gsnedders: must be the latter. |
| 16:06 | smaug____ | needs to try Opera's teleportation feature |
| 16:06 | <gsnedders> | This was the real reason for Opera Unite's name. Tying everyone together by bringing them together. |
| 16:07 | <jgraham> | First the word thing and now this. It's leak-city on #whatwg today |
| 16:18 | <dglazkov> | I am kind of worried that the discussions on bugzilla are getting no visibility for the rest of WG, but I would hate to spam public-webapps@ with all of them. |
| 16:20 | <dglazkov> | should we have another mailing list? I try to summarize activity with my progress update mails, but these are kind of post-factum. |
| 16:22 | <jgraham> | I don't mind having a web components mailing list |
| 16:22 | <jgraham> | Or having everything on webapps |
| 16:22 | <jgraham> | Having it all in bugzilla substantially reduces visibility though |
| 16:26 | <smaug____> | dglazkov: .createElement isn't supported but innerHTML is ? |
| 16:26 | <smaug____> | that is odd |
| 16:28 | <dglazkov> | smaug____: yeah, it is. It's very easy to support with custom tags, but right now, the spec is using the "is" attribute syntax, and there's no easy way to accomplish this. |
| 16:29 | <smaug____> | hmm, spec is talking about x- |
| 16:30 | <dglazkov> | smaug____: yes, but it's still the attribute value. |
| 16:30 | <smaug____> | hmm, right |
| 16:30 | <smaug____> | then .register is somewhat odd |
| 16:35 | <darobin> | dglazkov: yes, please, I don't care if it's all on webapps or a separate list but it would be better than bugzilla! |
| 16:36 | <smaug____> | dglazkov: www-dom is low traffic mailing list |
| 16:36 | <dglazkov> | darobin, jgraham: sent mail |
| 16:36 | <darobin> | dglazkov: rockin' |
| 16:37 | <jgraham> | dglazkov: Great, thanks\ |
| 16:41 | <dglazkov> | smaug____: yes, the machinery would look less odd if we used custom tags. I am also thinking of this machinery as a step toward just implementing all HTML elements as custom DOM elements. With that in mind, "is" attribute is less appealing. |
| 16:42 | <smaug____> | implementing all HTML elements as custom DOM elements? |
| 16:42 | <smaug____> | I doubt that will happen |
| 16:42 | <smaug____> | there are security issues |
| 16:42 | <smaug____> | of course internally browsers can do it |
| 16:42 | <smaug____> | but web pages... no |
| 16:42 | <jgraham> | Has firefox got a keyboard shortcut for the error console? Unity seems to have decided that I'm not allowed to see the ment |
| 16:42 | <jgraham> | *menu |
| 16:42 | <dglazkov> | smaug____: well, right. this is a UA implementation detail |
| 16:43 | <smaug____> | ctrl+shift+j is error console |
| 16:43 | <smaug____> | dglazkov: long ago bryner started to implement all form controls using XBL |
| 16:43 | <dglazkov> | bryner... I haven't heard that name in a long time |
| 16:44 | <smaug____> | (he never finalized that ) |
| 16:44 | smaug____ | has no idea what bryner does nowadays... thought he was still @Google but maybe not |
| 16:47 | <smaug____> | Gecko has also support for XTF, so that privileged JS can implement new elements. It has been only for new namespaces, and it was used mainly in the XForms project |
| 16:47 | <smaug____> | hmm, is there something in XTF that should be brought to web components... |
| 16:52 | <smaug____> | dglazkov: FYI, http://mxr.mozilla.org/mozilla-central/source/content/xtf/public/nsIXTFElement.idl?force=1 |
| 16:52 | <smaug____> | I guess we don't need most of that any time soon |
| 16:52 | <smaug____> | except default handling for events |
| 17:02 | <Ms2ger> | Ugh, XTF |
| 17:02 | <smaug____> | nothing wrong with XTF |
| 17:03 | <smaug____> | it is just a very low level way for addons to implement new elements in JS or C++ |
| 17:03 | <Ms2ger> | You like perl, I'm not sure I trust your judgment :) |
| 17:58 | <dglazkov> | XTF is dangerously close to WTF, but I am happy to take a look. |
| 17:58 | <dglazkov> | oh, would mrbkap know a lot about this? |
| 18:23 | <smaug____> | dglazkov: about XTF? no |
| 18:24 | <smaug____> | dglazkov: note, I'm not suggesting to have anything like XTF, but the API may give hints what features are possibly needed |
| 19:17 | <Yuhong> | A 90 day trial of Win8 RTM is available here: http://msdn.microsoft.com/en-us/evalcenter/jj554510.aspx |
| 19:44 | <jgraham> | Someone should tell dbaron that over-picky review hasn't been a problem in the HTML WG |
| 19:45 | <jgraham> | Getting review on the other hand... |
| 19:45 | <Yuhong> | IMO it would have helped a lot if DOM access could be restricted between some document.write calls. |
| 19:46 | <Ms2ger> | IMO it would have helped if we never had document.write at all |
| 19:46 | <Yuhong> | such as document.write("&"); document.write("amp;") |
| 19:47 | <Yuhong> | But the DOM was invented after document.write and I don't think it would have been feasible. |
| 19:47 | <Yuhong> | I would have suggested this as a compromise. |
| 19:48 | <Ms2ger> | Rather unfortunate that you didn't |
| 19:48 | <jgraham> | Wait, what? |
| 19:49 | <Yuhong> | Of course, it is too late to do it now. |
| 19:49 | <jgraham> | You want the behaviour of DOM methods to depend on the current character in the input stream? |
| 19:49 | <jgraham> | And you think that would make things better? |
| 19:50 | <Yuhong> | The idea is to not allow access to the inconsistent DOM during certain parser states. |
| 19:50 | <Yuhong> | Of course, by the time WHATWG was created, it was far too late to do this. |
| 19:51 | <jgraham> | Out of all the problems I have had with document write -- and really I have spent months of my life on document.write problems -- that has never been one |
| 19:54 | <dfltr> | Sort of a random question: http://www.whatwg.org/specs/web-apps/current-work/multipage/selectors.html#selector-enabled states that inputs with type="hidden" should be omitted from :enabled, but currently no browsers support this in their qSA implementations. Is this an in-progress feature or a known issue? |
| 19:54 | <Yuhong> | Of course, the big problem is back in 1997, security was not as important. |
| 19:55 | <Yuhong> | And HTML parsing was not well-defined. |
| 21:49 | <tantek> | oh hey dlftr - funny seeing you here :) |
| 21:49 | <tantek> | do you have an example page illustrating what you mean re: input type="hidden" and :enabled? |
| 21:53 | <dfltr> | Oh hey, it's a tantek! One sec, my example is in the Prototype.js test suite. I'll whip up a public test for it. |
| 21:58 | <dfltr> | Test here: http://jsfiddle.net/duHdp/ |
| 21:59 | <dfltr> | Expected result is that it will log both the enabled text field and the hidden input to the browser's console. |