| 04:21 | <heycam> | TIL: <p><div></div></p> is actually <p></p><div></div> |
| 04:21 | <heycam> | (should have known) |
| 07:49 | <MikeSmith> | "The value attribute, if specified, must have a value that contains no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters." |
| 07:50 | <MikeSmith> | for input type=text and type=search |
| 07:50 | <MikeSmith> | http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#text-(type=text)-state-and-search-state-(type=search) |
| 07:50 | <MikeSmith> | does that mean the value can be empty? |
| 09:40 | <annevk> | MikeSmith: yeah |
| 09:40 | <annevk> | MikeSmith: only when it's required="" it must be non-empty |
| 10:00 | <annevk> | matjas: you sure it works in Chrome for url.spec.whatwg.org and that it's not caching? |
| 10:00 | <annevk> | matjas: because if it does it's very weird the JS one does not work |
| 10:01 | <annevk> | matjas: in any event, the modifications I made were relative to the JS original logo so I'm not sure how that would have an effect on favicon use, does the original work as favicon? |
| 10:01 | <annevk> | context: https://github.com/voodootikigod/logo.js/issues/32 |
| 10:07 | <annevk> | I wonder how the GitHub language algorithm works... https://github.com/whatwg/quirks is 100% Racket?! I guess it doesn't work |
| 10:15 | <annevk> | http://www.unicode.org/mail-arch/unicode-ml/y2011-m07/0036.html |
| 10:16 | <annevk> | http://www.unicode.org/mail-arch/unicode-ml/y2011-m07/0057.html |
| 11:57 | <MikeSmith> | yay we got a code contribution for the validator that provides a "Show outline" feature |
| 11:57 | <MikeSmith> | and that conforms to the outline algorithm, as far as I can see |
| 12:47 | <Davstern15> | Can you somehow set the amount of anti-aliasing for text drawn in a Canvas? Like you can in Flash? |
| 12:49 | <MikeSmith> | Davstern15: no |
| 13:18 | <MikeSmith> | oh |
| 13:18 | <MikeSmith> | Davstern15: see recent discussion at http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/thread.html#msg124 |
| 13:52 | <Davstern15> | MikeSmith: Reading. |
| 13:53 | <Davstern15> | Or at least I thought I was reading it... |
| 13:53 | <Davstern15> | Reading, but am confused by the bizarre format it's in. |
| 14:01 | <MikeSmith> | Davstern15: eh? |
| 14:06 | <Davstern15> | MikeSmith: The weird threaded stuff. |
| 14:07 | <MikeSmith> | I don't understand what's weird about it man |
| 14:07 | <Davstern15> | I always found it weird. Unnavigitable. |
| 14:07 | <Davstern15> | I like the term "enable-able". |
| 14:11 | <Davstern15> | MikeSmith: I don't understand why people are opposed to letting me change how the text is displayed. |
| 14:11 | <Davstern15> | I want blurry AA sometimes. |
| 14:12 | <Davstern15> | I want sharp text sometimes. |
| 14:12 | <Davstern15> | I actually love the way text looks in Flash. |
| 15:38 | <zewt> | most font renderers in browsers probably don't have anything like that, so you're not asking for a simple feature |
| 16:27 | <GPHemsley> | annevk: Is Tcl |
| 16:28 | <GPHemsley> | annevk: mimesniff is Tcl |
| 16:35 | GPHemsley | wonders why so many people are now requesting wiki accounts, and why they're not using them. |
| 16:43 | <MikeSmith> | GPHemsley: spammers maybe? |
| 16:43 | <GPHemsley> | MikeSmith: If so, then I'm glad I left the autoconfirmed user restrictions in place. |
| 16:44 | <GPHemsley> | There was one request to day where the guy wants one username for himself and another for his company |
| 16:44 | <GPHemsley> | Not sure I understand that one |
| 16:46 | <Davstern15> | "today" or "to day"? |
| 16:47 | <Davstern15> | Very different meanings. |
| 17:02 | <GPHemsley> | Wow, Microsoft. Way to be annoying. |
| 17:03 | <GPHemsley> | The EOT magic number is 34 bytes in. |
| 17:14 | <Davstern15> | GPHemsley: ? |
| 17:30 | <Hixie> | anyone know of any online software that i can use to edit subtitles? |
| 17:31 | <GPHemsley> | Hixie: UniversalSubtitles.org? |
| 17:32 | <GPHemsley> | Davstern15: This mostly a development channel; we blog out loud here. |
| 17:32 | <GPHemsley> | +is |
| 17:34 | <Hixie> | GPHemsley: that looks like it'd be awesome, except the video i want to subtitle is private |
| 17:34 | <GPHemsley> | oh :/ |
| 17:35 | <Hixie> | yeah :-( |
| 17:35 | <Hixie> | i'll just do it by hand i guess |
| 17:35 | <zewt> | maybe one of these days i'll get around to hacking up mpc or something to let me edit subtitles in-place |
| 17:35 | <Davstern15> | If I had the authors of Firefox, Chrome, Safari and Opera in a room... I would make so many threats... |
| 17:35 | <zewt> | for those regular occurances of seeing a really bad translation and wanting to just pause and fix it and continue |
| 17:35 | <Hixie> | yeah i was just thinking i'd just do it by hand at some point |
| 17:35 | <Davstern15> | Terrible, terrible threats. |
| 17:35 | <Davstern15> | And also IE. |
| 17:36 | <GPHemsley> | Davstern15: And what purpose would that serve? |
| 17:40 | <Davstern15> | GPHemsley: Hopefully it would make them fix the broken things. |
| 17:40 | <GPHemsley> | And those would be...? |
| 17:40 | <Davstern15> | Such as... actually make Canvas rendering fast (all except for IE). |
| 17:40 | <GPHemsley> | And you think human beings respond best to threats? |
| 17:40 | <Davstern15> | IE guys would have to make WebGL or some kind of WebX. |
| 17:41 | <Davstern15> | No, but it was more of a joke. |
| 17:41 | <GPHemsley> | You think threatening them would motivate them to do things for you more than being kind to them? |
| 17:41 | <GPHemsley> | Maybe lending them a hand? |
| 17:41 | <GPHemsley> | Because you basically have developers from all those camps right here in this room. |
| 17:41 | <Davstern15> | They are here? |
| 17:42 | <Davstern15> | If a Firefox developer is here right now: kindly fix your slow Canvas rendering. Please. |
| 17:42 | <GPHemsley> | I would guess it's a lot harder than waving a magic wand. |
| 17:42 | <Davstern15> | And if an Opera guy is here: PLEASE let me hide the cursor when hovering a div square used for a game. |
| 17:42 | <Davstern15> | There is nothing security-related that prevents that. |
| 17:42 | <Davstern15> | It is only annoying. |
| 17:42 | <Davstern15> | Well... |
| 17:43 | <Davstern15> | It is year 2012 after all. I frankly cannot believe that even CPU-based drawing is this slow. |
| 17:43 | <Davstern15> | I mean, when arc() for example is called, that isn't JavaScript doing it. It's the implementation being told what to do. |
| 17:44 | <Davstern15> | So it should be native speed, which means any computer younger than 40 years or so should be able to draw an arc flawlessly at super speed. |
| 17:44 | <GPHemsley> | It being "the year 2012" is also a magic wand. |
| 17:45 | <GPHemsley> | The actual design behind canvas is only a few years old. |
| 17:45 | <GPHemsley> | The code has likely not been optimized for every usecase. |
| 17:45 | <GPHemsley> | Have you file a bug with Mozilla? |
| 17:45 | <GPHemsley> | +d |
| 17:45 | <Philip`> | Davstern15: Anybody who cares about speed likely uses pre-rendered bitmaps, so browser developers can provide the most benefit by optimising that - arcs are used too rarely to be worth much development effort |
| 17:46 | <Philip`> | GPHemsley: The basic design is from about 2005, I think |
| 17:46 | <GPHemsley> | Philip`: That falls within my definition of "a few" :) |
| 17:47 | <GPHemsley> | (Although 2005 keeps getting farther and farther away....) |
| 17:48 | <Davstern15> | Arcs are integral for games, though. |
| 17:48 | <Davstern15> | And yes, I ended up pre-rendering them, but that also is very... undynamic. |
| 17:48 | <Davstern15> | Stiff, if you will. |
| 17:48 | <Davstern15> | And also was a nightmare code-wise. |
| 17:49 | <Davstern15> | I guess I cannot comprehend why it is such a problem to draw 2D stuff to a canvas speed-wise in this day and age. |
| 17:49 | <Davstern15> | Even with no optimizations. |
| 17:49 | <Davstern15> | Also, drawing text with shadows is SUPER slow. |
| 17:52 | <Philip`> | What you need to do is make a cool-looking benchmark that depends on all the features you care about it, and then publicise it to all the people who publish graphs of Sunspider performance every time a new browser version or new CPU comes out |
| 17:52 | <Philip`> | and then browser developers will be motivated to improve those features |
| 17:54 | <Davstern15> | Dang... |
| 17:57 | <annevk5> | Sniffing EOT is not needed. Just treat it like any other unknown format GPHemsley |
| 17:57 | <GPHemsley> | Why? |
| 17:59 | <annevk5> | Because it's not part of the platform |
| 17:59 | <annevk5> | No need to support unsupported proprietary formats |
| 18:01 | <annevk5> | You only need to sniff the formats from my email. Supporting other formats would be bad for interop |
| 18:02 | <GPHemsley> | Sniffing and supporting are separate things, though. |
| 18:02 | <annevk5> | No they are closely related |
| 18:03 | <annevk5> | Why waste code on sniffing something that must be rejected? |
| 18:04 | <GPHemsley> | To present the user with information about what kind of file it is? |
| 18:04 | <GPHemsley> | Firefox, at least, displays the MIME type in the download box |
| 18:04 | <GPHemsley> | s/box/prompt/ |
| 18:04 | <GPHemsley> | IIRC |
| 18:05 | <GPHemsley> | TabAtkins: Hey, why didn't you mention that there were plans to go ahead with the 'font' type? |
| 18:06 | <GPHemsley> | annevk5: Weren't we just discussing yesterday that we should have a list of magic numbers? |
| 18:11 | <GPHemsley> | also, there appears to be discussion about a WOFF 2 format |
| 18:21 | <GPHemsley> | top-level 'font': http://www.w3.org/Fonts/WG/track/actions/115 |
| 18:27 | <Yuhong> | annevk5: I do agree that other browsers have never supported EOT, but you do want IE implementing the standard do you? |
| 18:30 | <GPHemsley> | I maintain that sniffing is not the same as supporting. |
| 18:30 | <GPHemsley> | In fact, this document says nothing about what UAs should or should not support. |
| 18:37 | <Yuhong> | Sniffing without supporting is not very useful, but just because the formats are listed in the spec don't mean that the browser need to sniff all the formats. |
| 18:46 | <GPHemsley> | The sole purpose of this document is to be able to properly identify a file. |
| 18:46 | <GPHemsley> | What a user agent does with that information is beyond the scope of this document. |
| 18:48 | <GPHemsley> | The barrier for inclusion in this document is whether the UA is likely to encounter such a file on the Web. |
| 19:25 | <zewt> | doesn't sound like the right approach for a web spec; specs should specify things that determine browser behavior, not just pools of data that they might or might not use |
| 19:31 | <GPHemsley> | zewt: The behavior is deciding what kind of file something is. |
| 19:31 | <GPHemsley> | It is up to the browser to decide whether to then parse the file or to pass it off to some other software that can. |
| 19:34 | <zewt> | but it should specify only cases where browsers need the info, and there are normative requirements depending on the result |
| 19:36 | <GPHemsley> | Browsers can need the info without there being normative requirements that depend on it. |
| 19:37 | <zewt> | specs are about normative requirements |
| 19:38 | <GPHemsley> | again, the normative requirements are only regarding identifying the file |
| 19:38 | <GPHemsley> | the mimesniff spec says nothing else |
| 19:39 | <Ms2ger> | Hmm, apparently SMS encoding depends on the country you're in |
| 19:39 | <zewt> | normative requirements that aren't used normatively don't make much sense, afaik |
| 19:40 | <GPHemsley> | mimesniff defines the behavior of sniffing a file... it is up to other specs to decide how that information is used |
| 19:40 | <GPHemsley> | I don't see the issue here |
| 19:41 | <GPHemsley> | it is the first filter between the server and the rest of the browser |
| 19:42 | <zewt> | it should only define formats that other specs actually need to know about--for example, unless some spec actually cares, there's no need to say anything about .torrent files |
| 19:43 | <Yuhong> | zewt: Normative requirements can be optional. |
| 19:43 | <GPHemsley> | Yuhong: But they're not, in this case |
| 19:45 | <GPHemsley> | zewt: Are there browsers that parse postscript files? |
| 19:46 | <zewt> | having a "file type unknown to the spec with a content-type of foo" fallback is fine, it's the "include every file format that browsers might see on the web" thing that i don't like |
| 19:46 | <zewt> | (no idea) |
| 19:48 | <GPHemsley> | Part of this spec is identifying the type of a file whose type is unknown; without these additional signatures, many files would be spit out as application/octet-stream or text/plain |
| 19:49 | <GPHemsley> | and given that there are certain types that are common on the Web that no browser actually supports, I don't think it hurts to do a little extra |
| 19:50 | <GPHemsley> | and certainly if there are some but not all browsers that support a particular type (like EOT) |
| 19:50 | <zewt> | files that are common on the web is a much larger set than files that browsers do magic file detection for |
| 19:51 | <zewt> | torrent files are common, and browsers don't sniff them; you have to either have the content-type set, or the resource's filename needs to match *.torrent, basically |
| 19:51 | <GPHemsley> | well, part of the point of this spec, too, is to get away from sniffing based on file extension |
| 19:51 | <zewt> | (maybe the latter is a subset of sniffing, but there's no peeking at the contents of the file and looking for a header) |
| 19:52 | <zewt> | ... have browser vendors agreed to do that? heh |
| 19:52 | <GPHemsley> | well, it's part of the security concerns |
| 19:52 | <zewt> | that's not specifying current behavior, that's specifying something new |
| 19:52 | <Yuhong> | Of course. Some are difficult to sniff, like docx and odt. |
| 19:52 | <GPHemsley> | Yuhong: Actually, odt is much easier than docx. |
| 19:52 | <GPHemsley> | docx is pretty much impossible |
| 19:52 | <Yuhong> | But both are based on ZIP. |
| 19:53 | <GPHemsley> | Yeah, but ODT actually makes an effort to provide a mechanism for detection. |
| 19:53 | <Yuhong> | And there are many times where they are sniffed as such and the files had to be manually renamed.. |
| 19:53 | <zewt> | but have browser vendors agreed to switch from filename matching (ridiculously simple) to file content detection (much more complex, not always possible and sometimes ambiguous)? |
| 19:54 | <GPHemsley> | I have no idea what the browsers have agreed to |
| 19:54 | <zewt> | that sounds like a hard sell, so i'm just wondering if you've actually sold it :) |
| 19:54 | <GPHemsley> | I wasn't privy to any of those discussions |
| 19:54 | <GPHemsley> | if there even were any |
| 19:54 | <Yuhong> | I'd focus on moving away from filename matching for *scriptable* formats, like HTML and XML. |
| 19:55 | <zewt> | well, if you don't know whether vendors have agreed to such a big and probably risky change, then you may be wasting a bunch of effort |
| 19:55 | <GPHemsley> | why risky? |
| 19:55 | <Yuhong> | Most of the others typically have filename extensions, and scriptable formats present more of a security risk.. |
| 19:55 | <zewt> | because what's deployed now works, and whatever you spec may or may not work in the real world |
| 19:56 | <zewt> | additionally it would interact in some unobvious way with the file type UIs that most browsers give, which tend to be based on extensions (in part because users understand extensions better than MIME types) |
| 19:57 | <GPHemsley> | the problem is, there are at least 3 different ways to identify a file, and only one of them is anywhere near reliable |
| 19:58 | <zewt> | i don't know if i agree with that or not, but it's not really the point |
| 19:59 | <GPHemsley> | and besides, not using the file extension to determine the supplied type is one of the normative requirements of the spec |
| 19:59 | <GPHemsley> | ...although I suppose there is no restriction on using it for sniffing... |
| 19:59 | <zewt> | but you putting a normative requirement in a spec isn't going to magically make browsers agree to do it |
| 19:59 | <GPHemsley> | hmm |
| 20:00 | <GPHemsley> | zewt: Well, actually, I didn't put that one in there ;) |
| 20:00 | <GPHemsley> | remember, this spec began as basically documenting what Chrome did |
| 20:01 | <zewt> | if you drop this spec on vendors without talking to them first, i predict a response of: "wooooah slow down we're not changing something that fundamental" |
| 20:01 | <zewt> | chrome definitely uses the file extension in some cases |
| 20:01 | <GPHemsley> | yeah, IDK |
| 20:01 | <GPHemsley> | I'll have to do some investigating |
| 20:02 | <Yuhong> | Yea, the original author was abarth. |
| 20:02 | <zewt> | (at least, when it relates to launching registered system handlers, which in windows are entirely extension-based) |
| 20:03 | <GPHemsley> | I suppose the question is where the line is drawn between what the browser does and what the OS does |
| 20:04 | GPHemsley | shrugs |
| 22:48 | <annevk> | GPHemsley: Firefox' download dialog is UI and therefore interoperability does not matter |
| 22:49 | <annevk> | GPHemsley: so I would not consider that a valid use case for defining EOT sniffing |
| 22:50 | <annevk> | GPHemsley: the magic number list is only for formats that are actually part of what we want interoperability for and what we want developers to use |
| 22:50 | <gsnedders> | SimonSapin: As Ms2ger said, plan is to use 3to2 and have Py3 as the main copy (mainly because there's enough gnarly Unicode/bytes frontieers as to make it important to get those right and keep them right, which Py3 enforces) |
| 22:50 | <annevk> | GPHemsley: and in particular for format identifiers not documented in MIME sniffing, such as WEBVTT and CACHE MANIFEST |
| 22:51 | <annevk> | Yuhong: I want IE to drop support for EOT in the end |
| 22:59 | <annevk> | zewt: I doubt browsers sniff on filename actually, be interesting to see a testcase for that (outside the limited case for plugins the HTML spec does require it for) |
| 22:59 | <annevk> | GPHemsley: zewt is right that we only want to list things which can be tested |
| 23:00 | <annevk> | GPHemsley: I think some browsers might have postscript support, or maybe it's important to detect postscript so it doesn't get detected as something else? |
| 23:00 | <zewt> | annevk: they do for the "figure out whether to open with an external program, save to disk, prompt the user, etc." path |
| 23:00 | <zewt> | i don't know of any for file types supported *internally* by browsers |
| 23:00 | <SimonSapin> | gsnedders: for new projects I prefer running in 2 and 3 with the same code base |
| 23:00 | <annevk> | zewt: ah yeah, the UI layer might be broken |
| 23:00 | <SimonSapin> | but porting existing code to that can be painful |
| 23:00 | <annevk> | zewt: well, "broken" |
| 23:01 | <annevk> | but in any event the UI layer is outside our jurisdiction |
| 23:01 | <SimonSapin> | https://github.com/mitsuhiko/python-modernize can help |
| 23:01 | <gsnedders> | SimonSapin: That's always harder for things where you have complex encoding boundaries, in my experience |
| 23:02 | <SimonSapin> | yeah it can be hard, but once the switch is done everything is so much easier than running 2to3 (sloooooow) all the time |
| 23:03 | <SimonSapin> | but of course every project is different |
| 23:04 | <gsnedders> | I think there are sufficently few changes made that that isn't a problem :P |
| 23:04 | <SimonSapin> | night time. ’later |
| 23:05 | <gsnedders> | gn |
| 23:05 | <annevk> | gsnedders: how many more years of studying? |
| 23:05 | <gsnedders> | annevk: 1.5 |
| 23:06 | <annevk> | then you come back to us or are you going to do something new? |
| 23:06 | <gsnedders> | "us"? the web? |
| 23:06 | <annevk> | uhuh |
| 23:06 | <gsnedders> | I guess. |
| 23:24 | <annevk> | btw, I was thinking of writing a blog post / email announcing all the new stuff on /specs/ one of these days |
| 23:25 | <annevk> | if people have suggestions, let me know, or leave them here for me to read later |
| 23:27 | <GPHemsley> | annevk: Can you elaborate on your reference to WEBVTT and CACHE MANIFEST? |
| 23:28 | <GPHemsley> | Also, why do we have RAR, ZIP, and GZIP in the list, anyway? |
| 23:28 | <GPHemsley> | given what you've said |
| 23:29 | <GPHemsley> | and if you only detect the other things as specced, there's no need to sniff postscript separately |
| 23:29 | <GPHemsley> | as protection |
| 23:29 | <GPHemsley> | but abarth's article also discussed sniffing from a file upload perspective, too |
| 23:30 | <GPHemsley> | so I wonder if that's related and if that should be in the spec |
| 23:30 | <GPHemsley> | (server-side sniffing) |
| 23:30 | <annevk> | GPHemsley: http://dev.w3.org/html5/webvtt/#webvtt-file-body has a required file signature, http://www.whatwg.org/specs/web-apps/current-work/#writing-cache-manifests does too |
| 23:30 | <GPHemsley> | right, but how does that relate to the current spec? |
| 23:30 | <GPHemsley> | i.e. mimesniff |
| 23:31 | <annevk> | GPHemsley: I meant that if we want a registry for file signatures important to the platform, which is pretty much mime sniff, we might want to mention these somehow too |
| 23:31 | <GPHemsley> | ah |
| 23:31 | <GPHemsley> | ok |
| 23:31 | <annevk> | GPHemsley: maybe Safari supports postscript? |
| 23:31 | <GPHemsley> | so that was a separate thing, then? |
| 23:31 | <GPHemsley> | I don't think so, but let me check |
| 23:32 | <annevk> | GPHemsley: I had not considered file upload, for file upload the Content-Type header user agents set does matter for interoperability |
| 23:32 | <annevk> | GPHemsley: that seems related to defining multipart/form-data, which we haven't fixed either yet |
| 23:32 | <annevk> | GPHemsley: yes, the file signature registry was a separate thing |
| 23:33 | <GPHemsley> | well, you didn't mention it in the context of a registry this most recent time |
| 23:33 | <GPHemsley> | but ok |
| 23:35 | <GPHemsley> | Opera and Chrome sniff postscript |
| 23:36 | <GPHemsley> | but don't parse it |
| 23:36 | <GPHemsley> | Safari and Firefox do not sniff it |
| 23:36 | <GPHemsley> | (and treat my test file as plaintext) |
| 23:36 | <GPHemsley> | http://whatwg.gphemsley.org/tests/mimesniff/application/postscript/PS-Adobe- |
| 23:37 | <GPHemsley> | incidentally, when Opera and Chrome prompt for download, they automatically add a .ps extension |
| 23:37 | <annevk> | my Minefield.app says postscript |
| 23:37 | <GPHemsley> | really? where? |
| 23:37 | <zewt> | browsers that aren't IE messing with filenames? gross |
| 23:38 | <annevk> | GPHemsley: offers a download dialog |
| 23:38 | <zewt> | thought that was just an IE evil :| |
| 23:38 | <GPHemsley> | oh |
| 23:38 | <GPHemsley> | shoot |
| 23:38 | <GPHemsley> | I might have cached it |
| 23:38 | <GPHemsley> | looks like you're right |
| 23:38 | <GPHemsley> | ok |
| 23:38 | <zewt> | actually i vaguely recall something about old safari adding .zip (the most common completely-broken-renaming-behavior), but that was a long time ago |
| 23:38 | <annevk> | and Safari opens it directly |
| 23:38 | <annevk> | as a postscript file |
| 23:38 | <annevk> | inline |
| 23:38 | <GPHemsley> | really? |
| 23:38 | <GPHemsley> | hmm |
| 23:39 | <zewt> | (since .zip is probably the single most widely repurposed file format) |
| 23:39 | <GPHemsley> | need a real file to test that |
| 23:39 | <GPHemsley> | bbl, dinner |
| 23:39 | <zewt> | (well, unless you consider "text file" to be a file format, which I don't think I do, any more than "binary file" is a file format) |
| 23:39 | <annevk> | I'm gonna sleep, ttyl |
| 23:40 | <annevk> | GPHemsley: fwiw, displaying as "text/plain" versus offering a download dialog does seem like a potential interoperability issue and something we should tackle, though it's not really clear to me that's the case here |
| 23:52 | <annevk> | TabAtkins: hmm yeah, url.query = new URLQuery(...) might be nice |
| 23:53 | <annevk> | TabAtkins: guess I should work with heycam|away to get the necessary IDL hooks |
| 23:56 | <annevk> | TabAtkins: also note that http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets does not account for setting to a list |
| 23:56 | <annevk> | TabAtkins: other than that the current proposal should map pretty closely |
| 23:57 | <annevk> | TabAtkins: and given that we have duplicate keys, I was thinking delete(key, val) might be nice too next to having delete(key) |
| 23:58 | <GPHemsley> | annevk: No, I think it was a side effect of the file originally having different headers sent. |
| 23:58 | <GPHemsley> | (which were cached on my primary browser) |
| 23:59 | <annevk> | no? |
| 23:59 | <GPHemsley> | it seems that they all prompt to download |
| 23:59 | <GPHemsley> | (at least Firefox doesn't append a file extension, AFAICT) |