| 13:50 | <Domenic_> | annevk's offhand comment has launched me into a topsy-turvy what-if world where every time i see some CSS selectors juxtaposed I contemplate what could have been, and whether it would have been better. |
| 14:29 | <annevk> | Hah, sorry Domenic_! |
| 15:13 | <Jasper> | Is there a standard test suite for <canvas>? |
| 15:14 | <Jasper> | I found http://philip.html5.org/tests/canvas/suite/tests/ but it seems to be really outdated. |
| 15:16 | <annevk> | http://w3c-test.org/html/tests/approved/canvas/ I suspect |
| 15:17 | <Jasper> | Aha, thanks. |
| 15:22 | <Jasper> | annevk, yeah, that doesn't seem to test what I'm looking for. Is there a way to submit new tests to that? |
| 15:22 | <annevk> | Jasper: pull requests to https://github.com/w3c/web-platform-tests I suspect |
| 15:23 | <annevk> | Jasper: seems there's a 2dcontext directory too... |
| 15:24 | <annevk> | Probably has something to do with the W3C making the silly decision to publish them as distinct documents while there's still only one person writing them... |
| 15:27 | <Jasper> | OK, yeah. Every browser that I can test with does not seem to use the clipping path when rendering text. |
| 15:27 | <Jasper> | even though: "These shapes are painted without affecting the current path, and are subject to shadow effects, global alpha, the clipping region, and global composition operators." |
| 15:28 | <Jasper> | I wonder if we should just remove "clipping path" from that sentence, since fixing that bug might cause backwards compatibility issues. But then in order to clip text I'd need to create a new scratch canvas and copy pixels over |
| 15:30 | <annevk> | Jasper: I guess you're familiar with posting issues to whatwg⊙wo? |
| 15:30 | <Jasper> | I'm not, actually. |
| 15:30 | <annevk> | Jasper: http://www.whatwg.org/mailing-list#specs |
| 15:31 | <annevk> | Jasper: you can also file a bug, but emailing will give other implementers a better heads up, generally |
| 15:31 | <Jasper> | annevk, do I need to subscribe to the list, or can I just send one email? |
| 15:32 | <annevk> | Jasper: need to subscribe unfortunately, we're bad at handling spam :/ |
| 15:38 | <Jasper> | annevk, sent http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-September/040835.html |
| 15:38 | <Jasper> | sorry if I broke some etiquette or didn't explain myself clearly enough |
| 15:39 | <annevk> | Jasper: seems fine |
| 15:39 | <annevk> | Jasper: might take a while for people to get back to you, mind |
| 15:39 | <Jasper> | Yep. |
| 15:39 | <Jasper> | It's a weekend, too. |
| 15:39 | <Jasper> | annevk, thanks! |
| 18:16 | <gsnedders> | Hixie_: So your change about lone surrogates is still a change from the old html5lib tests and what the spec used to say. Lone surrogates used to get converted to U+FFFD. Now, is that desirable or not? Dunno. |
| 20:24 | <annevk> | That's what they do in CSS. I think we should be consistent at least... Rationale for one ought to apply to the other... |
| 20:41 | <Hixie_> | gsnedders: i tried to do that and people screamed at me that DOM APIs shouldn't do unicode sanitising... *shrug* |
| 21:04 | <gsnedders> | Oh well. Anyone feel like updating a ton of tests? |
| 21:36 | <zcorpan> | annevk: CSS doesn't U+FFFD lone surrogates, i think |
| 21:37 | <annevk> | zcorpan: per recent changes to css3-syntax it does, not at the CSSOM level though |
| 21:37 | <annevk> | I thought this discussion was about the parser because html5lib tests were mentioned... |
| 21:38 | <Hixie_> | it's at the parser level but only for document.write() and innerHTML |
| 21:38 | <annevk> | Fucking lone surrogates. We should really make up a set of principles and start applying them everywhere. |
| 21:38 | <zcorpan> | annevk: css-syntax only U+FFFDs lone surrogates in css escapes |
| 21:38 | <zcorpan> | annevk: which html does also |
| 21:39 | <annevk> | zcorpan: okay, and you can't get them in the input stream, so I guess that's consistent then |
| 21:39 | <zcorpan> | yeah. except when the input stream comes from cssom i guess |
| 21:40 | <annevk> | So it seems the principles are what I thought they'd be. Script is 16-bit code units and includes lone surrogates. Just parsing from network guarantees Unicode scalar values, including if you use escapes... |
| 21:40 | <zcorpan> | yep |
| 21:40 | <annevk> | I think I'd prefer to just use 16-bit code units everywhere, but oh well... |
| 21:41 | <annevk> | I guess it's somewhat nicer if you don't have JavaScript and still want to interpret some HTML and use non-browser strings... But the difference seems marginal and if you want code sharing you'll end up with browser strings anyway. |
| 21:45 | <Hixie_> | i'd be nicer if javascript was unicode scalar values and you never saw utf-16 anywhere ever ever ever |
| 21:46 | <gsnedders> | Well, that'd be easier if JS didn't predate UTF-16. |
| 21:49 | <Hixie_> | UTF-16 predates the web, let alone JS |
| 21:49 | <Hixie_> | though i guess teh surrogates don't predate the web |
| 21:50 | <Hixie_> | so practically you're right |
| 21:50 | <gsnedders> | UCS-2 predates the web, no? |
| 21:50 | <gsnedders> | UTF-16 comes later. |
| 21:50 | <zewt> | err, surrogates define utf-16 |
| 21:50 | <annevk> | Well we can't change JavaScript. I'm not sure JavaScript predated utf-16 |
| 21:50 | <Hixie_> | surrogates are 1996 |
| 21:51 | <gsnedders> | UTF-16 was Unicode 2.0, 1996. |
| 21:51 | <Hixie_> | and livescript was 1995 |
| 21:51 | <Hixie_> | so there we go |
| 21:51 | <gsnedders> | Superseding UCS-2. |
| 21:51 | <zewt> | (is this a conversation about how powerful we need to build our time machine) |
| 21:51 | <Hixie_> | yes |
| 21:51 | <annevk> | Yeah, copying Java :/ |
| 21:52 | <Hixie_> | well, before utf-16, ucs2 made a lot of sense |
| 21:52 | <gsnedders> | It could map the entire Unicode codespace. |
| 21:52 | <gsnedders> | The problem is the codespace got expanded. |
| 21:52 | <annevk> | Sure, when 16-bit was enough for all code points... |
| 21:52 | <gsnedders> | annevk: Which it was when JS was created. |
| 21:52 | <annevk> | Now it's 21-bit, hopefully that'll last |
| 21:52 | <annevk> | gsnedders: yeah I know |
| 21:53 | <zewt> | ucs-2 makes a lot more sense than utf-16, now and then, it's just limited |
| 21:53 | <gsnedders> | annevk: Well, given we're still at a point of most things being unassigned, it probably depends mostly on the rate of language change. Which I'm dubious about, given everything is typed nowadays. |
| 21:54 | <annevk> | Anyway, this keeps coming up. We should sort it out somehow... |
| 21:54 | <gsnedders> | Language change insofar as it changes alphabets, that is |
| 21:54 | gsnedders | votes lone surrogates always map to U+FFFD |
| 21:54 | <annevk> | gsnedders: that's not gonna happen |
| 21:54 | <gsnedders> | annevk: Why not? |
| 21:55 | <annevk> | gsnedders: we can't change the nature of strings in JavaScript |
| 21:55 | <gsnedders> | annevk: Oh, no, at that level it makes sense. |
| 21:55 | <annevk> | gsnedders: and we don't want the perf impact for every API |
| 21:55 | <gsnedders> | Then do we want to never convert them? |
| 21:56 | <annevk> | I think accepting 16-bit code units everywhere is the logical outcome, yes |
| 21:56 | <gsnedders> | Then we should probably change what � does. But maybe we can't? |
| 21:56 | <zcorpan> | http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Nov/0020.html |
| 21:56 | <annevk> | But it depends on what other arguments are put forward. E.g. I can see compatibility with clients that don't want 16-bit code units to be seen as important. Although I'm not sure how important that is... |
| 21:57 | <Hixie_> | can we please not change this stuff? it's irrelevant to the wider world and just wastes implementer time. |
| 21:57 | <zcorpan> | i agree with Hixie_. we have interop on this now iirc |
| 21:57 | <annevk> | Hixie_: the thing is, but this still being in flux it's still wasting time |
| 21:58 | <annevk> | Hixie_: e.g. for Rust / Servo |
| 21:58 | <annevk> | Hixie_: and the design of encoders/decoders |
| 21:58 | <Hixie_> | just, don't change what's implemented, that's all i ask |
| 21:58 | <annevk> | Hixie_: see recent thread on whatwg⊙wo, see thread on www-international⊙wo about text rendering, etc. |
| 22:01 | <Hixie_> | do mutation observers not provide a simple way to just detect when an element is removed from the DOM? |
| 22:01 | <Hixie_> | i just want to observe an element until it's removed from its parent |
| 22:04 | <annevk> | You can observe the parent changes to its children. |
| 22:05 | <Hixie_> | yeah but that means i have to filter out all the other children and then disconnect when i finally see what i care about |
| 22:05 | <Hixie_> | which is like twenty times more code than i want |
| 22:09 | <annevk> | File a bug? Could look into new mutation observer features at some point... I wonder if we should do that before or after MVC stuff is done. |
| 22:10 | <annevk> | I need to get some sleep. If anyone here has feedback for TC39, please let me know. W3C TAG feedback welcome too... Will be in Boston / NY for a couple of weeks starting next week to talk to those guys. |
| 22:11 | <Hixie_> | so here's a problem |
| 22:11 | <Hixie_> | i need to follow the node's parent |
| 22:11 | <Hixie_> | before i know what it is |
| 22:11 | <Hixie_> | since the element hasn't been added to the dom yet |
| 22:11 | <Hixie_> | at the point where i want to set up observing its parent going away |
| 22:16 | <Hixie_> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=23250 |
| 22:25 | <Hixie_> | is there a way to do "instanceof Document" that actually works? i.e. won't only be true for the current browsing context's Document? |
| 22:26 | <Hixie_> | o.ownerDocument == o, i guess... |
| 22:26 | <Hixie_> | oh, crap, that returns null for documents |
| 22:27 | <Hixie_> | well, o.ownerDocument == null, then, if i know it's a Node |