| 00:00 | <TabAtkins> | You mean starDate. |
| 00:02 | <Hixie> | oops |
| 00:02 | <Hixie> | wait, no |
| 00:02 | <Hixie> | i thought you meant i had actually done that |
| 00:03 | <TabAtkins> | You need to quit listening to me. |
| 00:03 | <Hixie> | indeed |
| 00:03 | <Hixie> | :-P |
| 00:17 | <zewt> | http://groups.google.com/group/mongodb-user/browse_thread/thread/04d5a8148a9cc557 and you thought initMouseEvent had too many arguments |
| 00:17 | <zewt> | message = struct.pack("<i", 16 + len(data))\n\nerror: pack requires exactly 3415645423173094629 arguments\n') |
| 00:26 | <TabAtkins> | Hahaha |
| 02:07 | <roc_> | Hixie: I thought Opera tried to implement it |
| 02:09 | <roc> | Hixie: by the way, I have a question about Workers ... what would you think of an extension to postMessage that takes an extra string argument representing the global-scope function to be invoked (instead of the onpostmessage handler)? |
| 02:13 | <Hixie> | roc: yeah, opera were the ones asking for the rename |
| 02:13 | <zewt> | i wouldn't like having global functions in my workers executable like that; it's exposing something as an API that i probably didn't intend to be |
| 02:13 | <zewt> | prefer to have the entry points better defined |
| 02:14 | <Hixie> | roc: for Worker.postMessage? |
| 02:14 | <Hixie> | roc: that sounds pretty messed up, especially once we do cross-origin workers :-) |
| 02:14 | <Hixie> | roc: can't the other end implement that manually if they want to? |
| 02:15 | <Hixie> | function (event) { self[event.data.function].apply(event.data.arguments) } or some such |
| 02:18 | <roc> | yes |
| 02:18 | <roc> | perhaps you could chime in on this thread: http://lists.w3.org/Archives/Public/public-audio/2012JanMar/0343.html |
| 02:18 | <roc> | one of your friends at Google wants to add something like that |
| 02:18 | <zewt> | ... and he's discussing it on public-audio? |
| 02:18 | <roc> | it's specifically for audio (or media) processing |
| 02:19 | <zewt> | if it's a worker feature, it's not |
| 02:19 | <Hixie> | roc: your e-mail seems to pretty much summarise what i would say :-) |
| 02:19 | <roc> | the idea is you might have a Worker handling several different kinds of processing and he wants to be able to dispatch to particular processing callbacks instead of a single event handler like I'm proposing |
| 02:20 | <roc> | Hixie: OK, but your input might carry more weight |
| 02:20 | <Hixie> | if there's a working group in which the same argument from two different people carries different weight with the relevant spec editor, that should be stamped out immediately |
| 02:20 | <roc> | Hixie: I know you don't approve of such authority, but it's still a reality |
| 02:20 | <zewt> | Hixie: severe idealism :) |
| 02:23 | <Hixie> | roc: do you have a link to the e-mail in which Dmitry first suggests it |
| 02:23 | <Hixie> | ? |
| 02:25 | <roc> | http://lists.w3.org/Archives/Public/public-audio/2012JanMar/0245.html |
| 02:25 | <roc> | item 2 |
| 02:26 | <Hixie> | thanks |
| 02:27 | <Hixie> | what is onprocessmedia? |
| 02:27 | <roc> | that's my proposal |
| 02:27 | <roc> | https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html#worker-processing |
| 02:28 | <Hixie> | oh so you pass a worker to the audio system and it starts sending these special messages? |
| 02:28 | <roc> | yes |
| 02:29 | <Hixie> | if you have a custom mechanism like that why not just have a way to register lots of different event handlers with different event names? |
| 02:29 | <Hixie> | a bit like what EventSource does |
| 02:29 | <Hixie> | or indeed without using event handlers at all, if cpu is a concern |
| 02:30 | <Hixie> | just have a dedicated registration mechanism |
| 02:31 | <Hixie> | worker.registerMediaHandler('handlerType', function (whateverIsNeeded) {}); |
| 02:31 | <Hixie> | not sure how the UA decides what to send to the worker, so i'm not sure how you decide the handlerTypes |
| 02:31 | <Hixie> | bbiab |
| 02:56 | <roc> | right now onprocessmedia is like onmessage, it's not a full-fledged event handler, just a Function? callback |
| 02:56 | <roc> | a dedicated registration system seems like overkill |
| 02:57 | <roc> | the page author always chooses which callback should be invoked, there's no types or anything like that to dispatch on. Each callback represents a different kind of processing effect supported by the worker. |
| 02:57 | <roc> | in the simple case, each Worker only supports one kind of processing and the onprocessmedia callback is fine |
| 05:01 | <Hixie> | roc: onmessage is a fully fledged event handler |
| 05:02 | <Hixie> | roc: i don't really understand why there's a need for a dispatching thing then. or how it would work. |
| 05:05 | <roc> | "[TreatNonCallableAsNull] attribute Function? onmessage;" ... that's a fully fledged event handler? |
| 05:07 | <Hixie> | that's just an attribute. what makes it fully fledged is "The following are the event handlers (and their corresponding event handler event types) that must be supported, as IDL attributes, by objects implementing the DedicatedWorkerGlobalScope interface: Event handler: onmessage Event handler event type: message" |
| 05:07 | <roc> | ok |
| 05:08 | <roc> | when you associate a worker with an audio stream, the idea is that normally the UA perodically invokes whatever was assigned to the onprocessmedia callback to process the audio. Dmitry argues that we might want to associate a single worker with multiple streams (to save resources), and furthermore that the processing required for each stream might be different, so we should support the... |
| 05:08 | <roc> | ...ability to pass the name of a function which gets called |
| 05:08 | <roc> | instead of routing everything through the single callback |
| 05:08 | <Hixie> | ah |
| 05:08 | <Hixie> | huh |
| 05:08 | <Hixie> | interesting |
| 05:08 | <Hixie> | wouldn't such a worker be stateful? |
| 05:08 | <roc> | he claims that's more convenient and more performant than doing dispatch manually |
| 05:08 | <roc> | yes |
| 05:08 | <Hixie> | even if it only did one thing? |
| 05:09 | <roc> | these workers are stateful |
| 05:09 | <Hixie> | so you wouldn't want to dispatch based on a different method |
| 05:09 | <Hixie> | you'd want to dispatch based on state |
| 05:09 | <roc> | no, the dispatch isn't stateful |
| 05:10 | <roc> | the dispatch is for cases like "stream A wants the echo effect, stream B wants the high-pass filter effect, and stream C wants the fade effect" |
| 05:10 | <Hixie> | what if streams A and B want an echo effect |
| 05:10 | <roc> | then they'd both specify the same effect function I guess |
| 05:11 | <Hixie> | wouldn't that then mean that the echoes would stomp on each other? |
| 05:11 | <roc> | ah |
| 05:11 | <Hixie> | if i were designing a system to support that, i would have an event that fires when a media thingy starts using the worker, and that handler would have a handle that you can use to register a callback (not dom event based) for that media thingy. |
| 05:11 | <roc> | the per-stream state should be attached as expandos to the event object passed into the callback, which is defined to be one per stream |
| 05:12 | <Hixie> | so you're passing the same object again and again? |
| 05:12 | <roc> | yes |
| 05:12 | <Hixie> | please don't make it inherit from Event |
| 05:12 | <roc> | too late, but I can fix that. Why? |
| 05:12 | <Hixie> | what you're describing is nothing like events, it's some weird new callback system |
| 05:13 | <Hixie> | Event objects have all kinds of dispatch state |
| 05:13 | <roc> | why? just because of the reuse? |
| 05:13 | <Hixie> | DOM Events have a number of key characteristics: |
| 05:13 | <Hixie> | - you can register more than one handler for each event type |
| 05:13 | <Hixie> | - they have a dispatch mechanism and can be redispatched |
| 05:14 | <Hixie> | - they have bubbling and capture modes |
| 05:14 | <Hixie> | - they can be cancelled, or have propagation aborted |
| 05:14 | <Hixie> | and all kinds of other subtle things |
| 05:14 | <Hixie> | you just want a callback |
| 05:14 | <roc> | ok |
| 05:14 | <Hixie> | which is passed a dedicated object over and over |
| 05:14 | <roc> | thanks |
| 05:14 | <roc> | I gotta go for now |
| 05:14 | <Hixie> | k |
| 05:14 | <roc> | I'll look into that |
| 05:14 | <Hixie> | ttyl |
| 05:14 | <Hixie> | cc me on the next mail in that thread |
| 05:14 | <Hixie> | and i can chip in advice if you like |
| 05:18 | <Hixie> | hober, tantek, TabAtkins: did we ever decide where we were meeting tomorrow? |
| 05:20 | <tantek> | I remember lunch. |
| 05:20 | <tantek> | in Mountain View |
| 05:20 | <tantek> | Hixie, shall we meet at your usual spot? |
| 05:21 | <Hixie> | the b43 lobby? |
| 05:21 | <Hixie> | works for me |
| 05:21 | <tantek> | oh new usual spot ok |
| 05:21 | <Hixie> | what was the old usual spot? :-) |
| 05:21 | <tantek> | the place where you've always ordered the same one dish |
| 05:21 | <Hixie> | oh la fiesta |
| 05:21 | <Hixie> | still only ever ordered that one dish btw! |
| 05:22 | <Hixie> | no i think hober and TabAtkins planned to meet at google |
| 05:22 | <tantek> | "at Google" is a bit vague ;) |
| 05:22 | <Hixie> | hence my asking :-) |
| 05:25 | <Hixie> | TabAtkins, hober, tantek: ok i'm going to assume we'll meet at the b43 lobby at whatever time it is tab organised. if you decide otherwise, drop me an e-mail or /msg me or something. |
| 05:26 | <Hixie> | back later |
| 05:43 | <tantek> | Hixie, cool. looks like about a 4 mile bike ride from Mozilla / Castro st. |
| 05:44 | <tantek> | I'm going to assume noon unless I hear otherwise |
| 07:32 | <annevk> | didn't realize Web IDL has both octet and byte... |
| 07:32 | <annevk> | and byte is signed |
| 07:41 | <hsivonen> | annevk: that's confusing |
| 07:44 | <annevk> | sure is |
| 07:45 | <annevk> | I have asked for removal of byte and to then rename octet to byte |
| 07:45 | <annevk> | which seems more in line with terminology used throughout the platform |
| 07:49 | <annevk> | oh right, I keep forgetting why I got up at all thus far |
| 08:05 | <annevk> | Ms2ger: did anolis stop recognizing [PUBLISH] ? |
| 08:11 | <Ms2ger> | What about it? |
| 08:12 | <annevk> | it didn't get replaced when generating a draft |
| 08:12 | Ms2ger | tries to remember what it did |
| 08:13 | <annevk> | it's the w3.org/TR/shortname/ link |
| 08:15 | <Ms2ger> | Seems to be [LATEST] in the source... |
| 08:16 | <annevk> | oh |
| 08:16 | <annevk> | maybe I never published CORS before :) |
| 08:16 | <annevk> | using anolis that is |
| 08:20 | <annevk> | that seems to be it |
| 08:20 | <annevk> | thanks Ms2ger |
| 08:20 | <Ms2ger> | Np |
| 08:21 | <Ms2ger> | The docs for Bert's tool don't mention it either |
| 08:23 | <annevk> | I probably assumed it was called PUBLISH for some reason |
| 08:23 | <Ms2ger> | That could be it |
| 08:24 | <annevk> | took a good twenty minutes or so figuring out the wording for two groups and making it right |
| 08:24 | <annevk> | and it's probably wrong |
| 08:30 | <annevk> | took me a while to get zcorpan's testcase |
| 08:30 | <annevk> | parsing fun |
| 08:34 | <Ms2ger> | Yeah |
| 08:37 | <annevk> | I now have a list of 609 responding URLs that don't declare utf-8 or iso-8859-1 in their content-type declaration |
| 08:37 | <annevk> | I guess I should start fetching the raw data and run some byte analyze scripts |
| 08:44 | <vcvc> | hi |
| 08:44 | <annevk> | hey hey |
| 08:46 | <annevk> | I'm on a role in #csspubquiz :) |
| 08:46 | <Ms2ger> | A role? :) |
| 08:47 | <jgraham> | Yup, he's a wizard |
| 08:47 | Ms2ger | puts on his ro... Nvm |
| 08:47 | <smaug____> | so, will there be webapps wg f2f next month |
| 08:48 | <Ms2ger> | Apparently |
| 08:48 | <annevk> | spelling is overrated |
| 08:48 | <annevk> | this is not reddit |
| 08:49 | <Ms2ger> | 20ish people registered for WebApps |
| 08:49 | <Ms2ger> | I guess that's more efficient than the 200 last time |
| 08:57 | <smaug____> | but is it still useful meeting... |
| 08:57 | <smaug____> | perhaps I could try to get rid of file system api |
| 08:58 | jgraham | stands back as smaug____ lights blue touch paper |
| 09:00 | <annevk> | what's the fastest way to do a byte case-insensitive match on a file-like object in Python? |
| 09:01 | <jgraham> | Probably using regexp |
| 09:02 | <jgraham> | Although byte-case-insensitive doesn't really mean much to me |
| 09:02 | <jgraham> | YOu are either matching bytes, which don't have a case, or matching characters, which do |
| 09:03 | <annevk> | i'm matching against bytes but I want "B" and "b" to be the same |
| 09:03 | <Ms2ger> | But those aren't bytes ;) |
| 09:03 | <annevk> | maybe I should just give up on this and deal with it in post processing |
| 09:04 | <annevk> | Ms2ger: b"B" and b"b" then... |
| 09:04 | <zcorpan> | do you need it to be fast? do you look at each byte anyway? |
| 09:05 | <annevk> | former |
| 09:06 | <annevk> | but it's premature optimization, can do it later when everything is on disk |
| 09:06 | <zcorpan> | yeah i'd do it when you're looking at each byte anyway :-) |
| 09:10 | <zcorpan> | using URLs for schemes would be ... interesting |
| 09:11 | <annevk> | because of the Xzibit Yo Dawg meme? |
| 09:14 | <zcorpan> | right |
| 09:23 | <annevk> | did not know that file.read() could fail :( |
| 09:24 | <jgraham> | Seems pretty likely e.g. if the data doesn't exist anymore |
| 09:24 | <annevk> | well I just fetched it |
| 09:25 | <jgraham> | Hmm, I dunno how urllib works in that way |
| 09:25 | <jgraham> | s/way/regard/ |
| 09:50 | <zcorpan> | https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility/Overview.html#sec-processing-model is a bit weird for how it defines "unload a document" |
| 09:51 | <zcorpan> | it seems to basically override the algorithm in the html spec, but then says to "continue" that algorithm |
| 10:19 | gsnedders | hates window.attachEvent |
| 10:20 | <gsnedders> | The fact that keeping it breaks some sites, but not keeping it seems to break even more… |
| 10:21 | <roc> | we don't have it |
| 10:22 | <Ms2ger> | You should use Gecko ;) |
| 10:23 | <jgraham> | roc: You have never had it, so sites don't depend on it in the codepaths they send you down |
| 10:23 | <smaug____> | very true |
| 10:23 | <roc> | change your UA to Gecko |
| 10:24 | <smaug____> | gsnedders: you could start warn about attachEvent |
| 10:24 | <smaug____> | warning may or may not help |
| 10:24 | <jgraham> | I think doing that in the past (UA changing) probably got us into this mess :) |
| 10:25 | <smaug____> | does IE still support attachEvent |
| 10:25 | <smaug____> | in the non-legacy mode |
| 10:25 | <jgraham> | Probably if you didn't do the magic dance to get into standards mode |
| 10:26 | Ms2ger | has a look |
| 10:26 | <Ms2ger> | Where does this attachEvent thing live? |
| 10:26 | <jgraham> | Well since gsnedders hates window.attachEvent… |
| 10:28 | <Ms2ger> | Still there with <!doctype html> in IE10 |
| 10:28 | <smaug____> | boo |
| 10:28 | <Ms2ger> | Exactly my thoughts |
| 10:30 | Ms2ger | adds a test |
| 10:30 | <gsnedders> | roc: UA changing should probably make web developers hate us. |
| 10:30 | <Ms2ger> | s//more/ |
| 10:31 | Ms2ger | goes back to fixing storage |
| 10:31 | <gsnedders> | (What we do now is apply the same hiding as document.all to window.attachEvent, which helps us avoid going down IE codepaths, which fixes a lot of the sites that having it breaks) |
| 11:15 | <sedovsek> | Hey! |
| 11:15 | <sedovsek> | http://www.youtube.com/watch?feature=player_detailpage&v=q_O9_C2ZjoA#t=145s |
| 11:15 | <sedovsek> | Does anyone know how this video was made? |
| 11:16 | <Ms2ger> | paul_irish probably does |
| 11:24 | <annevk> | sweet |
| 11:24 | <annevk> | http://lists.w3.org/Archives/Public/www-archive/2012Apr/0008.html |
| 11:24 | <annevk> | I was afraid that would be marked as spam |
| 11:25 | <annevk> | wait what |
| 11:25 | <annevk> | why did it inline the .txt file |
| 11:25 | <annevk> | aaaaaaah |
| 11:25 | <Ms2ger> | Woo, Infraware's got more tests |
| 11:26 | jgraham | wonders who infraware actually are |
| 11:27 | <jgraham> | Medical transcription? |
| 11:28 | <jgraham> | Ah, probably the korean one |
| 11:29 | <Ms2ger> | Yep |
| 11:34 | <charlvn> | annevk: multipart messages with a mime type of text/plain will usually get treated like the "mail body" by most mail systems (that i know of) |
| 11:34 | <charlvn> | it doesn't have a good way of knowing what the mail body is because the mail body is also sent as a text/plain in the multipart |
| 11:35 | <charlvn> | so the mail body is usually "append all text/plain attachments" |
| 11:39 | <annevk> | well it sucks |
| 11:40 | <annevk> | the email arrived in my inbox perfectly fine |
| 11:42 | <Ms2ger> | Yay, another bug |
| 11:43 | <annevk> | Ms2ger: yeah, at some point we should write down new terminology rules; return means terminate; throw is not caught; etc. |
| 11:43 | <Ms2ger> | Yeah |
| 11:43 | <annevk> | prolly give it the same sane default as in programming... |
| 11:44 | <Ms2ger> | This would all be so much easier if we wrote in C++ ;) |
| 11:44 | <jgraham> | Copy the ES5 sepc |
| 11:44 | <jgraham> | *spec |
| 11:44 | <Ms2ger> | INTELLECTUAL PROPERTY VIOLATION |
| 11:48 | <jgraham> | That's NS_ERROR_INTELLECTUAL_PROPERTY_VIOLATION to you :p |
| 11:53 | <Ms2ger> | Hey, we fixed that for DOMExceptions |
| 11:57 | <matjas> | I hope you guys don’t mind me posting a #csspubquiz question. |
| 11:58 | <gsnedders> | You shall be hanged, drawn, and quartered! |
| 11:58 | <annevk> | matjas: zcorpan "forked" without asking, should be no problem |
| 11:58 | <zcorpan> | matjas: do it :-) |
| 11:58 | <annevk> | there you go :) |
| 11:58 | <matjas> | zcorpan: http://twitter.com/mathias/status/187146793132371968 |
| 11:59 | <Ms2ger> | Empty string? |
| 11:59 | <matjas> | Ms2ger: yep |
| 12:01 | <annevk> | #whatwg regulars should probably not be allowed to reply |
| 12:01 | <annevk> | usually within minutes the answer is found |
| 12:02 | <gsnedders> | Probably a lot of the people who see on Twitter don't follow #whatwg though |
| 12:02 | <Ms2ger> | Well, if *we* can't find it... ;) |
| 12:06 | <zcorpan> | hsivonen: changing from ascii to utf-8 midstream also affects resolving URLs, so links can go from working to not working or vice versa during parsing |
| 12:07 | <matjas> | haha thomasfuchs just asked “is it on http://en.wikipedia.org/wiki/List_of_typefaces?” — I’d be lying if I said no |
| 12:09 | <zcorpan> | you could say that it doesn't have a bullet point dedicated to it on that page |
| 12:09 | <zcorpan> | or go with "yes and no" :-P |
| 12:11 | <matjas> | I’d rather troll |
| 12:12 | <zcorpan> | matjas: i think i found a bug. try two spaces |
| 12:13 | <matjas> | zcorpan: good catch. will fix |
| 12:13 | <zcorpan> | or anything that begins with a space |
| 12:16 | <zcorpan> | matjas: another: foo 1 |
| 12:17 | <matjas> | zcorpan: what’s wrong with `font-family: foo\ 1;`? |
| 12:17 | <matjas> | the space is escaped |
| 12:17 | <matjas> | so it’s all 1 identifier |
| 12:17 | <zcorpan> | oh, right! |
| 12:19 | <matjas> | looks weird huh |
| 12:19 | <matjas> | but most of the time it’s more readable than escaping the first char of the next identifier |
| 12:19 | <zcorpan> | yeah |
| 12:28 | <annevk> | zcorpan: how would it affect URLs zcorpan if you have not encountered non-ASCII yet? |
| 12:30 | <annevk> | I like how it's completely useless |
| 12:30 | <zcorpan> | annevk: entities |
| 12:31 | <annevk> | hmm yeah, and then you'd have to use windows-1252? |
| 12:32 | <annevk> | for the query part |
| 12:32 | <zcorpan> | yes |
| 12:32 | <annevk> | URLs are evil |
| 12:33 | <zcorpan> | or other escapes in js |
| 12:40 | <hsivonen> | Can someone who has been paying attention explain to me how aria-describedat differs from adding a longdesc to every element? |
| 12:40 | <jgraham> | Someone has been paying attention? |
| 12:44 | <annevk> | hsivonen: maybe no ties to legacy content? it always looked like a recipe for failure to me |
| 12:44 | <hsivonen> | annevk: good point |
| 12:51 | hsivonen | marks everything concerning httprange-14 as read |
| 12:51 | <annevk> | hardly any sites uses bytes in the problematic range it turns out |
| 13:22 | <zewt> | Ms2ger: uh, wow, way to be a dick on the tracker |
| 13:25 | <zewt> | and way to close a ticket without responding in any way to the issues raised; very poor show |
| 13:30 | <Ms2ger> | zewt, did you notice I actually fixed the bug before the troll came in? |
| 13:30 | <zewt> | uh, what? |
| 13:30 | <zewt> | i'm a troll, now? |
| 13:31 | <Ms2ger> | Ugh |
| 13:31 | <Ms2ger> | I'm sorry |
| 13:31 | <zewt> | i'm going to go take a shower, I don't like getting pissed off at 8:30am because of spec shit |
| 13:32 | <Ms2ger> | I thought that was the other Glenn :/ |
| 13:33 | <AryehGregor> | Ms2ger, I know this is a radical idea, but maybe you could resolve bugs primarily based on their content instead of the filer? Just saying. |
| 13:36 | hsivonen | wonders what bug this was |
| 13:37 | <AryehGregor> | It's really annoying that XChat starts all my window titles with "XChat: AryehGregor @ FreeNode / #" or such. It makes it impossible to tell which is which when they're minimized. |
| 13:38 | AryehGregor | Googles and finds he can try forcing the titles with xdotool |
| 13:41 | <AryehGregor> | for SEARCH in '#developers' '#chromium' '#mediawiki' '#wikimedia-tech' '#webkit' '#whatwg' '#wikimedia-operations'; do xdotool search --name $SEARCH set_window --name $SEARCH --icon-name $SEARCH; done |
| 13:41 | <AryehGregor> | Yay. |
| 13:54 | <AryehGregor> | Of course, they reset after a while, so clearly I need to run it from a cron job. |
| 13:54 | <AryehGregor> | Yay Linux! |
| 13:56 | <Philip`> | Just put a "while true; do ...; done" around it |
| 13:56 | <AryehGregor> | To be friendly to system resources, I should add a sleep statement. |
| 13:57 | <Philip`> | You've (presumably) got a multi-core CPU, you might as well make use of it |
| 13:57 | <Philip`> | One core dedicated to renaming windows doesn't seem that bad a plan |
| 13:58 | <zewt> | AryehGregor: amazon is annoying like that, too; unlike every other search-based website, they put their name at the start of <title> |
| 13:58 | <AryehGregor> | Philip`, I compile with -j16. |
| 13:59 | <AryehGregor> | (thus it only takes 15 minutes to compile Gecko from scratch) |
| 14:00 | <jgraham> | Does that work?! I mean whenever I compile with -j(something > 2 or so) my system becomes unusably laggy until the compile is done |
| 14:00 | <jgraham> | Not that I have compiled Gecko recently |
| 14:00 | <AryehGregor> | jgraham, works fine for me on Ubuntu 11.10. |
| 14:00 | <AryehGregor> | What OS do you use? |
| 14:00 | <Ms2ger> | wfm with -j12 |
| 14:01 | <jgraham> | Hmm, could be my old ubuntu. |
| 14:01 | <jgraham> | 10.04 |
| 14:01 | <zewt> | jgraham: as long as you're not using so many processes you're running out of memory, it shouldn't |
| 14:01 | <Philip`> | -j$numcores seems very laggy for me if I'm running it inside VirtualBox, but otherwise it's fine (assuming sufficient RAM) |
| 14:01 | <zewt> | afk work |
| 14:01 | <jgraham> | Maybe I just need more RAM |
| 14:01 | <zewt> | (this isn't everyone's day job :| ) |
| 14:01 | <AryehGregor> | jgraham, try nice -n 19 if it's really a CPU-bound problem. |
| 14:01 | <Philip`> | (Ubuntu in VirtualBox in Win7, in particular) |
| 14:02 | <jgraham> | Or maybe the Opera build is sufficiently different from the Gecko build that there is some difference |
| 14:02 | <AryehGregor> | How much RAM do you have? |
| 14:02 | <AryehGregor> | I found that 8G wasn't really enough. |
| 14:02 | <AryehGregor> | 16 is fine. |
| 14:02 | <jgraham> | Not enough :) |
| 14:02 | <Philip`> | I think the general rule is "if you can afford it, it's not enough" |
| 14:02 | <AryehGregor> | RAM is stupidly cheap. |
| 14:03 | jgraham | doesn't really compile that often atm but will get more RAM before he moves onto a project where he has to |
| 14:03 | <Ms2ger> | You could move onto the Mozilla project ;) |
| 14:04 | <Philip`> | You could reimplement Opera's build system to work the same as Mozilla's, and see if that makes a difference |
| 14:05 | <Ms2ger> | Would not recommend |
| 14:07 | AryehGregor | notes that Linus Torvalds claims he can compile the Linux kernel from scratch in 15 seconds with no ccache or anything, as long as the files are in memory |
| 14:07 | <AryehGregor> | (of course, it's a custom compile that leaves out all the stuff he doesn't need) |
| 14:07 | <AryehGregor> | I see large parts of the Gecko build with close to 0% CPU/disk usage, so I suspect it's not optimal. |
| 14:07 | <Ms2ger> | Not at all |
| 14:08 | <AryehGregor> | Rebuilding Gecko with ccache and an objdir when *nothing has changed* takes 45 seconds for me. |
| 14:08 | <AryehGregor> | Can someone fix that plz? :( |
| 14:13 | <Philip`> | Was the work on pymake meant to help fix that? |
| 14:13 | <Ms2ger> | Pymake was more because gnu make is dog slow on windows |
| 14:13 | <Ms2ger> | And loves deadlocking |
| 14:14 | <Philip`> | Ah, so it won't make much difference on Linux? |
| 14:15 | <Ms2ger> | I don't know |
| 14:15 | <Ms2ger> | Probably not |
| 14:18 | smaug____ | wonders why AryehGregor needs to rebuild gecko if nothing has changed |
| 14:18 | Ms2ger | whacks smaug____ |
| 14:18 | <AryehGregor> | smaug____, well, sometimes I'm lazy and don't want to manually copy tests or something like that. I don't actually have to, but the point is stuff I didn't change should take ~0s to rebuild. |
| 14:19 | <AryehGregor> | It might have to be relinked, but it shouldn't spend 45s going into and out of subdirectories and saying "nothing to do". |
| 14:19 | <AryehGregor> | Like, can it at least do that in parallel? |
| 14:20 | <Ms2ger> | Not always |
| 14:22 | <smaug____> | there are dependencies.. |
| 15:51 | <dglazkov> | good morning/afternoon/evening/night, Whatwg! |
| 15:53 | <Ms2ger> | Good day |
| 15:53 | <Hixie> | 'sup |
| 15:57 | <hober> | yo |
| 15:59 | <Velmont> | 'lo |
| 15:59 | <Hixie> | hober: is there a spec i should be reading up on to be ready for our meeting? |
| 15:59 | <Hixie> | (for fullscreen) |
| 15:59 | <Ms2ger> | Fullscreen? :) |
| 16:00 | <Hixie> | i was thinking the answer might be something like "display" |
| 16:00 | <Ms2ger> | A spec for display? Hah |
| 16:14 | <hober> | yeah |
| 16:14 | hober | digs up a link to the ED |
| 16:15 | <hober> | https://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html |
| 16:22 | <Hixie> | hober: cool, thanks |
| 16:22 | <Hixie> | hober: in case you didn't see the discussion last night, plan as far as i am aware is to meet in the b43 lobby |
| 16:27 | <hober> | ok |
| 16:27 | <hober> | at noon? |
| 16:31 | <Hixie> | i believe so |
| 16:42 | <Hixie> | i'm dropping initialTime |
| 16:45 | <TabAtkins> | AryehGregor: Come back to Google and you can use -j300 |
| 16:45 | <TabAtkins> | 3 minutes or so to build WebKit from scratch. ^_^ |
| 16:46 | <Ms2ger> | TabAtkins-- |
| 16:48 | <TabAtkins> | Ms2ger: Not my fault we've got server farms to lean on. |
| 16:49 | <TabAtkins> | It probably wouldn't be that expensive to set up an Amazon cluster to get similar results. |
| 16:51 | <jgraham> | Mozilla have a large pool of build slaves, right? So all you really need to do is kill off the other developers so they are always free |
| 16:52 | <Ms2ger> | What? Why would you want to go through a build farm for your local builds? |
| 16:52 | <TabAtkins> | Or just get more build slaves. |
| 16:52 | <TabAtkins> | Ms2ger: Because then you can parallelize your build? |
| 16:53 | <jgraham> | Ms2ger: Well if it is significantly faster… |
| 17:27 | <[tm]> | Qt going full 5 |
| 17:28 | <[tm]> | we got a great big convoy |
| 17:34 | Ms2ger | wishes Opera would implement the StorageEvent ctro |
| 17:35 | <[tm]> | ctro? |
| 17:35 | <TabAtkins> | constructor, presumably. |
| 17:36 | <[tm]> | ah |
| 17:36 | <Ms2ger> | ctor, but I can't type either |
| 17:36 | <annevk> | file a bug |
| 17:37 | <Ms2ger> | Link? |
| 17:37 | <[tm]> | i think we should change our theme song to full fathom five |
| 17:37 | <[tm]> | instead of whatever happened to the teenage dream |
| 17:38 | <annevk> | Ms2ger: https://bugs.opera.com/wizarddesktop/ |
| 17:41 | <Ms2ger> | DSK-360666 |
| 17:41 | <Ms2ger> | Nice number |
| 17:43 | <annevk> | since I'm superstitious I made that CORE-45500 |
| 17:44 | <Ms2ger> | You are? |
| 18:39 | <Hixie> | TabAtkins: fyi i'm in b43 lobby |
| 18:39 | <TabAtkins> | Hixie: I'll be there shortly. |
| 18:40 | <Hixie> | well don't bother rushing, our guests aren't here yet ;-) |
| 18:40 | <TabAtkins> | tantek said he'll be a bit late. Conservative estimate is 12:30 |
| 18:40 | <Hixie> | i just figured it was easier to just sit here when i got in rather than find another couch them move :-) |
| 18:40 | <Hixie> | k |
| 19:25 | <annevk> | WebGL https://www.w3.org/Bugs/Public/show_bug.cgi?id=16604 :/ |
| 20:41 | <jamesr> | zewt, blue text is how i know an email is from an @microsoft.com |
| 21:05 | <jsbell> | annevk: another Encoding spec glitch: "escape state" --> "escape start state" |
| 21:06 | <annevk> | cheers, will take a look tomorrow |
| 21:52 | <Hixie> | roc_: yt? |
| 22:00 | <roc> | yes |
| 22:01 | <Hixie> | roc: i am told you have a concern over introducing a new stacking context for making fullscreen and modal <dialog>s work -- can you elaborate on that? |
| 22:03 | <roc> | I think it'll be OK if it's done properly |
| 22:04 | <roc> | people were proposing language like "<dialog> displays on top of everything else" which isn't precise enough |
| 22:04 | <Hixie> | ah ok |
| 22:04 | <Hixie> | so how's this: |
| 22:04 | <roc> | because obviously that breaks as soon as two specs say that :-) |
| 22:05 | <Hixie> | we introduce a new stacking context between layers 9 and 10 of CSS 2.1 Appendix E, and define two operations, "push" and "yank". "push" adds an element to this layer, above all the things on it already. "yank" removes the element from this layer. |
| 22:05 | <Hixie> | stacking contexts in this layer are not affected by things like clip/mask/opacity of their elements |
| 22:05 | <Hixie> | of their ancestor elements, rather |
| 22:06 | <Hixie> | z-index is ignored on this layer |
| 22:06 | <Hixie> | positioning in the plane is done as normal, the only effect here is on z-axis stacking |
| 22:06 | <roc> | I'm not sure what those ignore/not-affected-by comments mean |
| 22:06 | <Hixie> | (alternatively, positioning on the plane is always done per position:absolute) |
| 22:07 | <roc> | what about CSS transforms? |
| 22:07 | <Hixie> | it means the element is rendered as if its box was a sibling of the root element |
| 22:07 | <Hixie> | of the root element's box |
| 22:07 | <roc> | how does this affect getBoundingClientRect on ancestors of such elements? |
| 22:07 | <roc> | oh, never mind |
| 22:08 | <roc> | so this affects layout as well as rendering? |
| 22:08 | <Hixie> | probably, though i could go either way on that |
| 22:08 | <Hixie> | seems simplest if it does |
| 22:09 | <roc> | this is almost like a new 'position' scheme |
| 22:09 | <Hixie> | yes |
| 22:09 | <TabAtkins> | Kinda, but not really, since you still want positioning to work. |
| 22:09 | <TabAtkins> | Like you want dialogs to be position:center. |
| 22:09 | <roc> | the basic idea seems reasonable but it feels quite invasive, lots of CSS things could be affected |
| 22:10 | <TabAtkins> | And the actual layering is outside of CSS, based on the stack. |
| 22:10 | <Hixie> | definitely invasive |
| 22:10 | <roc> | can stuff escape from an <iframe> in this model? |
| 22:10 | <TabAtkins> | I think so, yes. |
| 22:10 | <TabAtkins> | You want to be able to fullscreen Youtube videos embedded via iframe. |
| 22:11 | <roc> | well, we currently support that without having things escape from <iframe> |
| 22:11 | <TabAtkins> | How so? |
| 22:11 | <roc> | by fullscreening the <iframe> first |
| 22:11 | <TabAtkins> | Oh, okay. |
| 22:12 | <TabAtkins> | So do authors have to do two fullscreen requests? |
| 22:12 | <Hixie> | yeah for anything inside iframes you fullscreen all the browsing context containers first |
| 22:12 | <roc> | the current fullscreen approach is good because it's not invasive at all |
| 22:12 | <roc> | TabAtkins: no, it's automatic. |
| 22:12 | <Hixie> | nothing should ever be able to escape its viewport |
| 22:12 | <TabAtkins> | Sure, putting all the browsing context containers on the stack below the actual fullscreened element is fine. |
| 22:12 | <Hixie> | different stack |
| 22:12 | <Hixie> | each browsing context / viewport gets its own stack |
| 22:12 | <roc> | the thing is |
| 22:13 | <TabAtkins> | Hixie: Ah, I see. |
| 22:13 | <roc> | if you want an <iframe>'d widget to show a <dialog>, you really don't want to fullscreen the <iframe> and you want the <dialog> to be visible outside the <iframe> viewport. Don't you?> |
| 22:13 | <Hixie> | you never want anything outside an <iframe> |
| 22:13 | <Hixie> | that's a security disaster |
| 22:13 | <roc> | yes |
| 22:13 | <roc> | but |
| 22:13 | <TabAtkins> | Hixie: If you alert() in an iframe, it escapes. |
| 22:13 | <roc> | we have a conflict here |
| 22:14 | <gsnedders> | Likewise print |
| 22:14 | <roc> | <dialog> users will want their dialogs to escape |
| 22:14 | <zcorpan> | do we want outlines in the page to show when an element is fullscreened? |
| 22:14 | <TabAtkins> | I'm probably okay with "welp, that's not a big deal". |
| 22:14 | <roc> | <dialog> in a widget's small <iframe> will be pretty useless |
| 22:14 | <Hixie> | i don't see why <dialog> users would want anything different than what they're getting today with <div> |
| 22:14 | <hober> | <dialog> shouldn't escape the <iframe> it's in |
| 22:14 | <hober> | <dialog>s don't escape the main browsing context |
| 22:15 | <roc> | Hixie: I can see why they'd want more. I'm OK with not giving it to them. |
| 22:16 | <zcorpan> | annevk: have you considered 'outline' and fullscreen? |
| 22:16 | <roc> | Are there strong reasons to require this special escaping magic? Is it too hard to make authors hang <dialog>s off the root element? |
| 22:17 | <Hixie> | roc: the solution that's used by current widgets is to just spawn another iframe the size of the dialog, fwiw. That's fine by me. |
| 22:17 | <Hixie> | roc: the problem is with nesting dialogs and fullscreen |
| 22:17 | <Hixie> | roc: and making sure the layering still works |
| 22:18 | <Hixie> | zcorpan: in practice nobody puts outlines at layer 10 and we should just remove that from the spec |
| 22:18 | <roc> | we do |
| 22:18 | <Hixie> | how do you make them be affected by transforms then? |
| 22:18 | <Hixie> | or opacity? |
| 22:19 | <zcorpan> | opera does afaict |
| 22:19 | <roc> | Hixie: I dunno. "code" :-) |
| 22:20 | <Hixie> | i don't see how you can do 'opacity' while putting outlines in layer 10 |
| 22:20 | <TabAtkins> | So you don't draw them at layer 10, you draw them at a magical undocumented layer. |
| 22:20 | <Hixie> | opacity composites atomically |
| 22:21 | <TabAtkins> | Plus, doesn't drawing at layer 10 imply that the entire outline overlaps any elements that may be above the element? |
| 22:21 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1444 - i don't see the outline in gecko or webkit |
| 22:21 | <roc> | I don't understand what you think the problem is |
| 22:21 | <TabAtkins> | roc: See zcorpan's test case. |
| 22:22 | <TabAtkins> | If you drew outlines at layer 10, you'd see the outline drawn above the covering div. |
| 22:23 | <zcorpan> | why does css have layer 10? what makes outlines so important they have to be visible above everything else? |
| 22:23 | <Hixie> | "accessibility" |
| 22:23 | <zcorpan> | -_- |
| 22:32 | <Hixie> | actually i guess we should put hte layer after layer 10, and just say that outlines in these elements are always rendered atomically in this layer. |
| 22:37 | <roc> | sorry yes, I was wrong, we put them in layer 7. |
| 22:38 | <roc> | we could easily put them in layer 10, not sure why I thought we had |
| 22:38 | <roc> | anyway |
| 22:40 | <Hixie> | TabAtkins: actually position:center as you described it at lunch isn't what we'd want for <dialog> |
| 22:40 | <TabAtkins> | Really? Seems fine to me. |
| 22:40 | <Hixie> | TabAtkins: for <dialog> the top position has to be based on the scroll position at the time the dialog is shown |
| 22:40 | <TabAtkins> | Ah. |
| 22:40 | <TabAtkins> | For modals too? |
| 22:40 | <Hixie> | yeah |
| 22:41 | <Hixie> | otherwise scrolling breaks for dialogs that are taller than the viewport |
| 22:41 | <TabAtkins> | Okay. |
| 22:41 | <TabAtkins> | It's fine to just define it as abspos with a particular static position. |
| 22:41 | <Hixie> | i expect we'll have to define some custom positioning actually, but i haven't looked at the issue closely recently |
| 22:42 | <TabAtkins> | Nah, if you want document-scrolling to scroll the dialog, then just use abspos with a custom static position. |
| 22:42 | <Hixie> | if the width changes i need the dialog to stay horizontally centered |
| 22:42 | <Hixie> | maybe i can do that with margins |
| 22:42 | <Hixie> | i'll have to examine it more closely |
| 22:42 | <TabAtkins> | That doesn't let you adjust it (because using anything other than 'auto' in trbl would make it position relative to containing block instead). |
| 22:43 | <TabAtkins> | Yes, left:0; right:0; margin-left: auto; margin-right: auto;. |
| 22:44 | <Hixie> | does anything other than background-* apply to ::backdrop? |
| 22:44 | <TabAtkins> | Sure, why not let everything apply? |
| 22:45 | <TabAtkins> | I never see good reasons to artificially limit these unless absolutely necessary. |
| 22:45 | <Hixie> | dunno, is there ever a need for 'display:inline' to apply to it, say? |
| 22:45 | <Hixie> | seems like htat's just asking for trouble |
| 22:45 | <roc> | Hixie: currently we disallow an element from going fullscreen if there's an existing fullscreen element that's not its ancestor |
| 22:45 | <roc> | are we doing something similar for <dialog?? |
| 22:45 | <TabAtkins> | Since it's in the layer, it's forced to a block-level display. |
| 22:46 | <TabAtkins> | roc: Yes, I think. |
| 22:46 | <TabAtkins> | But I'm not sure. |
| 22:46 | <Hixie> | roc: when there's no fullscreen elements around, any <dialog> can be showModal()ed |
| 22:47 | <Hixie> | roc: there's some implications for when you do it to a <Dialog> that's an ancestor of one already showing |
| 22:47 | <roc> | the way we handle the "make the fullscreen element escape from opacity/transforms/etc of its ancestors" problem currently, is that we have a pseudoclass for elements that are ancestors of the fullscreen element, and we set their opacity/transform etc to none with UA CSS rules |
| 22:47 | <Hixie> | roc: yeah |
| 22:47 | <roc> | which works for fullscreen since those ancestors are typically not visible anyway |
| 22:48 | <roc> | but less so for <dialog> |
| 22:48 | <TabAtkins> | roc: That's weird if the ancestors are visible. |
| 22:48 | <Hixie> | well, they can be visible |
| 22:48 | <TabAtkins> | And yeah, generally unusable for dialog. |
| 22:49 | <roc> | it's tempting to make go-fullscreen and show-dialog move the element to the end of the DOM :-) |
| 22:49 | <Hixie> | actually i think it works fine if you make a (previously-visible) ancestor of a modal dialog itself modal. the complication is when the ancestor is display:none |
| 22:50 | <TabAtkins> | roc: And log mutation records? |
| 22:50 | <zcorpan> | and we don't set outline. would need to set outline on all elements except the fullscreen element and its descendants, not only ancestors of the fullscreen element |
| 22:50 | <Hixie> | but i think the solution there is just that in that case nothing visible happens |
| 22:50 | <roc> | TabAtkins: I don't think I'm serious. It would break stuff. |
| 22:50 | <TabAtkins> | Yeah, I know. ^_^ |
| 22:50 | <roc> | but |
| 22:51 | <roc> | having elements punch all the way out of effects from CSS containers, while still inheriting style from those containers, seems super painful :-( |
| 22:51 | <Hixie> | why? |
| 22:51 | <Hixie> | (just trying to understand the constraints) |
| 22:51 | <roc> | It's a new behavior |
| 22:52 | <Hixie> | (i believe you that's it's painful!) |
| 22:52 | <roc> | breaks existing CSS invariants |
| 22:52 | <Hixie> | my mental model was that you just move the element's boxes into a different part of the render tree |
| 22:52 | <Hixie> | and act as if it's display:none in the original tree |
| 22:53 | <roc> | yeah, it's actually pretty easy for us to implement that way |
| 22:53 | <TabAtkins> | Yeah, moving the render tree around is sensical. |
| 22:53 | <roc> | however |
| 22:53 | <roc> | understanding all the implications of that, for the CSS spec, is hard |
| 22:53 | <Hixie> | (notably, there's no double-rendering going on, which is the usual complication) |
| 22:54 | <TabAtkins> | roc: The implications are pretty reasonable, I think. |
| 22:54 | <TabAtkins> | If you're literally just mutating the box tree. |
| 22:54 | <roc> | so of course, the sensible thing to do would be to rush out the obvious implementation and let someone else clean up the mess |
| 22:55 | <roc> | it wouldn't be so bad if the CSS specs weren't generally confused about box tree vs element tree |
| 22:55 | <TabAtkins> | There's a lot less of that left than there used to be, at least. :/ |
| 22:55 | <Hixie> | yeah, i really wish we had someone to do the "CSS5" treatment on the box model and related areas |
| 22:55 | <TabAtkins> | Big thing that's still broken to me is the table fix-up. |
| 22:57 | <Hixie> | ok so new stacking layer with all its css implications, push and yank algorithms, and the new pseudo for backdrops |
| 22:57 | <Hixie> | am i missing anything? |
| 22:57 | <roc> | Hixie: so I think perhaps the way to go is to define a new positioning scheme, say position:viewport, which behaves like fixed but escapes from all ancestor effects, might be the way to go |
| 22:58 | <Hixie> | roc: that's basically what i'm proposing, except without the new value. we need the existing 'position' values to control the positioning. |
| 22:58 | <Hixie> | roc: since e.g. fullscreen wants to be position:fixed, but <Dialog> wants to be position:absolute or position:center, typically |
| 22:59 | <Hixie> | roc: also, we wouldn't want the author to be able to put elements into this layer from CSS, since if we did that we'd lose the ordering |
| 22:59 | <Hixie> | roc: which is the most important aspect of this :-) |
| 22:59 | <roc> | how would your new thing behave with position:static, then? |
| 22:59 | <Hixie> | to quote from the e-mail i'm writing to whatwg: |
| 22:59 | <Hixie> | The 'position' property for elements in one of these stacks computes to |
| 22:59 | <Hixie> | 'absolute', 'fixed', or 'center' if that is its specifed value, and to |
| 22:59 | <Hixie> | 'absolute' if the specified value is anything else. |
| 22:59 | <roc> | ok |
| 23:00 | <roc> | er wait |
| 23:01 | <roc> | so how does a position:absolute <dialog> element inside a transformed element behave? It somehow gets its layout from the transformed element but isn't affected by the transform? |
| 23:01 | <Hixie> | to quote from my e-mail again: |
| 23:01 | <Hixie> | The containing block for such an element is the initial containing |
| 23:01 | <Hixie> | block, same as for the root element. |
| 23:02 | <Hixie> | (so the transform has no effect) |
| 23:02 | <Hixie> | (not sure what you mean by "gets its layout") |
| 23:02 | <roc> | what is the static position for left/top? |
| 23:03 | <roc> | also |
| 23:03 | <Hixie> | hm, good point, have to define the static position |
| 23:03 | <roc> | the CSS Regions people redefined initial containing block so that it's a property of elements, there's no longer "the initial containing block" |
| 23:03 | <Hixie> | o_O |
| 23:04 | <Hixie> | see, this is why there should only be one CSS spec and it should be continuously maintained |
| 23:04 | <roc> | actually I'm not sure what ended up happening there, but you might want to check |
| 23:05 | <roc> | Hixie: at this point I should probably just wait for you to post the email |
| 23:05 | <roc> | the general direction seems scary, but I can't think of a better approach |
| 23:05 | <Hixie> | roc: your feedback has been very helpful so far, please don't hesitate to keep talking :-) |
| 23:06 | <roc> | yeah, but I've got work to do :-) |
| 23:06 | <Hixie> | fair enough :-) |
| 23:08 | <Hixie> | is http://dev.w3.org/csswg/css3-regions/Overview.src.html the regions spec? |
| 23:08 | <astearns> | yep |
| 23:08 | <Hixie> | it doesn't seem to redefine containing block |
| 23:08 | <Hixie> | it defers to 2.1 |
| 23:08 | <astearns> | The edges of the first region in a region chain associated with a named flow establish the rectangle that is the containing block used for absolutely positioned elements in the named flow which do not have an ancestor with a ‘position’ of ‘absolute’, ‘relative’ or ‘fixed’ (see [CSS21]). That first region rectangle is used as the containing block instead of the initial containing block. |
| 23:08 | <astearns> | that's it |
| 23:09 | <Hixie> | ah ok |
| 23:09 | <Hixie> | that seems harmless enough |
| 23:09 | <astearns> | we hope so :) |
| 23:09 | <Hixie> | since i'm just bypassing the whole tree |
| 23:13 | <Hixie> | ok, e-mail away |