| 00:09 | <ojan> | TabAtkins: aahhhhh. writing test-cases for some of these flexbox things is so confusing. |
| 00:09 | <ojan> | TabAtkins: it's surprisingly hard to think about what the correct rendering is for many cases. |
| 00:12 | <TabAtkins> | Yus. Anything in particular? |
| 00:14 | <ojan> | TabAtkins: <div class="flexbox vertical-rl column"> versus <div class="flexbox vertical-lr column"> |
| 00:14 | <ojan> | TabAtkins: assume the classnames set the display, writing-mode and flex-flow values respectively |
| 00:14 | <ojan> | TabAtkins: do those render the same? or is one the reverse order of the other |
| 00:15 | <ojan> | TabAtkins: in my current implementation it's rendering them reverse...but i think it might be wrong? |
| 00:15 | <TabAtkins> | The lr/rl set the block-flow direction. The inline-flow direction is top-to-bottom in both. |
| 00:16 | <TabAtkins> | So, since 'column' makes the main direction follow the block-flow direction, they'd be reversed. |
| 00:16 | <ojan> | TabAtkins: ok. that explanation makes sense. |
| 00:17 | <ojan> | TabAtkins: so, ignoreing multiline, <div class="flexbox vertical-rl column"> would render the same as <div class="flexbox horizontal-tb row rtl"> |
| 00:17 | <ojan> | TabAtkins: i say ignoring multiline because i haven't even sstarted thinking about how multiline affects things. |
| 00:18 | <TabAtkins> | Yes, they'd render the same. |
| 00:18 | <ojan> | TabAtkins: they'd render the same except for padding-start, etc would be ltr in the first case and rtl in the second |
| 00:18 | <TabAtkins> | They'd also render the same in multiline, since the perpendicular axises go in the same direction for both. |
| 00:18 | <TabAtkins> | Yes. |
| 00:18 | <ojan> | TabAtkins: great. |
| 00:19 | <ojan> | TabAtkins: thx for helping me think this through. you might want to give some of the above as examples in the spec. |
| 00:19 | <ojan> | TabAtkins: since they clarify expected behavior. i think the spec text matches what you just described, but it's hard to think all that through. |
| 00:20 | <TabAtkins> | Heh, kk. I need to draw up pictures for some of these, because writing-modes are hard to wrap your head around. |
| 00:20 | <ojan> | yes! |
| 00:20 | <TabAtkins> | The spec text definitely matches what I just said, because I checked it before saying anything just to make sure. ^_^ |
| 00:20 | <ojan> | TabAtkins: by far, the hardest part of implementing any of this is thinking through the tests |
| 00:20 | <ojan> | TabAtkins: the C++ code is mostly relatively straightforward |
| 00:22 | <TabAtkins> | Related: urgh, writing the "figure out the hypothetical size of each flexbox item" is the hardest part of the algorithm. |
| 00:23 | <ojan> | TabAtkins: yup, the rest of the algorithm is relatively straightforward i think |
| 00:45 | <Hixie> | who's a good person to cc for perf wg issues? |
| 00:46 | <TabAtkins> | jamesr_ ? |
| 00:46 | <ojan> | Hixie: jamesr_ works with perf wg stuff a lot, i'm not sure how directly involved he is with the wg, but i believe he's editor of requestAnimationFram spec |
| 00:46 | <Hixie> | k |
| 00:49 | <jamesr_> | sup? |
| 00:49 | <jamesr_> | Hixie, i'm editor of requestAnimationFrame and sit close to people who follow the rest of the specs |
| 00:49 | <jamesr_> | heycam's also editor on rAF |
| 00:49 | <jamesr_> | i'm not sure of his level of involvement in other specs |
| 00:49 | <jamesr_> | (and i've been too busy lately to do much at all, but oh well) |
| 00:51 | <Hixie> | cced you on a bug |
| 00:51 | <Hixie> | w3c bug |
| 00:52 | <jamesr_> | Hixie, kk |
| 00:52 | <Hixie> | on another note, chrome trunk has an absurd regression rendering the html spec |
| 00:53 | <Hixie> | taking 100s of milliseconds to repaint, continuously |
| 00:53 | <Hixie> | even if nothing happens but mouse movement |
| 01:03 | <jamesr_> | can you file a bug? |
| 01:18 | <Hixie> | jamesr_: jamesr_ http://code.google.com/p/chromium/issues/detail?id=98963 |
| 01:26 | <TabAtkins> | Hixie, ojan: fantasai reminded me why display:none isn't very good, and thus why we probably do want a different model of hiding, such as what visibility:collapse might be able to offer. |
| 01:27 | <TabAtkins> | display:none has additional magic effects beyond the hiding - it also suppresses list counter increments, and there's a good chance it'll be defined as suppressing animations too. |
| 01:27 | <ojan> | TabAtkins: i see that thread...i'll respond eventaully...if we want a different behavior, that's fine....but retro-fitting visibility:collapse for that seems wrong since it already does the wrong thing most of the time |
| 01:28 | <TabAtkins> | (This is because display:none subtrees are generally optimized away almost completely.) |
| 01:28 | <Hixie> | TabAtkins: sure, that's why i said you map [hidden] whatever you actually need |
| 01:28 | <TabAtkins> | ojan: Yeah, perhaps. |
| 01:28 | <Hixie> | TabAtkins: height:0, width:0, opacity:0, whatever it is you're styling |
| 01:28 | <Hixie> | s/styling/animating/ |
| 01:28 | <ojan> | TabAtkins: fantasai basically wants visiblity:collapse to be height:0;overflow:hidden, right? |
| 01:29 | <ojan> | s/height/logicalHeight/ |
| 01:29 | <TabAtkins> | Well, for block elements, yeah. |
| 01:29 | <ojan> | right |
| 01:29 | <TabAtkins> | That's not sufficient for flexbox items, because of flex-pack:justify. |
| 01:29 | <zewt> | it'd be unpleasant if using hidden results in a slower page than display: none |
| 01:30 | <TabAtkins> | I suspect a better definition might be "position:absolute; height:0; width:0;". Still completely out-of-flow, but it generates boxes. |
| 01:30 | <zewt> | i guess that'd mean everyone would force [hidden] to display: none if it made a visible (err, ... perceptible, heh) difference |
| 01:31 | <ojan> | TabAtkins: regardless, this should clearly be a new property/value |
| 01:31 | <TabAtkins> | Yeah, you're probably right. So I should still revert the visibility:collapse change. |
| 01:35 | <Hixie> | position:absolute is not much better than display:none, since it overrides 'display' |
| 01:35 | <Hixie> | but it does happen to not screw up counters |
| 01:35 | <TabAtkins> | It's much better in that it still generates a box, yeah. |
| 01:36 | <Hixie> | i think height:0 or width:0 is what you typically want if you want to affect layout |
| 01:36 | <Hixie> | then you'd get a transition and so on |
| 01:36 | <Hixie> | animating 'position' isn't likely to be useful |
| 01:37 | <TabAtkins> | Just setting height or width doesn't work for flexbox. You can still detect the presence of the "hidden" element if "flex-pack:justify" is used, because it'll look like a double-wide space there. |
| 01:37 | <Hixie> | that seems... bad |
| 01:37 | <Hixie> | why is it not bad? |
| 01:37 | <TabAtkins> | Do you mean that it's bad that this effect occurs? |
| 01:38 | <Hixie> | well it seems like if your box has no height or width it should probably not make spaces appear |
| 01:38 | <Hixie> | but i'm not familiar with contemporary flexbox ideas |
| 01:39 | <TabAtkins> | flex-pack distributes the leftover space when all the items are done flexing. 'justify' puts it equally between every item. |
| 01:40 | <Hixie> | ah, i see |
| 01:40 | <Hixie> | so you want a margin-collapsing-like effect |
| 01:40 | <Hixie> | hmm |
| 01:40 | <TabAtkins> | Maybe? Note, though, that even if you did have something that acted like margin-collapsing, it still wouldn't animate well. |
| 01:40 | <Hixie> | how would you transition from the element being there to the element not being there and the space being distibuted as if it was not? |
| 01:41 | <Hixie> | with the spacing animating properly the whole way through? |
| 01:41 | <TabAtkins> | As soon as you stopped meeting the requirements for collapsing through, the two spaces would uncollapse and you'd have a wider space again. |
| 01:41 | <Hixie> | seems like that's the problem to fix |
| 01:41 | <TabAtkins> | Yeah, you can't. |
| 01:41 | <TabAtkins> | As far as I can tell. |
| 01:41 | <TabAtkins> | Because that would require the algorithm to be stateful. |
| 01:41 | <Hixie> | that seems bad. people are all about their animations these days. |
| 01:41 | <Hixie> | that's probably the place to start in trying to fix this |
| 01:42 | <TabAtkins> | There's a difference between the desired spacing around an element that just un-hid and the desired spacing around an element of the same size that's been sitting there the whole time. |
| 01:43 | <Hixie> | there's a difference between the spaces around the other elements in those two cases too |
| 01:43 | <TabAtkins> | Yes. |
| 01:43 | <Hixie> | but it seems one needs a solution that allows for that value to transition smoothly |
| 01:43 | <Hixie> | for this to be useful in practice |
| 01:44 | <jamesr_> | Hixie, you're using Leopard? |
| 01:48 | <Hixie> | jamesr_: yes |
| 07:12 | <zcorpan> | Hixie: maybe we should count keystrokes in the comment box to prevent people from pasting a chunk of the spec and submitting that |
| 07:51 | <Hixie> | zcorpan: send me a patch |
| 07:51 | <Hixie> | zcorpan: going to bed now |
| 07:51 | <Hixie> | i haven't been able to update the spec today, jgraham's site has been down for me |
| 07:57 | <annevk> | http://infrequently.org/2011/10/real-constructors-webidl-last-call/#comment-238768 sadly true |
| 07:59 | <Hixie> | yet more reasons why "last call" is a waste of time... |
| 08:00 | <Hixie> | ok really gonig to bed now |
| 08:00 | <Hixie> | nn |
| 08:02 | <hsivonen> | http://www.adobe.com/devnet/html5/articles/css-shaders.html |
| 08:02 | <hsivonen> | it seems that Adobe has really decided to do their stuff in WebKit instead of Flash Player from now on |
| 08:06 | <hsivonen> | Do vertex shaders make it possible to do hit testing computations easily when the user interacts with a distorted mesh? |
| 09:24 | <Philip`> | hsivonen: The usual approach for hit testing on the GPU is to render the scene with a different solid colour per object, then read back the colour underneath the mouse cursor to figure out which object it was |
| 09:24 | <Philip`> | and doing it on the CPU instead sounds hard (since you'd have to emulate the vertex shaders, with adequate performance) |
| 09:25 | <Philip`> | so it doesn't seem like a trivial problem either way |
| 10:01 | <hsivonen> | Philip`: so you have to enumerate hit targets ahead of time |
| 10:02 | <hsivonen> | Philip`: what if the user clicks a distorted canvas. is there any feasible way to deliver the click coordinates to JS in the undistorted coordinate space? |
| 10:08 | <Philip`> | I don't think I've ever heard of anything like that (though it might be technically possible with some hack like rendering to a floating-point buffer with the R channel corresponding to the original x coordinate and G channel for y, then read back the colour to get the original coordinates, or something) |
| 10:08 | Philip` | would defer to someone with more experience of this kind of stuff, though |
| 10:10 | <foolip> | gsnedders, how old were you when you attended your first W3C meeting? |
| 10:10 | <foolip> | we have disagreement in the office, the lowest bid being 12 :) |
| 10:11 | <jgraham> | Wasn't it TPAC 2008 when he was, uh, 16? |
| 10:12 | <foolip> | that sounds more... sane |
| 10:13 | <annevk> | http://www.flickr.com/photos/gsnedders/2964101064/ |
| 10:14 | <jgraham> | First post to WHATWG was january 2007 when he was 14ish |
| 13:33 | <RIch_Clark> | I'm seeing a few use cases for <output> like this http://jsfiddle.net/robertc/YCEKQ/ question is, is that an appropriate use case as it doesn't really represent "the result of a calculation" can anyone advise? |
| 13:36 | <zcorpan> | why is it not a result of a calculation? |
| 13:37 | <Rich_Clark> | because it's a single input, nothing is 'calculated' by moving a slider for type=range, it's just showing the current value |
| 13:40 | <zcorpan> | yeah. file a spec bug with the use case :) |
| 13:43 | <Rich_Clark> | Sure, to confirm do you think the output wording needs editing to allow a use case as this? |
| 13:44 | <zcorpan> | probably yeah |
| 13:44 | <Rich_Clark> | ok cheers |
| 16:38 | <annevk> | smaug____, so why exactly does the Gecko insertNode behavior make sense? |
| 16:39 | <annevk> | smaug____, from http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html#Level-2-Range-Insertions it does seem like insert operations result in including the inserted node into the range |
| 16:39 | <annevk> | of course they are non-normative examples |
| 16:39 | <smaug____> | because of consistency, but since others changed behavior to match acid3, I think gecko may do so too |
| 16:39 | <annevk> | but what else can you go by with the standards from 2000 |
| 16:39 | <smaug____> | per D2R Gecko behavio is right |
| 16:40 | <annevk> | consistency with what? |
| 16:40 | <smaug____> | consistency with other dom mutations |
| 16:40 | <annevk> | really? |
| 16:45 | <smaug____> | yes :) |
| 16:48 | <annevk> | where is that defined? |
| 16:49 | <annevk> | ah yeah |
| 16:49 | <annevk> | okay |
| 16:50 | <annevk> | so do we now do this for collapsed ranges in general? |
| 16:50 | <annevk> | or only for insertNode? |
| 16:50 | <annevk> | my apologies for being slow |
| 16:50 | <timeless> | has anyone here installed a `cvs` client on windows recently? |
| 16:50 | timeless | is having trouble *finding* cvsnt |
| 16:50 | <annevk> | cygwin? |
| 16:51 | <annevk> | when I had Windows, cygwin was the way |
| 16:51 | <annevk> | but IE6 was too, so... |
| 16:51 | <timeless> | cygwin gives me headaches |
| 16:51 | timeless | could probably get cvs from an old moztools |
| 16:53 | <timeless> | seems like the primary distributor of cvsnt stopped offering it around Wednesday June 30th, 2010 |
| 16:53 | <zewt> | fortunately cvs is dead and buried out here in the civilized world :) |
| 16:54 | <timeless> | yeah, http://dev.w3.org/2009/dap/contacts/CVS/is uncivilized |
| 16:54 | <timeless> | s/is/ is/ |
| 16:54 | <zewt> | y |
| 16:54 | <annevk> | if you promise MikeSmith beer he can move it |
| 16:55 | timeless | was hoping to be able to do a migration and offer it up |
| 16:55 | <timeless> | but clearly that's too hard :( |
| 16:59 | <annevk> | 1) why is http://w3c-test.org/webperf/specs/ResourceTiming/ on w3c-test.org? |
| 16:59 | <annevk> | 2) it does not define basic terms such as "browsing context" and "fetch" and went into Last Call anyway? |
| 17:00 | <annevk> | nobody does any basic checks anymore? |
| 17:01 | arun_ | sets a trap for heycam and lurks |
| 17:08 | <jgraham> | annevk: There is a small community that doesn't totally suck at spec writing and they don't have time to follow all the specs people are trying to write |
| 17:08 | <annevk> | I'm not sure that spec is good |
| 17:09 | <annevk> | it's not really bad, but still |
| 17:09 | <annevk> | I gave some feedback |
| 17:09 | <annevk> | last time I gave feedback to web-perf however I think it went largely unaddressed because plh distracted it by focusing on a very simple thing |
| 17:10 | <annevk> | jgraham, the main problem here is that these specs are not developed in WebApps |
| 17:10 | <arun_> | Hmm... that spec. also has outdated references (why DOM3Core, for example?) |
| 17:10 | <timeless> | arun_: if he's in .nz, you might need to lurk for a while... |
| 17:10 | <annevk> | if they were in WebApps I'm sure people in WebApps would have steered them in the right direction |
| 17:11 | <timeless> | annevk: yep |
| 17:11 | timeless | would have given more feedback |
| 17:11 | <arun_> | timeless, guess you're right; was kinda hoping he lingered in MV after all hands at Moz' but oh well :-\ |
| 17:11 | <timeless> | arun_: i certainly am not in a position to *know* that |
| 17:12 | <timeless> | i do know that some people tend to flee .us eagerly |
| 17:12 | <timeless> | (roc?) |
| 17:12 | <timeless> | but that's for accounting (irs) reasons |
| 17:12 | timeless | currently has to avoid leaving ON, CA for extended periods of time |
| 17:16 | <jgraham> | annevk: I haven't really understood the point of the web-perf stuff yet. But it seemed like people really wanted to rush some stuff through |
| 17:17 | <annevk> | arun_, sicking, I think I will just go with DOMError; given that the other has exception in the name that seems the clearest, even though it is arguably somewhat redundant |
| 17:17 | <jgraham> | And some really useful stuff (requestAnimationFrame) got put in the same WG for no real reason |
| 17:17 | <annevk> | arun_, sicking, and then e.g. HTML could have MediaError : DOMError or some such |
| 17:18 | <annevk> | if Hixie wants to go through with all the extensions |
| 17:18 | <annevk> | jgraham, yeah Microsoft and Google |
| 17:18 | <annevk> | and of course they don't care about API simplicity or correctness |
| 17:18 | <annevk> | just needs to be "good enough" |
| 17:19 | <annevk> | never mind that everyone with smaller teams will have a hard time learning and what not |
| 17:19 | <arun_> | annevk, I'm in agreement. I'm sure there's some aesthetic reason why exceptions aren't reusable as interfaces, but I don't quite understand it. DOMError just buys into this model, and I'm ok with that. |
| 17:19 | <TabAtkins> | Dude, we're in the WG to try and mitigate the train wreck. |
| 17:20 | <timeless> | TabAtkins: well, it seems anne's not giving you high marks for your efforts :) |
| 17:20 | <arun_> | annevk, do we need to extend DOMError, or can we reuse it as you define it, but merely say what to use for .name? |
| 17:20 | <annevk> | arun_, you can use it as is |
| 17:20 | <annevk> | arun_, Hixie seemed to have some other needs for it that would require extending it |
| 17:21 | <timeless> | (to be fair, trainwrecks abound) |
| 17:21 | <arun_> | annevk, yeah. Hixie was actual lukewarm / neutral about even having a DOMError, but it seems useful to me. |
| 17:23 | <arun_> | As a general observation, staying on top of all relevant specs is hard, and the general tendency seems to be to link to Editor's drafts, not WDs. This suggests a diminishing usefulness of WDs, but folks still crack the process whip :) |
| 17:24 | timeless | read that as full of crack |
| 17:24 | <annevk> | I don't care much about WDs versus EDs |
| 17:24 | <AryehGregor> | It seems like there are slight differences between the output of http://aryeh.name/tests-root/tests/submission/AryehGregor/reflection/reflection-embedded.html and http://dvcs.w3.org/hg/html/raw-file/tip/tests/submission/AryehGregor/reflection/reflection-embedded.html. Anyone have suggestions on how to find them? |
| 17:24 | <annevk> | the problem arises when stuff gets implemented before it reaches the attention of anyone with some experience in web platform API design |
| 17:25 | <arun_> | annevk, well, I care about being up to date. And I'm not sure WD are up to date always (I blame myself, of course. It's just a general preference to keep specs dynamic). |
| 17:25 | <annevk> | strike some, some of these issues are subtle |
| 17:25 | <annevk> | arun_, I'm with you there :) |
| 17:26 | AryehGregor | tries Save as File and diff |
| 17:26 | <annevk> | I don't mind much how other people go about it I mean, as long as they ensure to get some review from WHATWG / WebApps |
| 17:26 | <arun_> | annevk, yeah, but in particular, within WHATWG/WebApps, to pester implementers for review. |
| 17:27 | <timeless_> | annevk: so... |
| 17:27 | <timeless_> | some WGs (i18n, TAG) manage to get themselves a wildcard demand for "please ask us for review before publishing" |
| 17:27 | <timeless_> | would it be impossible for webapps to manage the same? |
| 17:27 | <timeless_> | (for a slightly more limited domain) |
| 17:27 | timeless | hunts lunch |
| 17:28 | <annevk> | we get requests I guess, but usually when drafts are in Last Call |
| 17:28 | <arun_> | annevk, to wrap up DOMError discussion: I'll link to DOM4 ED, and optimistically hope that DOMError will magically appear before Art beats me up for LCWD :) |
| 17:28 | <annevk> | which is sort of counter to the point of Last Call |
| 17:28 | <timeless> | annevk: yeah |
| 17:28 | <timeless> | they're generally presented as fait a compli |
| 17:28 | <timeless> | which is unhelpful |
| 17:29 | <annevk> | because before you go to Last Call you have to make sure you have followed advice from other groups and generally expect them not to make comments |
| 17:29 | <annevk> | but whatever, it's a big mess |
| 17:29 | <annevk> | arun_, cool, I can do it now I guess |
| 17:34 | <Hixie> | annevk: i love how the person who asked the question in your g+ post is the chair of a group that just forked a part of the whatwg spec |
| 17:34 | <Hixie> | annevk: that just fills one with confidence |
| 17:35 | <annevk> | I love how he's your colleague :) |
| 17:36 | <annevk> | arun_, how about this language: |
| 17:37 | <annevk> | a "SyntaxError" <code>DOMError</code> object |
| 17:37 | <annevk> | means a DOMError object whose name is initialized to "SyntaxError" |
| 17:39 | <arun_> | annevk, works for me. Question: the assumption here is that name/code pairs can be reusable across both DOMException/DOMError. So the "new" errors I add for FileAPI are candidates for the 'non-normative" list, and usable in both DOMError and DOMException, right? |
| 17:40 | <arun_> | annevk, also: Israel, IndexedDB guy, suggests that code = 0 in newly introduced errors. Is that something I should follow, or should I pick the next available number? |
| 17:42 | <annevk> | if you say "throw a 'SyntaxError' exception" that will set code appropriately |
| 17:42 | <annevk> | it is indeed 0 for non-legacy values but there's nothing other drafts need to say about that |
| 17:43 | <arun_> | annevk, Aha! So, new (non-legacy) error types are always set to 0, but we don't need to ever mention code value, right? |
| 17:44 | <arun_> | annevk, so should I have a table for any new error names, which you can later appropriate into DOM4? |
| 17:44 | <arun_> | I'm tempted to just make a radical shift and have my spec. never mention constants and their affiliated numerical values, which I think is right. |
| 17:46 | <Hixie> | ok i'm nuking the Web Apps 1.0 spec and making the WHATWG TML spec contain everything that was in Web Apps 1.0 |
| 17:46 | <Hixie> | having to generate both specs every time is killing pms |
| 17:46 | <Hixie> | plus it' kinda confusing to have bothe anyway |
| 17:48 | <arun_> | Hixie, expect some lamenting ;-) |
| 17:48 | <Hixie> | most people won't notice, i expect |
| 17:49 | <annevk> | arun_, yes you don't need to mention constants |
| 17:49 | <annevk> | arun_, you don't even need a table |
| 17:49 | <annevk> | arun_, you just need "throw a ... exception" and "must return a ... DOMError" |
| 17:49 | <annevk> | arun_, and then for the ... that DOM4 is missing you can file a bug or email |
| 17:50 | <annevk> | massive simplification is what we are aiming for :) |
| 17:50 | <arun_> | annevk, ok. this is so radically simple, I can't help but feel happier and lighter about the whole damn morass of errors/exceptions :) |
| 17:50 | <Hixie> | annevk: for the DOMError thing are there integer constants at all? (e.g. the four from MediaError?) |
| 17:51 | <annevk> | Hixie, no; my thinking was that you could make MediaError inherit from it or something |
| 17:51 | <Hixie> | k |
| 17:51 | <annevk> | Hixie, or maybe it is not too late to change MediaError |
| 17:51 | <Hixie> | just making sure there was no conflict |
| 17:51 | <annevk> | there's only DOMError.name atm |
| 17:51 | <Hixie> | i swear, 80% of the traffic to the various browser security lists i'm on is people nominating other people to join the security lists |
| 17:51 | <arun_> | Hixie, I'm not sure why MediaError can't follow what we're going to do in File API. Namely use language of the sort "must return a NOT_FOUND DOMError". |
| 17:52 | <Hixie> | arun_: well there's only one MediaError object, to start with |
| 17:52 | <arun_> | Hixie, ahahah I know what you mean. |
| 17:52 | <Hixie> | arun_: and its value changes over time |
| 17:52 | <Hixie> | arun_: iirc |
| 17:52 | <Hixie> | i don't see much value in converging the error objects |
| 17:53 | <annevk> | arun_, that would become "NotFound" DOMError fyi |
| 17:53 | <annevk> | fwiw* |
| 17:53 | <annevk> | it's a string-based world |
| 17:53 | <arun_> | Hixie, ok. In the case of DOMException/DOMError, it eliminates the need for FileException/FileError, but I think MediaError may need to be more nuanced. |
| 17:53 | <arun_> | annevk, yes. |
| 17:53 | arun_ | slaps his own face for getting all constant-y. |
| 17:53 | <Hixie> | arun_: MediaError is unrelated to exceptions, unlike the situation in FileAPI |
| 17:54 | <Hixie> | (sorry, i misspoke. There's one MediaError per error that triggered, its value doesn't change.) |
| 17:54 | <Hixie> | (but you can fetch it multiple times.) |
| 17:55 | <annevk> | arun_, http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-domerror |
| 17:56 | <arun_> | annevk, I am happy enough with it :) |
| 18:04 | <annevk> | Hixie, I fully support the merge btw |
| 18:04 | <annevk> | Hixie, though it'll require some updating to the FAQ et al |
| 18:04 | <Hixie> | yeah |
| 18:05 | <Hixie> | btw that means i'm no longer using philip`'s splitter, only yours |
| 18:06 | <Philip`> | Oh, so I can retire mine? |
| 18:06 | <Hixie> | yeah |
| 18:06 | <Hixie> | thanks for your service :-) |
| 18:07 | Philip` | will probably drop it when moving his server to a new machine, then |
| 18:09 | <timeless> | Hixie: how often do you see people dropping off security lists? :) |
| 18:09 | <Hixie> | i don't follow the lists closely enough to tell you |
| 18:09 | <Hixie> | i only follow the lists so that i can update the specs when the bugs found are intrinsic to hte platform |
| 18:10 | <annevk> | oh sweet, only the unmaintained splitter teehee |
| 18:10 | <annevk> | I wonder if it's in version control somewhere so I can still blame Philip` |
| 18:15 | <Philip`> | (The version in Google Code html5 is the exact one I was running, I think) |
| 18:17 | <annevk> | I was sort of planning on following this Apple event and then they post all the details ahead of time on the Japanese site |
| 18:17 | <annevk> | boring |
| 18:20 | <timeless> | heh |
| 18:21 | <timeless> | does someone post a translation of that? |
| 18:29 | <annevk> | yeah macrumors & co |
| 18:39 | <timeless> | oh right |
| 19:06 | <roc> | timeless: ? |
| 19:17 | <zcorpan> | Hixie: wait, you banned <h1> in <td>? |
| 19:18 | <Hixie> | not intentionally |
| 19:18 | <Hixie> | did i? |
| 19:18 | <Hixie> | no |
| 19:36 | <aho> | is there something like an aspect ratio css property planned? i.e. something that would allow you to crate a div which resizes like an image (you set the width and the height gets calculated) |
| 19:37 | <TabAtkins> | I've got a post on my blog with a proposal. I'll work on it when fantasai and I (or maybe Anton) starts work on the Box Module. |
| 19:37 | <aho> | woo! :) |
| 19:39 | <aho> | something like that might be interesting for that "responsive image" stuff. the easiest way to get something like that is via inline svg, but that's all kinds of awkward :> |
| 19:47 | <annevk> | Hixie, the multipage copy still says Web Applications 1.0 |
| 19:49 | <annevk> | Hixie, also whatwg.org/C used to be multipage; whatwg.org/c is single-page |
| 19:55 | <timeless> | hsivonen: grrr, why aren't you on #foxymonkies? :) |
| 20:02 | <Hixie> | annevk: the multipage copy saying Web Applications 1.0 is an issue on your side, i think |
| 20:03 | <Hixie> | annevk: the shortcuts should still work, did i break them? |
| 20:03 | <annevk> | it seems you reversed c and C? |
| 20:03 | <annevk> | uppercase was for multipage |
| 20:03 | <annevk> | lowercase for singlepage |
| 20:04 | <annevk> | i'll take a look at the script on html5.org |
| 20:04 | <Hixie> | where are they reversed? |
| 20:04 | <Hixie> | or do you mean they resolve reversed? |
| 20:05 | <Hixie> | oh i see, the link on the header is wrong |
| 20:05 | <Hixie> | got it |
| 20:05 | <annevk> | html5.org uses complete.html |
| 20:05 | <annevk> | is that wrong? |
| 20:05 | <Hixie> | oh oops hold on |
| 20:07 | <Hixie> | ok that should fix itself next time i regen |
| 20:07 | <Hixie> | thanks |
| 20:07 | <Hixie> | (i forgot to update complete.html) |
| 20:07 | <Hixie> | (i need to update it for svn too) |
| 20:07 | <annevk> | okay |
| 20:07 | <Hixie> | although, wait |
| 20:07 | <Hixie> | complete.html has been 301ing to index today |
| 20:08 | <Hixie> | shouldn't that fix it on your end? |
| 20:08 | <annevk> | so web-apps-tracker already uses index |
| 20:08 | <annevk> | Hixie, oh, I use svn |
| 20:08 | <Hixie> | ah ok |
| 20:09 | <Hixie> | well it'll get fixed when i next check in |
| 20:09 | <annevk> | svn update, then generate, etc. |
| 20:09 | <annevk> | k |
| 20:09 | <Hixie> | which is now |
| 20:09 | <Hixie> | so we'll see what happens |
| 20:09 | <Hixie> | interesting though. that means i have to do the svn checkin to get the multipage updated :-) |
| 20:09 | <Hixie> | didn't know that |
| 20:09 | <Hixie> | good to know |
| 20:10 | <annevk> | it'll generate a copy regardless, but it will generate it from complete.html as things stand |
| 20:10 | <annevk> | so yeah, if you want something new :) |
| 20:10 | <Hixie> | right |
| 20:10 | <Hixie> | that's fine |
| 20:13 | <annevk> | hsivonen, apple.com is giving access denied for me too |
| 20:13 | <annevk> | hsivonen, earlier it had some stuff on the iPhone 4S |
| 20:13 | <annevk> | I wonder if I should get one to do away with my camera |
| 20:13 | <annevk> | pretty expensive camera upgrade though |
| 20:13 | <annevk> | for a P&S |
| 20:15 | <annevk> | Hixie, but you can just drop the crossorigin attribute and get the image |
| 20:15 | <annevk> | oh well |
| 20:15 | <Hixie> | the server can return nothing at all for that case |
| 20:21 | <annevk> | Hixie, re multipage; success! |
| 20:21 | <Hixie> | yay |
| 20:33 | <FlorianX> | HTML and WebApplications 1.0 are now the same specifications, ist that right? |
| 20:37 | <annevk> | yes |
| 20:38 | <FlorianX> | annevk: may I ask why? (I am writing my master thesis about HTML5) |
| 20:38 | <annevk> | simplicity mainly |
| 20:38 | <FlorianX> | Is there an official announcement yet (because of one referral source)? |
| 20:38 | <annevk> | from a WHATWG perspective the split made little sense |
| 20:39 | <annevk> | there's http://twitter.com/WHATWG/status/121268735381221376 |
| 20:39 | <annevk> | maybe I'll mention it in the WHATWG Weekly, not sure whether it's worth it |
| 20:39 | <FlorianX> | so the webapps 1.0 is now HTML or reverse? |
| 20:40 | <annevk> | what was called Web Applications 1.0 is now called HTML |
| 20:40 | <Hixie> | they're the same |
| 20:40 | <annevk> | HTML used to be a subset of that; the subset no longer exists |
| 20:40 | <FlorianX> | ok thats what i mean |
| 20:40 | <FlorianX> | thanks for help |
| 20:41 | <FlorianX> | But then what I write now in my thesis :-) |
| 20:41 | <Hixie> | what was called Web Apps 1.0 originally, many years ago, was at one point renamed HTML, then things were dropped from it to track the w3c, eventually they dropped so much that we added a separate spec at the whatwg to include everything again, and called it Web Apps 1.0 for nostalgic reasons |
| 20:42 | <Hixie> | and today i got tired of having two specs at whatwg (it makes various things annoying and some of our tools are overloaded by it) and so i just went back to the state after the first time we renamed the spec |
| 20:42 | <Hixie> | i think |
| 20:42 | <Hixie> | you'd have to check the svn archive to see how accurate that is |
| 20:43 | <annevk> | sounds about right |
| 20:45 | <FlorianX> | my thesis is half finished, in that I always refer to the two specifications. Now I have quite the problem that I need to rewrite everything. But so does the living. |
| 20:47 | <FlorianX> | thanks again for the explanations @ Hixie + annevk |
| 20:47 | <Hixie> | heh |
| 20:47 | <Hixie> | sorry man :-) |
| 20:48 | <FlorianX> | I just bribe my professor :-D |
| 21:13 | <rniwa> | AryehGregor: yt? |
| 21:13 | <AryehGregor> | rniwa, I'm just leaving, actually. |
| 21:13 | <rniwa> | AryehGregor: ah ok |
| 21:13 | <rniwa> | AryehGregor: did you my msg a couple of days about selectstart? |
| 21:13 | <AryehGregor> | rniwa, yeah. I have a bug open: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13952 |
| 21:13 | <rniwa> | AryehGregor: great |
| 21:14 | <rniwa> | AryehGregor: also, you may want to investigate interaction between selection & focus |
| 21:14 | <AryehGregor> | rniwa, could you file a bug with details? |
| 21:14 | <rniwa> | AryehGregor: right now WebKit's focus follows selection |
| 21:14 | <rniwa> | AryehGregor: whereas IE & FF's selection follows focus |
| 21:15 | <rniwa> | AryehGregor: will do |
| 21:15 | <smaug____> | selection follows focus? |
| 21:16 | <rniwa> | smaug____: when selection is set on some node |
| 21:16 | <rniwa> | smaug____: webkit automatically focuses its editing host |
| 21:16 | <rniwa> | smaug____: whereas in IE & FF, selection is automatically moved to wherever focus is |
| 21:16 | <smaug____> | webkit automatically focuses? |
| 21:16 | <smaug____> | that is surprising |
| 21:17 | <rniwa> | smaug____: someone told me this behavior might be some Mac-ism |
| 21:17 | <smaug____> | but I'm not sure I understand "selection is automatically moved to wherever focus" |
| 21:17 | <rniwa> | smaug____: yes, it has caused some compat issues for us but we haven't been able to change it |
| 21:17 | <smaug____> | ah, I'm very much not aware of Mac-isms |
| 21:17 | <rniwa> | smaug____: when a focus is set on some contenteditable region |
| 21:17 | <rniwa> | smaug____: and user starts pressing keys |
| 21:18 | <rniwa> | smaug____: IE & FF automatically moves the selection there |
| 21:18 | <rniwa> | smaug____: e.g. <div id="has_focus"><br></div><div id="has_selection"><br></div> |
| 21:18 | <smaug____> | rniwa: but webkit doesn't? |
| 21:18 | <rniwa> | smaug____: webkit inserts a letter in #has_selection whereas IE&FF inserts it in #has_focus |
| 21:22 | <rniwa> | AryehGregor: filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=14383 |
| 22:31 | <hober> | AryehGregor: the formatting of http://dvcs.w3.org/hg/editing/raw-file/tip/source.html is all messed up |
| 22:41 | <annevk> | hmm |
| 22:41 | <annevk> | guess I have to look into XHR garbage collection yet again |
| 22:41 | <annevk> | joy joy joy |