| 00:00 | <Domenic_> | +1, we have wanted this background-blurring ourselves |
| 00:00 | <Domenic_> | I might try breaking out the old ::before, putting the background in there, and blurring the ::before? |
| 00:01 | <Domenic_> | Bet it doesn't work though, everyone forgets poor pseudo-elements when implementing cool features like filters. |
| 01:23 | <zewt> | Domenic_: not really fair to expect that, heh (and if there was a way to do it, ::before doesn't seem right anyway) |
| 01:27 | <cabanier> | Hixie_: pong |
| 01:30 | <cabanier> | Domenic_: why would a filter not work on a pseudo? |
| 02:11 | <MikeSmith> | I'm running IE10 in virtualbox on my Mac. Anybody know if there's a way I can copy the generated DOM from IE to the clipboard? |
| 02:12 | <MikeSmith> | like "Copy InnerHTML" in Firefox devtools or "Copy HTML" in Chrome devtools |
| 02:12 | <MikeSmith> | I can't even figure out how to to do "View source".. |
| 02:23 | <cabanier> | MikeSmith: hit F12, select the node and say copy innterHTML |
| 02:24 | <cabanier> | MikeSmith: "view source" is right-click |
| 02:27 | <MikeSmith> | cabanier: thanks but for some reason I can't even get a context menu with right-click -- nothing happens. And for F12 also, nothing happens |
| 02:28 | <MikeSmith> | but I did manage to to get the Developer Tools UI to display |
| 02:28 | <MikeSmith> | and there's Save HTML button there |
| 02:30 | <MikeSmith> | now I don't don't how to move the file between the VirtualBox environment and my Mac filesystem but I guess it's just easier to send it to myself by Gmail |
| 02:30 | <MikeSmith> | cabanier: btw what I'm working is canvas-related |
| 02:31 | <MikeSmith> | preparing a report on browser results for the 2dcontext test sute |
| 02:32 | <cabanier> | MikeSmith: ah. |
| 02:32 | <cabanier> | MikeSmith: is it so we know to go to the next stage and cut the at-risk features? |
| 02:33 | <MikeSmith> | yeah |
| 02:35 | <MikeSmith> | cabanier: results so far at at http://w3c-test.org/testrunner/2dcontext/results.html |
| 02:35 | <cabanier> | I thought someone already did that a couple of months ago. |
| 02:35 | <MikeSmith> | probably they did |
| 02:36 | <MikeSmith> | but if so I don't recall where or if they produced an actual report of some kind |
| 02:36 | <MikeSmith> | the above results are generated using a test-runner that Ms2ger put together |
| 02:37 | <cabanier> | I remember seeing it. They used the same test suite from philip |
| 02:37 | <MikeSmith> | (general test-runner, not specific to canvas)a |
| 02:37 | <MikeSmith> | OK |
| 02:38 | <MikeSmith> | you don't remember who it was? |
| 02:48 | <cabanier> | Let me check my email |
| 02:52 | <MikeSmith> | cabanier: thanks -- I appreciate it |
| 02:53 | <cabanier> | MikeSmith: Jay created a report: https://github.com/w3c/html/commit/e39702df26606c248e4446f4371ca5ce739 |
| 02:53 | <cabanier> | MikeSmith: I don't know how extensive it is |
| 02:54 | MikeSmith | looks |
| 02:54 | <cabanier> | http://dev.w3.org/cvsweb/~checkout~/html5/2dcontext/canvas2d-implemtation.html?rev=1.3;content-type=text%2Fhtml |
| 02:54 | <MikeSmith> | cabanier: not so bad for what it is I guess |
| 02:54 | <MikeSmith> | https://rawgithub.com/w3c/html/e39702df26606c248e4446f4371ca5ce73912e61/CR_canvas_Status-6-20-2013.html |
| 02:54 | <MikeSmith> | cabanier: thanks |
| 02:55 | <MikeSmith> | yeah but not so extensive |
| 02:55 | <cabanier> | no. I think he mentioned that |
| 02:55 | <MikeSmith> | we need to granularity |
| 02:56 | <cabanier> | more granularity? |
| 02:56 | <MikeSmith> | I mean, we all already know that that we don't have implementations of Path object and hit testing |
| 02:56 | <MikeSmith> | granularity as in, exactly which tests fail |
| 02:56 | <MikeSmith> | and do they fail in more than one browser |
| 02:56 | <cabanier> | yes |
| 02:57 | <cabanier> | sometimes the spec is wrong but all the browser agree anyway |
| 02:57 | <cabanier> | ie stroking |
| 02:57 | <MikeSmith> | or to put it in other terms, for any given test, do we have a least 2 engines that pass it |
| 02:57 | <MikeSmith> | yeah |
| 02:58 | <MikeSmith> | cabanier: or if you look at the first failure in http://w3c-test.org/testrunner/2dcontext/results.html |
| 02:58 | <MikeSmith> | fill-and-stroke-styles/2d.pattern.image.incomplete.immediate.html |
| 02:58 | <MikeSmith> | fails in all UAs |
| 02:59 | <MikeSmith> | http://w3c-test.org/testrunner/2dcontext/fill-and-stroke-styles/2d.pattern.image.incomplete.immediate.html |
| 03:01 | <cabanier> | 2d.pattern.image.incomplete.immediate.html is part of the blink/webkit testsuite and passes there |
| 03:01 | <MikeSmith> | really? |
| 03:01 | <MikeSmith> | not passing for me when I run it in Chromium 31 |
| 03:02 | <cabanier> | This is the script: |
| 03:02 | <cabanier> | _addTest(function(canvas, ctx) { |
| 03:02 | <cabanier> | var img = new Image(); |
| 03:02 | <cabanier> | img.src = "NotARealFileName.png"; |
| 03:02 | <cabanier> | _assertSame(img.complete, false, "img.complete", "false"); |
| 03:02 | <cabanier> | _assertSame(ctx.createPattern(img, 'repeat'), null, "ctx.createPattern(img, 'repeat')", "null"); |
| 03:02 | <cabanier> | }); |
| 03:02 | <MikeSmith> | http://w3c-test.org/testrunner/2dcontext/results-chrome31.html |
| 03:02 | <MikeSmith> | I get "Failed assertion ctx.createPattern(img, 'repeat') === null (got [object CanvasPattern][object], expected [object])" |
| 03:03 | <MikeSmith> | assert_equals: ctx.createPattern(img, 'repeat') === null (got [object CanvasPattern][object], expected [object]) expected null but got object "[object CanvasPattern]" |
| 03:03 | <cabanier> | the code looks the same |
| 03:03 | <MikeSmith> | I get tht same failure in Firefox 26 |
| 03:04 | <cabanier> | ah, in your case it's finding the image |
| 03:07 | <cabanier> | this is testing image fetching from the main HTML spec: http://www.whatwg.org/specs/web-apps/current-work/#update-the-image-data |
| 03:08 | <cabanier> | and I'm not sure if it's asserting on something correct |
| 03:09 | <MikeSmith> | so maybe there's something wrong with the test |
| 03:10 | <MikeSmith> | by my count we have about 40 tests from thw 2dcontext test suite that aren't passing in any UA |
| 03:10 | <cabanier> | I'm not 100% sure that the test is wrong, but it's not failing on something that's part of canvas |
| 03:11 | <MikeSmith> | ok |
| 03:11 | <MikeSmith> | so that's the kind of thing we need to isolate, and change the test or drop it or whatever if it's not valid |
| 03:12 | <cabanier> | yes |
| 03:14 | <MikeSmith> | to me the main real utility of the http://w3c-test.org/testrunner/2dcontext/results.html report is, we go through all the fails-in-two-or-more-browsers cases and figure out why they're failing, then either make changes to the tests as needed, or if it's a real conformance failure with the current spec, then we either change the spec or list it as a known issue or whatever |
| 03:15 | <cabanier> | 2d.pattern.repeat.null.html is actually something where the whatwg is diverging from the w3c one |
| 03:16 | <cabanier> | MikeSmith: yes, let's go through them and see if we find spec bugs |
| 03:17 | <MikeSmith> | cabanier: if/when you have time on your own, and you see some low-hanging fruit, please make some notes and send them to the public-html-testsuite list or even to public-html |
| 03:18 | <MikeSmith> | in the meantime, plh is going to be talking about the results with Kris Kruger |
| 03:19 | <cabanier> | ok |
| 03:19 | <MikeSmith> | myself after this weekend I'm going to be away for two weeks at some Web events in Inida |
| 03:21 | <cabanier> | I assume that you will add all results to http://w3c-test.org/testrunner/2dcontext/results.html ? |
| 03:22 | <MikeSmith> | cabanier: which other results are needed? |
| 03:23 | <MikeSmith> | plh and I are only testing the latest versions of each UA |
| 03:23 | <cabanier> | MikeSmith: ah. I thought you were still adding test results |
| 03:23 | <cabanier> | ok |
| 03:23 | <MikeSmith> | no, those are complete results for all the http://w3c-test.org/web-platform-tests/master/2dcontext/ tests at least |
| 03:25 | <MikeSmith> | I know we have other canvas tests in http://w3c-test.org/web-platform-tests/master/html/semantics/embedded-content-0/the-canvas-element/ but I'm not doing any reporting on those yet at this point |
| 03:38 | <Hixie_> | cabanier: is 2d.pattern.repeat.null.html assuming the whatwg spec or the w3c one? and what do browsers do? |
| 03:38 | <cabanier> | the one mike ran assumes w3c |
| 03:38 | <Hixie_> | cabanier: the reason i pinged you earlier was wondering if you were aware of any css plans to do blurring during composition, of the content you're being composited on |
| 03:39 | <cabanier> | s/w3c/whatwg |
| 03:39 | <cabanier> | the one from webkit/blink assumes w3c |
| 03:39 | <cabanier> | blurring of the element? that's already in |
| 03:40 | <Hixie_> | not of the element |
| 03:40 | <Hixie_> | of the stuff behind the element |
| 03:40 | <cabanier> | ah |
| 03:40 | <cabanier> | like blurring your backdrop? |
| 03:40 | <cabanier> | we've talked about that but it's not in a spec yet |
| 03:40 | <Hixie_> | k |
| 03:41 | <Hixie_> | had a need for it in a personal project recently, so, consider this a +1 :-) |
| 03:41 | <Hixie_> | looks like the whatwg spec is just wrong about the createPattern() call. |
| 03:42 | <cabanier> | http://lists.w3.org/Archives/Public/public-fx/2012AprJun/0003.html |
| 03:42 | <Hixie_> | w3c spec seems wrong too though |
| 03:42 | <cabanier> | we've had a bug on createPattern |
| 03:43 | <cabanier> | "If the empty string or null is specified, repeat must be assumed" |
| 03:43 | <Hixie_> | that's not the bug |
| 03:43 | <Hixie_> | the bug is the idl is wrong |
| 03:43 | <Hixie_> | it says first argument isn't nullable |
| 03:43 | <Hixie_> | (both specs say that) |
| 03:45 | <cabanier> | yes. the idl is wrong |
| 03:47 | <Hixie_> | man, the w3c one is way out of date |
| 03:47 | <Hixie_> | either that or i'm looking at the wrong spec |
| 03:48 | <Hixie_> | wait |
| 03:49 | <Hixie_> | i'm getting different results here |
| 03:49 | <Hixie_> | oh, i misread the test |
| 03:49 | <cabanier> | I might have been looking at a different test. several failed |
| 03:49 | <cabanier> | which one are you looking at? |
| 03:49 | <Hixie_> | http://w3c-test.org/testrunner/2dcontext/fill-and-stroke-styles/2d.pattern.repeat.null.html, but i was misreading it |
| 03:49 | <Hixie_> | testing again now. |
| 03:52 | <cabanier> | ok. the test you run assumes that 'null' will throw, but the same test in blink assumes that it will work |
| 03:57 | <Hixie_> | i wonder (a) why the browsers do this, given that it's so inconsistent with everything else, and (b) why the specs forked on this |
| 03:58 | <cabanier> | it was an accidental change by Cameron when he updated everything to webidl |
| 03:58 | <Hixie_> | what was? |
| 03:59 | <cabanier> | no longer allowing null |
| 03:59 | <cabanier> | for createPattern |
| 03:59 | <Hixie_> | ah |
| 03:59 | <Hixie_> | that doesn't explain the forking though |
| 04:00 | <cabanier> | I'm trying to find the bug |
| 04:00 | <Hixie_> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=17891 |
| 04:00 | <Hixie_> | that's where we decided to make the whatwg version make more sense |
| 04:01 | <Hixie_> | but the w3c one forking apparently sowed confusion and led to implementations staying with the old behaviour |
| 04:01 | <Hixie_> | ffs |
| 04:01 | <Hixie_> | this forking crap keeps causing stuff like this |
| 04:01 | <Hixie_> | i wish the htmlwg would stop doing this |
| 04:01 | <cabanier> | the browsers all agreed that null was ok |
| 04:02 | <Hixie_> | because of the fork |
| 04:02 | <Hixie_> | they wouldn't have otherwise |
| 04:02 | <Hixie_> | see e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=784809 |
| 04:02 | <cabanier> | no, the old canvas spec said it was ok |
| 04:02 | <Hixie_> | yeah, and we tried to fix it |
| 04:02 | <Hixie_> | but the w3c spec didn't |
| 04:02 | <cabanier> | why? |
| 04:02 | <cabanier> | what needed fixing? |
| 04:03 | <Hixie_> | why the w3c didn't? beats the heck out of me |
| 04:03 | <Hixie_> | what needs fixing is "null" being treated as empty string is not normal behaviour |
| 04:03 | <cabanier> | this is when the test was changed to disallow null: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17141 |
| 04:05 | <cabanier> | https://bugzilla.mozilla.org/show_bug.cgi?id=784809 was to undo the change that ms2ger made shortly after he changed the test |
| 04:09 | <cabanier> | so, as far as I can tell: |
| 04:09 | <cabanier> | 1. everyone allowed null (and the tests verified this) |
| 04:10 | <cabanier> | 2. you integrated cameron's change |
| 04:10 | <cabanier> | 3. ms2ger changed mozilla and the test |
| 04:11 | <cabanier> | 4. Boris did not agree with the change, someone filed a bug against the w3c spec and the whatwg |
| 04:11 | <cabanier> | 5. the w3c version was changed back and mozilla reverted its change |
| 04:12 | <cabanier> | I don't remember why I changed the IDL back... |
| 04:13 | <cabanier> | I had a domstring? there at one point |
| 04:13 | <Hixie_> | re 1, pretty sure opera didn't. |
| 04:14 | <Hixie_> | re 4, the mozilla bug makes it clear that it was because the specs forked that bz felt he should pick something |
| 04:14 | <cabanier> | yes, they were the odd one out |
| 04:14 | <Hixie_> | the net result is, the web gets one more crazy quirk. yay us. |
| 04:15 | <cabanier> | I don't think so. I remember that bz wanted the old behavior. see also https://www.w3.org/Bugs/Public/show_bug.cgi?id=17891#c8 |
| 04:17 | <cabanier> | fwiw, I think the canvas api's should be more lax. |
| 04:18 | <Hixie_> | https://bugzilla.mozilla.org/show_bug.cgi?id=784809 was filed by bz specifically with the reason "the spec changed" which he later clarified to mean your fork |
| 04:18 | <Hixie_> | so step 4 happened after the w3c spec changed, and because of it |
| 04:19 | <Hixie_> | anyway, the specifics are water under the bridge. i just find it irritating that we once again have inconsistency in the platform, especially since this time it's specifically because the w3c is forking specs that we have it. |
| 04:20 | <cabanier> | I'm not sure if you can blame forking here. I agree forking is bad! |
| 04:20 | <cabanier> | boris would have objected to this even if there was no w3c spec |
| 04:21 | <cabanier> | https://bugzilla.mozilla.org/show_bug.cgi?id=784809#c2: "The user impact is that createPattern calls that used to work and should work per the updated spec throw on m-c and aurora right now." |
| 04:22 | <cabanier> | some websites broke with this change |
| 04:22 | <Hixie_> | which? |
| 04:23 | <cabanier> | I don't remember but there was a popular library that stopped working |
| 04:23 | <Hixie_> | i don't see that documented anywhere |
| 04:25 | <cabanier> | yes, I can only find that aurora is throwing |
| 04:26 | <cabanier> | I think that was really the divergence :-P |
| 04:26 | <cabanier> | the only divergence |
| 04:27 | <Hixie_> | there's like half a dozen different versions of the canvas spec on the w3c site, but the ones i found were all very divergent when it comes to createPattern. For example, they don't have ImageBitmap. |
| 04:27 | <Hixie_> | or CanvasImageSource or whatever it's called. |
| 04:27 | <Hixie_> | (i really don't understand why the w3c insists on forking when they keep talking, as you just did, about how forking is bad) |
| 04:28 | <Hixie_> | anyway, i gotta go. bbl. |
| 04:29 | <cabanier> | ok! |
| 04:31 | <cabanier> | canvasimagesource should be there |
| 04:32 | <cabanier> | and imageBitmap is imageData. weird |
| 04:32 | <cabanier> | some integration must have gone bad |
| 05:01 | <MikeSmith> | cabanier: do you know offhand which test cases correspond to the changes Hixie just made to the canvas spec? |
| 05:02 | <MikeSmith> | if not, no worries, I'll go in and try to match them up so I can annotate the report |
| 05:43 | <cabanier> | MikeSmith: I think it's the one with 'pattern.repeat.null' |
| 05:44 | <cabanier> | It does seem like the latest canvas spec is out of sync with the whatwg one. I will find out why that happend |
| 05:54 | <MikeSmith> | cabanier: ok |
| 05:56 | <MikeSmith> | btw I don't think there's any tests in the canvas test suite that have ever intentionally been changed to assume the W3C spec and to not conform to the upstream spec |
| 05:57 | <MikeSmith> | if there are cases where they match the w3c spec but not the whatwg spec, I would thikn that's due to the whatwg spec having made a change and that change not getting ported to the w3c spec |
| 05:59 | <MikeSmith> | that is, the test is matching outdated behavior and needs to be updated |
| 07:01 | <cabanier> | MikeSmith: we should test what the browsers implemented. If all (or most) of them converge on a certain behavior, then that is what should be in the spec and what we should test |
| 07:02 | <cabanier> | MikeSmith: the createPattern issue is a good example of that |
| 07:02 | <MikeSmith> | yeah |
| 07:03 | <MikeSmith> | well, in that specific case, the test did originally match what was implemented |
| 07:04 | <cabanier> | yes. so most of them converged (except opera) and then it became impossible to change it to something more sane |
| 07:04 | <MikeSmith> | but then Mozilla changed to implement what the spec says, and at that time Ms2ger also changed the test, to match the spec and to match what Mozilla (and Opera) had implemented |
| 07:04 | <MikeSmith> | yeah |
| 12:54 | <Domenic_> | annevk: `class Elements extends Array` got spontaneous applause about an hour ago at JSConf EU :D |
| 14:54 | <xvzf> | hi there, I started to read Mark Pilgrim's book and he had written that WhatWG wanted to describe how popular browsers had provided fallback modes for erroneous html. Which documents should I read if I'm interested in this? |
| 14:58 | <Philip`> | xvzf: Probably http://whatwg.org/html |
| 15:08 | <xvzf> | Philip`, : especially http://www.whatwg.org/specs/web-apps/current-work/multipage/#auto-toc-14 I guess |
| 15:12 | <Philip`> | xvzf: The "Writing HTML documents" vs "Parsing HTML documents" sections might be the most obvious example - the first section defines what is correct/erroneous syntax, and the second section defines how to parse HTML regardless of its correctness (with the handling of erroneous content being compatible with what browsers have done historically, because there is content that relies on that) |
| 20:36 | <annevk> | bkardell__: I don't follow your question on Twitter |
| 21:55 | <Hixie_> | is there a way to make opacity:0 elements transparent for event targetting purposes also? |
| 21:55 | <Hixie_> | i'm using opacity to fade them out in a transition instead of marking them display:none, but they're still there so clicks still go to them... |
| 21:56 | <zewt> | pointer-events: none? |
| 21:57 | <Hixie_> | does that work these days? |
| 21:58 | <zewt> | might not be in IE |
| 22:00 | <Hixie_> | pointer-events doesn't seem to work in chrome either |
| 22:00 | <Hixie_> | or firefox |
| 22:01 | <Hixie_> | oh wait, typo |
| 22:01 | <zewt> | i've used it a ton in webkit-specific stuff, at least |
| 22:02 | <Hixie_> | nope, can't get pointer-events: none to work |
| 22:03 | Hixie_ | tries in a test case |
| 22:03 | <Hixie_> | works in my test... |
| 22:03 | <Hixie_> | wtf |
| 22:06 | <zewt> | it also doesn't prevent non-pointer stuff, like tab navigation, which can take some extra work |
| 22:08 | <Hixie_> | oh, it was working i just missed an element |
| 22:08 | <Hixie_> | duh |
| 22:10 | <Hixie_> | man i wish specificity didn't exist |
| 22:14 | <annevk> | I wonder if last matching selector wins would've been a better rule |