| 00:00 | <ojan> | jamesr: as in...if flex-item-align is auto, then it uses the flex-align value of it's parent |
| 00:01 | <jamesr> | ah ok, i think that modification should apply to the computed value, then |
| 00:14 | <ojan> | jamesr: hmmm...i'm not really sure that's correct |
| 00:14 | <ojan> | because the value isn't inherited exactly |
| 00:14 | <jamesr> | what exactly modifies it? |
| 00:14 | <ojan> | auto on the child just means look at the parent's flex-align |
| 00:14 | <jamesr> | some stuff stays 'auto' and then is figured out at layout time (aka computed->used time) |
| 00:14 | <ojan> | yeah |
| 00:14 | <ojan> | that's this |
| 00:15 | <ojan> | hm...but it's not used value as per flexAlignForChild |
| 00:15 | <ojan> | hmmm... |
| 00:15 | <ojan> | as per http://dev.w3.org/csswg/css3-cascade/#computed |
| 00:15 | <ojan> | becuase you don't need to format the document to figure out the value |
| 00:16 | <ojan> | i can't think of other cases where we have auto values that can be resolved without laying out the document |
| 00:16 | <ojan> | hm...maybe i should just send an email to www-style |
| 00:17 | <jamesr> | i think the "resolve as much as possible" text is pretty vague |
| 00:17 | <ojan> | yeah |
| 00:17 | <jamesr> | i think that means for calc() |
| 00:23 | <jamesr> | but i'm not sure |
| 00:54 | <AryehGregor> | Why does an error event fired at a <source> not bubble? If it bubbled, you could put a single onerror on <video> and be done with it. |
| 00:54 | <AryehGregor> | Maybe we don't want it bubbling up to the body or document or whatever and confusing people? |
| 00:55 | <AryehGregor> | In that case, maybe it would make sense to fire an error event at the <video> separately. |
| 00:59 | <rniwa> | AryehGregor, Hixie: ping |
| 00:59 | <AryehGregor> | rniwa, pong. |
| 00:59 | <rniwa> | AryehGregor: hi, I think drag & drop model is somewhat flawed |
| 00:59 | <Hixie> | rniwa: here |
| 00:59 | <AryehGregor> | The one in the HTML spec? I'm not familiar with it. |
| 00:59 | <rniwa> | http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#drag-and-drop-processing-model |
| 00:59 | <Hixie> | rniwa: the drag and drop model is terribly flawed |
| 00:59 | <Hixie> | rniwa: news at 11 :-) |
| 00:59 | <rniwa> | says that we need to insert contents immediately after firing drop event |
| 00:59 | <Hixie> | it's just what IE5.5 did |
| 01:00 | <Hixie> | which is just what COM did |
| 01:00 | <Hixie> | or COM+ or something |
| 01:00 | <Hixie> | old windows tech |
| 01:00 | <rniwa> | and then delete contents inside dragend event |
| 01:00 | <rniwa> | but this would mean that when the user undo the actions the last action to be undone is the insertion of the contents |
| 01:01 | <rniwa> | so we end up placing the caret at the drag destination |
| 01:01 | <rniwa> | as supposed to selecting the dragged (moved) source |
| 01:02 | <rniwa> | Hixie, AryehGregor: the fact the insertion and deletion of the contents happen at a different timing makes it really hard to implement correctly in webkit |
| 01:07 | <rniwa> | Hixie, AryehGregor: e.g. Firefox 9 deletes & inserts the content after dragend event is fired |
| 01:08 | <rniwa> | Hixie, AryehGregor: and I'm more inclined to follow that behavior than following the current spec. |
| 01:09 | <rniwa> | any opinion about this? |
| 01:12 | AryehGregor | has no opinions about DnD |
| 01:13 | <rniwa> | AryehGregor: https://bugs.webkit.org/show_bug.cgi?id=57185 |
| 01:14 | <rniwa> | AryehGregor: my current approach is an insane hack |
| 01:14 | <rniwa> | AryehGregor: and frankly, firefox's behavior is much saner |
| 01:14 | <rniwa> | sicking: hi sicking |
| 01:19 | <Hixie> | rniwa: what does IE do? |
| 01:19 | <Hixie> | rniwa: this is probably related to the way IE collapsed all (scripted and UA-driven) DOM modifications during DND into a single undo event |
| 01:20 | <rniwa> | Hixie: presumably what your spec says now? |
| 01:20 | <Hixie> | presumably, but if it doesn't then it's much easier to argue that we should change the spec |
| 01:20 | <rniwa> | Hixie: I don't have a windows machine at hand now |
| 01:21 | <Hixie> | me either :-( |
| 01:22 | <rniwa> | Hixie: though I'm not too concerned about matching undo behavior for dragging text |
| 01:23 | <rniwa> | Hixie: I don't think it really matters as long as we define whether script-initiated dom mutations should be undone or not |
| 01:23 | <rniwa> | whether all dom mutations being in single dom transaction or not isn't that important as far as i'm concerned |
| 01:23 | <Hixie> | the undo behaviour isn't a huge problem here but i would imagine that how to react to events getting canceled does |
| 01:24 | <rniwa> | Hixie: right. |
| 01:24 | <Hixie> | which would imply not being able to move the point in the algorithm where stuff is removed and added to the dom |
| 01:24 | <rniwa> | Hixie: right now, things are added then removed :( |
| 01:24 | <rniwa> | Hixie: that's the problem |
| 01:25 | <rniwa> | if we had removed then added, this won't be an issue |
| 01:25 | <Hixie> | right but my point is that we maybe can't change that |
| 01:25 | <Hixie> | a site could rely on the add happening, and the remove not |
| 01:25 | Hixie | doesn't know |
| 01:25 | <rniwa> | Hixie: how could that be? |
| 01:25 | <Hixie> | maybe they want the user to be able to copy stuff or something |
| 01:25 | <rniwa> | Hixie: webkit doesn't even fire drop & dragend events for text drag at the moment |
| 01:26 | <rniwa> | they can't possibly be relying on that |
| 01:26 | <Hixie> | webkit is irrelevant to code written for IE |
| 01:26 | <rniwa> | and firefox moves the text atomically in dragend |
| 01:26 | <Hixie> | webkit didn't _exist_ when this stuff was in a browser with 99% market share |
| 01:26 | <Hixie> | nor did firefox |
| 01:26 | <Hixie> | who knows what old code is out there that relies on this API |
| 01:27 | <rniwa> | maybe |
| 01:27 | <Hixie> | but maybe nothing depends on it and we can change it |
| 01:27 | <Hixie> | i have no data either way |
| 01:34 | <rniwa> | Hixie: oops, I was wrong. Firefox and WebKit matches the behavior |
| 01:34 | <rniwa> | Hixie: we both remove & insert text at the timing drop event is fired |
| 01:34 | <rniwa> | Hixie: only IE delays deletion until drop event |
| 01:34 | <rniwa> | Hixie: I can't figure out how to trigger text drag on Opera though... |
| 01:35 | <Hixie> | spec matches which, IE? |
| 01:35 | rniwa | tires firefox beta |
| 01:35 | <rniwa> | Hixie: the spec matches IE |
| 01:35 | <rniwa> | Hixie: I've just checked IE9 |
| 01:35 | <Hixie> | k |
| 01:36 | <rniwa> | Hixie: I'd go as far as to say I don't think WebKit will ever match IE |
| 01:36 | <rniwa> | Hixie: since it's extremely challenging for us to match IE's behavior here |
| 01:46 | <Hixie> | that's good information to have |
| 01:46 | <Hixie> | if i can convince you to, it would be helpful for you to post to the list saying this, along with a test case showing the problem |
| 01:46 | <Hixie> | maybe public-webapps since it'd be good to get a microsoft person to comment |
| 01:46 | <rniwa> | Hixie: good idea |
| 01:47 | rniwa | puts that on his long todo list |
| 01:47 | <Hixie> | heh |
| 01:47 | <Hixie> | i know that feeling |
| 01:48 | <rniwa> | Hixie: these days, I feel like I almost need a personal secretary program to keep track of what I need to do |
| 01:50 | <Hixie> | i've been tempted to ask chris if i can get a secretary |
| 01:50 | <Hixie> | but then i'd have to, like, manage them |
| 01:52 | <rniwa> | Hixie: yeah, your case is much more extreme |
| 01:53 | <rniwa> | Hixie: but then if that secretary doesn't know about html/etc... he/she won't be much of a help either |
| 01:54 | <rniwa> | i guess the knowledge of the web technology is a requirement for your secretary but even then finding a person who knows well enough about it and wants to be a secretary instead of a developer might be hard |
| 01:56 | <Hixie> | yeah well |
| 01:56 | <Hixie> | that's the main problem with finding spec writers in general |
| 01:57 | <Hixie> | all the good ones aren't stupid enough to go into spec writing as a career :-P |
| 01:57 | <Hixie> | apparently with the exception of a few of us here ;-) |
| 02:31 | <rniwa> | Hixie: yeah I hear you |
| 03:36 | <MikeSmith> | https://twitter.com/#!/james_clark/status/157667289947312128 |
| 03:36 | <MikeSmith> | nattokirai: ↑ |
| 03:37 | <nattokirai> | now that's cute... |
| 03:46 | <MikeSmith> | nattokirai, gotta love james, man |
| 03:46 | <nattokirai> | but now i'm very curious to see the final invitation... |
| 03:46 | <MikeSmith> | heh |
| 03:46 | <MikeSmith> | yeah |
| 05:44 | <crassus> | Does anyone know how to sync cookie/login information for mobile webapps that get homescreened to the server? |
| 05:45 | <crassus> | basically I'm wondering how to keep the cookies there for homescreened webapps so the user won't be logged out once the phone restarts or whatever |
| 05:45 | <nattokirai> | MikeSmith: https://twitter.com/?iid=am-167106996113264332229250283&nid=4+status_user&uid=48654803&utm_content=profile#!/H_FJ/status/157698482357014528 |
| 05:46 | <MikeSmith> | heh |
| 05:46 | <MikeSmith> | yah man |
| 05:46 | <MikeSmith> | certainly true in JP |
| 05:47 | <MikeSmith> | where 25:00 is seriously a real time indicator |
| 05:47 | <nattokirai> | 25:60 sounds like a good time for a wedding |
| 05:47 | <MikeSmith> | heh |
| 05:47 | <MikeSmith> | yeah |
| 06:44 | <smaug____> | dglazkov: looks like shadow DOM's event handling is rather limited... but I need to read still some more documentation... |
| 08:35 | <zcorpan> | AryehGregor: it doesn't bubble because if you have three <source>s, and the first two fail, you'd get two error events |
| 08:36 | <zcorpan> | AryehGregor: and it would mess with window.onerror which is for something else |
| 08:36 | <zcorpan> | AryehGregor: if you want to know that all sources have failed, put onerror="" on the last one and be done with it |
| 08:38 | <zcorpan> | AryehGregor: we don't fire on the video separately because the resource selection algorithm never finishes if the sources fail |
| 09:30 | <zcorpan> | execCommand on element is an opportunity to use a different API that sucks less |
| 09:47 | <hsivonen> | I wonder if it is a known bug that WebKit reuses the inner window in this case: https://bug715739.bugzilla.mozilla.org/attachment.cgi?id=586285 |
| 09:47 | <hsivonen> | the spec says not to. Firefox, IE and Opera don't. |
| 10:30 | <hsivonen> | it bothers me that the a11y TF keeps expecting to use DOM events for tracking the document state from AT |
| 10:54 | <jgraham> | Ms2ger: https://github.com/jgraham/html-testsuite/commit/b0f5a00987220d600e12d7546431e8ab5e002fb5 |
| 10:57 | <Ms2ger> | Thanks |
| 11:02 | <jgraham> | Ms2ger: You can even review the code if you are so inclined :) |
| 11:02 | <Ms2ger> | r-, inconsistent style ;) |
| 11:03 | <Ms2ger> | And forgot a 'var' |
| 11:07 | <jgraham> | Wow, github is pretty email-happy |
| 11:08 | <Ms2ger> | Hmm, maybe I shouldn't have clicked the button for each comment |
| 11:08 | <jgraham> | Anyway, I will fix :) |
| 11:09 | <Ms2ger> | Thanks :) |
| 11:12 | <jgraham> | (once I figure out hg-git a bit better. Is there really no documentation?!) |
| 11:15 | <hsivonen> | I still haven't figured out if JS-based "responsive design" that swaps images belongs in the same Web authoring bandwagon bucket that XHTML-as-text/html belonged to or if the need and benefits are real |
| 11:16 | <hsivonen> | was my email to the list too grumpy? |
| 11:20 | <jgraham> | hsivonen: No, that email was barely a blip on my grumpy-o-meter |
| 11:21 | <jgraham> | What the mobify people are doing sounds pretty nuts to me |
| 11:21 | <hsivonen> | jgraham: thanks |
| 11:26 | <jgraham> | Ms2ger: Do you have a use case for overriding on a per-test basis? It seems to me that if you are running in a perf-sensitive environment where the output will never ne used (e.g. buildbot) you want final say on whether it is generated or not |
| 11:26 | <jgraham> | s/ne/be/ |
| 11:42 | <Ms2ger> | jgraham, I don't really care either way |
| 12:13 | <NimeshNeema> | Can someone please suggest a GUI text editor for web dev (will be mostly editing hand-written .js .css and .html) with code folding and bracket matching for ubuntu 11.10 |
| 12:14 | <Ms2ger> | vim |
| 12:26 | <jgraham> | emacs |
| 12:31 | <Ms2ger> | vim! |
| 12:32 | <jgraham> | emacs!important |
| 12:34 | <Ms2ger> | vim!legal |
| 13:12 | <Workshiva> | But legal and important are the same level, aren't they? |
| 13:14 | <jarek> | NimeshNeema: Sublime Edit 2 |
| 13:14 | <jarek> | no, it's actually called "Sublime Text 2" |
| 13:14 | <NimeshNeema> | jarek: i tried it. it didn't supported Indian Language characters which i am working on extensively |
| 13:15 | <smaug____> | s/(emacs|vim)/jedit/ |
| 13:16 | <jarek> | NimeshNeema: Geany, Gedit? |
| 13:17 | <jgraham> | Eclipse? |
| 13:17 | <jgraham> | (joking) |
| 13:17 | <NimeshNeema> | jarek: Geany did the trick. I didn't found the required features in gedit so was searching for something which fulfills my needs |
| 13:22 | <MikeSmith> | visual studio |
| 13:24 | <hsivonen> | jgraham: why do people make fun of Eclipse? It's the new Emacs. |
| 13:25 | <wilhelm> | I can't think of any reason not to make fun of Eclipse. |
| 13:25 | <wilhelm> | I was exposed to it last week. |
| 13:26 | <NimeshNeema> | wilhelm: he he |
| 13:26 | <MikeSmith> | Eclipse is an acronym for "Eclipse makes a computer even slower than Emacs" |
| 13:28 | <Ms2ger> | That's an... interesting acronym |
| 13:33 | <jgraham> | hsivonen: Last time I tried it it first crashed on startup and then, once I did something to make it not crash, froze shortly after startup. For all I know there isn't actually an editor there at all. |
| 13:34 | <hsivonen> | you just need to make an offering of RAM to Eclipse up front |
| 13:34 | <wilhelm> | And a goat. Don't forget the goat. |
| 13:36 | <jgraham> | I suppose it could have been lack of memory; I don't really recall. But I do remember the problem didn't seem temporary and I had to kill it. |
| 13:44 | <hsivonen> | Eclipse ships with JVM heap parameters that are insufficient for editing the Firefox codebase |
| 13:45 | <MikeSmith> | um |
| 13:45 | <MikeSmith> | what kind of madman uses Eclipse to edit Firefox code.. |
| 13:45 | <hsivonen> | MikeSmith: I do |
| 13:45 | <MikeSmith> | oh |
| 13:45 | <MikeSmith> | you are nuts man |
| 13:45 | <MikeSmith> | why why why |
| 13:46 | <MikeSmith> | masochism |
| 13:46 | <hsivonen> | MikeSmith: ctrl-space, ctrl-shift-g among other things |
| 13:46 | <MikeSmith> | ah |
| 13:46 | <MikeSmith> | well |
| 13:46 | <MikeSmith> | speaking madness |
| 13:46 | <hsivonen> | I regret that I spent so much time using XCode on Mac before I switched to Eclipse on Linux |
| 13:46 | <MikeSmith> | there is the eclim thing for vim |
| 13:47 | <hsivonen> | ctrl-shift-g would be more useful if Gecko was less COMtaminated |
| 13:47 | <MikeSmith> | which at the risk of also being considered insane I will admit to having used |
| 13:47 | <MikeSmith> | ah yeah |
| 13:47 | <MikeSmith> | the grand XPCOM experiment |
| 13:48 | <MikeSmith> | that was a grand idea at the time |
| 13:49 | <hsivonen> | I like Eclipse and have made hardware purchases motivated by it |
| 13:49 | Philip` | can barely stand writing C++ in anything other than Visual Studio + Visual Assist |
| 13:49 | <Philip`> | (Eclipse is the least bad alternative I've used) |
| 14:05 | <niloy_> | Anyone thinks Netbeans is a good editor? |
| 14:08 | <hsivonen> | niloy_: it uses the Validator.nu HTML parser, so it has to be ;-) |
| 15:16 | <AryehGregor> | zcorpan (in absentia): ah, that makes a lot of sense. If you have <source>s, you can put the error event on the last <source>, and if you don't, you can put it on the <video>. |
| 15:16 | <AryehGregor> | I'd still think a separate error event fired at the <video> as well would be useful, but what we have now sounds like it should work fine too. |
| 15:46 | <niloy_> | Error event on the last source implies all sources are processed from top to bottom, that is standardized? |
| 16:06 | <AryehGregor> | niloy (in absentia): yes. |
| 16:38 | <speedxcore> | I'm looking for the WHATWG development workflow. Anyone who has a link. |
| 16:39 | <Ms2ger> | http://wiki.whatwg.org/wiki/FAQ, maybe? |
| 16:54 | <dglazkov> | good morning, Whatwg! |
| 16:54 | <dglazkov> | smaug____: please file bugs as you find problems! Your help is greatly appreciated. |
| 16:54 | <smaug____> | dglazkov: I will |
| 16:54 | <speedxcore> | Ms2ger: Thanks I found what I was looking for. |
| 16:54 | <Ms2ger> | Np |
| 16:54 | <smaug____> | is there a component in w3c bugzilla ? |
| 16:54 | <smaug____> | dglazkov: ^ |
| 16:55 | <dglazkov> | smaug____: yep. There's even a handy button at the top |
| 16:55 | <dglazkov> | which prefills the bug with the right stuff |
| 16:55 | <dglazkov> | The "File a bug" button :) |
| 16:56 | <speedxcore> | How is the editor for WHATWG elected? Is there any semi-democratic process? |
| 16:56 | <Ms2ger> | No |
| 16:56 | <jgraham> | Yes, it is "semi" democratic |
| 16:56 | <Ms2ger> | There's only one person who's mad enough to do it |
| 16:57 | <jgraham> | In the same way that all good dictatorships are |
| 16:57 | <jgraham> | Except this one actually has a basis in merit, and an out clause |
| 16:57 | <speedxcore> | I guess if the editor is misbehaving a revolution will accour =) |
| 16:58 | <gsnedders> | Technically the members can place whoever they want as editor. In practice, there are few people who'll actually manage to get paid to work fulltime on editing a spec. |
| 16:58 | <jgraham> | The out clause being "if Hixie stops being a good editor, browser vendors will just ignore him and fork the spec" |
| 16:59 | <speedxcore> | jgraham: Thanks, I just wanted to confirm my suspicion from reading the faq. Fork on misbehave sounds correct. |
| 17:00 | <speedxcore> | Does google-ceo have any influence over Ian when he takes crucial decisions? |
| 17:00 | <Ms2ger> | Also, the WHATWG Members |
| 17:01 | <Ms2ger> | speedxcore, Hixie claims not |
| 17:01 | <speedxcore> | btw. I'm not trying to troll or anything. I'm writing a report on html development, and want everything to be correct. |
| 17:01 | <gsnedders> | In practice the WHATWG Members have influence insofar as they can just threaten to walk out and replace the editor. |
| 17:02 | <speedxcore> | gsnedders: Now I get it. Thanks. |
| 17:08 | <Philip`> | It seems the most unique visible influence of Google is in providing resources for research, and in Google developers being able to easily have face-to-face meetings with Hixie |
| 17:08 | <smaug____> | speedxcore: well, browser vendors have influence what Ian does, and I could assume google-ceo can affect to Chrome, so that way he has some influence |
| 17:08 | <Philip`> | Otherwise they don't seem to do anything much different to any other similar organisation |
| 17:12 | <speedxcore> | Philip`: if the chrome-team would know what decision Hixie is going to take before it gets published that could be a competitive edge, but maybe that doesn't happen. Or isn't a problem. |
| 17:13 | <Ms2ger> | Philip`, from what I hear, other browser vendors in the bay area can get to meet Hixie f2f about as easily |
| 17:13 | <Ms2ger> | So I guess we're just excluding Opera |
| 17:13 | <jamesr> | IE team isn't in the bay area |
| 17:13 | <hober> | Ms2ger: yeah, pretty much |
| 17:13 | <smaug____> | (Afaik Opera has an office in that area) |
| 17:14 | <Ms2ger> | Pff, IE |
| 17:14 | <gsnedders> | smaug____: Sales and marketing only. |
| 17:14 | <smaug____> | oh |
| 17:14 | <gsnedders> | There are a few engineering staff in the US, but related to contracts with US companies. |
| 17:15 | <smaug____> | well, if Hixie does something Opera doesn't like, Anne can always do counter changes in one of his specs :p |
| 17:15 | <gsnedders> | And one or two who work remotely from home. |
| 17:15 | <Ms2ger> | smaug____, you mean, in half a year, when he gets to edit that spec again ;) |
| 17:15 | <smaug____> | half a year? |
| 17:16 | <Philip`> | speedxcore: Decisions about things like API design usually don't seem to happen until the point when the spec text is written, and at that point it gets pushed to SVN and everyone can see it |
| 17:17 | <smaug____> | and after something is in the spec, it gets reviewed and often changed |
| 17:17 | <speedxcore> | Philip`: sounds like a minor or non-existant problem in that case. |
| 17:17 | <Ms2ger> | smaug____, with the number of specs he's editing, how could he get to each spec more than once very six months? :) |
| 17:17 | <smaug____> | reviewing may happen months or even years after the text has been written |
| 17:17 | <smaug____> | Ms2ger: ah, true |
| 17:23 | <AryehGregor> | speedxcore, FWIW, I worked for the last year on spec editing under Hixie, and no one from Google got disproportionate influence over my technical decisions. Some of them would send me private e-mail, but so would other people. I met once face-to-face with some Google people, but Mozilla people too. |
| 17:24 | <AryehGregor> | Hixie would tell me what I could work on on Google's time, but not what I had to put in the spec. |
| 17:28 | <speedxcore> | AryehGregor: Interesting to know. Development workflow seems fair according to your account. I have poor understanding for what goes on behind the scenes and writing on a report so that's why I brought this up. Thank you |
| 17:56 | <smaug____> | Nightly's 3D is fun. I wonder why Facebook and Gmail use so deep DOM hierarchies |
| 18:31 | <TabAtkins> | jamesr: Box is *completely* obsolete. Pay no attention to it. |
| 18:31 | <jamesr> | even the dec 2011 revision? |
| 18:31 | <jamesr> | sorry, nov 2011 |
| 18:32 | <AryehGregor> | smaug____, Gmail is generated using GWT from a Java program, IIUC, not hand-written or anything close to it. |
| 18:33 | <TabAtkins> | jamesr: Yes. |
| 18:33 | <jamesr> | AryehGregor: ?????? no |
| 18:33 | <smaug____> | AryehGregor: based on the 3D view of it, there should be plenty of ways to optimize it |
| 18:34 | <TabAtkins> | Anton should be working on it now, but it'll still be a while before it's usable. |
| 18:34 | <jamesr> | TabAtkins: k. is anyone/anything working on improving or replacing visres/visdet? |
| 18:34 | <jamesr> | ah ok |
| 18:35 | <AryehGregor> | jamesr, it's not? |
| 18:35 | <AryehGregor> | My bad. |
| 18:36 | <AryehGregor> | So it's just regular div soup. :) |
| 18:36 | <TabAtkins> | Gmail was, at one point, a GWT program I think. Just not anymore. |
| 18:36 | <TabAtkins> | Definitely not since the Kennedy refresh. |
| 18:37 | <jamesr> | newp. common misconception |
| 18:37 | <TabAtkins> | Huh. Ok. |
| 18:47 | <dglazkov> | TabAtkins: people on GMail team will probably punch you for saying that they at any point used GWT :) |
| 18:47 | <TabAtkins> | dglazkov: I'll punch them back for using impossible-to-track ids and classes. |
| 18:49 | <dglazkov> | TabAtkins: should I start selling tickets for the event? :) |
| 18:51 | <TabAtkins> | Only if I get a cut. |
| 18:52 | <dglazkov> | :) |
| 19:02 | <jamesr> | rumble in the DOM jungle |
| 19:15 | <gsnedders> | AryehGregor: A fair number of Google things *are* GWT-based, neither Gmail nor Maps are. |
| 19:16 | <gsnedders> | Hmm, Maps appears to have some JS in it now that looks GWT-ish. |
| 19:17 | <gsnedders> | But most of it isn't, still. |
| 20:43 | <TabAtkins> | jamesr: So, we're discussing how to specify exactly when transitions are checked for, since right now it's "whenever the browser notices a change". |
| 20:43 | <TabAtkins> | jamesr: Boris suggests hooking it to the rAF cycle. Does that seem feasible? |
| 20:44 | <jamesr> | it's feasible in some cases |
| 20:44 | <jamesr> | but some things no |
| 20:44 | <jamesr> | so one big question is what exactly depends on this value |
| 20:44 | <jamesr> | is it the ordering of events? timestamps? |
| 20:44 | <jamesr> | for systems that run some transitions off the main thread (like CoreAnimation) the start time has to be decided by that thread |
| 20:45 | <TabAtkins> | Ordering, mainly. Frex, we're making it so that transitions don't start from a display:none state. |
| 20:45 | <TabAtkins> | If you change to display:block and change a transitionable property, whether or not it kicks off a transition depends on whether a flush happened between the two. |
| 20:45 | <jamesr> | so the model internally in WebKit when using CoreAnimation is the style system figures out that the transition has started, then sends a request to the CoreAnimation thread to start it. at some point later, it gets a message back saying "ok, here is the start time" |
| 20:45 | <jamesr> | ah i see |
| 20:45 | <TabAtkins> | And all browsers flush somewhat differently. |
| 20:46 | <TabAtkins> | So we're trying to find a less controversial "look for computed-value changes" point. |
| 20:46 | jamesr | has found the thread |
| 20:46 | <jamesr> | what if we have to resolve styles earlier for some other reason? |
| 20:46 | <TabAtkins> | Jump down to the latest exchange between Boris and me. |
| 20:46 | <jamesr> | do we just have to defer judgement on the transitions until later? |
| 20:46 | <TabAtkins> | jamesr: If we settle on something else, I guess those just wouldn't trigger transitions? I dunno. |
| 20:46 | <TabAtkins> | (Possibly, we add a method that forces a check.) |
| 20:47 | <TabAtkins> | Or rather, they wouldn't trigger transitions *yet*. They would when we eventually hit the checkpoint. |
| 20:47 | <jamesr> | fyi text input is fucking crazy land |
| 20:47 | <TabAtkins> | Apparently. |
| 20:47 | <jamesr> | and requires all sorts of style flushing shenanagins. but probably not relevant here |
| 20:48 | <jamesr> | TabAtkins: lemme get some grub and catch up on that thread |
| 20:48 | <TabAtkins> | jamesr: You in campus? |
| 20:49 | <jamesr> | nope, gardening from home |
| 20:49 | <TabAtkins> | Ah, kk. Then I'll get lunch too, we'll meet back here in a few. |
| 20:49 | <jamesr> | ooo an IRC date. how exciting! |
| 21:19 | <jamesr> | TabAtkins: ok, think i'm caught up |
| 21:20 | <jamesr> | is boris in here? |
| 21:21 | <jamesr> | also does CSS have an explicit "as-if" clause anywhere like HTML does? |
| 21:23 | <jamesr> | like this: "Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)" |
| 22:04 | <TabAtkins> | jamesr: Back now. |
| 22:04 | <TabAtkins> | We don't have an explicit clause at the language-level, but it's assumed anyway. |
| 22:04 | <TabAtkins> | I don't think Boris is here, unless he's bzed. |
| 22:05 | <jamesr> | /who says bzed is someone else |
| 22:05 | <TabAtkins> | That's what I thought. |
| 22:05 | <jamesr> | so i interpret that as meaning timing is out of scope unless it's security sensitive |
| 22:05 | <root0> | hi all. I use lxml how to get absolute link? |
| 22:05 | <TabAtkins> | Or just detectable in general. |
| 22:06 | <TabAtkins> | But otherwise, yes, as long it's not detectable in any important way, timing is up to the UA to do as they please. |
| 22:06 | <jamesr> | well no, detectable isn't the right metric |
| 22:07 | <jamesr> | whether it's detectable or reliably detectable isn't a concern unless it's a security concern |
| 22:07 | <TabAtkins> | No, that's wrong. |
| 22:07 | <TabAtkins> | Because if two browsers have different timing behavior such that transitions fire at different times in a way that's detectable from script, that's a problem. |
| 22:08 | <TabAtkins> | Particularly if the different timings actually produce different behavior, as in the situation that Sylvain mentioned. |
| 22:08 | <jamesr> | that's not the sort of timing i mean |
| 22:08 | <jamesr> | i mean how long things take, not in which order things happen |
| 22:08 | <jamesr> | so i'm not sure how any of the proposals address Sylvain's scenario |
| 22:08 | <TabAtkins> | Oh, yeah, we don't carea bout that. |
| 22:08 | <jamesr> | or exactly what the behavior he expects is |
| 22:08 | <root0> | http://paste.pocoo.org/show/534459/ |
| 22:09 | <TabAtkins> | jamesr: I was just referring to the fact that there may be a difference in behavior based on whether a flush happens between or after the two style changes. |
| 22:09 | <root0> | this is my code. i can get result like http://paste.pocoo.org/show/534462/ |
| 22:09 | <root0> | I want add http://www.111111.com to head |
| 22:10 | <TabAtkins> | root0: This isn't really an lxml help room. |
| 22:10 | <TabAtkins> | root0: I cant' suggest a better place to find help, but here is probably not good. |
| 22:10 | <jamesr> | in the spec excluding transitions, the concept of flushes doesn't exist |
| 22:10 | <TabAtkins> | Yes. |
| 22:11 | <TabAtkins> | Because it's undetectable from just applying every style change as it happens. |
| 22:11 | <jamesr> | right. we also do a bunch of other work at the same time (because it's convenient and the other work is also not observable) |
| 22:12 | <jamesr> | defining flush points would restrict that other work as well |
| 22:12 | <jamesr> | i also don't think it will really help authors |
| 22:13 | <jamesr> | today when perf is the only consequence it's pretty much impossible for authors to deal with |
| 22:14 | <TabAtkins> | I don't understand your point. |
| 22:15 | <jamesr> | so your proposal as i understand is to define flush points explicitly and say that all changes between flush points are treated atomically |
| 22:15 | <jamesr> | right? |
| 22:15 | <TabAtkins> | Well, my aim is to find *some* way of defining in a cross-browser-possible way when precisely styles are examined for "changes" to trigger transitions off of. |
| 22:16 | <TabAtkins> | If it's done by specifying flush points, fine. If it's something else, also fine. |
| 22:16 | <jamesr> | i think that trying to define transitions in this way isn't going to pan out |
| 22:16 | <jamesr> | in css changes don't happen |
| 22:16 | <TabAtkins> | They've gotta be defined in *some* way. :/ |
| 22:17 | <TabAtkins> | Sure, in pure CSS. If it's pure-CSS changes, we don't care; they can continue to happen "whenever". |
| 22:17 | <TabAtkins> | But script-based changes need to have their timing defined relative to Transitions. |
| 22:17 | <TabAtkins> | (That is, a :hover pseudo kicking off a transition can continue to do so whenever.) |
| 22:18 | <jamesr> | is display:none the only thing where the behavior of the transition depends on the timing? |
| 22:19 | <TabAtkins> | Not necessarily. For example, Boris points out that in visibility:hidden subtrees, some properties may be optimized to not compute unless necessary. |
| 22:20 | <jamesr> | and that affects transition behavior? |
| 22:20 | <TabAtkins> | Since transitions fire on computed-value changes, yes. If you don't calculate computed values, you may miss some changes. |
| 22:21 | <jamesr> | sounds like you've got yourself a bit of a mess, then |
| 22:21 | <TabAtkins> | This is why Boris is suggesting finding some other useful regularly-occurring trigger point for "compute everything, and look for changes from last trigger point". |
| 22:22 | <TabAtkins> | Like, as he suggested, something tied to the rAF cycle. |
| 22:22 | <jamesr> | that wouldn't do what Sylvain expected |
| 22:22 | <TabAtkins> | That's fine. I expect that we have a set of contradictory constraints. |
| 22:22 | <TabAtkins> | And thus some can't be satisfied. |
| 22:24 | <jamesr> | so we'd still generate new computed values as needed, but whether transitions happen or not is based on comparing the computed value at Doom Time to the value at the last Doom Time? |
| 22:24 | <TabAtkins> | Yes. |
| 22:24 | <jamesr> | and even if it changes in between in a script-observable way so long as it changes back by the next Doom Time the transition doesn't happen? |
| 22:24 | <TabAtkins> | Yup. |
| 22:24 | <TabAtkins> | That's Boris' idea, at least. |
| 22:24 | <jamesr> | i think you'd want to hook in closer to HTML's "Update the rendering" concept |
| 22:25 | <jamesr> | which is similar but not identical to rAF time |
| 22:25 | <jamesr> | (i think they're the same in gecko, but aren't always the same in chrome or safari) |
| 22:25 | TabAtkins | goes to look up that term. |
| 22:26 | <TabAtkins> | Ah, so that's at the end of each task. |
| 22:27 | <jamesr> | not necessarily |
| 22:27 | <jamesr> | it's an optional step |
| 22:27 | <TabAtkins> | Yes. |
| 22:27 | <jamesr> | requiring at every task might be too much |
| 22:28 | <TabAtkins> | It's not actually optional; it's "as necessary". |
| 22:28 | <jamesr> | yeah, but necessary is up to the UA |
| 22:28 | <jamesr> | so pretty much the same as optional |
| 22:28 | <TabAtkins> | Sure. We can intelligently dirty, though, to ensure that transitions happen as expected. |
| 22:30 | <jamesr> | if you can define expected |
| 22:30 | <jamesr> | your expected behavior is definitely different from Sylvain's, and i'm not sure how it compares to Boris' |
| 22:31 | <TabAtkins> | Yes. |
| 22:31 | <TabAtkins> | Okay, I just wanted to sanity-check and fill out details. I'll return to the thread with info. |
| 22:31 | <jamesr> | i think it's kind of weird for authors to set up a transition and then observe values from script that are different but that don't trigger the transition |
| 22:31 | <jamesr> | but who knows what authors expect there |
| 22:31 | <jamesr> | i've seen all sorts of wacky ideas |
| 22:32 | <jamesr> | some guy from zynga was convinced that rapidly polling a transitioned property's computed value was the best way to measure the browser's FPS (wtf?) |
| 22:32 | <TabAtkins> | Heh. |
| 22:35 | <jamesr> | i just implement and haven't tried to author these things, so i say that the whole model is stupid and you should throw it away |
| 22:35 | <TabAtkins> | Transitions are so awesome, though! |
| 22:36 | <jamesr> | you can't chain them |
| 22:36 | <jamesr> | they make trivial things easy and not-completely-trivial things impossible |
| 22:37 | <TabAtkins> | Yes. |
| 22:37 | <TabAtkins> | Trivial things being easy is a good thing! |
| 22:37 | <TabAtkins> | And then we can fix the rest by abstracting. |
| 22:38 | <TabAtkins> | Such that transitions become a syntax-blessed simple form of the greater system. |
| 22:38 | <jamesr> | good API design makes easy things easy and hard things possible |
| 22:38 | <TabAtkins> | Animations are in the exact same boat. |
| 22:38 | <jamesr> | the greater system doesn't allow chaining either |
| 22:38 | <TabAtkins> | Animations are very simple in some ways, and expose complexity in others. Luckily, both the exposed complexities and the holes of Transitions and Animations are amenable to a shared abstraction. |
| 22:38 | <TabAtkins> | Sure it does. |
| 22:45 | <jamesr> | if you have an animation in progress, how do you say "start this animation as soon as the previous one ends and line up the start time of this animation with the end time of that animation so it interpolates smoothly" ? |
| 22:46 | <TabAtkins> | Right now? You can't, because the higher abstraction doesn't exist. |
| 22:46 | <TabAtkins> | Sometime this year I expect something to appear, though. |
| 22:49 | <TabAtkins> | Shane and I were working more-or-less on that last year. |
| 23:26 | <dglazkov> | is there any work at all anywhere on specifying display:transparent? |
| 23:28 | <jamesr> | wassat? |
| 23:29 | <dglazkov> | it throws away the box of the matching element and tells its content to step up instead. |
| 23:31 | <dglazkov> | http://lists.w3.org/Archives/Public/www-style/2011Apr/0162.html |
| 23:32 | <TabAtkins> | Not yet, no. |
| 23:32 | <TabAtkins> | Pretty much anything regarding 'display' is delayed by lack of editor\. |
| 23:32 | <TabAtkins> | Presumably for Box. |
| 23:32 | <TabAtkins> | Including my desire for display-outside/inside. ;_ |
| 23:32 | <TabAtkins> | ;_; |
| 23:33 | <dglazkov> | can we make an editor? |
| 23:33 | <dglazkov> | make editor |
| 23:33 | <dglazkov> | sudo make editor |
| 23:33 | <TabAtkins> | Need root for the universe. |
| 23:33 | <Hixie> | make: *** No rule to make target `editor'. Stop. |
| 23:34 | <jamesr> | best bet is to fork one off existing editors |
| 23:34 | <jamesr> | can take a while, though |
| 23:40 | <dglazkov> | git clone Hixie editor |
| 23:40 | <Hixie> | dude i'm not a git :-P |
| 23:41 | <dglazkov> | :) |