fluid-work IRC Logs-2011-01-28

Owned by Fluid IRC Log Bot
Last updated: Jan 28, 2011Version comment
15 min read

[08:24:00 CST(-0600)] <colinclark> Morning, anastasiac
[08:24:09 CST(-0600)] <colinclark> I'll join you on the MDN sprint shortly
[08:24:14 CST(-0600)] <colinclark> It's irc.mozilla.org, right?
[08:24:25 CST(-0600)] <anastasiac> colinclark, sure - yes. everyone is introducing themselves now
[08:24:34 CST(-0600)] <anastasiac> #devmo
[08:25:42 CST(-0600)] <colinclark> How do the introductions work?
[08:25:47 CST(-0600)] <colinclark> Just going down the list alphabetically?
[09:12:33 CST(-0600)] <anastasiac> interesting: another redirect to codetalks, colinclark: https://developer.mozilla.org/en/Accessible_DHTML
[09:13:10 CST(-0600)] <colinclark> So, anastasiac, the reference to :before is indeed gone
[09:13:30 CST(-0600)] <colinclark> I wonder if we should some better practices in the same code
[09:13:36 CST(-0600)] <colinclark> worth experimenting with to see how complex it gets
[09:13:46 CST(-0600)] <colinclark> but I don't imagine anyone should be using onclick attributes in markup
[09:14:06 CST(-0600)] <colinclark> Arguably, putting ARIA on markup directly is probably a poor idea as well
[09:14:12 CST(-0600)] <colinclark> That one could be covered by a note about it
[09:15:09 CST(-0600)] <anastasiac> colinclark, you could add that point to your aria overview, as well
[09:15:59 CST(-0600)] <anastasiac> I'm thinking I'll focus on the actual text of the tutorial first today, and at least get that into MDN, then maybe go back and improve the code (so long as there's nothing that's really horrible)
[09:16:06 CST(-0600)] <anastasiac> does that make sense, colinclark?
[09:16:46 CST(-0600)] <colinclark> That seems reasonable
[09:17:14 CST(-0600)] <anastasiac> I'll make sure what's there is actually correct and up-to-date, of course
[09:17:21 CST(-0600)] <colinclark> Sure
[09:17:48 CST(-0600)] <colinclark> I do think that obtrusive JavaScript probably does border on the "really horrible," but I agree with the one thing at a time approach
[09:25:22 CST(-0600)] <heidi_> colinclark did the progress bar patch/scroll bar issue happen after the uploader patch was applied? or before
[09:27:03 CST(-0600)] <colinclark> after
[09:27:11 CST(-0600)] <anastasiac> colinclark, the sample code I mentioned is actually on moz.com, and not dev.moz.com, and I don't think I have edit permission. I'm thinking the thing to do is "move" it to dev.moz.com rather than try to get write permission - would you agree?
[09:27:26 CST(-0600)] <colinclark> Sure
[09:27:30 CST(-0600)] <colinclark> Let's ask jms about it
[09:28:59 CST(-0600)] <heidi_> colinclark looks like the width of the filequeue is too big with recent commit
[09:31:30 CST(-0600)] <colinclark> Ah, so your two patches weren't harmonized
[09:31:53 CST(-0600)] <colinclark> Do you think, then, that the Progress patch is probably good but the Uploader needs to be tweaked?
[09:32:11 CST(-0600)] <heidi_> yeah i think uploader.css still needs work, but we knew that. ill fix 'er up
[09:32:40 CST(-0600)] <heidi_> i'm guessing the css changed a bit after the progress patch
[09:33:05 CST(-0600)] <heidi_> but once the file-queue is the right width, progress shouldn't cos scrollbars
[09:33:13 CST(-0600)] <heidi_> *cause
[09:33:31 CST(-0600)] <colinclark> cool
[09:33:33 CST(-0600)] <colinclark> thanks, heidi_
[09:34:33 CST(-0600)] <heidi_> uploader has lots of inline css that would be nice to possibly ditch
[09:35:08 CST(-0600)] <colinclark> yes!
[09:35:22 CST(-0600)] <colinclark> Can you think of any specific examples?
[09:40:30 CST(-0600)] <heidi_> mm, every table row has display:block on it
[09:41:11 CST(-0600)] <colinclark> Yeah, it's likely due to using jQuery's hide() and show() methods
[09:41:17 CST(-0600)] <colinclark> they're not entirely awesome
[09:41:29 CST(-0600)] <heidi_> yeah ... and styles on progress bars for each tr
[09:41:44 CST(-0600)] <colinclark> The progress bar styles are interesting
[09:41:52 CST(-0600)] <heidi_> yeah i agree
[09:41:54 CST(-0600)] <colinclark> you should look into it and see how many of them are dynamically generated
[09:42:14 CST(-0600)] <colinclark> There's definitely room to replace some of this with some nice CSS3
[09:42:26 CST(-0600)] <heidi_> cool
[09:42:27 CST(-0600)] <colinclark> with some kind of fallback to jQuery in IE
[09:43:01 CST(-0600)] <heidi_> yeah and some display:none stuff, prob from hiding/showing
[09:43:17 CST(-0600)] <heidi_> not sure if any of these are avoidable, but worth checkin out
[09:43:39 CST(-0600)] <colinclark> I think they are avoidable in some cases
[09:43:44 CST(-0600)] <colinclark> Again, animation complicates things
[09:43:59 CST(-0600)] <colinclark> But in cases where it's just decorative animation, we have some options
[09:44:22 CST(-0600)] <colinclark> So hiding/showing table rows is easy enough to do just by toggling a class on and off
[09:44:38 CST(-0600)] <colinclark> but if you want the thing to gently fade in and out, that's where the complication comes in
[09:45:01 CST(-0600)] <colinclark> We could do this sort of animation in CSS3 and just assume that IE6 users will get a "degraded" experience, meaning they don't get fancy decorative animations
[09:45:13 CST(-0600)] <heidi_> right ya
[09:45:21 CST(-0600)] <colinclark> Progress bars are a little harder, since it would be quite a bug if an IE6 user couldn't see the thing progressing because we were using CSS3
[09:46:41 CST(-0600)] <heidi_> ya
[10:04:47 CST(-0600)] <anastasiac> colinclark, I'm checking the aria in another example: http://www.mozilla.org/access/dhtml/tree Based on my understanding of the "presentation" role, it seems to me that all the <div>s with the presentation role are really not necessary - would you concur, or is my understanding wrong?
[10:06:36 CST(-0600)] <colinclark> I don't fully know
[10:06:46 CST(-0600)] <colinclark> I'd suggest having a look at Gunderson's Tree example for comparison
[10:06:59 CST(-0600)] <colinclark> The presentation roles do look conspicuous to me
[10:07:04 CST(-0600)] <colinclark> clown might have some thoughts, too
[10:09:43 CST(-0600)] <clown> anastasiac, why don't you think all the presentation roles are unnecessary? note: i haven't looked at the example, yet.
[10:09:57 CST(-0600)] <clown> gah. rather why do you think...
[10:10:26 CST(-0600)] <anastasiac> clown, what I'm looking at is lots of: <div role="presentation"><span tabindex="-1" role="treeitem" class="treeitem">Bell peppers</span></div>
[10:10:35 CST(-0600)] <anastasiac> in a tree example
[10:11:16 CST(-0600)] <anastasiac> my understanding of 'presentation' is to ensure that the usual role of a thing is basically ignored (e.g. on an <img> that's just used for a checkbox)
[10:11:45 CST(-0600)] <anastasiac> here, that doesn't seem to be the case - there's no risk of an AT describing these divs incorrectly without the role
[10:11:50 CST(-0600)] <anastasiac> does that make sense?
[10:12:12 CST(-0600)] <clown> anastasiac: to be precise, anything with a @role=presentation is not published to the a11y api.
[10:12:37 CST(-0600)] <clown> so, based on the code fragment above, the <div> is not published, but the span is.
[10:12:44 CST(-0600)] <anastasiac> would a <div> be otherwise "published" (and exactly what does that mean, anyway? (smile)
[10:13:21 CST(-0600)] <anastasiac> what does it mean to the user for a div to be "published"?
[10:13:36 CST(-0600)] <anastasiac> could I not just use <div tabindex="-1" role="treeitem" class="treeitem">Mangos</div> ?
[10:13:54 CST(-0600)] <clown> you can think of it this way: there is an a11y tree in parallel with the dom tree, but only accessible objects appear in the a11y tree. And, yes, a <div> would be published – I think it maps to a "region" in FF.
[10:14:37 CST(-0600)] <clown> re: could I not just use <div tabindex="-1" role="treeitem" class="treeitem">Mangos</div> ? Maybe. Usually <div>'s are added for layout.
[10:14:46 CST(-0600)] <anastasiac> which is the case here
[10:15:15 CST(-0600)] <clown> even though the <div> is irrelevant for a11y, it may well be necessary for visual rendering.
[10:15:46 CST(-0600)] <anastasiac> so the latter version, divs alone instead of divs around spans: would that confuse a user, if the divs have a role of listitem?
[10:16:52 CST(-0600)] <clown> according to what you wrote, they have a role of treeitem, not listitem, but I think I understand what your asking...
[10:17:03 CST(-0600)] <anastasiac> yes, sorry
[10:17:31 CST(-0600)] <clown> that wouldn't confuse a user – the <div> would show up in the a11y tree as a treeitem (not a div, nor a region).
[10:17:59 CST(-0600)] <clown> but... note that <div> is a block-level element, while <span> is inline.
[10:18:59 CST(-0600)] <anastasiac> and the implication of that, clown?
[10:19:17 CST(-0600)] <clown> I don't really know why all those <div>'s are there – I'd have to look at the html (and the css, and the javascript) to see if they have any non-a11y purpose.
[10:19:45 CST(-0600)] <anastasiac> seems to me they were there for their effect on the layout
[10:19:54 CST(-0600)] <anastasiac> i.e. to place each tree item on its own line
[10:20:14 CST(-0600)] <clown> I suspect they are there for layout. Are there cases where the <div> surrounds more than one <span>? To put it another way: are the divs containers for one or more tree items?
[10:21:10 CST(-0600)] <anastasiac> when there are multiple treeItems in a group, there is a div with role="group", but then inside that, the individual treeItem spans are enclosed in divs
[10:21:13 CST(-0600)] <colinclark> mlam: You saw that I reopened FLUID-4017 with a suggestion
[10:21:28 CST(-0600)] <anastasiac> it just seems excessive to me
[10:21:34 CST(-0600)] <colinclark> It also occurs to me that part of the reason this error occurred was due to poor naming on my choice for the remote strategy's start() method
[10:21:46 CST(-0600)] <clown> it might be excessive, anastasiac. Ask the author?
[10:21:53 CST(-0600)] <mlam> Strange, I didn't get an email about FLUID-4017...taking a look now
[10:22:02 CST(-0600)] <colinclark> I wonder if you'd consider making a separate patch that renames it uploadNext() or something like that
[10:22:11 CST(-0600)] <anastasiac> not sure who the author is, clown (smile) but it's a couple of years ole
[10:22:14 CST(-0600)] <anastasiac> old
[10:22:27 CST(-0600)] <colinclark> mlam: Shoot, I forgot to reassign it to you, which is why you didn't get the email perhaps
[10:23:46 CST(-0600)] <mlam> Ok, I'll create another patch.
[10:24:10 CST(-0600)] <colinclark> mlam: Yeah, maybe make two patches
[10:24:26 CST(-0600)] <colinclark> one that uses currentBatch.fileIdx instead of storing that model information yourself on some random that
[10:24:36 CST(-0600)] <colinclark> and another that renames start() to something you think is more meaningful
[10:24:45 CST(-0600)] <mlam> ok
[10:24:49 CST(-0600)] <colinclark> The other thing I wonder about, which isn't an easy question, is if we can write unit tests for your fix
[10:25:12 CST(-0600)] <colinclark> Ordinarily we could use the jquery mockjax utility, but we're doing some rather unusual things with XHR
[10:25:21 CST(-0600)] <colinclark> I can imagine you probably could find a way to test it
[10:26:43 CST(-0600)] <mlam> hmm yah, i'm not sure.
[10:29:00 CST(-0600)] <colinclark> jhung: A suggestion for your Builder design walkthrough
[10:29:25 CST(-0600)] <colinclark> Show us what it looks like for someone to deselect a dependency, and then to select something new, which also depends on that item
[10:29:32 CST(-0600)] <colinclark> Does that make sense?
[10:29:50 CST(-0600)] <jhung> sure
[10:30:29 CST(-0600)] <colinclark> jhung: I also think you might want to call third part modules just "Third Party Modules."
[10:30:50 CST(-0600)] <colinclark> "Additional Third Party Modules" made me think that there were some other type of Third Party Modules somewhere else
[10:31:10 CST(-0600)] <jhung> good point.
[10:31:45 CST(-0600)] <colinclark> You might want to sit down and chat with jessm about some of the wording in general--she's a good editor
[10:32:00 CST(-0600)] <colinclark> I thought "Selection is missing dependencies important to functionality" was a bit fuzzy
[10:32:09 CST(-0600)] <colinclark> but now I'm getting into the little details
[10:32:13 CST(-0600)] <colinclark> (which is a really good sign)
[10:46:26 CST(-0600)] <jhung> colinclark: yes the wording definitely needs tweaking - our choice of wording here really needs to be intentional. The component descriptions need editing as well.
[10:50:05 CST(-0600)] <colinclark> anastasiac: Ultimately I'd love to take the whole slide deck that Justin, Jess, and I put together for the Balboa Park accessibility workshop and turn it into an accessibility tutorial
[10:50:09 CST(-0600)] <colinclark> it'd be perfect for MDN
[10:50:27 CST(-0600)] <anastasiac> colinclark, yes - that's be an excellent idea!
[10:51:01 CST(-0600)] <colinclark> It shows screenshots and markup and step-by-step instructions for doing things like labelling forms, using alt text, etc
[10:51:14 CST(-0600)] <colinclark> All the examples are of Fluid's own sites, which is sort of dorky
[10:51:14 CST(-0600)] <colinclark> s
[10:51:20 CST(-0600)] <colinclark> so we'd have to redo that
[10:51:24 CST(-0600)] <jessm> +1
[11:03:14 CST(-0600)] <clown> anastasiac: another thought about the excessive div's, although, I don't really feel comfortable second guessing the author ...
[11:03:33 CST(-0600)] <clown> ...with the div/span combination, there are two degrees of freedom with respect to styling in that one can style the div and span independently of one another ...
[11:03:59 CST(-0600)] <clown> ...for example, there could be a border for the div and another border for the the span, with different colours, widths, etc. ...
[11:04:37 CST(-0600)] <clown> ...if you reduce it to just a div, then there is only one element or one degree of freedom – all the layout is on that one element. Just a thought.
[11:05:28 CST(-0600)] <anastasiac> clown, good point. In this example, they don't seem to be using that, it's very simply styled. For the purpose of this example, I think I'll simplify as much as possible
[11:06:16 CST(-0600)] <clown> ok.
[11:07:27 CST(-0600)] <Justin_o> colinclark: any other type of file we want to drop from the repos other than psd
[11:07:39 CST(-0600)] <Justin_o> i think there is a keynote one for one of the workshops
[11:13:22 CST(-0600)] <colinclark> Justin_o: Toast that
[11:13:28 CST(-0600)] <colinclark> I'm not sure what else made it in there
[11:13:29 CST(-0600)] <Justin_o> colinclark: thanks
[11:13:34 CST(-0600)] <colinclark> any large jars or anything?
[11:13:48 CST(-0600)] <Justin_o> hmm... not sure
[11:14:03 CST(-0600)] <Justin_o> jamon: do you know if there are any other large binaries there
[11:15:13 CST(-0600)] <jamon> all i can really get is a list Justin_o, colinclark
[11:15:53 CST(-0600)] <jamon> e.g. /utoronto/fluid/components/test/jsunit/java/lib/jasper-compiler.jar
[11:16:42 CST(-0600)] <mlam> colinclark: I had to set the default value of the fileIdx value from -1 to 0 due to the timing of the startFile() call in the fileQueue. Any reason why it was defaulted to -1 in the first place?
[11:18:05 CST(-0600)] <Justin_o> jamon: do you have revision numbers for those
[11:18:25 CST(-0600)] <Justin_o> then we can look at svn on the web and at least try to download them to see the size
[11:19:03 CST(-0600)] <jamon> Justin_o: in the middle of batch cloning repositories, will take a few minutes
[11:19:14 CST(-0600)] <Justin_o> jamon: sure
[11:19:28 CST(-0600)] <colinclark> I'm very wary of "historical revisionism," so we should really only toast a file like this if it's huge and never should have been in SVN in the first place
[11:19:34 CST(-0600)] <jamon> cutting out the psd's brings infusion down to 22mb Justin_o, colinclark
[11:19:47 CST(-0600)] <colinclark> how exceptional, jamon!
[11:19:49 CST(-0600)] <colinclark> mlam: I don't know off the top of my head
[11:19:53 CST(-0600)] <Justin_o> jamon: that's really good
[11:19:53 CST(-0600)] <colinclark> I guess you can always try it and see
[11:20:06 CST(-0600)] <colinclark> this is where writing a few unit tests might come in handy, mlam (smile)
[11:20:07 CST(-0600)] <jamon> i'm going to say let's not worry about jars? they won't be that large i don't think
[11:20:13 CST(-0600)] <colinclark> Hopefully the DemoUploadManager tests will help
[11:20:27 CST(-0600)] <colinclark> jamon: +1 for that
[11:20:31 CST(-0600)] <jamon> and for historical integrity, they are likely functionally necessary
[11:20:40 CST(-0600)] <colinclark> At 22 mb, we're fine
[11:21:13 CST(-0600)] <colinclark> To be clear, for historical integrity, we're also going to have to maintain our SVN repository in perpetuity as well
[11:21:20 CST(-0600)] <jamon> yep
[11:21:20 CST(-0600)] <colinclark> just to catch the edges
[11:21:25 CST(-0600)] <colinclark> No big deal, though
[11:22:17 CST(-0600)] <jamon> perhaps a lat commit indicating the location of a) git repos, and b) location of documentation on the wiki/fluidproject sites?
[11:22:25 CST(-0600)] <jamon> s/lat/last
[11:25:19 CST(-0600)] <jhung> athena: ping.
[11:25:43 CST(-0600)] <athena> heya
[11:25:59 CST(-0600)] <jhung> do you have time to chat in 30 mins?
[11:26:18 CST(-0600)] <colinclark> jamon: yes, for sure
[11:26:36 CST(-0600)] <athena> yes, i think i can do that
[11:26:38 CST(-0600)] <athena> (smile)
[11:26:39 CST(-0600)] <colinclark> SVN will still remain active for design work, too, which is cool
[11:27:30 CST(-0600)] <jhung> athena: cool. I'll ping you again in a few.
[11:27:34 CST(-0600)] <athena> sounds good!
[11:36:24 CST(-0600)] <Bosmon2> mlam - I'm totally dropping in on the discussion... but I am opposed to "-1ism" in general (tongue)
[11:38:05 CST(-0600)] <mlam> Bosmon2: Any particular reason?
[11:41:38 CST(-0600)] <mlam> Oh, and Bosmon2: I didn't have to incorporate CPS into the uploader after all. The events were already "chained" to behave in a synchronous fashion. We introduced asynchronous uploading into the HTML5 version, so all I had to do was remove it.
[11:47:07 CST(-0600)] <anastasiac> colinclark, I'm looking at http://wiki.codetalks.org/wiki/index.php/Docs/Keyboard_navigable_JS_widgets#Use_setTimeout_with_element.focus.28.29_to_set_focus and I'm not clear about the need for setTImeout. The text glosses over the reasoning, and I'm not convinced... does it make sense to you, and if so, why?
[11:50:30 CST(-0600)] <colinclark> anastasiac: It shouldn't be necessary, no
[11:50:59 CST(-0600)] <anastasiac> colinclark, thanks for the sanity check
[11:51:02 CST(-0600)] <colinclark> It seems to stem from the sort of superstition we all experience when dealing with the little details of focus management
[11:53:00 CST(-0600)] <colinclark> Our plugin certainly is successful at calling focus(), in the rare occasions that it is necessary, without wrapping it in a setTimeout
[11:57:32 CST(-0600)] <jhung> anastasiac: you have time later this aft to talk about demos and documentation?
[11:58:46 CST(-0600)] <anastasiac> jhung, possibly, but I wouldn't hold out hope. I'm participating in this MDN docs sprint today, and I'd like to get this tutorial into shape and up on mdn before the end of the day. can I check in with you in a bit as to how it's going?
[11:59:45 CST(-0600)] <jhung> anastasiac: sure. just ping me.
[11:59:51 CST(-0600)] <anastasiac> thx
[12:02:08 CST(-0600)] <jhung> athena: ping.
[12:03:15 CST(-0600)] * athena waves
[12:03:26 CST(-0600)] <Bosmon2> mlam: "-1ism" seems to philosophically symbolise that you are not really in control of your control flow
[12:03:36 CST(-0600)] <Bosmon2> Since there is no reason that "-1" should ever be a valid counter value for anything
[12:03:50 CST(-0600)] <Bosmon2> Part of this general model that it "should never be possible to observe a system in an inconsistent state"
[12:03:56 CST(-0600)] <Bosmon2> And - good news about the Uploader
[12:17:14 CST(-0600)] <colinclark> mlam: I guess it's not really the case that you made anything synchronous in the Uploader...
[12:17:23 CST(-0600)] <colinclark> in fact, it was always built to work asychronously
[12:17:44 CST(-0600)] <colinclark> in that a call to start() would always return immediately, not block until the file was completely uploaded
[12:18:12 CST(-0600)] <colinclark> It's actually that we removed some "synchronous assumptions" from the Uploader, to make it work happily in an asynchronous model
[12:18:21 CST(-0600)] <colinclark> where files are still uploaded one at a time, not simultaneously
[12:18:28 CST(-0600)] <colinclark> details, details (tongue)
[12:19:00 CST(-0600)] <mlam> sorry sorry! (tongue)
[12:19:26 CST(-0600)] <colinclark> (smile)
[12:23:25 CST(-0600)] <mlam> colinclark: I've posted the 2 patches for FLUID-4017, I'll come back to thinking about how we can test the XHR work when I finish up the tests for testing the addFiles() function
[12:23:52 CST(-0600)] <colinclark> sounds good to me, mlam
[12:25:38 CST(-0600)] <mlam> colinclark: did you manage to take a look at the FLUID-3886 patch? It's for HTML5 file exclusions
[12:25:50 CST(-0600)] <colinclark> ah, no
[12:25:55 CST(-0600)] <colinclark> I will
[12:26:49 CST(-0600)] <mlam> ok, cool
[12:46:31 CST(-0600)] <colinclark> clown: Is this still the definitive source for the DHTML style guide? http://dev.aol.com/dhtml_style_guide
[12:47:04 CST(-0600)] * clown checking, colinclark
[12:49:15 CST(-0600)] <clown> colinclark, yes. Note that the guide is (more or less) part of the aria authoring practices guide: http://www.w3.org/WAI/PF/aria-practices/Overview.html#aria_ex
[12:49:26 CST(-0600)] <colinclark> Ah, this is great
[12:49:28 CST(-0600)] <colinclark> thanks
[12:49:31 CST(-0600)] <colinclark> I'll include links to both
[12:49:32 CST(-0600)] <clown> wlcm
[12:49:53 CST(-0600)] <athena> for the record, the infusion builder plans look terrific
[12:50:32 CST(-0600)] <athena> also, Justin_o, thanks for the tip on the "markup" component thing yesterday - that worked perfectly
[12:51:23 CST(-0600)] <Justin_o> athena: np glad to have been able to help (smile)
[13:07:11 CST(-0600)] <jamon> colinclark: Justin_o and i am wondering about r4415, it is the move from /utoronto/fluid to /fluid
[13:07:30 CST(-0600)] <jamon> it is difficult to capture the move since git does not track directories, only files
[13:07:50 CST(-0600)] <jamon> we're wondering if it is ok to miss out on that one commit in the git history of infusion
[13:11:15 CST(-0600)] <colinclark> Why is that particular move different from any other directory restructuring, jamon and Justin_o?
[13:14:41 CST(-0600)] <jamon> colinclark: not sure, it has to do with not tracking directories, we're checking another import to see how widespread an issue it is
[13:14:58 CST(-0600)] <colinclark> Sounds like it's worth looking into more closely
[13:15:49 CST(-0600)] <anastasiac> colinclark, do you agree with using try/catch in cases where a property may not be supported? http://wiki.codetalks.org/wiki/index.php/Docs/Keyboard_navigable_JS_widgets#Use_try.2Fcatch_to_avoid_JavaScript_errors
[13:16:20 CST(-0600)] <colinclark> I'd prefer not to lose that history, at least as far back as clown's historic r4124 commit, jamon
[13:17:05 CST(-0600)] <colinclark> anastasiac: I think that paragraph is dated and confused
[13:17:08 CST(-0600)] <colinclark> Toss it
[13:17:16 CST(-0600)] <anastasiac> good (smile)
[13:17:22 CST(-0600)] <colinclark> But it definitely is worth covering some of the quirks of Tabindex across browser
[13:17:30 CST(-0600)] <colinclark> and citing Simon's canonical Fluid blog post about the subject
[13:17:30 CST(-0600)] <jamon> colinclark: we're checking, the full import goes back to 4124, just 4415 seems problematic
[13:18:11 CST(-0600)] <colinclark> anastasiac: I'm making pretty good progress with my overview...
[13:18:18 CST(-0600)] <colinclark> I might need your help with a bit of wikifying
[13:18:25 CST(-0600)] <colinclark> I think I have to pack up and leave by 3 pm today
[13:18:25 CST(-0600)] <anastasiac> np
[13:18:28 CST(-0600)] <colinclark> thanks
[13:18:40 CST(-0600)] <colinclark> I'd love your editorial advice, too
[13:29:52 CST(-0600)] <anastasiac> colinclark, I'm trying to verify the accuracy of this one, but I'm not finding any supporting mention: http://wiki.codetalks.org/wiki/index.php/Docs/Keyboard_navigable_JS_widgets#Don.27t_rely_on_consistent_behavior_for_key_repeat.2C_at_this_point any thoughts?
[13:30:01 CST(-0600)] <colinclark> lemme look
[13:30:21 CST(-0600)] <colinclark> anastasiac: I think it's actually true
[13:30:32 CST(-0600)] <colinclark> but I wonder how helpful this information is without specifics.
[13:31:09 CST(-0600)] <anastasiac> true - there's no suggestion of actual techniques
[13:48:06 CST(-0600)] <jamon> colinclark: we're still stuck deciding what to do/trying the conversion
[13:53:12 CST(-0600)] <colinclark> jamon: okay...
[13:53:35 CST(-0600)] <colinclark> hey anastasiac and jessm, I sent along a draft of the new Overview of Accessible Web Applications and Widgets document I am drafting for MDN
[13:53:42 CST(-0600)] <colinclark> if you have a few spare cycles to edit, I'd appreciate it
[13:53:55 CST(-0600)] <colinclark> I'll put it up in the wiki shortly, but I'm going to need to run soon (sad)
[13:53:57 CST(-0600)] <colinclark> this is fun
[14:00:02 CST(-0600)] <anastasiac> colinclark, sure - so edit and return to you, and let you post?
[14:00:20 CST(-0600)] <colinclark> I'll post now, then maybe you can edit directly in the MDN wiki?
[14:00:28 CST(-0600)] <anastasiac> k
[14:08:30 CST(-0600)] <jessm> colinclark: it's awesome
[14:08:50 CST(-0600)] <jessm> some of the clearest, most concise and easy-to-understand text i've read in a while
[14:09:24 CST(-0600)] <jessm> is 'often times' one word?
[14:09:38 CST(-0600)] <jessm> 'tis
[14:09:44 CST(-0600)] <colinclark> ok
[14:09:57 CST(-0600)] <colinclark> thanks for the feedback
[14:11:54 CST(-0600)] <jessm> def. worth a free t-shirt
[14:20:50 CST(-0600)] <mlam> colinclark: I posted a patch to complete the test cases for addFiles. Hopefully this will do it