| 00:01 | <TabAtkins> | Do I have to write something special to say that an IDL method takes a TypedArray or a TypedArrayView, or is that implicit in saying TypedArray? |
| 00:01 | <TabAtkins> | Or maybe there's a typedef living somewhere that means that. |
| 00:02 | <heycam> | Uint32Array is a "typed array view" interface |
| 00:05 | <TabAtkins> | heycam: Right. But there's no reason for a method taking a TypedArray to not take a Uint32Array, right? So is there an easy way to just say "any of those typed array things"? |
| 00:06 | <heycam> | what is "TypedArray"? |
| 00:06 | <heycam> | the same as "any of those typed array things"? |
| 00:06 | <TabAtkins> | sorry, ArrayBuffer |
| 00:06 | <heycam> | ah |
| 00:06 | <TabAtkins> | Dunno why my fingers kept typing TypedArray. |
| 00:06 | <zewt> | tab: that API makes me sad, such a mess |
| 00:07 | <Hixie_> | what isn't |
| 00:07 | <zewt> | an unexcusable mess, as far as the distinction goes |
| 00:07 | <heycam> | TabAtkins, I don't think there's an existing typedef for "an untyped ArrayBuffer or a specific typed array type" |
| 00:07 | <heycam> | if that's what you're after |
| 00:08 | <TabAtkins> | Yeah, that's what I'm after. |
| 00:08 | <TabAtkins> | I guess someone needs to do a "typedef BinaryData (ArrayBuffer or ...);" somewhere. |
| 00:09 | <TabAtkins> | Because, again, there's definitely no reason that something taking an ArrayBuffer shouldn't be able to accept a JS Struct, once they finish speccing that stuff. |
| 00:09 | <TabAtkins> | Frex, you could set up a WOFF file as a somewhat-complex JS binary-data Struct, and you should be able to pass that directly to the FontFace constructor I'm writing. |
| 00:10 | <zewt> | all of the views should have just been subclasses of ArrayBuffer ... iirc, the only thing preventing doing that now is some difference in how slice() works, or something like that |
| 00:11 | <TabAtkins> | zewt: You mean that .slice() works different on an ArrayBuffer versus a view? |
| 00:13 | <TabAtkins> | .slice() doesn't seem to be defined on ArrayBufferViews at all - they have .subarray() instead, which is different (a sliced view, rather than a slice of the data). |
| 00:22 | <MikeSmith> | earthquake in tokyo just now |
| 00:27 | <zewt> | great, now gmail is intentionally ignoring what I tell it to search for too |
| 00:28 | <zewt> | apparently all search engines from now on will treat the user like an imbecile, and assume search queries are just vague suggestions |
| 00:31 | <TabAtkins> | zewt: If you saw the average search query... |
| 00:31 | <zewt> | how about: don't treat me like an idiot (and cripple my tools) because other people are idiots |
| 00:31 | <zewt> | </rant> |
| 00:33 | <zewt> | oh, i think i remember what I was thinking about |
| 00:34 | <zewt> | new UInt8Array(buffer) creates a copy, where it should have just created a view over the buffer |
| 00:36 | <zewt> | and new UInt8Array(buffer, offset, length) does create a view--which alongside the above, is confusing as hell |
| 00:36 | <zewt> | but the mantra of web apis: oh well, too late |
| 00:37 | <zewt> | (not entirely sure that's what I was thinking about, but no real point in digging around to find it) |
| 00:40 | <zewt> | oh, lovely gmail bug |
| 00:41 | <zewt> | i see an empty editing reply in a thread I'm reading; I discard it (assuming it was a temporary reply, which I often create before merging replies); then I go "hold on", hit undo discard, and surprise: there was a whole reply in there |
| 00:41 | <TabAtkins> | zewt: Aw jeez, that's a really dumb behavior. |
| 00:41 | <TabAtkins> | Like, crazy stupid. |
| 00:42 | <zewt> | the arraybuffer thing or the gmail thing? (heh) |
| 00:42 | <zewt> | (answer: yes) |
| 00:42 | <TabAtkins> | The arraybuffer thing. |
| 00:44 | <TabAtkins> | Am I missing something, or is http://dom.spec.whatwg.org/#error-names-0 missing TypeError and RangeError? |
| 00:49 | <zewt> | two simple changes would have simplified typed arrays to a stupid degree: get rid of ArrayBuffer entirely (return Uint8Array from APIs, don't have a typeless class at all) and fix the ctor problem (to make it easy to cast Uint8Array to whatever you need) |
| 00:49 | <zewt> | i think i suggested that and the response was something like "some Java API did that and it caused performance problems so it's a bad idea" o_O |
| 00:51 | <TabAtkins> | That was indeed the response. I didn't understand it well enough to really figure out what the issue was. |
| 00:52 | <zewt> | java and javascript have so little in common, all I can say is o_O |
| 00:52 | <TabAtkins> | Or no, that was about endianness. |
| 00:52 | <zewt> | (wish I could remember where that discussion was, if only to verify my recollection, but I have no idea) |
| 00:52 | <TabAtkins> | It wasn't a syntax issue, so Java vs Javascript is fairly irrelevant to the point. |
| 00:53 | <zewt> | err, java and javascript's differences are much deeper than syntax |
| 00:53 | <zewt> | probably the only thing they have in common is GC |
| 00:53 | <TabAtkins> | None of which are particularly relevant to the treatment of binary data. |
| 00:54 | <zewt> | if somebody saw performance issues with returning a uint8_t* and then casting it to uint32_t* in Java, that doesn't inform JS API development at all |
| 00:55 | <TabAtkins> | It was something about processors and memory pipelines or something like that. Something pretty language-agnostic. |
| 00:55 | <zewt> | maybe it was a different conversation, since in the one I had I don't recall any technical followups |
| 00:55 | <TabAtkins> | Doesn't mean it was validly generalizable - it may have been something more API-specific, or dated. But it wasn't *language*-specific. |
| 00:56 | <TabAtkins> | Kenneth Russell was the one talking about it. |
| 00:56 | <TabAtkins> | And Gregg Tavares. |
| 00:58 | <zewt> | nothing in my experience would explain a processor-level performance difference between "return an object that accesses a void* as 8-bit unsigned ints, then create an object that accesses the same void* as 32-bit unsigned ints" and "return an opaque object holding a buffer, then create an object that accesses the buffer as 32-bit unsigned ints" |
| 00:58 | <TabAtkins> | The only Java-based performance argument I recall was one about endianness. I don't really remember one about ArrayBuffer vs ArrayBufferView. |
| 00:59 | <TabAtkins> | If I pass a DOMString representing a url to a function, does it make sense to parse the url and reject it if there's a parse error? |
| 00:59 | <TabAtkins> | Or should I be forgiving and just work with whatever the URL parser spits out? |
| 00:59 | <zewt> | i think i remember that conversation (but it's a different one, or at least a different subargument) |
| 00:59 | <TabAtkins> | Ah, then I dunno what we're talking about. ^_^ |
| 01:00 | <zewt> | where we were saying "having UInt32Array be the platform endianness is interop death and don't do it" |
| 01:02 | <zewt> | TabAtkins: copy whatever new WebSocket(url) does? |
| 01:02 | <zewt> | (was going to say "xhr", but thought better of that) |
| 01:02 | <TabAtkins> | Good point. |
| 01:03 | <TabAtkins> | Throw a SyntaxError and abort. Can do. |
| 01:45 | <zewt> | now there's somebody on www-dom who's so important he's sending all his mails in Gigantic Red |
| 01:48 | <TabAtkins> | annevk: How do I deal with a response once it's been returned by Fetch? |
| 01:49 | <TabAtkins> | Just check if it returned a code of 200 and a non-null body? |
| 01:51 | <TabAtkins> | (I presume redirects are automatically handled for me and I wont' see them, unless I've set the manual redirects flag.) |
| 02:04 | <TabAtkins> | annevk: If it helps, I'm doing a synchronous fetch, because I'm already in an async portion of the algorithm, and it seemed like that was easiest. |
| 03:56 | <zewt> | also cool google joins the ranks of "you gave us your email address, and we've decided it's okay to use it for ads" |
| 03:57 | <zewt> | "Your Google Wallet has exciting new updates", as if I've ever used "google wallet" (much less opted into ads) |
| 06:41 | <TabAtkins> | zewt: You should use Wallet - it's a lot more convenient than PayPay for sending people money. |
| 06:43 | <annevk> | TabAtkins: so yes, don't do normalization in CSS. Just say people ought to normalize, but don't require it from implementations. Deal in 16-bit code units as the whole thing bottoms out to JavaScript in the end... |
| 06:43 | <annevk> | TabAtkins: TypeError and RangeError are defined by JavaScript, not DOM (we need to revise DOMException in some way still, haven't figured out how) |
| 06:44 | <TabAtkins> | annevk: Ah, the error thing is confusing. Perhaps a note in the Event Names section is warranted? I'll file a bug. |
| 06:44 | <annevk> | TabAtkins: so there's a bug on moving the whole error thing over to Web IDL already |
| 06:45 | <TabAtkins> | Ah, then I'll just leave it alone I suppose. |
| 06:45 | <annevk> | TabAtkins: as for something accepting bytes, just use ArrayBuffer for now and we'll think of something better once ES6 has assimilated the whole bunch |
| 06:45 | <TabAtkins> | I just did a typedef for (ArrayBuffer or ArrayBufferView). |
| 06:47 | <annevk> | TabAtkins: yeah I guess, one technical problem with that is that ArrayBuffer/ArrayBufferView are no longer IDL-defined |
| 06:47 | <TabAtkins> | Meh. |
| 06:51 | <annevk> | I guess I should file a bug on IDL for that too, though I suspect heycam might wanna wait for ES6 with that... |
| 06:52 | <heycam> | are they going in to the ES spec in the ES6 timeframe? |
| 06:52 | <heycam> | (not that I know what that timeframe is) |
| 07:00 | <TabAtkins> | annevk: So what about my last question, regarding what to do with a response returned by fetch? |
| 07:00 | <annevk> | heycam: yeah, timeframe is end-of-year plus a year to fix bugs I think |
| 07:00 | <annevk> | TabAtkins: we generally don't look at the response code at all, except for redirects which Fetch handles |
| 07:01 | <heycam> | ok |
| 07:01 | <annevk> | TabAtkins: so you either get something back which you decode or you get a network error |
| 07:01 | <TabAtkins> | Okay, so I just trust that if I got a response rather than an error, I can read the body for the data? |
| 07:01 | <TabAtkins> | Ooh, I have to decode it now? |
| 07:01 | <annevk> | TabAtkins: that's how <img>, <script>, et al work, yes |
| 07:01 | <annevk> | TabAtkins: dunno, depends on what you're fetching :) |
| 07:01 | <TabAtkins> | Oh, right, just font data, so no text decoding necessary. |
| 07:01 | <TabAtkins> | Okay. |
| 07:01 | <TabAtkins> | This would be useful information in Fetch. ^_^ |
| 07:02 | <annevk> | TabAtkins: just font decoding then :) |
| 07:02 | <annevk> | TabAtkins: file a bug? |
| 07:02 | annevk | is still at the stage where he tries to make Fetch work for the entire platform |
| 07:06 | <annevk> | heycam: they're in http://people.mozilla.org/~jorendorff/es6-draft.html fwiw |
| 08:56 | <annevk> | TabAtkins: I guess the other thing is that I hope example usage needs go away once more specs start using the revised building blocks; you just happen to be an early adaopter... :/ |
| 09:33 | <jgraham> | annevk: Yes. Tests are BSD/W3C dual licensed |
| 09:33 | <jgraham> | i.e. they are BSD licensed but you don't get to call it the "W3C testsuite" |
| 09:33 | <annevk> | They cannot be more liberally licensed I guess? |
| 09:34 | <jgraham> | Not really |
| 09:34 | <jgraham> | I mean that's pretty reasonable I think |
| 09:34 | <jgraham> | (more liberal than any browser engine, for example) |
| 09:52 | <zcorpan> | TabAtkins: WebSocket throws if the url is invalid |
| 09:52 | <zcorpan> | TabAtkins: but there's probably also precedent for silent fail |
| 09:52 | <annevk> | Like <a> |
| 09:53 | <annevk> | And setting <a>.href |
| 10:08 | <annevk> | Why has nobody noticed that http://encoding.spec.whatwg.org/#dom-textencoder-encode does not throw the exception it should? |
| 10:08 | <annevk> | That's kind of disturbing... |
| 10:10 | <darobin> | annevk: probably because no one has read it? |
| 10:10 | <annevk> | Oh wait, only utf-8 / utf-16. Doh. |
| 10:10 | <annevk> | No people have read that and implemented it. I just assumed it had to work for arbitrary encodings which is not true. |
| 10:11 | <annevk> | We might want to add that at some point I suppose. |
| 10:23 | annevk | wonders where SimonSapin is |
| 10:23 | <Ms2ger> | Behind you! |
| 10:28 | <annevk> | Ms2ger, typically that'd be very close, but today... |
| 10:28 | <Ms2ger> | I dunno, he's French, maybe on vacation? :): |
| 10:30 | <annevk> | So both the utf-8 and utf-16 encoders deal with lone surrogate input... Does that make sense? |
| 10:31 | <annevk> | That also contradicts my earlier point about them always being safe... |
| 10:31 | <jgraham> | annevk: draw a cone out from your back across the surface of the earth, and he is contained in the cone. At least if you allow it to wrap around the surface |
| 10:32 | <jgraham> | So I guess he is behind you? |
| 10:32 | <annevk> | s = new TextEncoder("utf-16le"); w(s.encode("\ud800")) |
| 10:32 | <annevk> | Gives 0, 216 |
| 10:33 | <SimonSapin> | annevk: should it throw? |
| 10:34 | <annevk> | SimonSapin: either that, or before it even reaches the encoder it should've been replaced with FFFD |
| 10:35 | <annevk> | I think currently the latter is what's required through IDL... |
| 10:35 | <annevk> | I'm fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=23103 so I ran into this |
| 10:38 | <annevk> | Gecko does the FFFD treatment for utf-8 |
| 10:38 | <SimonSapin> | uh. JS strings biting us again |
| 10:39 | <annevk> | The more I run into it, the more I think we should just embrace it and define everything in terms of 16-bit code units. Although that'd be a pain for some encodings... |
| 10:39 | <annevk> | Like rewriting gbk to work on 16-bit code units is way less nice. |
| 10:40 | <annevk> | And by everything I mean URL, Encoding, HTML, CSS, ... |
| 10:48 | smaug____ | wonders why Promises are so hip |
| 10:49 | <jgraham> | Because they are new and unproven and therefore we don't fully understand all the problems with them yet |
| 10:50 | <Ms2ger> | zcorpan, jgraham: do you know if there's tests for MessageChannel and stuff somewhere? |
| 10:51 | <jgraham> | Or, to be less synical, because all the async primitives we have tried in in so far have sucked, so trying a new approach that has theoretical benefits and some positive experience in the js framework community seems like a good idea |
| 10:51 | <jgraham> | *cynical |
| 10:53 | <zcorpan> | Ms2ger: https://github.com/w3c/web-platform-tests/tree/master/webmessaging/message-channels |
| 10:54 | <Ms2ger> | zcorpan, thanks |
| 11:27 | <SimonSapin> | annevk: code points everywhere |
| 11:28 | <annevk> | SimonSapin: that might mean encoders that fail, depending on how we define them |
| 11:32 | <SimonSapin> | annevk: do "16bits units everywhere" fix that? You can still get lone surrogates |
| 11:33 | <SimonSapin> | is whatwg.org supposed to support https? |
| 11:33 | <SimonSapin> | <link href="//www.whatwg.org/style/specification"; rel="stylesheet"> times out from https://rawgithub.com |
| 11:34 | <jgraham> | I don't think it is |
| 11:35 | <SimonSapin> | HTML uses href="http://www.whatwg.org/style/specification"; |
| 11:46 | <Ms2ger> | Apparently the Google Authenticator update is no good |
| 11:48 | <annevk> | SimonSapin: yeah, but then we just embrace lone surrogates, and only catch them when absolutely necessary |
| 11:49 | <annevk> | SimonSapin: which is almost never |
| 11:49 | <SimonSapin> | annevk: same as with code points? |
| 11:49 | <annevk> | SimonSapin: code points doesn't really exist |
| 11:49 | <annevk> | SimonSapin: so that seems kinda pointless as a concept |
| 13:27 | <annevk> | (In case you were wondering, that's false starting with ES6. It'll expose methods around String objects that deal with code points, not 16-bit code units, or Unicode scalar values. That's a first though I think.) |
| 13:39 | <SimonSapin> | annevk: I went through the Encoding changes. Looks good. |
| 13:40 | <annevk> | Thanks. I guess next would be figuring out if I want that abstract stream concept... |
| 13:40 | <annevk> | Or maybe look into the various issues around encodings... |
| 14:01 | <GPHemsley> | W3C is updating its Bugzilla instance tomorrow! \o/ |
| 14:01 | <jgraham> | W3C is breaking bugzilla tomorrow! |
| 14:01 | <GPHemsley> | \o/ |
| 14:10 | <Domenic_> | Where is Mozilla's JS engine source located? |
| 14:10 | <Domenic_> | Preferably web-viewable |
| 14:13 | <jgraham> | https://dxr.mozilla.org |
| 14:13 | <jgraham> | http://dxr.mozilla.org/mozilla-central/source/js specifically |
| 14:13 | <Domenic_> | Awesome, thanks |
| 14:14 | <annevk> | jgraham: what's the difference with http://mxr.mozilla.org/mozilla-central/source/js/ ? |
| 14:14 | <jgraham> | dxr is shinier |
| 14:15 | <jgraham> | It has a bunch of fancy features based on static analysis of the code |
| 14:15 | <jgraham> | But only works on m-c and one revision |
| 14:15 | <SimonSapin> | cool |
| 14:15 | <annevk> | But it's not live it seems |
| 14:16 | <SimonSapin> | live? |
| 14:16 | <jgraham> | Right, it probably only gets updated sometimes |
| 14:17 | <jgraham> | Because you need to do all the static analysis |
| 14:18 | <jgraham> | I'm not sure how often, but the files seem to be dated 3rd September, so I guess daily? |
| 14:45 | <Ms2ger> | Mxr isn't live either |
| 14:51 | <Ms2ger> | annevk, r? https://critic.hoppipolla.co.uk/r/294 :) |
| 14:51 | <annevk> | long test is long |
| 14:55 | <zewt> | TabAtkins: nothing I use supports it |
| 14:57 | <jgraham> | That's a long test? |
| 14:58 | <Ms2ger> | Have you seen jgraham's loading tests? |
| 14:59 | <jgraham> | Well they're just silly |
| 14:59 | <jgraham> | Tests that require navigation to three different files |
| 14:59 | <Ms2ger> | I started reviewing, but... |
| 15:00 | <jgraham> | Yeah :| |
| 15:00 | <annevk> | jgraham: I know I know |
| 15:00 | <jgraham> | I would love to say "they were reviewed internally at Opera and are fine" |
| 15:00 | <jgraham> | But that just isn't true |
| 15:00 | <Ms2ger> | Well |
| 15:01 | <Ms2ger> | The result of that would probably be people filing bugs and bz having to review them |
| 15:01 | <jgraham> | gsnedders probably reviewed them a bit, but they are quite likely to be buggy, and the spec was unstable and the implementation was never finished |
| 15:01 | <jgraham> | So.. |
| 15:02 | <SimonSapin> | annevk: ES6 codePointAt and fromCodePoint are the only things that "expose" code points to the platform … but are unicode scalar values exposed ? |
| 15:02 | <annevk> | Yes, utf-8 |
| 15:02 | <SimonSapin> | if exposed means from JS |
| 15:02 | <annevk> | No it just means exposed |
| 15:04 | <SimonSapin> | data:text/html,<script>document.write('\uD800')</script> looks like a missing glyph in Gecko. Isn’t that the text subsystem working on code points? |
| 15:05 | <SimonSapin> | (missing glyph, as opposed to replacement character) |
| 15:05 | <jgraham> | Ms2ger: So I don't mind bz reviewing them :) |
| 15:05 | <Ms2ger> | jgraham, well, I'm not sure if I'd prioritize it over his other work ;) |
| 15:05 | <Ms2ger> | Maybe I should enlist the Servo folks |
| 15:06 | <jgraham> | Yeah, well the servo people are the ones that should benefit the most from this |
| 15:06 | <jgraham> | But afaict they are so far away from having a working DOM that it is too early to do any of this kind of testing |
| 15:07 | <jgraham> | Maybe I should work out how to build servo |
| 15:08 | <Ms2ger> | I mentioned getting testharness.js to work to jdm and he seemed positive |
| 15:08 | <annevk> | SimonSapin: doesn't seem interoperable |
| 15:09 | <SimonSapin> | chrome just seems to just stop at lone surrogate and drop the rest of the string: data:text/html,<script>document.write('ab\uD800cd')</script> |
| 15:10 | <SimonSapin> | well, worse than that: data:text/html,<script>document.write('ab\uD800cd')</script>ef |
| 15:10 | Ms2ger | wonders how to update his tree again |
| 15:11 | <Domenic_> | annevk: SimonSapin: there's a bit more code point exposure in ES6 than just those methods, e.g. http://www.slideshare.net/domenicdenicola/es6-is-nigh/41 |
| 15:12 | <annevk> | Domenic_: I mentioned the iterator in my email I think |
| 15:12 | <annevk> | Domenic_: it's not in the draft though |
| 15:12 | <annevk> | Domenic_: anyway, it could do the same |
| 15:12 | <Domenic_> | annevk: ah right, sorry missed that |
| 15:13 | <Domenic_> | I believe the ES6 conceptual model was supposed to be 21 bit code points, with "legacy" string[i] and string.charCodeAt(i) exposing 16-bit code units. |
| 15:14 | <annevk> | Yeah, it's pretty clear what they went for, I think it'd be better to align with Unicode's actual data model if possible (which means not exposing surrogates if we don't have to) |
| 15:15 | <Domenic_> | I don't know very much about this so I'm not sure what they're doing wrong, heh. |
| 15:26 | <zewt> | well, if you have UTF-16 as your underlying storage, random access to indexed codepoints is hard, heh |
| 15:27 | <Ms2ger> | If you have anything but utf-32? :) |
| 15:27 | <SimonSapin> | The i in s.codePointAt(i) counts 16 bit units, not code points |
| 15:28 | <zewt> | SimonSapin: sure, replying to "supposed to be 21-bit codepoints" |
| 15:29 | <zewt> | Ms2ger: utf-32 is probably the right storage format |
| 15:29 | <Domenic_> | SimonSapin: I don't believe that's true, I believe it's supposed to count 21-bit code points. |
| 15:29 | <jgraham> | zewt: Arguably that depends on what you think is important |
| 15:30 | <jgraham> | If indexed access isn't important then UTF-32 is just a waste of memory in most cases |
| 15:30 | <jgraham> | Well, unless your system is mainly storing Linear-B I guess |
| 15:30 | <zewt> | indexed access isn't particularly important, as long as you have an API model that works with it ... JS developers are probably too programmed for it |
| 15:31 | <SimonSapin> | Domenic_: from the draft: Let first be the code unit value of the element at index position in the String S. |
| 15:31 | <SimonSapin> | ie. first = S[position] |
| 15:32 | <Domenic_> | SimonSapin: no, indexed positions are code points |
| 15:33 | <Domenic_> | SimonSapin: []s are not, but those are different from the spec term "index position" |
| 15:33 | <jgraham> | Uh |
| 15:33 | <jgraham> | That's one confusing spec then |
| 15:33 | <Domenic_> | SimonSapin: compare codePointAt and charAt (which uses "the code unit at position position") |
| 15:34 | <SimonSapin> | So is this wrong? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/charCodeAt#Example_4.3A_ES_6_codePointAt_shim |
| 15:34 | <zewt> | exposing anything about codepoint indexes on top of utf-16 would be pretty ugly, though you can probably optimize the most common cases to avoid n^2 (forward and backward scanning) |
| 15:35 | <annevk> | Domenic_: where is index position defined? |
| 15:35 | <Domenic_> | annevk: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.8.6 |
| 15:36 | <Domenic_> | there are broken links pointing to 8.4, but that is outdated. (Wasn't keeping references up to date an actual feature of Word? :-S) |
| 15:37 | <annevk> | Domenic_: searching for "index position" doesn't get there... |
| 15:37 | <Domenic_> | annevk: right, but SV is an (indexed) sequence of CVs, which are defined there. |
| 15:38 | <zewt> | (though I guess caching could run into catastrophic performance dropoffs; eg. if only a single position is cached, and a parser is scanning linearly from two different places, performance would mysteriously fall through the floor) |
| 15:39 | <SimonSapin> | I’m confused |
| 15:39 | <annevk> | Domenic_: CV only seems to talk about code unit sequences, not code point sequences |
| 15:39 | <Domenic_> | annevk: I don't think so... e.g. the CV of \u{six digits} is given as a single number |
| 15:40 | <annevk> | Domenic_: no, it says to unwrap it using utf-16 into two code units |
| 15:40 | <annevk> | Domenic_: if it's higher than U+FFFF anyway |
| 15:41 | <Domenic_> | ah yeah, you're right |
| 15:41 | <Domenic_> | hrm |
| 15:41 | <annevk> | Domenic_: the CV stuff is kinda confused |
| 15:41 | <annevk> | Domenic_: it suddenly starts talking about characters now and then rather than empty code unit sequence |
| 15:42 | <Domenic_> | I wonder if I have the intent right though. Notably codePointAt(i) and charAt(i) say very different things about what to do with `i`. |
| 15:43 | <annevk> | maybe :) |
| 15:43 | <annevk> | it'd make codePointAt quite a bit slower |
| 15:44 | <Domenic_> | http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aunicode_supplementary_characters&cache=cache&media=harmony:supplementary_characters_for_ecmascript.pdf |
| 15:45 | <annevk> | The way TC39 operates reminds me of OMA back in 2005 when I started at Opera... |
| 15:45 | <annevk> | It's 2013, PDFs you have to download to read a proposal? Come on... |
| 15:46 | <Domenic_> | my hatred of PDFs has decreased significantly since pdfjs got into Firefox stable :) |
| 15:46 | <zewt> | pdf is still terrible, even in chrome's viewer |
| 15:47 | <zewt> | spent like a minute copying a couple pages of a list the other day because it wouldn't let me extend a selection (in osx) |
| 15:47 | <annevk> | Domenic_: codePointAt is implemented in terms of charCodeAt there |
| 15:47 | <annevk> | Domenic_: passing index directly to charCodeAt that is to find the first surrogate (if any) |
| 15:48 | <annevk> | Domenic_: sure, but this is not served in a way that opens in pdf.js automatically |
| 15:48 | <Domenic_> | annevk: yeah, looks like I was just wrong, darn. codePointAt seems not very useful. |
| 15:48 | <Domenic_> | annevk: interesting, it opened in pdfjs automatically for me. |
| 15:48 | <annevk> | Domenic_: the language differences are kinda broken though |
| 15:49 | <Domenic_> | annevk: agreed, if they are supposed to be using the same indexing paradigm, the current spec does not make that clear. |
| 15:50 | <zewt> | could be maybe sort-of useful if it returned -1 for high surrogates, so you could say for(i=0;i<n;++i) { codepoint = s.codePointAt(n); if(codepoint == -1) continue; /* skip */ log(codepoint); } |
| 15:50 | <annevk> | It might be better to just have the iterator and maybe String.fromUnicode(...) or some such |
| 15:50 | <annevk> | Does String.from() exist? |
| 15:50 | <Domenic_> | no |
| 15:50 | <zewt> | so you'd just skip over high surrogates (that you already dealt with at n-1) |
| 15:50 | <annevk> | Why is not called String.from()? |
| 15:51 | <zewt> | (er, probably flip high/low) |
| 15:51 | <Hixie_> | i use http://people.mozilla.org/~jorendorff/es6-draft.html as the js spec, but i don't know if there's proposals in html format |
| 15:51 | <annevk> | Hixie_: same and there's the wiki pages... |
| 15:51 | <Domenic_> | annevk: what would you want as String.from()? Your proposed String.fromUnicode()? |
| 15:51 | <annevk> | Hixie_: last meeting there was talk about putting it all in GH but inertia I guess |
| 15:52 | <annevk> | Domenic_: yeah, sequence of 21-bit code points, but with surrogates banned (so, Unicode scalar values) |
| 15:52 | <Ms2ger> | And you're not allowed to look at the wiki, because you have to smell that they're out of date, why are you even looking there, stupid |
| 15:53 | <Domenic_> | annevk: like... String.from(65, 1234, 23341)? |
| 15:53 | <annevk> | They could use some project management indeed. Outward communication is really poor. You kinda have to attend meetings to understand what's going on and how stuff works, which I'm doing atm... |
| 15:53 | <annevk> | Domenic_: yeah |
| 15:53 | <annevk> | Domenic_: just a better String.fromCharCode() |
| 15:54 | <Domenic_> | That's called String.fromCodePoint() now :) |
| 15:54 | <annevk> | Domenic_: I know, but that one outputs lone surrogates |
| 15:54 | <annevk> | Domenic_: and I thought we preferred shorter names? |
| 15:54 | <Ms2ger> | Well, that or put everything that's being implemented into the spec |
| 15:55 | <annevk> | Ms2ger: they are in on that plan now I think |
| 15:55 | <Domenic_> | What other plan would there be O_o |
| 15:56 | <Ms2ger> | But maybe also not have the spec in a word document that's only released once in a blue moon |
| 15:56 | <annevk> | Ms2ger: so if something is missing we could file a bug... although BE does still value underdefining features |
| 15:57 | <annevk> | Domenic_: well they refused to document a bunch of stuff until we made it clear via e.g. http://javascript.spec.whatwg.org/ that it's actually implemented |
| 15:57 | <Domenic_> | annevk: ah right that stuff. |
| 15:57 | <annevk> | Domenic_: I'm not sure if '<!--'-style comments are now? |
| 15:57 | <Domenic_> | annevk: there's a TODO for those in annex B I believe |
| 15:57 | <annevk> | they're gonna patch the core grammar in an annex? maha |
| 15:58 | <Domenic_> | ideally Node.js would not need <!-- comments |
| 15:58 | <annevk> | I don't really see what's ideal about having an additional code path in your ES engine about something so minor |
| 15:58 | <Ms2ger> | annevk, sounds like css21 |
| 15:59 | <annevk> | especially if it means more transition cost when converting JS files |
| 16:00 | <jgraham> | Domenic_: Doesn't node.js get wahtever V8 provides? |
| 16:01 | <jgraham> | Which I assume includes <!-- |
| 16:01 | <Domenic_> | jgraham: yeah. you can do HTML comments in Node at the moment. |
| 16:01 | <Ms2ger> | Well |
| 16:01 | <Ms2ger> | Ideally node doesn't use JS ;) |
| 16:10 | <gsnedders> | jgraham, Ms2ger: I vetted them for release, not so much following the spec. And given I know they never matched the spec… |
| 16:10 | <annevk> | hah, matjas ^^ |
| 16:11 | <matjas> | :) |
| 16:12 | <matjas> | still not as bad as php recognizing <script> |
| 16:23 | <annevk> | I hope Norbert has rationale for the surrogate thing because it sure seems like Brendan didn't think of it |
| 16:25 | <matjas> | Allen mentioned use cases like strings containing “binary data” before |
| 16:26 | <matjas> | at one point he wanted to allow up to 8 digits for the new `\u{xx}` escapes for that reason |
| 16:26 | <matjas> | maybe this surrogates thing is similar? |
| 16:27 | <jgraham> | String containing binary data? |
| 16:27 | <matjas> | well, you know |
| 16:27 | <jgraham> | Those aren't strings… |
| 16:27 | <jgraham> | Having a single data type for strings and random binary data is an oft-repeated mistake in language design |
| 16:27 | <matjas> | e.g. `foo © bar` becomes `\x66\x6F\x6F\x20\xC2\xA9\x20\x62\x61\x72` if you represent it as UTF-8 |
| 16:28 | <matjas> | if you dont wanna use an array of bytes for some reason, i guess |
| 16:28 | <annevk> | matjas: I'd like to see why |
| 16:28 | <matjas> | yeah, i was glad when they decided only to allow 6 digits in \u{xx} |
| 16:28 | <annevk> | in any event, climbing time |
| 16:30 | <matjas> | https://mail.mozilla.org/pipermail/es-discuss/2012-March/021919.html: “Exclude 0xD800-0xDFFF? No.” |
| 17:01 | <TabAtkins> | Why would you *possibly* want 8 character in \u? |
| 17:02 | <TabAtkins> | Unicode is only 21 bits wide, which is 6 hex chars. utf-8 is 4 bytes wide, or 8 hex chars, but \u doesn't specify utf-8, it specifies unicode code points (or scalars, whatever). |
| 17:03 | <TabAtkins> | I mean, maybe plan for the future and make sure the syntax can be expanded up to 8, just in case we ever expand unicode up to 32 bits, but that's it. (And the \u{} syntax is okay with that, so we're good.) |
| 17:05 | <gsnedders> | A lot of languages use \U00000000, because they go back to UCS-4 days. |
| 17:05 | <jgraham> | TabAtkins: YOu might, if you wanted the string type to be used for both strings and arrays of binary data. Then \u{} notation would provide a convenient way of specifying 32bits of data at a time |
| 17:06 | <jgraham> | (you would be wrong to want that, but lots of languages have historically worked like that so you would be in good company) |
| 17:06 | <TabAtkins> | jgraham: But... it *doesn't* specify 32 bits at a time. Unless you have some magic switch in your encoder that says that codepoints greater than u+10ffff get encoded as raw 32-bit ints. |
| 17:07 | <jgraham> | Well you could have that |
| 17:07 | <jgraham> | Although I guess it still doesn't really work |
| 17:07 | <jgraham> | So pass? |
| 17:07 | <TabAtkins> | Right. |
| 17:08 | <TabAtkins> | It sounds like the sort of thing you'd do only if you were certain that it would get encoded in ucs-4. |
| 18:06 | <dglazkov> | good morning, Whatwg! |
| 18:17 | <TabAtkins> | marcosc: There an agenda posted for the ricg meetup next week? |
| 18:22 | <Domenic_> | So there's no event for <details> opening and closing. My guess is you're supposed to use "click" on the <summary>? |
| 18:26 | <TabAtkins> | Hixie_ was just saying a few weeks ago that he was surprised nobody had ever requested a <details> event. Yeah, for now you just use "click" on <summary>. |
| 18:28 | <Domenic_> | thanks! converting my boss to using semantic HTML :P |
| 18:31 | <Hixie_> | Domenic_: if you have an opinion on whether we should have onopen/onclose or just one event, comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=22942 |
| 18:32 | <Domenic_> | Hixie_: hmm. I don't think I have a strong enough opinion. My opinion is more along the lines of "damn browser vendors, hurry up and implement `Object.observe` already." |
| 18:32 | <Hixie_> | oh well if you just want that you can use a mutation observer on the open="" attribute |
| 18:33 | <Domenic_> | i get so confused on these boolean attributes, whether they work or not. i guess it's just [checked] vs. defaultChecked vs. checked that threw me off but the confusion persists. |
| 18:42 | <marcosc> | TabAtkins: only an initial one - still waiting for confirmation from speakers. https://github.com/ResponsiveImagesCG/paris-meetup#proposed-agenda |
| 18:43 | <TabAtkins> | marcosc: Good enough for me, I just had my boss request an agenda. |
| 18:58 | <TabAtkins> | Hixie_: How should I hook into the Structured Clone algorithm to define a new type that can be cloned? |
| 18:59 | <TabAtkins> | I need to define that FontFace objects can be cloned to Workers (creating a fresh FontFace with the same information on the other end). |
| 19:04 | <Ms2ger> | See the typed array spec |
| 19:06 | <Hixie_> | TabAtkins: e-mail me and i'll add it, probably |
| 19:08 | <Hixie_> | looking for bike shed colours in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22942 (event name for <details>) |
| 19:32 | <Domenic_> | What was the point of the wheel event (as opposed to mousewheel)? |
| 19:33 | <Ms2ger> | D3E not wanting to figure out what legacy browsers did, and instead inventing something else? |
| 19:34 | <Domenic_> | yeah ok that's what it seemed like |
| 19:34 | <Domenic_> | then FF had to go and implement wheel but not mousewheel :-S |
| 19:34 | <Ms2ger> | Disclaimer: I wasn't around at the time |
| 19:42 | <annevk> | TabAtkins: your email doesn't make sense |
| 19:42 | <annevk> | TabAtkins: to elaborate, encoder != decoder, and the decoder already does the right thing |
| 19:48 | <smaug____> | Domenic_: all the browser which implement mousewheel implement it in very different ways |
| 19:48 | <smaug____> | and it didn't have the features I wanted :) |
| 19:49 | <smaug____> | hmm, who knows about hgroup? |
| 19:49 | <smaug____> | why it is so controversial ? |
| 19:49 | smaug____ | doesn't want to read html wg mailing list |
| 19:52 | <jgraham> | Because people like arguning over silly things |
| 19:52 | <jgraham> | *arguing |
| 19:54 | <darobin> | is hgroup controversial? |
| 19:54 | <darobin> | I thought some people thought one thing, others thought another, but they didn't bother talking about it anymore |
| 19:54 | <Ms2ger> | HTMLWG forked |
| 19:54 | <jgraham> | I can't actually remember what the controversy was about now, but I am pretty sure it was something that will become irrelevant once the feature is used |
| 19:54 | <Ms2ger> | Apart from that, no |
| 19:55 | <jgraham> | (and will clearly be irrelevant if the feature is never used) |
| 19:55 | <Ms2ger> | I think the argument was that you were supposed to break the outline |
| 19:55 | <darobin> | I reckon either the feature gets used, and the debate becomes irrelevant, or it doesn't get used, and the debate becomes irrelevant |
| 19:55 | <darobin> | but then again the outline is broken :) |
| 19:56 | <darobin> | pulling wheel out of the 927 trap might be more useful |
| 19:56 | <smaug____> | darobin: well, we have a bug which has been reopened and closed many times depending on who is looking at it... the ones who care about W3C HTMLx specs close it, and the ones who care about WhatWG HTML spec reopen it |
| 19:57 | <darobin> | smaug____: how can one open and close a bug on this? even the forked HTML WG version has it as a legacy element so browser can safely just support it |
| 19:58 | <smaug____> | can or must? |
| 19:58 | <darobin> | I don't recall |
| 19:58 | <darobin> | that's how much I care :) |
| 19:58 | <smaug____> | :) |
| 19:58 | <smaug____> | I should not care either |
| 19:59 | <jgraham> | The element doesn't *do* anything in a typical browser |
| 19:59 | <annevk> | matjas: thanks for the help! |
| 19:59 | <Ms2ger> | Well, the bug is about the mapping to a11y apis |
| 19:59 | <darobin> | smaug____: in the parser at least it's clearly must |
| 19:59 | <jgraham> | Oh right |
| 19:59 | <darobin> | oh that |
| 19:59 | <jgraham> | Well that is the one place it does make a difference |
| 20:00 | <annevk> | matjas: ooh, sad email is sad. |
| 20:00 | <darobin> | jgraham: it actually makes very minor differences in a few other places |
| 20:00 | <darobin> | e.g. it closes a <p> |
| 20:01 | <darobin> | it's also in the UA style sheet with some non-default rules |
| 20:01 | <darobin> | but yeah, no big deal |
| 20:02 | <darobin> | interestingly, in the parsing section it's marked as having "special parsing rules", but then it proceeds to only appear under the comment "the normal ones" :) |
| 20:02 | <darobin> | anyway |
| 20:03 | darobin | trots off to read stuff made of paper |
| 22:04 | <annevk> | Domenic_: I wondered whether it might be better to give you promises.spec.whatwg.org and note in dom.spec.whatwg.org the spec has moved |
| 22:04 | <annevk> | Domenic_: it seems you're doing a fine job of maintaining it and there's not really any good reason I can see for me to sit in the middle |
| 22:37 | <Hixie_> | annevk: yt? |
| 22:39 | <Hixie_> | annevk: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jun/thread.html#msg207 http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/thread.html#msg1 looks like a thread for your spec, but i don't see a response from you -- did it slip your radar or is it something you want me to deal with? |
| 22:44 | <annevk> | Hixie_: we wontfixed that plan before that thread started, not sure if someone referenced the bug |
| 22:45 | <Hixie_> | could you update the people on the thread and respond to any novel points there or point people to where the points are already answered? |
| 22:45 | <Hixie_> | or i can, if you know what bug it was |
| 22:45 | <annevk> | Hixie_: yeah I guess I can, not now though |
| 22:46 | <Hixie_> | k |
| 23:25 | <TabAtkins> | What's an idiomatic way to write a "safe" version of a method for a spec to call (not overridable)? Define some operation abstractly, then for the actual method, just say "do foo"? |
| 23:26 | <Hixie_> | that's a sound way to do it |
| 23:27 | <Hixie_> | but i basically rely on invokations of methods from prose implicitly not going through idl |
| 23:27 | <Hixie_> | so it's always gonna call the "real" one |
| 23:27 | <Hixie_> | imho |
| 23:28 | <TabAtkins> | Yeah, I've depended on that before too. It seems silly to *not* depend on it, but shrug. |
| 23:34 | <TabAtkins> | heycam: The [MapClass] section says that if you're manually implementing the Map methods, you *must* match the method signatures given there. CSSFontFeatureValuesMap doesn't do this, though: http://dev.w3.org/csswg/css-fonts/#om-fontfeaturevalues |
| 23:34 | <TabAtkins> | Its value type is sequence<unsigned long>, but its set() method accepts (unsigned long or sequence<unsigned long>), with prose converting the former into the latter, and I think that's reasonable. |
| 23:35 | <TabAtkins> | heycam: Also, I'm now using SetClass, just by extrapolating from MapClass. |
| 23:36 | <heycam> | yeah, that's probably ok for the type to be a superset there. I'll make a note to allow that. |
| 23:36 | <heycam> | TabAtkins, where are you using SetClass btw? |
| 23:37 | <TabAtkins> | Font Load Events. I'll have a version uploaded in a moment. |
| 23:37 | <heycam> | ok |
| 23:45 | <TabAtkins> | heycam: Okay, it's still under heavy editing churn at the moment, but the SetClass-relevant parts are in now: http://dev.w3.org/csswg/css-font-load-events/#FontFaceSet-interface |
| 23:46 | <heycam> | TabAtkins, I don't think you'd be able to inherit from EventTarget if you make it a SetClass |
| 23:46 | <TabAtkins> | EventTarget is dumb. |
| 23:46 | <TabAtkins> | It shouldn't be a superclass. :/ |
| 23:47 | <Hixie_> | i tried to fight that |
| 23:47 | <Hixie_> | but lost. |
| 23:47 | <Hixie_> | people were like, "oh, you'll always be able to inherit from it" |
| 23:47 | <Hixie_> | TabAtkins: (you can cheat, just say "MyInterface implements EventTarget"... :-) ) |
| 23:48 | <TabAtkins> | Heh, that works. |
| 23:48 | <TabAtkins> | Also: those people were dumb. No. Bad. |