| 01:05 | <crankharder> | app manifest and indexed as implemented currently in the latest ffx and chrome both ask permission of the user before allowing them to be used. anyone know if that is a permanent 'feature' |
| 01:05 | <AryehGregor> | Surely that's only up to a certain amount of disk space used or such? |
| 01:05 | <crankharder> | nope |
| 01:06 | <crankharder> | *indexedDB |
| 01:06 | <AryehGregor> | Interesting. |
| 01:06 | <AryehGregor> | That seems unreasonable. |
| 01:06 | <crankharder> | i can see it for indexeddb - maybe, after a certain size limit |
| 01:07 | <crankharder> | but app manifest - i'd think it should be seamless |
| 01:07 | <AryehGregor> | Chrome seems to not have a permission prompt for this: https://developer.mozilla.org/en-US/demos/detail/filesystemdb/launch |
| 01:08 | <crankharder> | i can have an example of the two in conjunction up in a few minutes |
| 01:13 | <crankharder> | meh, ssl issues - can't really open it up. suffice it to say, two popups in ffx and chrome :/ |
| 01:17 | <crankharder> | anyways - another issue. i've noticed that the application manifest is protocol specific, maybe? my manifest looks like this http://pastie.org/3216691 - and is served up on /offline which is always SSL. if I visit the root of my app on HTTP while offline, then the manifest doesn't get used. if I visit the root while on https, then it does get recognized |
| 01:17 | <crankharder> | the issue is that my homepage is HTTP - so nobody is going to visit it at https |
| 01:18 | <AryehGregor> | As a general rule, a different protocol means a different origin as far as the same-origin policy goes. |
| 01:18 | <AryehGregor> | I don't know about app manifests specifically. |
| 01:19 | <AryehGregor> | This is to stop the non-secure version of the site from having unsecured access to secure parts of the site. |
| 01:19 | <AryehGregor> | E.g., if the secure version of a site stores something in localStorage, maybe it's important that MITMs can't get it, so we can't let the unsecured version of the site read it. |
| 01:21 | <crankharder> | I guess i'm in a nebulous secure situation... I'm fine with http accessing the manifest once it's stored on the computer - I just don't want to transmit that data over the air as http |
| 01:21 | <AryehGregor> | I don't know anything about manifests, so I can't really help you, but isn't the whole point that when you're offline, nothing is transmitted over the network anyway? |
| 01:22 | <crankharder> | yes, but when i suck down data to populate indexDB i want that connection to be secure |
| 01:23 | <crankharder> | unfortunately that means the whole page must be https, and so the manifest is received over https, but nobody's going to hit / as https |
| 01:23 | <AryehGregor> | Why not? |
| 01:24 | <crankharder> | cause the root of my app just isn't https |
| 01:24 | <AryehGregor> | Dunno how that works, then. |
| 01:24 | <crankharder> | so people, w/o wifi, will just go to "foo.com" in their browser |
| 05:06 | <MikeSmith> | http://blogs.adobe.com/webplatform/2012/01/13/html5-image-progress-events/ |
| 05:14 | <jwalden> | seems plausible at first glance, although I'm not familiar with the area enough to say that it's definitely a good idea, and workable that way |
| 05:14 | <zewt> | Display the image by encoding the XHR response in base 64, appending it to a data URI, and setting an image elementfs src attribute to the data URI. |
| 05:14 | <zewt> | ugh |
| 05:15 | <zewt> | progress events for images are useful; that, however, is disgusting and horrible |
| 05:16 | jwalden | would agree with that |
| 05:16 | <zewt> | throw all kinds of sane memory handling and cache handling right out the window |
| 05:16 | <jwalden> | I can't think of a time I've had a need for loading a regular old <img> and needed progress information for it, myself |
| 05:16 | <jwalden> | medical image display is a nice instance, tho |
| 05:17 | <zewt> | useful when loading background images, eg. for canvas/webgl |
| 05:17 | <jwalden> | it'd go well for viewing any big image standalone, actually |
| 05:17 | <zewt> | that is, images which aren't actually being displayed as they load |
| 05:17 | <jwalden> | well, for background images (presumably in CSS), how would you get a handle on the image for progress notifications? |
| 05:17 | <zewt> | ah okay that link wasn't actually *recommending* the above--rather indicating that it's a replacement for it (okay) |
| 05:18 | <erlehmann> | medical imaging |
| 05:18 | <erlehmann> | i chuckled a bit |
| 05:18 | <zewt> | you just create an HTMLImageElement, fill it in and (optionally--may be browser-dependant) stuff it in a hidden container in the doc |
| 05:19 | <jwalden> | oh, you're assuming an <img> will seed the same cache that the CSS would use |
| 05:19 | <zewt> | (i've never been sure whether all browsers will load an image if it isn't in a document; i just always stick it in the doc to be sure) |
| 05:19 | <zewt> | not referring to CSS at all |
| 05:19 | <jwalden> | which is probably reasonable, or should be |
| 05:19 | <jwalden> | if you don't mean CSS, what do you mean by "background images"? |
| 05:19 | <zewt> | i'm talking about loading images, then using the image as an argument to eg. webgl's ctx.texImage2D |
| 05:19 | <zewt> | images loaded in the background |
| 05:20 | <jwalden> | aargh, namespace collisions :-) |
| 05:20 | <zewt> | (or in the foreground but not displayed, eg. a loading screen) |
| 05:20 | <jwalden> | okay, I get you now |
| 05:20 | <zewt> | the most obvious case being a loading screen progress indicator (i think i mentioned that on the list thread--not sure if I sent that mail) |
| 08:46 | <hsivonen> | uh oh. looks like the CSS WG will tweak the commas in CSS function notation in prefix-deployed modules |
| 08:46 | <hsivonen> | that'll cause a lot of confusion |
| 09:26 | <hsivonen> | yay. someone managed to make Validator.nu take so much RAM that the kernel killed the validator (and other stuff, too) |
| 09:28 | <MikeSmith> | oh boy |
| 09:28 | <MikeSmith> | I hope there are not a lot of someones out there who can do that |
| 09:28 | <zcorpan> | was it Philip`? |
| 09:30 | <hsivonen> | zcorpan: evidence points to Sweden rather than the UK |
| 09:32 | <jgraham> | It wasn't me |
| 09:44 | <zcorpan> | maybe Philip` used a proxy |
| 09:47 | <jgraham> | zcorpan: Pretty sure you're the prime suspect. And arguments like that aren't helping your case ;) |
| 09:47 | <zcorpan> | heh |
| 13:27 | <matjas> | hsivonen: re: “DOM strings are strings of 16-bit code units”, am I correct in reading that as “UCS-2 like strings”? |
| 13:30 | <matjas> | do you mean to say that all text in the entire DOM is stored as UCS-2 internally? (not just the JS engine) woah. do all browsers do that? |
| 13:31 | <matjas> | that does make a lot of sense |
| 13:32 | <hsivonen> | matjas: I mean they are like UCS-2 except the surregate range is not out of use |
| 13:32 | <hsivonen> | matjas: but they aren't guarenteed to be valid UTF-16 |
| 13:32 | <matjas> | so, just like JS |
| 13:32 | <hsivonen> | matjas: so they aren't guaranteed to be valid UCS-2 and they aren't guaranteed to be valid UTF-16 |
| 13:33 | <hsivonen> | matjas: so the correct answer is that JS/DOM strings are neither UCS-2 nor UTF-16 in the sense of being valid either |
| 13:33 | <matjas> | stuff like unpaired surrogates? |
| 13:33 | <hsivonen> | matjas: yes |
| 13:34 | <matjas> | hsivonen: thanks for clarifying |
| 13:34 | <hsivonen> | but for non-bogus results, authors should use valid UTF-16, of course |
| 13:35 | <hsivonen> | the interpretation as UTF-16 happens in layout |
| 13:36 | <hsivonen> | so you can have the high surrogate and the low surrogate in separate document.write calls and they end up rendering as one glyph |
| 13:36 | <matjas> | right |
| 14:36 | <jacobrask> | Does anyone know if some event is emitted when an alternate stylesheet is selected? |
| 14:36 | <jacobrask> | I can't seem to find anything in the specs, but maybe something non-standard |
| 14:44 | <hsivonen> | matjas: FWIW, in Gecko, if the most significant byte of all code units in a DOM text node is zero, Gecko stores the text 8 bits per character |
| 14:45 | <hsivonen> | matjas: so if you have one non-ISO-8859-1 character in a comment in an inline JavaScript, the storage of the whole text node gets doubled |
| 14:46 | <hsivonen> | #littleknownimplementationdetails |
| 14:46 | <hsivonen> | (where I meant real ISO-8859-1--not Windows-1252) |
| 14:47 | matjas | just edited hsivonen’s comment at http://mathiasbynens.be/notes/javascript-encoding#comment-5, adding all that |
| 14:48 | <matjas> | knowledge bomb! thanks a lot |
| 14:49 | <hsivonen> | matjas: you're welcome |
| 15:20 | <niloy_> | how to include unicode in javascript string that are 5 hex chars long? |
| 15:26 | <Philip`> | niloy_: With surrogates, e.g. U+10000 is "\ud800\udc00" |
| 15:27 | <niloy_> | Philip`, thanks |
| 15:28 | <niloy_> | Philip`, how did U+10000 become \ud800\udc00? |
| 15:29 | <niloy_> | Philip`, nevermind, lemme google for it |
| 15:33 | <hsivonen> | niloy_: http://www.rishida.net/tools/conversion/ |
| 15:33 | <niloy_> | thank you |
| 17:40 | <kennyluck> | So obviously UTF-16 → UTF-32 conversion isn't straightforward. |
| 17:41 | <kennyluck> | I guess there do exist use cases of UTF-16 escape in CSS. |
| 17:41 | <Ms2ger> | Probably |
| 17:41 | <Ms2ger> | But enough to care? |
| 17:47 | <kennyluck> | ms2ger, probably not really, but we just need to go to one way or another. |
| 18:01 | <dglazkov> | good morning, Whatwg! |
| 18:28 | <divya> | dglazkov: have you seen? http://harmful.cat-v.org/software/xml/s-exp_vs_XML (there *are* a few interesting bits) |
| 18:28 | <divya> | Next, introduce macros that look exactly like elements, but that are expanded in place between the reader and the "object model" |
| 18:28 | <divya> | errr quote from that email |
| 18:31 | <bga> | http://okmij.org/ftp/Scheme/SXML.html |
| 18:31 | <bga> | https://gist.github.com/1332310 |
| 18:32 | <dglazkov> | divya: whoa, so.. many.. words... |
| 18:32 | <divya> | yeah its a rant that could have been shorter :) |
| 18:32 | <divya> | also the dude died recently I heard. |
| 18:33 | <dglazkov> | oh noes, from reading this email? |
| 18:33 | <divya> | HAHAHHAHAHA |
| 18:33 | <yolin> | does js support only ascii numbers? |
| 18:34 | <Ms2ger> | Yeah, Roman numerals are such a burden |
| 18:35 | <yolin> | but each unicode point has a number property right? |
| 18:43 | <TabAtkins> | yolin: Yes, numbers must be composed of the ten ascii digits, and the ascii characters "+-.eE" |
| 18:44 | <TabAtkins> | All of JS's syntax is in ascii. The only non-ascii things are user-defined identifiers like variable names. |
| 18:45 | <gsnedders> | Well, theoretically host objects could be non-ascii. |
| 18:45 | <gsnedders> | But those are just identifiers. |
| 18:45 | <TabAtkins> | Yeah. |
| 18:46 | <yolin> | will it be difficult to implement non-ascii numbers ? |
| 18:46 | <TabAtkins> | The big question is "what's the benefit of non-ascii digits"? |
| 18:47 | <yolin> | say I have a input box which accepts numbers in some language other than english, I can directly perform calculation on the number? |
| 18:48 | <TabAtkins> | Are you talking about accepting numbers that use digits elsewhere in the unicode range, or ones from completely different number systems? |
| 18:48 | <yolin> | numbers that use digits elsewhere in unicode range |
| 18:48 | <yolin> | Indian numerals is what I have in mind |
| 18:49 | <TabAtkins> | That is, there are multiple glyphs that look like "0" - are you talking about that, or about numbers like 一十三 |
| 18:49 | <gsnedders> | yolin: for <input type=number> it should just be a UI issue as to what it displays. |
| 18:49 | <AryehGregor> | In theory, <input type=number> should allow such localization, but in practice I don't think it does. |
| 18:49 | <gsnedders> | yolin: The value property should be just a Number primitive |
| 18:49 | <AryehGregor> | Also it's not universally supported yet. |
| 18:49 | <AryehGregor> | So you have to convert manually, yes. |
| 18:50 | <yolin> | I was reading the unicode wiki article, http://en.wikipedia.org/wiki/Mapping_of_Unicode_characters |
| 18:50 | <yolin> | it mentions every unicode has a numerical property |
| 18:51 | <yolin> | which is its ascii equivalent in number |
| 18:51 | <yolin> | if thats true, it should be easy to implement non-ascii numbers? |
| 18:52 | <TabAtkins> | No, since you'd be tying basic number parsing to a giant array of unicode mappings. |
| 18:52 | <TabAtkins> | Also, while *most* number systems are base-10, not all of them are. |
| 18:52 | <yolin> | like Roman numbers? |
| 18:52 | <TabAtkins> | (Many are officially base-10, but don't use the style of digit system that English does.) |
| 18:52 | <TabAtkins> | That's an extreme example, but yet. |
| 18:52 | <TabAtkins> | s/yet/yes/ |
| 18:52 | <Philip`> | It's hard to implement something that matches a user's expectation of how a number should be interpreted, since that's an ill-defined problem and can't be solved by mapping characters to digits |
| 18:53 | <Philip`> | and there's no real point implementing something that doesn't match a user's expectation |
| 18:53 | <TabAtkins> | But also, say, the CJK longhand style, Armenian, Hebrew, and several others. |
| 18:53 | <TabAtkins> | Basically, all the number systems in http://dev.w3.org/csswg/css-counter-styles/ that aren't in the "numeric" type. |
| 18:53 | <Philip`> | (Even stuff like "0x10" and "1e+3" is a problem if you're trying to accept what a user might consider to be a number) |
| 18:54 | <TabAtkins> | Oh yeah, I forgot that "xX" (and soon "oObB") are allowed in numbers too. |
| 18:54 | <yolin> | okay, got it |
| 19:09 | <bencc> | in webrtc when sending a STUN message and than passing the signaling message to the other peer |
| 19:10 | <bencc> | are the username and password attributes part of STUN or webrtc or something google made up? |
| 19:20 | <erlehmann> | . |
| 19:21 | <TabAtkins> | Is that like answering "mu"? |
| 19:33 | <erlehmann> | TabAtkins, just testing my new IRC client :3 |
| 19:34 | <TabAtkins> | erlehmann: Ah, kk. |
| 19:36 | <erlehmann> | TabAtkins, <https://github.com/erlehmann/uii>;, it is just a shell script wrapper for ii |
| 19:37 | <erlehmann> | ii is a client that creates directories and files for irc channels |
| 19:37 | <erlehmann> | in this channel i talk by writing the text into ~/irc/chat.freenode.org/#whatwg/in |
| 19:38 | <erlehmann> | and what is written here is shown in ~/irc/chat.freenode.org/#whatwg/out |
| 19:38 | <TabAtkins> | Interesting. |
| 19:38 | <Hixie> | wow that's... cool |
| 19:38 | <erlehmann> | i consider that pretty usable. way more than xchat, irssi or *shudder* pidgin. |
| 19:38 | <erlehmann> | ii is here <http://tools.suckless.org/ii/>; |
| 19:39 | TabAtkins | still wants a minimalistic irc server that he can pipe into a webpage, so he write himself a client UI. |
| 19:39 | <erlehmann> | but it is also packaged by distributions. |
| 19:40 | <erlehmann> | oh, i also use inotify to see when a file that i have not opened is written to to show a popup using libnotify |
| 19:40 | <erlehmann> | first i went for opening terminals in that case, but it became pretty easy to spam me that way |
| 19:42 | <erlehmann> | its a shame plan9 died |
| 19:42 | <erlehmann> | the combination of tail -f and readline input really serves so much well :3 |
| 19:43 | <TabAtkins> | Plus: free logging! |
| 19:44 | <erlehmann> | indeed. grep was never the same. |
| 19:46 | <erlehmann> | handling is also easier. because i do not have to learn the window management of a specific client (irssi is pretty usable, but i already have a window manager) |
| 22:58 | <jwalden> | anyone familiar enough with webidl to cite the song and verse that state what the length of the ECMAScript function for a WebIDL |void foo(long a, optional long b);| would be? |
| 22:58 | <jwalden> | the length is supposed to be the "argument list length" |
| 22:58 | <jwalden> | I'm kind of guessing it's 2 there |
| 22:58 | <jwalden> | but I'm not sure |
| 22:59 | <jwalden> | and it's not clear to me how that'd be computed for a function like |void bar(long a, ...)| as a further thought |
| 23:00 | <Hixie> | why guess? why not look it up? :-) search for "The value of the Function object" |
| 23:01 | <jwalden> | I did look it up |
| 23:01 | <jwalden> | "argument list length" is not a term of art as far as I can tell |
| 23:02 | <Hixie> | yeah the term of art is "length property" |
| 23:02 | <jwalden> | "the maximum argument list length of the functions in the entries of S" is how it's defined |
| 23:03 | <Hixie> | right |
| 23:03 | <jwalden> | but it's not stated what "maximum argument list length" means in the context of specified-but-optional arguments, ..., and so on |
| 23:04 | <jwalden> | ECMAScript the spec had a rule for determining this stuff; webidl is doing things somewhat differently, so the rule doesn't transfer over, unfortunately |
| 23:04 | <Hixie> | the effective overload set doesn't have optional arguments, does it? |
| 23:04 | <Hixie> | i thought the effective overload set was "expanded out" for lack of a better term |
| 23:05 | <Hixie> | i.e. it's important to do step 1 of that algorithm |
| 23:05 | <jwalden> | hmm, I'd thought that was accumulating all the different instances with different arguments as a list, not something more complex |
| 23:05 | jwalden | reads some more |
| 23:05 | <Hixie> | yeah the definition of effective overload set explicitly expands out all the optional argument cases so by the time you get to the step that talks about "the maximum argument list length" there's no optional arguments |
| 23:08 | <jwalden> | it really would have been preferable for typed arrays to use ECMAScript notation, given that they're trying to be basically a native-to-ECMAScript thing :-\ |
| 23:08 | <jwalden> | c'est la vie, or something |
| 23:09 | <Hixie> | i think that was basically the result of the webgl guys getting tired of waiting for the tc39 guys |
| 23:09 | <Hixie> | personally i was still waiting for tc39 and think that the arraybuffer stuff is scary |
| 23:09 | <Hixie> | because of its platform-specific endianness stuff |
| 23:09 | <jwalden> | fair |
| 23:10 | <Hixie> | but at this point looks like we're stuck with it |
| 23:10 | jwalden | knows people hugely negative on it for that reason |
| 23:10 | <Hixie> | even canvas uses arraybuffer now |
| 23:10 | <jwalden> | so far I haven't been convinced the alternatives really do well enough at it, tho |
| 23:10 | <jwalden> | but I haven't spent too much time reading up on them, so take that with a grain of salt |
| 23:27 | <Hixie> | holy cow, i finally got the main whatwh bucket to below 1000 e-mails |
| 23:27 | <paul_irish> | \o\ \o/ /o/ |
| 23:27 | <Hixie> | only 1638 total e-mails to go |
| 23:30 | Ms2ger | looks at the bug count |
| 23:30 | <jamesr_> | Hixie, i believe that's an accurate characterization (re: arraybuffer/tc39) |
| 23:30 | <Ms2ger> | First you're complaining about design-by-committee, and now you're complaining about non-design-by-committee! |
| 23:39 | <Hixie> | indeed |
| 23:40 | <Hixie> | it's the "committee" part i have a problem with, no the "design" part :-P |
| 23:47 | <Ms2ger> | What's up next, no caring about var vs. i? |
| 23:47 | <TabAtkins> | Sounds legit. |
| 23:48 | <Hixie> | what is this "caring" you speak of |
| 23:48 | <Hixie> | :-P |
| 23:55 | <crankharder> | so, in ffx, the user is prompted whenever the application cache is initialized |
| 23:55 | <crankharder> | is there an event fired when the user confirms/denies the usage of application cache? |
| 23:57 | <Hixie> | there's an event for when the cache finished |