| 02:17 | <TabAtkins> | Urgh, appcache examples are... lacking. |
| 02:17 | <TabAtkins> | Say I want to cache a single-page app. There's one data script I'd like to load fresh when online, but allow to draw from cache when offline. How to write? |
| 02:18 | <TabAtkins> | I kinda suspect it's "CACHE: data-script.js SETTINGS: prefer-online NETWORK: data-script.js"? |
| 02:18 | <TabAtkins> | The loading algo is too long and annoying to read to figure out what the actual behavior of this is. |
| 03:08 | <Domenic_> | MikeSmith: yeah after ES6 ships we hope to move to something like that. |
| 03:21 | <MikeSmith> | Domenic_: cool |
| 08:30 | <zcorpan> | TabAtkins: isn't this wrong for inlines? "If the property does not apply to this element, then the element has no used value for that property." http://dev.w3.org/csswg/css-cascade/#used |
| 08:30 | <zcorpan> | TabAtkins: (and the width/height properties) |
| 09:42 | <hsivonen> | http://telemetry.mozilla.org/#release/28/DECODER_INSTANTIATED_HZ/saved_session/Firefox is encouraging |
| 09:42 | <IZh> | Hi. |
| 09:43 | <IZh> | I have seen <html lang="en-US-x-hixie"...> on developers.whatwg.org. What does it mean? Is it Hixie's dialect of US English? ;-) |
| 09:44 | <hsivonen> | IZh: yes |
| 09:44 | <hsivonen> | IZh: http://ian.hixie.ch/bible/english |
| 09:45 | Ms2ger | wonders if changing it to en-GB-x-hixie would be a good way to annoy people who want to fork it into en-US |
| 09:49 | <IZh> | What's the point of having own language? I don't see drastical difference to en-US. |
| 10:39 | <annevk> | Welcome back hsivonen! |
| 10:39 | <annevk> | hsivonen: it'd be great if hz-gb-2312 could be nuked |
| 11:13 | <hsivonen> | annevk: I'm wondering if I should just nuke it without moving it to c-c myself and let Thunderbird devs know that it's up to them to add it to c-c |
| 11:13 | <hsivonen> | ...or if I should move it to c-c |
| 11:13 | <hsivonen> | annevk: curiously, the supposedly unreachable IBM encodings have been reached in very small numbers *somehow* |
| 11:14 | <hsivonen> | I wonder what kind of bug is involved |
| 11:14 | <annevk> | Could it be that custom builds of Firefox still report back? |
| 11:15 | <hsivonen> | dunno. could be a fringe extension doing something |
| 11:16 | <annevk> | hsivonen: makes sense I guess |
| 11:16 | <hsivonen> | I can't even get c-c to build right now |
| 11:17 | <hsivonen> | it would be easier to help TB devs if I could build their stuff |
| 11:17 | <annevk> | hsivonen: I think letting Thunderbird know what's up is okay... |
| 11:18 | <annevk> | hsivonen: it's a bit unclear to me how alive that project still is |
| 11:18 | <hsivonen> | hmm. I could do the initial "removal" the same way EUC-TW and the IBM encodings were removed |
| 11:18 | <annevk> | hsivonen: e.g. for Firefox OS we are building a new email client |
| 11:18 | <hsivonen> | i.e. remove it from the Encoding Standard alias table |
| 11:18 | <jgraham> | annevk: You haven't used the FirefoxOS email client have you? |
| 11:19 | <annevk> | jgraham: I don't think that would clarify what I'm unclear about |
| 11:19 | <jgraham> | Comparing it to Thunderbird isn't really talking about two similar products |
| 11:19 | <annevk> | hsivonen: yeah that makes sense |
| 11:20 | <jgraham> | Anyway the status of Thunderbird is that Mozilla keep the lights on but doesn't pay anyone to work on it |
| 11:21 | <jgraham> | There does seem to be some sort of community around it |
| 11:21 | <annevk> | hsivonen: btw, I'm happy to rewrite the algorithms to use bit shifting and such, I just need to figure out how to do it; I'm not really familiar with that kind of math, I imagine an implementor would be though |
| 11:32 | <hsivonen> | annevk: I see |
| 13:00 | <annevk> | hsivonen: so SimonSapin explained how to fix utf-8 |
| 13:54 | <annevk> | I was going to say something else, but I updated the bug instead it seems |
| 13:57 | <annevk> | whoa |
| 13:57 | <annevk> | GitHub displaying .csv is sweet https://github.com/briandailey/pycon-2014-job-fair/blob/master/data.csv |
| 13:58 | <annevk> | that kind of stuff just makes you want to start using that format again |
| 13:58 | <annevk> | we should get things like <table src=.cvs> without loads of JavaScript |
| 14:00 | <jgraham> | Seems like it would be pretty weird |
| 14:00 | <jgraham> | It would be kind of like a macro in the parser since it would presumably expand to a whole big DOM |
| 14:01 | <jgraham> | Well, I guess it could be a shadow DOM, but this is a case where encapsulation doesn't seem helpful |
| 14:02 | <Ms2ger> | Didn't tantek propose that eons ago? |
| 14:04 | <annevk> | jgraham: I was thinking DOM manipulation |
| 14:04 | <annevk> | Ms2ger: there's remnants of it in HTML4 |
| 14:04 | <annevk> | Ms2ger: I think IE had something like it |
| 14:05 | <jgraham> | In unrelated related news, Firefox OS isn't a company |
| 14:05 | <jgraham> | I assume |
| 14:05 | <annevk> | Why? |
| 14:05 | <jgraham> | Why isn't it a company? |
| 14:06 | <annevk> | Why is it news? |
| 14:06 | <jgraham> | Because that csv claims that a company called "Firefox OS" was at the jobs fair |
| 14:07 | <annevk> | jgraham: it seems that was fixed two hours ago |
| 14:07 | <jgraham> | Oh, well I got an old version then |
| 14:07 | <annevk> | GitHub must not like you |
| 14:08 | <jgraham> | Understandable |
| 14:08 | <annevk> | Quite |
| 14:44 | <annevk> | https://tankredhase.wordpress.com/2014/04/13/heartbleed-and-javascript-crypto/ Hmm, "One codebase means less room for error."... Heartbleed is the perfect example for why one codebase is a very bad idea... |
| 14:46 | <jtcranmer> | given the statements after the header |
| 14:46 | <jtcranmer> | I suspect he means more that fewer lines of code are better |
| 14:50 | <jgraham> | Yeah, the worrying sentence there was " If there’s anything we’ve learned from Heartbleed, it’s that no matter the choice of programming language, the biggest risk is human error." |
| 14:51 | <jgraham> | If you are only just now learning that human error is the cause of bugs in programs written by humans, I don't know what to say |
| 14:52 | <jgraham> | One kind of human error might be not correctly taking account of the tendency for humans to make errors and work with tools that make such errors especially troublesome |
| 14:52 | <Ms2ger> | Let's just blame Ritchie |
| 14:53 | <tantek> | Ms2ger indeed (re table and csv), and I think TabAtkins prototyped it too. |
| 15:02 | <jtcranmer> | annevk: ping |
| 15:02 | <annevk> | jtcranmer: http://www.nohello.com/ |
| 15:03 | <jtcranmer> | annevk: any updates on the IDNA clusterfuck? |
| 15:04 | <annevk> | jtcranmer: http://lists.w3.org/Archives/Public/www-archive/2014Apr/0018.html |
| 15:04 | <annevk> | jtcranmer: http://www.unicode.org/reports/tr46/proposed.html has my proposed changes, still no syntax definition of a domain though, not sure when we'll get that |
| 15:05 | <jtcranmer> | annevk: mostly, I'm trying to get a sense of what the URL statics will look like |
| 15:05 | <jtcranmer> | so I can attempt to convince Firefox to implement them so I can use them |
| 15:05 | <jtcranmer> | or at least polyfill them |
| 15:06 | <jtcranmer> | I need it for https://github.com/mozilla-comm/jsmime/issues/6 |
| 15:07 | <annevk> | jtcranmer: I think the two methods provided still make sense; the only question is how we want to signify error |
| 15:07 | <annevk> | jtcranmer: return the original string or throw |
| 15:07 | <jtcranmer> | well, the other question is about resolving unicode homograph attacks |
| 15:08 | <annevk> | if they are allowed per IDNA #46 I'm not going to disallow them |
| 15:08 | <jtcranmer> | all browsers do that nowadays by displaying the domain name in punycode form if it would contain a homograph |
| 15:08 | <annevk> | right |
| 15:08 | <annevk> | so one thing I wanted to add was domainToUI |
| 15:08 | <annevk> | which would use the tricks from the UA to decide whether or not it would do toUnicode in the end |
| 15:09 | <jtcranmer> | makes sense |
| 15:09 | <annevk> | as some browsers only display code points they think their users will understand (Chrome) whereas others follow other recommendations |
| 15:10 | <Domenic_> | annevk: have you seen mathiasbynens's http://nodejs.org/api/punycode.html API? |
| 15:11 | <annevk> | Domenic_: Punycode != IDNA, but I have seen that and did discuss it with him |
| 15:11 | <Domenic_> | ah right, yeah. i guess i was thinking of "possible URL static functions" |
| 15:11 | <annevk> | Domenic_: I'm not sure Punycode can fail |
| 15:12 | <annevk> | Domenic_: but IDNA ToASCII definitely can |
| 15:12 | <jtcranmer> | Domenic_: it lacks stringprep necessary for IDNA |
| 15:12 | <annevk> | And IDNA ToASCII is always used, even with eventual ToUnicode |
| 15:12 | <jtcranmer> | Domenic_: as I noted in my github issue, there is 0 pure-JS code that exists that can solve IDNA |
| 15:13 | <jtcranmer> | I can kind of polyfill domainToUI today in Firefox, but only because Firefox is apparently violating the URL spec |
| 15:14 | <annevk> | Firefox' mix of displaying the domain name in Unicode and the rest in ASCII is weird |
| 15:14 | <annevk> | Although bz considers it a best effort |
| 15:14 | <jtcranmer> | I'd argue that shoving things out in Unicode is better than always going to ASCII |
| 15:16 | <annevk> | So mathiasbynens' implementation does throw for ToASCII |
| 15:17 | <jtcranmer> | Domenic_: https://github.com/mathiasbynens/todo/issues/9 |
| 15:17 | <annevk> | jtcranmer: well you need ToASCII either way, and that's what will hit the DNS, it's the question of whether you go ToUnicode afterwards and then ToASCII again later on or just serialize |
| 15:18 | <jtcranmer> | annevk: true, but the more we can hide the punycode from end users, the better |
| 15:18 | <annevk> | jtcranmer: for end users you will already have to transform the string somehow |
| 15:18 | <annevk> | jtcranmer: you don't want ASCII paths |
| 15:19 | <annevk> | At some point I'll define URL.urlToUI too I suppose |
| 15:19 | <annevk> | Or maybe URL.prototype.toUIString() |
| 15:19 | <zewt> | ("toascii" sure seems to mean it loses any codepoints over U+7F or so) |
| 15:19 | <annevk> | Domenic_: does JavaScript have precedents for toUIString()? |
| 15:22 | <zewt> | (and yeah I know, just hard to get keep some people from getting confused over what "ASCII" means for some reason, heh) |
| 15:22 | <mathiasbynens> | annevk: you mean in `ToASCII` → `encode`? it *should* never throw, the errors are there just in case (http://rawgit.com/bestiejs/punycode.js/master/coverage/punycode.js/punycode.js.html) |
| 15:22 | <annevk> | mathiasbynens: oh okay |
| 15:23 | <Domenic_> | annevk: I don't think so... |
| 15:23 | <annevk> | mathiasbynens: so yeah, I dunno what's better |
| 15:23 | <zewt> | when I see JS code with var declarations at the top of functions, I smell old C programmer |
| 15:23 | <annevk> | Domenic_: is it better to have a static or a method for something like that? |
| 15:24 | <Domenic_> | annevk: ah interesting. I feel like this is related to discussions around whether things belong on Math. or Number.prototype.... |
| 15:24 | <annevk> | Domenic_: yeah I guess |
| 15:24 | <Domenic_> | probably a method though |
| 15:24 | <Domenic_> | since toString() is already a method |
| 15:25 | <annevk> | Domenic_: toString() is rather magical |
| 15:25 | <Domenic_> | how so? |
| 15:25 | <annevk> | Domenic_: for a long time I didn't even realize it was a thing; I thought objects just stringified |
| 15:25 | <annevk> | Domenic_: as happens when you do + "" and such |
| 15:25 | <Domenic_> | sounds like WebIDL-inspired thinking ;) |
| 15:25 | <annevk> | Domenic_: nah, this was way before IDL |
| 15:26 | <zewt> | i don't think toString should be a precedent for making other functions-that-convert-to-some-kind-of-string methods |
| 15:26 | <Domenic_> | ah ok |
| 15:26 | <Domenic_> | yeah toString() and valueOf() and then() and toJSON() are all methods used by various parts of the spec |
| 15:26 | <jtcranmer> | well, .toString() invokes magic paths in js |
| 15:27 | <Domenic_> | where if you use x in a certain context it will invoke x.method() |
| 15:27 | <jtcranmer> | and all I want to do is just be able to implement EAI and IDN for email addresses |
| 15:27 | <annevk> | jtcranmer: yeah sorry |
| 15:28 | <annevk> | jtcranmer: for domain names they'll have to be statics so the current API is roughly how it will be in the end |
| 15:28 | <jtcranmer> | I just need to build a FF polyfill so I can test it |
| 15:28 | <annevk> | jtcranmer: I might change to throwing or maybe returning the empty string in case of bad input |
| 15:28 | <JonathanNeal> | Polyfill for what, jtcranmer? |
| 15:28 | <annevk> | jtcranmer: but other than that I think those two are stable |
| 15:28 | <jtcranmer> | except I'm likely to find a corner case I want to test that the current implementations can't handle |
| 15:28 | <zewt> | for all of Firefox |
| 15:29 | <jtcranmer> | JonathanNeal: URL.domainTo* |
| 15:29 | <smaug____> | does gmail have some setting to logout automatically after closing it? |
| 15:30 | <JonathanNeal> | jtcranmer: got documentation for it? I could add one to polyfill.io |
| 15:30 | <jtcranmer> | JonathanNeal: http://url.spec.whatwg.org/#url-statics |
| 15:31 | <JonathanNeal> | wow, no idea what that is doing. |
| 15:31 | <jtcranmer> | yeah, it can't be polyfilled using existing techniques |
| 15:31 | <jtcranmer> | which is the problem |
| 15:31 | <annevk> | smaug____: is there no box to say the computer is untrusted? |
| 15:32 | <annevk> | jtcranmer: they can, just requires a bunch of code |
| 15:32 | <jtcranmer> | perhaps a better way to put it |
| 15:32 | <jtcranmer> | "there is no extant code that can polyfill it" |
| 15:32 | <JonathanNeal> | In dumb people terms, what does it do? |
| 15:33 | <annevk> | translates domain names between its different representations |
| 15:33 | <annevk> | s/its/their/ |
| 15:33 | <jtcranmer> | it converts strings like ケツァルコアトル。tlalocan to xn--bckc7bj7f1a6vd.tlalocan and vice versa |
| 15:34 | <annevk> | losing the fancy dots unfortunately |
| 15:34 | <annevk> | toUI might be able to do some extra tricky for those if people feel inclined |
| 15:34 | <jtcranmer> | consequence of me not hitting <Meta>-<Space> quickly enough |
| 15:35 | <JonathanNeal> | jtcranmer: thanks for the explanation, ah, translation |
| 15:36 | <jtcranmer> | the part I just described is the easy part (Punycode), the hard part is the preprocessing necessary first (StringPrep/NamePrep) |
| 17:13 | <manus> | Hi folks. Just following up on a question I had at a pretty inactive time in the channel about a week and a half ago, regarding the different notions of focus on a web page: http://krijnhoetmer.nl/irc-logs/whatwg/20140403#l-339 |
| 17:13 | <manus> | MikeSmith pointed me to SteveF, and jgraham pointed me to Hixie, but I'm not sure either of them got to see or respond to the issues |
| 17:14 | <MikeSmith> | manus: Hixie |
| 17:14 | <MikeSmith> | when he's around |
| 17:14 | <MikeSmith> | if it's about focus |
| 17:14 | <Hixie> | i'm here, give me a minute, afk |
| 17:14 | <manus> | cool, thanks |
| 17:14 | <manus> | oh, sweet, ok |
| 17:16 | <MikeSmith> | tantek: btw I think I misunderstood what you had said at the webapps wg f2f about the group being prevented from referencing whatwg specs |
| 17:16 | <MikeSmith> | tantek: and needing the AB to do.. something .. in order for the group to be able to reference whatwg specs instead of copying them |
| 17:18 | <Hixie> | manus: ok, here now. what's up? |
| 17:20 | <manus> | Hey Hixie. I just wanted to know if there's any defined/documented behavior for keyboard scrolling focus (as opposed to "normal" focus) for overflowed elements such as scrollable divs? |
| 17:20 | <manus> | Hixie: I.e., how should should keyboard scrolling work in different cases such as those in this jsfiddle: http://jsbin.com/sizofuse/7/edit?html,output ? |
| 17:20 | <Hixie> | Ah, yes |
| 17:20 | <Hixie> | this was recently updated in the spec |
| 17:20 | <MikeSmith> | tantek: anyway maybe we should all take that discussion to public-webapps and continue it there rather than just letting it drop |
| 17:20 | <Hixie> | the browsers aren't very interoperable in this rea, unfortunately |
| 17:21 | <manus> | Hixie: awesome that there's an update. are browsers hopelessly different, or would said spec update make it better? |
| 17:22 | <MikeSmith> | tantek: anyway I'm off to sleep now but maybe we can chat about it more here later after I'm back |
| 17:22 | <Hixie> | manus: hopefully the browsers will converge over time now that the spec is not completely out of touch with the reality |
| 17:23 | <Hixie> | manus: but it'd probably happen faster if someone agreed that it needed to be fixed and wrote tests and filed bugs on the browsers :-) |
| 17:23 | <manus> | Hixie: cool. I basically want a link to point to so I can file bugs with the concerned browsers |
| 17:23 | <manus> | yeah |
| 17:23 | <manus> | :] |
| 17:24 | <Hixie> | manus: http://www.whatwg.org/specs/web-apps/current-work/#focus is where it all begins |
| 17:25 | <Hixie> | manus: the term you're looking for is "scrollable regions" |
| 17:25 | <manus> | Hixie: thanks, I'll take a look. that helps a lot (terminology) |
| 17:28 | <Hixie> | hober: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=25236 |
| 18:02 | <TabAtkins> | zcorpan: What do you mean by "wrong for inlines"? |
| 18:03 | <Hixie> | hsivonen: getting timeouts from validator.nu when validating the HTML spec, fwiw |
| 18:20 | <Hixie> | TabAtkins: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=25026 - any ideas? |
| 18:28 | <Domenic_> | that's an interesting one |
| 18:29 | <TabAtkins> | Hixie: None besides, like, a 'min-line-height' property. |
| 18:30 | <Hixie> | should i just clamp it with prose for now? |
| 18:30 | <TabAtkins> | Yeah. |
| 18:30 | <Hixie> | k |
| 18:30 | <Hixie> | thanks |
| 18:46 | <tantek> | MikeSmith - I have no idea what the issue is or was, so I'm just going to keep pushing forward with the assumption that editors in the WebApps WG are free to reference WHATWG specs as they see fit. |
| 18:47 | <tantek> | If someone raises a specific issue, or says they're being blocked from doing that for some reason, we can respond as needed. |
| 18:51 | <jcgregorio> | Hixie: can I get an account on http://wiki.whatwg.org/ as jcgregorio? |
| 18:53 | <eatsomeatso> | I just found out that I cannot test my multiplayer netplay JavaScript game by opening multiple tabs in Firefox; only the one that is active seems to run any logic. So I opened two different instances (windows) of Firefox instead, and then it works. But then it lags so much that it becomes impossible to tell what the game is gonna be like when played on unique computers over the network. Dammit. |
| 19:11 | <annevk> | jcgregorio / Hixie: I can give you an account if you msg me your email |
| 19:13 | <annevk> | tantek: if that's the case pushback to people who raise objections to that, such as Glenn Adams, might be in order |
| 19:14 | <jcgregorio> | annevk: jcgregorio⊙gc, thanks! |
| 19:15 | <annevk> | done |
| 19:19 | <jcgregorio> | annevk: thanks! |
| 19:20 | <tantek> | annevk - oh yeah I certainly do :) |
| 19:49 | <arunranga> | heycam|away, any idea when you’ll have something in place for https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682, having to do with sequence<T> and friends? |
| 21:04 | <zcorpan> | TabAtkins: so consider <span>foo</span>, doesn't that have a used value for the 'width' property? |
| 21:04 | <SamB> | zcorpan: hmm? |
| 21:05 | <zcorpan> | SamB: http://dev.w3.org/csswg/css-cascade/#used "If the property does not apply to this element, then the element has no used value for that property." |
| 21:06 | <TabAtkins> | zcorpan: Are you talking about in practice, or observable effects via gCS(), or... |
| 21:06 | <zcorpan> | TabAtkins: in this case the observable effect of gCS |
| 21:07 | <zcorpan> | TabAtkins: but also interested in understanding how the model is intended to be |
| 21:07 | <TabAtkins> | Yeah, given that gCS is defined in terms of used values, looks like we'd need to fix our definition. |
| 21:07 | <TabAtkins> | The model is supposed to be what is said. inlines *dont'* have used 'width' property values. |
| 21:07 | <TabAtkins> | Because they don't use 'width' in their layout algorithms. |
| 21:08 | <zcorpan> | ok. so gCS needs to say something else. and .usedStyle will be less useful? |
| 21:09 | <zcorpan> | depending on what we want .usedStyle to do i guess |
| 21:09 | <TabAtkins> | What could .usedStyle possibly give for it? |
| 21:09 | <TabAtkins> | The computed value, I guess. |
| 21:09 | <zcorpan> | computed as in "auto"? |
| 21:09 | <TabAtkins> | Whatever the computed value is, yeah. |
| 21:10 | TabAtkins | wonders what it returns today. |
| 21:10 | <zcorpan> | nobody implements .usedStyle i think |
| 21:10 | <TabAtkins> | Right, I'm wondering about gcs. |
| 21:10 | <zcorpan> | gCS returns the ... old ... used style |
| 21:10 | <zcorpan> | so 123px |
| 21:11 | <TabAtkins> | I get "auto" in chrome. |
| 21:11 | <zcorpan> | yeah but everyone else uses the layouted width iirc |
| 21:11 | <TabAtkins> | Bleh. |
| 21:11 | <TabAtkins> | Well, at least we have an argument to the contrary. ^_^ |
| 21:12 | <zcorpan> | i thought gCS needed to return the layouted width for compat, but maybe webkit/blink not doing it means it can be changed? |
| 21:12 | <TabAtkins> | width/height are a bit magical in that they can be argued to be meaningful for all boxes, even when they don't have an effect. |
| 21:12 | <TabAtkins> | Yeah. |
| 21:13 | <zcorpan> | at least gCS was first implemented with the CSS2.0 semantics of computed style, which later changed but browsers didn't change what gCS returned |
| 21:14 | <TabAtkins> | Yeah, which is why we had to invent the "resolved style" term. |
| 21:14 | <TabAtkins> | I'll compose a thread. |
| 21:14 | <zcorpan> | ok. thakns! |
| 21:20 | <TabAtkins> | zcorpan: Hm, cssom already defines its way around this, doesn't it? It says "if the proeprty applies to the element... the resolved value is used value. Otherwise, the resolved value is the computed value." |
| 21:21 | <zcorpan> | TabAtkins: hum, that would mean chrome is correct per spec |
| 21:21 | <TabAtkins> | Yeah. |
| 21:21 | <zcorpan> | TabAtkins: but i thought the spec was intended to match the others |
| 21:21 | <TabAtkins> | Shrug. |
| 21:21 | <zcorpan> | relevant thing is what to do next :-) |
| 21:23 | <TabAtkins> | Yeah, we're consistent with all five of the special properties. |