| 00:07 | <volkmar> | Hixie: I guess so |
| 00:13 | <Hixie> | volkmar: TabAtkins might know |
| 09:51 | <jgraham> | odinho: In test metadata is seriously overrated |
| 09:51 | <jgraham> | Please don't makework people with it :) |
| 10:17 | <odinho> | jgraham: author is extremely helpful |
| 10:18 | <odinho> | jgraham: The help-assert things not as much right now. But for IDB, I did add lots of asserts etc to the tests, and had a script hilight the parts of the spec that was covered. |
| 10:18 | <odinho> | jgraham: That was very helpful. |
| 10:18 | <jgraham> | odinho: Happily git provides that information for you |
| 10:18 | <jgraham> | And with the directory structure thing you get close to help-assert with no effort |
| 10:18 | <marcosc> | Is it true that all the kids are no longer using booleans in APIs? That they prefer strings even in cases where things are clearly suited to be a boolean data type? |
| 10:19 | jgraham | goes looking for a five year old to ask |
| 10:19 | <odinho> | marcosc: ... No? Strings instead of stupid integers. |
| 10:19 | <odinho> | So called constants. |
| 10:19 | <marcosc> | yeah, that one makes sense |
| 10:19 | <marcosc> | but ... |
| 10:19 | <marcosc> | see this: http://www.w3.org/TR/2013/WD-web-alarms-20130205/#interface-alarmmanager |
| 10:19 | <jgraham> | marcosc: It is certainly true that a) people are using strings rather than named constants and b) there is a school of thought that bools in APIs are always bad |
| 10:20 | <marcosc> | the enum in that API |
| 10:20 | <marcosc> | enum TimezoneDirective { "respectTimezone", "ignoreTimezone" }; |
| 10:20 | <marcosc> | seems kinda silly to have a required enum that is just a boolean |
| 10:20 | <jgraham> | Well |
| 10:21 | <odinho> | marcosc: More readable |
| 10:21 | <jgraham> | The theory is that AlaramManager.add(some_date, true) |
| 10:21 | <marcosc> | odinho: right, it's more readable, but the type could still be a boolean |
| 10:21 | <odinho> | marcosc: although camelCase bloat is superugly. |
| 10:21 | <jgraham> | is impossible to understand without the API documentation to ahnd |
| 10:21 | <jgraham> | *hand |
| 10:21 | <marcosc> | AlaramManager.add(some_date, "respectYo") |
| 10:21 | <marcosc> | would still work just fine |
| 10:22 | <marcosc> | if the type was boolean |
| 10:22 | <odinho> | marcosc: lol, but people won't write that |
| 10:22 | <jgraham> | Woah |
| 10:22 | <odinho> | marcosc: And doesn't for false |
| 10:22 | <jgraham> | That's crazy |
| 10:22 | <odinho> | And it is crazy |
| 10:22 | <odinho> | ^_^ |
| 10:22 | <marcosc> | sure, it's crazy |
| 10:22 | <odinho> | So, down with the crazy man |
| 10:22 | <jgraham> | Personally, I would have set a default for respectTimezone and had |
| 10:23 | <marcosc> | I agree |
| 10:23 | <odinho> | Mm. |
| 10:23 | <marcosc> | jgraham: it should be optional |
| 10:23 | <jgraham> | AlarmManager.add(data, {respectTimezone:false, data:[]}) |
| 10:23 | <odinho> | Coolest kids use that these days. |
| 10:23 | <odinho> | It's in IDB |
| 10:23 | <odinho> | why double data? |
| 10:23 | <marcosc> | IDB is hated by all the kids |
| 10:23 | <jgraham> | odinho: Those two sentences don't agree :) |
| 10:23 | <odinho> | ah, you misspelled date |
| 10:24 | <jgraham> | Yeah |
| 10:24 | <odinho> | IDB is cool, man. |
| 10:24 | <jgraham> | date as a required parameter |
| 10:24 | <jgraham> | and the bool as an optional, named, parameter |
| 10:24 | <marcosc> | check all the hate at the bottom of http://www.html5rocks.com/en/tutorials/indexeddb/todo/http://www.html5rocks.com/en/tutorials/indexeddb/todo/ |
| 10:24 | <marcosc> | http://www.html5rocks.com/en/tutorials/indexeddb/todo/ |
| 10:24 | <marcosc> | even |
| 10:24 | <jgraham> | Or at least as some fake due to js deficiencies in this area |
| 10:26 | <marcosc> | seems like bad design in IDB that you have to wrap all your operations in a function, leads to a lot of bloat and you can't write the code atomically (e.g., in the browser's JS console) |
| 10:27 | <jgraham> | Well it has to be async |
| 10:28 | <marcosc> | yes, I get that. But setting event handlers after you start an operation seems a bit ... um... strange |
| 10:28 | <jgraham> | Well |
| 10:28 | <jgraham> | It makes sense if you understand the model |
| 10:29 | <jgraham> | Doesn't mean that it couldn't be better of course |
| 10:29 | <jgraham> | But I'm not sure what you are proposing as better |
| 10:29 | <marcosc> | Don't get me wrong, I get the model. It's just assumes that the code is all self contained in a file. |
| 10:31 | <marcosc> | jgraham: true, I'm not really proposing anything I guess. I guess most people would expect making, for instance, and OpenDBRequest (onsucces, onfail set), and then OpenRequst.open() |
| 10:31 | <marcosc> | OpenDBRequest even |
| 10:32 | <marcosc> | instead of function(){ ... do a bunch of DB stuff ...}(); |
| 10:33 | <marcosc> | the above takes all the fun out of async programming |
| 10:33 | <marcosc> | because it forces the actual javascript to be programmed as if it is sync by needing to wrap everything in a function |
| 10:35 | <marcosc> | Anyhooo |
| 10:35 | <odinho> | I prefer how it is now to that. :-) |
| 10:35 | <marcosc> | why is that? |
| 10:37 | <jgraham> | The callback style does tend to lead to spaghetti. And isn't really a pattern in the platform. |
| 10:37 | <jgraham> | Maybe you could make something based on promises |
| 10:38 | <marcosc> | promises would be nice |
| 10:38 | <jgraham> | Which would at least flatten out the spagetti |
| 10:38 | <odinho> | It is promises now, is it not? |
| 10:38 | <jgraham> | It's event based now isn't it? |
| 10:38 | <marcosc> | I thought it was all strings and no booleans? |
| 10:39 | <marcosc> | It's events by the looks of it |
| 10:39 | <odinho> | Yeah events, -- I didn't think they excluded eachother. |
| 10:39 | <odinho> | Promises work on top of events, do they not? |
| 10:40 | <jgraham> | Well, maybe given an event api you can write a promised, based API |
| 10:40 | <jgraham> | I'm not sure |
| 10:40 | <marcosc> | I'm not sure either |
| 10:40 | <jgraham> | But they are not identical at least |
| 11:48 | <annevk> | Man that spec is poorly written :( |
| 11:48 | <annevk> | http://sysapps.github.com/sysapps/proposals/alarm/Overview.html that is |
| 11:49 | <marcosc> | it's only a FPWD |
| 11:49 | <marcosc> | but yeah |
| 11:49 | <marcosc> | annevk: do you have any opinions about the whole http://sysapps.github.com/sysapps/proposals/alarm/Overview.html#interface-alarmrequest |
| 11:50 | <annevk> | Apart from it not being written properly? |
| 11:50 | <marcosc> | yeah |
| 11:50 | <annevk> | getAll() has the wrong signature |
| 11:50 | <marcosc> | Look at that AlarmRequest thing |
| 11:50 | <annevk> | enums should not use camelcase |
| 11:50 | <marcosc> | It's like a bad mix of events and callbacks |
| 11:51 | <annevk> | It's just events no? |
| 11:51 | <marcosc> | except for the error attribute |
| 11:51 | <annevk> | Except they're using some ancient syntax to declare event handlers |
| 11:51 | <marcosc> | yeah, just ignore that |
| 11:51 | <marcosc> | that's easy to update |
| 11:52 | <marcosc> | I'm about to do a pull request and fix all those |
| 11:52 | <marcosc> | I'm more concerned about the whole AlarmRequest model |
| 11:52 | <marcosc> | and the fact that this adds yet another database to the web platform |
| 11:52 | <marcosc> | (well, at least it tries to) |
| 11:53 | <karlcow> | :) |
| 11:53 | <karlcow> | one db for all |
| 11:53 | <marcosc> | sure, why not :) |
| 11:53 | <karlcow> | (my precious) |
| 11:54 | <annevk> | marcosc: I just looked at it high-level, actually reviewing would take more time |
| 11:54 | <marcosc> | annevk: fair enough |
| 11:54 | <annevk> | marcosc: maybe slightlyoff can yell at them so we don't have to :) |
| 11:55 | <marcosc> | heh, that would be nice :) |
| 11:57 | <annevk> | Hmm, need to install XCode again forgot about that |
| 11:57 | <annevk> | kinda happy I wrote that blog post now |
| 11:57 | <marcosc> | new mac, eh? Always fun :) |
| 11:58 | <annevk> | yeah and it's awesome |
| 11:58 | <annevk> | have to get used to not rebooting it all the time |
| 11:58 | <marcosc> | My main motivation for trying to get to the TAG meeting is so I can go shopping at the Mac Store :) |
| 11:58 | <marcosc> | So much cheaper in the US |
| 12:00 | <annevk> | Would be nice to say hi too :) |
| 12:01 | <annevk> | What's the canonical URL for Opera Nightly? |
| 12:02 | <jgraham> | There isn't one, I don't think |
| 12:02 | <jgraham> | I mean there is the desktop team blog |
| 12:02 | <annevk> | doh http://www.opera.com/browser/next/ |
| 12:02 | <annevk> | or is that not it? |
| 12:02 | <jgraham> | Well yeah |
| 12:03 | <jgraham> | But that isn't always the actual latest version |
| 12:03 | <marcosc> | annevk: I usually just go to the desktop blog |
| 14:23 | <annevk> | Hmm, to install Anolis I need to have hg? |
| 14:24 | <annevk> | Maybe Anolis should move to GitHub |
| 14:27 | <MikeSmith> | annevk: you gotta have hg to build firefox |
| 14:28 | <annevk> | babysteps |
| 14:28 | <darobin> | putting Anolis on GH would certainly be nicer |
| 14:29 | <darobin> | for one it would make it possible to have it in a submodule when it's a dependency |
| 14:30 | <jgraham> | You can get Mozilla on git also these days |
| 14:30 | <jgraham> | You might need hg to commit |
| 14:31 | <jgraham> | https://github.com/mozilla/mozilla-central |
| 14:34 | <MikeSmith> | jgraham: oh didn't know |
| 14:49 | <MikeSmith> | so btw it seems we are definitely going to have a WebApps WG meetup on April 25 and 26 in California |
| 14:49 | <MikeSmith> | and HTML WG on 23 and 24 |
| 14:50 | <MikeSmith> | and I think WebAppSec on 23 and 24 as well |
| 14:52 | <Ms2ger> | annevk, so you're becoming lead editor for sysapps? |
| 14:53 | <MikeSmith> | 'git push origin master:gh-pages' to push current master /wo extra local gh-pages branch |
| 14:54 | <MikeSmith> | dinnet know you could do that |
| 14:54 | <MikeSmith> | https://twitter.com/jviereck/status/299032009156726784 |
| 14:56 | <jgraham> | MikeSmith: The git bit or the github bit? |
| 14:57 | <MikeSmith> | git bit |
| 14:57 | <jgraham> | Ah |
| 14:57 | <MikeSmith> | can you use that locally too? |
| 14:57 | <jgraham> | You can even write HEAD instaed of master to push the head of the working branch. Or any random SHA1 |
| 14:57 | <MikeSmith> | ok |
| 14:58 | <MikeSmith> | d'oh forget what I asked about locally |
| 14:58 | <MikeSmith> | obviously not relevant for push 'ing |
| 15:44 | <zewt> | eh, is there really no way to tell box-shadow to draw the whole shadow and not cut out the box |
| 16:14 | <kerozene> | I wish. would make transparent borders more fun |
| 16:23 | <annevk> | Ms2ger: euh no :) |
| 16:23 | <annevk> | Ms2ger: trying to fix a bug in DOM |
| 16:23 | <annevk> | Ms2ger: but the meetings slow me down |
| 16:24 | <Ms2ger> | Heh |
| 16:24 | <Ms2ger> | And if you don't go there, they just have you do attrexodus :) |
| 16:25 | <annevk> | Ms2ger: exactly, we assign action items to pseudonymous external contributors |
| 16:25 | <Ms2ger> | Damn you all! :) |
| 16:31 | <Ms2ger> | Hmm, CSS discussing <!--/--> in style sheets |
| 16:51 | <annevk> | Ms2ger: what's there to discuss? |
| 16:53 | <Ms2ger> | Whether they're allowed in variables, aiui |
| 16:56 | <annevk> | Good times |
| 16:57 | <annevk> | Ms2ger: so uh, put Anolis under WHATWG? |
| 16:57 | <annevk> | Ms2ger: then I won't have to install hg |
| 16:57 | annevk | has reached the point where Anolis is the bottleneck |
| 16:58 | annevk | decides to not let Ms2ger be a bottleneck |
| 17:00 | <Ms2ger> | wfm :) |
| 17:09 | <annevk> | Hmm, how can installing command line tools possibly fail? |
| 17:27 | <annevk> | oh yes |
| 17:27 | <annevk> | it works |
| 17:27 | <annevk> | why o why did /usr/local/bin become permission denied? |
| 17:27 | <annevk> | so weird |
| 17:37 | <hsivonen> | has the SETTINGS: prefer-online thing always been there for app cache? |
| 17:38 | <hsivonen> | I don't see prefer-online on MXR. strongly suggests we don't support it |
| 17:38 | <hsivonen> | does Chrome? |
| 17:39 | <hsivonen> | not found in https://mxr.mozilla.org/chromium/search?string=prefer-online either |
| 17:40 | <hsivonen> | so is the SETTINGS part of the spec fiction? |
| 17:41 | <hsivonen> | ah. it was not always there: http://labs.ft.com/2012/07/prefer-online-not-so-much/ |
| 17:45 | <hsivonen> | we really need spec edits to start with red background that fades to white over time |
| 17:45 | <hsivonen> | so that you could tell new fiction from real stuff |
| 17:45 | <Ms2ger> | What colour would the navigation stuff be? :) |
| 17:46 | <annevk> | Ms2ger: go create Attr objects :p |
| 17:47 | <Ms2ger> | That's on my todo list for tomorrow ;) |
| 17:49 | <dglazkov> | good morning, Whatwg! |
| 17:49 | <hsivonen> | does IE10 support prefer-online? |
| 18:07 | <annevk> | Ms2ger: sweet |
| 18:09 | <hsivonen> | whoa whoa. Hixie basically advocates news sites and blogs to become Ajax apps instead of traditionally crawlable pages in https://www.w3.org/Bugs/Public/show_bug.cgi?id=14702#c20 |
| 18:11 | <nimbu> | hsivonen: are you gawker.com |
| 18:13 | <hsivonen> | nimbu: no, but what Hixie advocated in that bug is pretty shocking considering how people who try to use the app cache disagree |
| 18:18 | <hsivonen> | did IE10 extend app cache somehow? |
| 18:20 | <hsivonen> | :-( https://www.w3.org/Bugs/Public/show_bug.cgi?id=14702#c31 |
| 18:21 | <hsivonen> | Hixie: do you have a proposed set of changes to HTTP cache management that would address all the online acceleration use cases app cache is used for? |
| 18:24 | <hsivonen> | in the Client-Hints case, the person proposing it is a server module dev and has an HTTP hammer |
| 18:25 | <annevk> | hsivonen: yeah IE has extensions |
| 18:25 | <hsivonen> | but then in most other cases, devs want non-HTTP solutions, because HTTP headers are too hard |
| 18:25 | <hsivonen> | (though Client-Hints is a request header and response headers are too hard) |
| 18:25 | <hsivonen> | annevk: I didn't find them on MSDN. URL? |
| 18:26 | <hsivonen> | the prefer-online thing is so sad |
| 18:26 | <hsivonen> | it should be prefer-online-if-newer-than: 5min |
| 18:26 | <annevk> | I think you can find them in W3C Bugzilla |
| 18:27 | <annevk> | a WONTFIXed bug somewhere |
| 18:29 | <annevk> | https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&list_id=4905&short_desc=appcache&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&short_desc_type=allwordssubstr |
| 18:38 | <Ms2ger> | OH: "Bert resisting" |
| 20:13 | <Hixie> | hsivonen: um, no. i advocate _applications_ with data to be ajaxified. |
| 20:13 | <Hixie> | hsivonen: in general if you could just assume i'm not an idiot and interpret my statements in that light, that would help :-) |
| 20:14 | jgraham | isn't clear what's an application and what's a document |
| 20:14 | <jgraham> | e.g. is the new blogger an application or a document? |
| 20:14 | <Hixie> | hsivonen: well, it's a continuum |
| 20:14 | <esprehn> | jgraham: number of bytes of JS ;) |
| 20:14 | <jgraham> | esprehn: In that case it's an application for sure :) |
| 20:15 | <Hixie> | but generally speaking, a document is something that you give to other people to read, whereas an application is something that you log into to edit data |
| 20:15 | <Hixie> | er, s/hsivonen/jgraham/ in my most recent use of "hsivonen" |
| 20:16 | <Hixie> | hsivonen: dunno if it solves everything, but https://www.w3.org/Bugs/Public/show_bug.cgi?id=20083 is one proposal. |
| 20:17 | <Hixie> | hsivonen: for reasons i don't understand, the main people interested in appcache keep doing things in f2f meetings and the like instead of commenting on the whatwg list |
| 20:17 | <Hixie> | (or any other public list for that matter) |
| 20:21 | <jgraham> | Yes, I feel totally out of the loop on app-cache |
| 20:21 | <jgraham> | But on the other hand |
| 20:22 | <jgraham> | It seems fitting that all the discussions are happening off line |
| 20:22 | <esprehn_> | have things changed in app cache? |
| 20:22 | <Hixie> | hah |
| 20:22 | <Hixie> | esprehn_: not in the last few days |
| 20:23 | <Hixie> | i think medium term the next news on appcache will be some sort of generic network-layer filter |
| 20:23 | <Hixie> | that runs JS in its own thread and can respond to requests either by passing them through, or generating files, or getting files from a cache |
| 20:23 | <Hixie> | the biggest thing blocking that, i think, is lack of a good place to store files |
| 20:25 | <jgraham> | Woah |
| 20:25 | <jgraham> | That sounds scary |
| 20:25 | <Hixie> | that's what https://www.w3.org/Bugs/Public/show_bug.cgi?id=20083 is about |
| 20:27 | <esprehn_> | This has come up several times internally at Google |
| 20:27 | <esprehn_> | no one wants a manifest file, you want to be able to say "requests to http://xxx.com/ should go to a worker instead" |
| 20:27 | <jgraham> | Bugzilla makes it very easy to not know about these conversations |
| 20:28 | <Hixie> | esprehn_, jgraham: yeah, i keep telling people to post to the whatwg list |
| 20:28 | <Hixie> | the only public discussion i was able to get was that brain dump in the bug |
| 20:28 | <Hixie> | we're not going to get anywhere until people can discuss this publicly |
| 20:28 | <jgraham> | It explains why the whatwg list is so quiet these days |
| 20:28 | <jgraham> | If everyone is ghettoising |
| 20:29 | <esprehn_> | Hixie: I'll see if I can dig up our diagram from the architecture for that |
| 20:29 | <jgraham> | Anyway, without reading any of the bug, I wonder if this will avoid the problems of autoproxy |
| 20:29 | <esprehn_> | Hixie: you need magic for things like HttpOnly cookies to work |
| 20:30 | <jgraham> | Not that I remember exactly what those problems *are* |
| 20:30 | <jgraham> | But obviously badly behaved scripts can be problematic if they block network reqiests |
| 20:30 | <jgraham> | *requests |
| 20:31 | <jgraham> | (maybe this is less problematic if it is same-origin only) |
| 20:31 | <Hixie> | esprehn_: what's really needed is just a description of the problems we're trying to solve. even the brain dump in the bug is mostly talking about solutions, not problems. |
| 20:31 | <Hixie> | jgraham: this would be on a worker thread, and same-origin only. |
| 20:31 | <Hixie> | jgraham: (or rather, per-origin; i suppose an origin can provide a worker for when it's accessed from another?) |
| 20:32 | <esprehn_> | Hixie: I'll see if I can gather my notes from the discussions. There were just more pressing things at the time like Web Components |
| 20:32 | <Hixie> | jgraham: so you couldn't really do anything you can't do already on the server, in terms of harm. |
| 20:32 | <jgraham> | Yeah, being in a worker helps of cource since you can't block the event loop |
| 20:33 | <esprehn_> | effectively you want a persistent worker per origin, perhaps with some path prefixing logic |
| 20:34 | <esprehn_> | You run into issues with http://www.google.com/calendar/ and /images/ and other apps. They each need their own. |
| 20:36 | <Hixie> | the biggest problem i see is how to bootstrap without adding latency for first load yet without making first load avoid using the worker... |
| 20:37 | <Hixie> | the obvious way is to send a header with the request that says "if you recognise this, then instead of sending me back the page, send me back the worker", but you still add at least one RTT to the cost |
| 20:37 | <Hixie> | (and you add a header, which is itself bad) |
| 20:37 | <esprehn_> | what's the issue with the header? |
| 20:38 | <Hixie> | you have to send it on every request, so it costs global bandwidth; plus it adds a fingerprinting bit, plus it runs compat risks |
| 20:39 | <Hixie> | i guess the fingerprinting bit in this case would be correlated with the UA string so it wouldn't add a whole bit |
| 20:39 | <esprehn_> | heh, stick it on favicon |
| 20:39 | <Hixie> | wouldn't solve the path problem |
| 20:40 | <esprehn_> | sorry, which path problem? |
| 20:40 | <Hixie> | the one you mentioned, /calendar vs /mail |
| 20:40 | <Hixie> | nor does it solve the RTT issue |
| 20:41 | <esprehn_> | well, the header could specify which path it pertains to |
| 20:41 | <esprehn_> | or a table of paths |
| 20:41 | <Hixie> | oh you mean a header on the response |
| 20:41 | <Hixie> | interesting |
| 20:41 | <Hixie> | i meant on the request |
| 20:42 | <esprehn_> | ah no, the server should respond back with a table of delegates |
| 20:42 | <Hixie> | header on the response could work, though it still doesn't solve the RTT issue -- in fact it makes it worse |
| 20:42 | <Hixie> | now you have to do 3 RTTs to do what today uses just one |
| 20:42 | <esprehn_> | 3? |
| 20:42 | <Hixie> | 4, i guess |
| 20:43 | <esprehn_> | we decided it was probably fine for first request to hit the server unless the worker was already running |
| 20:43 | <Hixie> | 1 for TCP handshake, 1 for getting the index file, which you then drop because you see the header with this script, one to get the script, and one to get the data. |
| 20:44 | <Hixie> | well it would be pretty hard for the first request not to hit the server if you don't know about the worker :-P |
| 20:44 | <esprehn_> | right |
| 20:44 | <esprehn_> | I don't think you should need to pipe through the worker |
| 20:44 | <Hixie> | anyway, 4 RTTs just to get what today takes 2 is a big latency hit |
| 20:45 | <esprehn_> | so it wouldn't be 4 RTTs |
| 20:45 | <esprehn_> | you'd never "drop the current request", the header only applies to subsequent requests |
| 20:46 | <Hixie> | that's the "without making first load avoid using the worker" problem i was trying to solve |
| 20:46 | <Hixie> | it's pretty horrible to have a system where the very first time you try to use it, it doesn't work the way it's supposed to. |
| 20:46 | <Hixie> | not that i see another solution, but it doesn't make it any less lame |
| 20:47 | <esprehn_> | yeah, I think it's a reasonable compromise |
| 20:47 | <Hixie> | compromises suck. |
| 20:48 | <Hixie> | :-) |
| 20:49 | <esprehn_> | I don't know of any solution that isn't a compromise on the web |
| 20:49 | <esprehn_> | :) |
| 20:49 | <Hixie> | well, yeah |
| 20:49 | <Hixie> | but i keep hoping! |
| 20:49 | <Hixie> | one day! |
| 20:49 | <Hixie> | we shall solve a problem well! |
| 20:49 | <esprehn_> | cupcakes and ponies! |
| 21:19 | <Hixie> | is it just me or does this page not actually show the diff? https://github.com/w3c/html/commit/3d85bac87355240a433865ec56074a80c33a271d |
| 21:19 | <Hixie> | and how do i get to see the diff? |
| 21:21 | <miketaylr> | Hixie: https://github.com/w3c/html/commit/3d85bac87355240a433865ec56074a80c33a271d.diff |
| 21:21 | <miketaylr> | add .diff? |
| 21:21 | <Hixie> | is there ui for that? |
| 21:21 | <miketaylr> | oh, dunno |
| 21:21 | <Hixie> | or are we supposed to divine it |
| 21:21 | <Hixie> | (thanks, btw) |
| 21:22 | <gavinc> | Hixie: it looks like github decided that was a binary file, thus the lack of diff showing up on the page |
| 21:22 | <Hixie> | i see |
| 21:23 | <Hixie> | poor file doesn't have a single 8th bit set anywhere, but ok github :-) |
| 21:23 | <gavinc> | I imagine it has a size trigger ;) |
| 21:23 | <Hixie> | (or at least my version doesn't, i guess it's possible the htmlwg's does) |
| 21:23 | <gavinc> | Most source files aren't 5mb |
| 21:23 | <Hixie> | pah |
| 21:44 | <Hixie> | two questions: |
| 21:44 | <Hixie> | (a) why doesn't https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm define the actual event processing model? or am i missing something? |
| 21:44 | <Hixie> | (b) why doesn't it document the actually implemented 'mousewheel' event with wheelDelta, or am I missing something? |
| 22:19 | <Hixie> | MikeSmith: yt? |
| 22:28 | <Hixie> | MikeSmith: nm, i asked my question in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20068 |
| 22:40 | <rillian> | Hixie: re bug 20889, I think I'm misunderstanding how this section is written in general |
| 22:41 | Hixie | looks |
| 22:41 | <Hixie> | ah |
| 22:41 | <Hixie> | one sec |
| 22:41 | <rillian> | I have the same question with srclang |
| 22:41 | <Hixie> | see http://whatwg.org/html/#how-to-read-this-specification :-) |
| 22:41 | <rillian> | is one a guide for authors and the other parsing instructions |
| 22:41 | <Hixie> | (ignore paragraph 1) |
| 22:42 | <Hixie> | (about reading it cover to cover) |
| 22:42 | <rillian> | :) |
| 22:43 | <rillian> | ok, that helps |
| 22:43 | <Hixie> | cool |
| 22:43 | <rillian> | I'm still unclear how one tells which is which |
| 22:43 | <rillian> | maybe IETF specs have warped my mind |
| 22:43 | <Hixie> | just read it literally |
| 22:43 | <Hixie> | if it says "it must be empty", then when you generate it, you make sure it's empty |
| 22:44 | <Hixie> | if it says "if it's not empty", then if it's not empty, you follow the requirement |
| 22:44 | <Hixie> | you don't reject anything unless it says "you must reject" or some such |
| 22:45 | <Hixie> | (i'm assuming you're writing a browser) |
| 22:45 | <Hixie> | (if you're writing an editor or conformance checker, it's different) |
| 22:47 | <rillian> | yes, browser in this case |
| 22:48 | <rillian> | ok, thanks for explaining |
| 22:48 | <Hixie> | np. if it's still unclear don't hesitate to ask further. |