| 04:07 | <Yuhong> | https://news.ycombinator.com/item?id=4629698 |
| 08:07 | <annevk> | zewt: you around? |
| 08:42 | <sedovsek> | annevk: There are some photos of you I took at Fronteers 2012, http://www.flickr.com/photos/seddy/sets/72157631731160840/ |
| 08:43 | <annevk> | sedovsek: heh, thanks |
| 08:44 | <annevk> | must be a pretty nice camera |
| 08:46 | <sedovsek> | This is like complimenting a cook with "you must have some nice cans and pots", but yea… i guess it is. :P |
| 08:53 | <annevk> | sedovsek: :-) |
| 09:08 | <hsivonen> | huh? for .ch, you'd guess windows-1252. what's hard about that? |
| 09:09 | <hsivonen> | there is no .zh TLD, is there? |
| 09:18 | <hsivonen> | I think I'm interested in developing a Gecko feature that with the flip of a boolean about:config pref would replace guessing based on the Firefox localization with guessing based on the content TLD |
| 09:18 | <hsivonen> | it would be a hard fight to change the default though |
| 09:30 | <annevk> | apparently WebKit has almost no sniffing algorithm btw and is not planning on changing that |
| 09:30 | <annevk> | that's why I kinda gave up on defining encoding sniffing for now |
| 09:31 | <annevk> | ap argued that what Gecko had was not needed |
| 09:31 | <annevk> | (there's no .zh) |
| 09:33 | <annevk> | just found out they're gonna delete even more ccTLDs |
| 09:33 | <annevk> | ".an .su .tp" are next |
| 09:35 | <j_wright> | makes sense |
| 09:36 | <annevk> | not really http://www.w3.org/Provider/Style/URI.html |
| 09:44 | <annevk> | .nl is one of the largest ccTLD; just imagine if a couple of decades from now we're no longer independent but part of the EU, would kinda suck imo if all my links broke |
| 09:52 | <hsivonen> | .ax is not independent but they have a "country" TLD |
| 10:01 | <hsivonen> | I'm more worried about US agencies seizing domain under generic TLDs than about European TLDs going away because of the EU turning into a federal state |
| 10:24 | <hsivonen> | so if Firefox, Chrome and Opera support SPDY, what good can come out of the IETF making something incompatible? |
| 10:48 | <annevk> | IETF crowning it as "theirs"? |
| 10:57 | <hsivonen> | how likeöy is it that IETF would just crown SPDY? the IETF has stakeholders whose products SPDY treats as adversaries |
| 10:57 | <hsivonen> | i.e. products that are in the intercept business |
| 10:57 | <hsivonen> | s/likeöy/likely/ |
| 11:14 | <Velmont> | There's also the upgrade mechanism if it will get used. -- Many features has not been implemented either, so when Opera did implementation it didn't implement those not seen on the general web. |
| 11:19 | <annevk> | hsivonen: I guess we'll see; I'm not too interested in getting involved though, WebSocket was hell |
| 13:26 | <jgraham> | bmo produces a *huge* amount of mail per bug |
| 13:28 | <annevk> | email preferences |
| 13:29 | <jgraham> | Yeah, but there's no email pref that can distinguish between interesting comments and we-use-the-bug-tracker-as-a-code-review-tool comments |
| 16:13 | <annevk> | zewt: we can have iteration later |
| 16:13 | <zewt> | annevk: i just mean iteration can't follow Map since it doesn't do it (so either we wait until they do, or do something that probably won't match) |
| 16:14 | <zewt> | just a minor point |
| 16:14 | <annevk> | as for following Map, I guess I meant the ability to use it directly in some sense |
| 16:14 | <annevk> | obviously we can make our own using setter/getter/creator/deleter |
| 16:14 | <zewt> | i figured it was just expose the same interface |
| 16:15 | <annevk> | I guess "has" follows from indexed names |
| 16:15 | <annevk> | does dataset have has? |
| 16:16 | <zewt> | you mean 'x' in elem.dataset? |
| 16:16 | <annevk> | right |
| 16:17 | <zewt> | (i mean, it has that, not sure if you're asking something else) |
| 16:19 | <zewt> | fwiw i'm not dead set against a functional api or anything and boris might be right; i just wanted to examine it more closely since the arguments from the irc log didn't seem convincing |
| 16:19 | <zewt> | (uh, not "functional api", but you know what i mean) |
| 16:19 | <zewt> | on the other hand the prototype-less-sub-interface thing may also be fine |
| 16:24 | <zewt> | i guess url.query.values.foo is sort of ugly, though url.query.get("foo") isn't actually less typing or anything |
| 16:25 | <jgraham> | zewt: sydfunctional api? :p |
| 16:25 | <jgraham> | Argh |
| 16:25 | <jgraham> | *dysfunctional |
| 16:25 | <zewt> | dyslexics untie |
| 16:26 | <jgraham> | Or sydlexics, as I call them |
| 16:28 | <annevk> | url.query["foo"] would be less typing |
| 16:28 | <annevk> | or url.query.foo |
| 16:28 | <annevk> | it would allow for things like url.query.delete("x", "x") though (only delete x where its value is x) |
| 16:28 | <zewt> | but then you wouldn't want getAll on url.query |
| 16:29 | <annevk> | would not* |
| 16:29 | <annevk> | right, getter would always return a list |
| 16:29 | <zewt> | don't think i like that |
| 16:29 | <zewt> | because you end up having to write things like if(url.query.foo && url.query.foo[0] == "bar") all the time |
| 16:29 | <annevk> | hmm yeah |
| 16:30 | <annevk> | I guess maybe method-based approach is not too bad |
| 16:30 | <zewt> | i mean, one-item-per-key is by far the common case, even though we do want to handle the multiple-items case when needed |
| 16:30 | <annevk> | what happens if we have both methods and named getters and such? |
| 16:30 | <zewt> | well if you have url.query.getAll() and the query is ?getAll=1 ... |
| 16:30 | <annevk> | localStorage has that |
| 16:31 | <annevk> | and I guess TC39 doesn't like it, but on the other hand it already exists |
| 16:31 | <zewt> | well, with localStorage you're usually constructing what you're storing around the api, so you just don't store things like "toString" |
| 16:31 | <zewt> | a query api might be parsing any arbitrary url |
| 16:32 | <annevk> | you might want to store something like "length" though |
| 16:32 | <annevk> | I think having the explicit methods is probably better |
| 16:32 | <zewt> | i mean you'd just call it something else, or wrap it in a sub-object |
| 16:32 | <annevk> | also allows for some things http://medialize.github.com/URI.js/ offers |
| 16:32 | <zewt> | you usually don't take arbitrary external data and dump it straight into localStorage |
| 16:33 | <zewt> | am I the only person that cringes at this "how do you like" silliness heh |
| 16:34 | <zewt> | we definitely will want to support operations outside of simple getter/setter/iterate/contains, and i think that just either means 1: methods or 2: a sub-object for the subset of dictionary-like operations |
| 16:35 | <annevk> | if those are the choices I'm going with 1 |
| 16:36 | <annevk> | which means nothing much has to change, teehee |
| 16:38 | <zewt> | the first thing i'd probably do is monkey patch in values :P |
| 16:39 | <zewt> | (all of my query-handling code just converts to an object anyway) |
| 16:40 | <zewt> | bleh, one api we really need to unscrew: cookies |
| 16:40 | <zewt> | document.cookie has got to be the single worst (non-dead) API on the whole platform |
| 16:42 | <zewt> | hey look some class action lawyer got rich as hell and i get $.40 |
| 16:42 | <zewt> | Hachette, Harper Collins, and Simon & Schuster have settled an antitrust lawsuit about e-book prices. |
| 16:42 | <zewt> | the Attorneys General estimate that it will range from $0.30 to $1.32 for every eligible Kindle book that you purchased between April 2010 and May 2012. |
| 16:43 | <zewt> | didn't actually mean that in this channel, but sure why not |
| 16:47 | <jgraham> | FWIW I think a method based API is the only sane thing in js |
| 16:47 | <annevk> | document.cookie was supposed to be obsoleted by localStorage |
| 16:48 | <jgraham> | Even in better languages, handling one vs many nicely is difficult |
| 16:48 | <annevk> | of course localStorage made it somewhat worse, in hindsight |
| 16:48 | <zewt> | localStorage and cookies serve completely different use cases |
| 16:48 | <annevk> | meh |
| 16:49 | <zewt> | i mean, yeah, before localStorage the "store data for client-side access" use case was done with cookies, which was bad, but the "sending session info to the server" set of cases is still mostly cookies |
| 16:49 | <jgraham> | The web has an exciting selection of storage APIs |
| 16:49 | <jgraham> | All broken |
| 16:50 | <zewt> | and the next time I end up with a mystery duplicate cookie that I can't delete because I don't know its path and document.cookie doesn't tell me I'm going to something something |
| 16:54 | <annevk> | so on Storage Hixie_ is using "setter creator" on one line but on the dataset one he's not |
| 16:59 | <zewt> | what's the difference? |
| 16:59 | <zewt> | between "setter" and "creator" |
| 17:00 | <zewt> | i guess in javascript there isn't one |
| 17:01 | <zewt> | seems like there inherently can't be a new one with things like dataset, since you don't know in advance of running the algorithm whether the item exists or not |
| 17:07 | <annevk> | well you do I think per Web IDL |
| 17:08 | <annevk> | since it wouldn't be an indexed name |
| 17:09 | <zewt> | webidl itself doesn't keep track of what names are actually set, right? (since that's algorithmic for things like this) |
| 17:09 | <zewt> | (it has no idea that the set of names in classList changes because you messed with className) |
| 17:10 | <zewt> | (array, rather, same difference) |
| 17:11 | <zewt> | (guess I should stick to dataset for examples and not mix up the discussion heh) |
| 17:12 | <zewt> | so, it doesn't know that setAttribute might change the names you can retrieve with dataset |
| 17:14 | <annevk> | Web IDL has these concept of supported property names and such |
| 17:14 | <annevk> | concepts* |
| 17:14 | <annevk> | and they are defined for DOMStringMap too |
| 17:15 | <annevk> | but it's indeed algorithmic there, but it still exists for stuff like dataset.x |
| 17:15 | <annevk> | anyway, I cannot really think of a case where you'd want setter/creator to be different |
| 17:16 | <zewt> | well, the end behavior might be different, but still i'd put that all within a single algorithm, not making webidl part of that |
| 17:17 | <zewt> | eg. setting a query key should probably be a bit different depending on whether the key already exists (replace it in the same place) or not (append it), but webidl doesn't need to be involved in that |
| 18:09 | <zewt> | annevk: in encoding, given a DOMString with unpaired surrogates, "preprocessed" to unicode characters with http://dev.w3.org/2006/webapi/WebIDL/#dfn-obtain-unicode (giving having U+FFFDs), is the intended result that you get an encoder error with most encodings, but not with UTF-8 (which passes it through)? |
| 18:09 | <zewt> | giving having giving |
| 18:11 | <zewt> | on one hand it makes sense (unicode encodings have the replacement character, but most other encodings don't have any equivalent), but it might be unexpected for algorithms: what's really a UTF-16 error causing different results (encoder error or no encoder error) depending on the output |
| 18:12 | <zewt> | (just something that came to mind while reminding myself what https://www.w3.org/Bugs/Public/show_bug.cgi?id=16219 was about) |
| 18:21 | <zewt> | guess it doesn't really matter, since it's not like it's exposing code paths that otherwise wouldn't be |
| 18:22 | <annevk> | utf-16 would work too |
| 18:22 | <zewt> | yeah, any unicode encoding |
| 18:23 | <annevk> | so WebKit always uses &#{digits}; for the non-Unicode encodings |
| 18:23 | <annevk> | some browsers sometimes emit ? depending on the context |
| 18:24 | <annevk> | Gecko emits the utf-8 byte sequence... |
| 18:24 | <zewt> | well, different users of the algorithms will want to do different things in those cases, i imagine |
| 18:24 | <annevk> | (also depends on the context) |
| 18:24 | <annevk> | if we leave the encoding API alone there's only two users |
| 18:24 | <annevk> | <form> and URL |
| 18:25 | <annevk> | <form> everyone does &#...; |
| 18:25 | <annevk> | URL is &#...; / ? / utf-8 byte sequence |
| 18:25 | <zewt> | encoding api wants to be able to have nonfatal encoding, right? |
| 18:25 | <annevk> | iirc |
| 18:25 | <annevk> | I kinda think we should try to go with &#...; and fatal |
| 18:25 | <zewt> | don't remember offhand whether that api currently allows non-unicode encoding or if they're trying to limit that to unicode (that's flipped back and forth a couple times) |
| 18:25 | <annevk> | given that this is legacy |
| 18:26 | <annevk> | and then we can keep the behavior in the Encoding spec |
| 18:26 | <annevk> | (well we could do that anyway, but you know) |
| 18:27 | <zewt> | well, once it supports Ӓ (meaning "encoder error" is being passed the codepoint), adding a parameter to say "use ?" later would be trivial |
| 18:27 | <annevk> | The main problem is that people are not happy with aligning on legacy stuff |
| 18:27 | <annevk> | zewt: right |
| 18:29 | <zewt> | If the internal fatal flag of the decoder object is set, then a decoder error causes an DOMException of type EncodingError to be thrown rather than emitting a fallback code point. |
| 18:29 | <annevk> | in other news, URLQuery.delete cannot work, it's a reserved word |
| 18:29 | <annevk> | has to be remove like I named it earlier on |
| 18:29 | <zewt> | that's not really good, sort of a monkey-patch |
| 18:29 | <zewt> | annevk: i thought about that but when i tested "delete" as a method name it seemed to work |
| 18:30 | <zewt> | though it's probably good to avoid anyway, if only to not make syntax highlighting weird, heh |
| 18:30 | <annevk> | what's wrong with the exception stuff? |
| 18:31 | <zewt> | it's hard to follow algorithms when one spec is saying "run this other spec's algorithm, except when this sub-algorithm is run do this other thing" |
| 18:31 | <jgraham> | delete can work as a method name |
| 18:31 | <annevk> | not really sure what would be a better way |
| 18:31 | <jgraham> | Although I think it might not be ideal style |
| 18:32 | <zewt> | have an input flag that means "errors are fatal" and define the behavior branch within the encoding spec |
| 18:32 | <jgraham> | (reserved words don't apply to propery names) |
| 18:35 | <annevk> | zewt: cannot define behavior for e.g. XML parsers within the encoding spec |
| 18:35 | <annevk> | zewt: I guess it could be a "run these steps defined in some applicable spec" kinda thing |
| 18:36 | <annevk> | not sure I care too much about that right now |
| 18:39 | <annevk> | arv argued for delete |
| 18:39 | <annevk> | but most other APIs use remove so I guess I'll go with remove |
| 18:39 | <zewt> | i don't really care either way, but fwiw apparently Map uses delete |
| 18:40 | <zewt> | (at least, at the moment) |
| 18:49 | <SamB_MacG5> | grr... validator.nu doesn't seem to build with Java 1.5 :-( |
| 18:50 | <zewt> | java: "heh" |
| 18:51 | <annevk> | zewt: sure, and in JavaScript you'd do delete x[y] |
| 18:52 | <annevk> | not x.delete(y) |
| 18:52 | <annevk> | oh well, time for other stuff |
| 18:52 | <zewt> | annevk: from https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Map it looks like x.delete(y) |
| 18:52 | <zewt> | doesn't look like it uses any native syntax at all |
| 18:53 | <annevk> | whoa weird |
| 18:53 | <annevk> | well then lets keep delete |
| 18:53 | annevk | goes back to watching Homeland |
| 18:54 | <zewt> | (also no idea if that's up to date or how close to stable the spec is, this is about the first time i've even looked at Map) |
| 21:14 | <annevk> | oh TabAtkins, I was faster than you, but you gave a better answer |
| 21:15 | <annevk> | also, felt good to rant a little on URLs |
| 21:15 | <zewt> | but this is stackoverflow, only the first answer is right |
| 21:15 | <annevk> | then Opera wins |
| 21:15 | <zewt> | heh, one reason i got tired of that site, it encourages fast answers instead of good ones |
| 21:31 | <teear> | 123 |
| 21:44 | <annevk> | heh https://www.w3.org/Bugs/Public/show_bug.cgi?id=19528 |
| 21:51 | <zewt> | <adobe> i hope you don't mind if we try to block fixing problems by filing bugs and demanding multiple in-person meetings |
| 21:52 | <annevk> | lets not attribute this to Adobe |
| 21:53 | <zewt> | he's posting from @adobe, so that's what I'm inclined to do |
| 21:55 | <zewt> | if he doesn't mean what he says to be attributed to adobe, and to have the weight (whatever that may actually be) of adobe's w3c membership behind it, he should be posting from a personal address (at least re: the webapps post) |
| 21:55 | <annevk> | that seems way silly |
| 21:55 | <annevk> | company can have lots of opinions |
| 21:56 | <annevk> | in any event, retrofitting how URLs work into how the IETF specs think URLs work seems like a rather uninteresting task |
| 21:57 | <zewt> | it seems like trying to do anything with the IETF is a rather uninteresting task :) |
| 21:58 | <zewt> | (and not obviously a useful one) |
| 22:49 | <Benvie> | the collection spec is up to date |
| 22:49 | <Benvie> | and it's already implemented in V8 and Spidermonkey (for a while) |
| 22:49 | <Benvie> | unlikely to change much at this point |
| 23:12 | <annevk> | https://twitter.com/algermissen/status/257229931338137600 is why you don't go to the IETF |
| 23:13 | <annevk> | even though they could know from stuff like curl that their specs are broken, they still think the problem is with the implementations |
| 23:13 | <annevk> | bizarro world |
| 23:16 | <annevk> | party time |
| 23:18 | <SamB_MacG5> | zewt: just because something is an individuals professional opinion doesn't mean they want to claim that the entire company would agree with them ... |
| 23:30 | <zewt> | SamB_MacG5: and i didn't say anything like that |