| 00:16 | <Hixie> | maybe instead of .data['foo'] |
| 00:16 | <Hixie> | we should have .getData('foo') |
| 00:16 | <Hixie> | but then it's not much better than .getAttribute('data-foo') anyway |
| 00:19 | <annevk> | .dataset.foo |
| 00:20 | <Hixie> | the advantage of .data.foo is that we could provide .data.foo.has('foo') |
| 00:20 | <Hixie> | or .data.foo.asList(',')[0] if it's a comma separated list or something |
| 00:20 | <Hixie> | i guess that'd just be .data.foo.split(',') |
| 00:21 | <Hixie> | i should look at the dojo source |
| 01:06 | <eseidel> | othermaciej, Hixie: continueing from #webkit.. |
| 01:06 | <eseidel> | so you do you have an opinion on postMessage sync behavior? |
| 01:07 | <eseidel> | as I was saying in #webkit, I think sync is broken/bad for browsers |
| 01:07 | <Hixie> | i don't have any strong opinions |
| 01:07 | <Hixie> | i don't recall why we did it synchronous |
| 01:07 | <eseidel> | Hixie: my issue is in the scrollback of #webkit. but basically, postMessage being sync seems like it could cause issues for FF or Safari, once they land squirrel fish |
| 01:08 | <othermaciej> | I don't think postMessage being sync creates implementation-specific issues |
| 01:08 | <eseidel> | since with suspendable js, tabs can be running js in parallel |
| 01:08 | <Hixie> | wtf is squirrel fish |
| 01:08 | <eseidel> | Hixie: yet-another-re-write of the js interpreter |
| 01:08 | <othermaciej> | I'm also not sure we'd ever support different tabs running JS in parallel if it can be observed |
| 01:09 | <othermaciej> | it's our silly code name for a JS refactoring branch |
| 01:09 | <eseidel> | well, back to the basic issue. tab opens another tab. first tab posts to the second, second tab hangs |
| 01:09 | <othermaciej> | async feels right and works better if it is likely postMessage sequences will involve lots of replies back and forth |
| 01:09 | <othermaciej> | I can't really argue for it more than that |
| 01:09 | <eseidel> | assuming JS isn't run in teh UI thread |
| 01:09 | <eseidel> | which was always my point with bytecode work |
| 01:10 | <Hixie> | well i'm certainly ok with changing it |
| 01:10 | <eseidel> | I wanted an interruptable interpreter |
| 01:10 | <Hixie> | but i guess it depends on the browsers |
| 01:10 | <othermaciej> | keep in mind, if two windows are same domain they can call each other directly |
| 01:10 | <Hixie> | postMessage() has change a dozen times already |
| 01:10 | <othermaciej> | without postMessage |
| 01:10 | <Hixie> | the mozilla guys will kill me if it changes again |
| 01:10 | <othermaciej> | in Safari we turned it off for 3.1 due to spec changes |
| 01:10 | <eseidel> | othermaciej: so maybe i'm missunderstanding it. maybe it's when two tabs are opened independantly |
| 01:10 | <othermaciej> | I would not be against making it async |
| 01:10 | <othermaciej> | I don't feel strongly |
| 01:11 | <othermaciej> | eseidel: to use postMessage you still need a reference to the other window object |
| 01:11 | <othermaciej> | the only new thing it opens up is that this can be cross-domain |
| 01:13 | <dglazkov> | the async spec is what Hixie was working on? |
| 01:13 | <Hixie> | yeah there is an async message thing i'm working on too |
| 01:13 | <Hixie> | but that's separate really |
| 01:13 | <Hixie> | window.postMessage could be sync or async independent of this |
| 01:14 | <dglazkov> | http://hixie.ch/specs/dom/messages/0.9 |
| 01:14 | <Hixie> | right |
| 01:14 | <aroben> | eseidel: what issues do you see that are unique to postMessage? |
| 01:17 | <eseidel> | you reply to a postMessage w/ another yes? |
| 01:17 | <eseidel> | if that's the case, than any time you reply, you're likely to get hung |
| 01:18 | <eseidel> | I guess we could add a timeout |
| 01:18 | <eseidel> | but postMessage feels very UDP to me |
| 01:18 | <othermaciej> | I see, that's essentially passing file descriptors over sockets |
| 01:18 | <othermaciej> | (in unix systems programming terms) |
| 01:18 | <othermaciej> | eseidel: you don't have to reply synchronously, though it does offer the API to do so |
| 01:18 | <eseidel> | you don't wait for your UDP response packet (since it returns void) :) |
| 01:19 | <othermaciej> | eseidel: you can store the source window instead and message it later at a time of your choosing |
| 01:19 | <eseidel> | honestly, the UDP comparison is what sells it for me |
| 01:19 | <eseidel> | if postMessage had a return value, I'd understand |
| 01:19 | <eseidel> | (and that would force it to be sync) |
| 01:19 | <eseidel> | but it's a UDP send call, that's all |
| 01:20 | <eseidel> | ok, time to mail the list |
| 01:20 | eseidel | just sees postMessage as causing all sorts of deadlocks as-is |
| 01:20 | <eseidel> | list-posting post salsa-class however... |
| 01:20 | <annevk> | now in general dispatching events is synchronous |
| 01:21 | <annevk> | so making it async here doesn't make much sense to me |
| 01:21 | <othermaciej> | postMessage is not like UDP |
| 01:21 | <othermaciej> | it is not intended to be an unreliable transport |
| 01:21 | <othermaciej> | I do think that "message passing" often implies asynchrony |
| 01:23 | <annevk> | http://www.w3.org/mid/083D18C6B9B71F4CBCA7B76D97B7483102C681BD21⊙Nwwnmc ... I hope he follows that e-mail with one that addresses the concerns raised. |
| 01:24 | <othermaciej> | I'm still waiting for specifics on the security claims |
| 01:24 | <Hixie> | you won't get any |
| 01:24 | <eseidel> | othermaciej, annevk: so what happens when you message to a frame who is spinning/locked/whatever? |
| 01:24 | <othermaciej> | eseidel: in Safari at least, frames do not have separate threads of control |
| 01:24 | <othermaciej> | so it is not a meaningful question |
| 01:26 | <eseidel> | othermaciej: I guess that's true. gmail runs in the background via settimeout, refresh, etc. but when it hangs, it has already brought down the frame which was trying to talk to it |
| 01:27 | <eseidel> | anyway, I've got to run |
| 01:28 | eseidel | wonders what other pieces of HTML5 will strike him as broken |
| 01:28 | <eseidel> | ;) |
| 02:09 | <Hixie> | man, why does <object> use data="" instead of src="" |
| 02:09 | <Hixie> | that's so dumb |
| 02:11 | <othermaciej> | it is |
| 02:12 | <othermaciej> | one of the dumber things about it |
| 02:18 | <Hixie> | i wonder if we can just get away with not having data-* on <object> |
| 02:18 | <Hixie> | or if we should just use another DOM name |
| 02:18 | <Hixie> | like anne's "dataset" suggestion |
| 02:22 | <othermaciej> | that's not bad |
| 02:22 | <othermaciej> | or maybe Data Access for Rich Internet Applications - daria |
| 04:02 | <BenMillard> | just to add another syntax suggestion to the custom data brew, how about meta="foo" with meta="bar:baz quux:quuz" for multiple pairs and replace ".data" with ".meta" for the DOM suggestions? |
| 04:11 | <BenMillard> | a single custom attribute for all custom data seems neater in some respects than an unrestricted number of custom attributes |
| 04:12 | <BenMillard> | the "meta" attribute name sort of complements the <meta> element name and they have a similar purpose |
| 04:13 | <BenMillard> | it's slightly fewer keystrokes for authors and slightly fewer bytes to transfer |
| 04:15 | <BenMillard> | meta="bar:baz" would be for a value whose key couldn't be determined from the element or context around that element |
| 04:28 | <BenMillard> | authors concerned about the accessibility and usability of data in title attributes have discussed solutions on Accessify Forums previously, so I've linked them to the recent IRC logs and am now linking you to them: http://www.accessifyforum.com/viewtopic.php?p=59246#59246 |
| 06:45 | <Hixie> | i "transclution" a word? |
| 06:45 | <Hixie> | the fourth hit on google for that word is an e-mail i wrote |
| 06:45 | <Hixie> | and there are less than 100 hits |
| 06:45 | <Pavlov> | m-w.com? |
| 06:45 | <Hixie> | which leads me to suspect it's not |
| 06:45 | <Hixie> | but i don't know what the word would be |
| 06:46 | <Hixie> | Pavlov: m-w.com doesn't have it |
| 06:47 | <jruderman> | i think the word you are looking for is "transclusion" |
| 06:48 | <Hixie> | yes, so it seems |
| 06:48 | <Hixie> | thanks |
| 06:48 | <Hixie> | doesn't come up in m-w.com either, of course |
| 06:53 | <Hixie> | http://wiki.whatwg.org/wiki/New_Vocabularies has some solutions on it now |
| 07:05 | <mitsuhiko> | data is a good word |
| 07:12 | <mitsuhiko> | i really hope that ie8 is a joke |
| 07:13 | <mitsuhiko> | interestinly ie 6 renders better than ie8 when it comes to what we do |
| 08:16 | <hsivonen> | Does anyone have experience on how much time it takes to get things running in Amazon EC2? |
| 09:26 | <virtuelv> | Hixie: am I missing something, or is an explanation of what the dirty* arguments to putImageData are missing? |
| 09:57 | <hsivonen> | http://www.w3.org/TR/2008/WD-wai-aria-primer-20080204/#alookahead |
| 10:00 | <zcorpan> | hsivonen: that section confuses me |
| 10:01 | <hsivonen> | there's no good reason why certain bits of HTML5 could not be implemented in the same schedule as some bits of ARIA |
| 10:02 | <zcorpan> | but the group seems to care more about getting to LC than getting implementations... |
| 10:03 | <zcorpan> | (at least that's the impression i get) |
| 10:03 | <hsivonen> | do PFWG specs need two interoperable impls to advance to REC? |
| 10:04 | <zcorpan> | no idea |
| 10:33 | <hsivonen> | aaargh. annoying. The XPath attribute thingy requires quotes where CSS attribute selectors work without quotes |
| 10:44 | <hsivonen> | hmm. ../../ doesn't appear to actually work... |
| 12:39 | <Lachy> | Hixie, yt? |
| 12:41 | <Lachy> | Hixie, can you zip up a copy of acid3 and all support files for me? The last copy you sent me seems to be a bit out of date and some tests aren't working properly. |
| 13:03 | <hsivonen> | hmm. I have now sent 44% of all-time messages to public-pfwg-comments |
| 13:07 | <zcorpan> | hsivonen: interesting |
| 13:09 | <hsivonen> | which makes me wonder where all the comments from accessibility professionals are |
| 13:09 | <Philip`> | Maybe some are on non-public lists? |
| 13:14 | <hsivonen> | Philip`: surely all the pros aren't members of the secret list. (then there's wai-xtech, but I'm not seeing much spec review in the archives) |
| 13:16 | <zcorpan> | i haven't seen much spec review at all |
| 13:16 | <zcorpan> | it's also not so easy to review the spec, since it's impossible to do diffs |
| 13:16 | hsivonen | is just getting more grumpy when diving deeper into HTML5/ARIA integration issues |
| 13:16 | <zcorpan> | (unless you're an editor or in w3c staff or something) |
| 13:17 | <zcorpan> | i'll work on writing test cases for aria combined with native html semantics soonish |
| 13:18 | <zcorpan> | (i have no idea about pass conditions yet so they'll be demos initially) |
| 13:18 | <zcorpan> | i also don't know how to automate aria tests |
| 13:18 | <zcorpan> | i've heard it should be possible somehow |
| 13:18 | <hsivonen> | I think I'm just going to deploy an iteration of Validator.nu with part of the conformance reqs pulled out of my sleeve |
| 13:19 | <zcorpan> | that would be cool |
| 13:19 | <zcorpan> | hsivonen: btw, the conformance stuff is updated in the Member-only draft |
| 13:20 | <hsivonen> | zcorpan: I had a quick look, and it didn't seem to address major issues. I keep reading the public draft otherwise in order to avoid leaking secrets in the Validator.nu SVN repo |
| 13:21 | <hsivonen> | It would be nice if the PFWG made their Editor's Drafts public |
| 13:21 | <zcorpan> | i agree |
| 13:21 | <zcorpan> | i don't get the impression that anything is intended to be secret |
| 13:22 | <zcorpan> | it's just behind closed doors due to cargo cult |
| 13:22 | <zcorpan> | or at least that's what i want to believe |
| 13:42 | <virtuelv> | for what it's worth, http://labs.opera.com/news/2008/03/28/ |
| 13:43 | <virtuelv> | 100/100, pixel perfect |
| 13:44 | Philip` | thinks Acid3's definition of "pass" is too subtle |
| 13:44 | <Philip`> | since 100/100 isn't enough to pass, and being pixel-perfect to the reference isn't either |
| 13:45 | <virtuelv> | Philip`: thinking of the performance stuff? |
| 13:46 | <Philip`> | virtuelv: Yes |
| 13:47 | <hsivonen> | Safari's perf side wasn't smooth on my Mac |
| 13:47 | <virtuelv> | Philip`: clicking the "A" reveals it, but I agree -- it's too subtle |
| 13:47 | <hsivonen> | but it was a lot smoother on reload (but still not smooth) |
| 13:47 | <virtuelv> | which, I think is why we added that extra instruction to the build notice |
| 13:48 | <Philip`> | Particularly with people competing to be the first to 'pass', it's really not helpful if passing is partly subjective or depends on hardware and network conditions |
| 13:50 | <hsivonen> | does Opera on Linux and Windows use the system TTF rasterizer? |
| 13:57 | <virtuelv> | hsivonen: I'll have to admit to being a bit unsure about what we do on every platform |
| 13:58 | <hsivonen> | virtuelv: ok. (the OS X builds appear to use the same TrueType rendering code path as Firefox 3) |
| 14:42 | <BenMillard> | zcorpan, section 6 confuses me as well |
| 14:42 | <BenMillard> | the "WCAG 1.0 Style Accessibility" could use a nested list to convey depth |
| 14:43 | <BenMillard> | the alt on the image for the + and - symbols could say "Expanded" or "Closed" |
| 14:43 | <BenMillard> | position would also be handled by using a nested list, AFAICT |
| 14:45 | <BenMillard> | upon expanding part of the tree, the number of items in that branch would become apparent by counting the <li> |
| 14:46 | <BenMillard> | you could use title="4 items" when a branch is closed |
| 14:47 | <hsivonen> | BenMillard: a screen reader saying "item two of fifteen" is chrome but title='' is content |
| 14:49 | <BenMillard> | according to that document: "Description/Help: Limited to HTML 4.0 - Alt Text, title text" |
| 14:55 | <Lachy> | othermaciej, does apple have any selectors api test cases to contribute to the test suite, which I need to start creating very soon? |
| 15:00 | <BenMillard> | hsivonen, I agree that title="Item x of y" on every item is unnecessary. |
| 15:01 | <BenMillard> | I think I've misunderstood their example. I thought aria-setsize="4" meant how many items were contained by the current item, but it actually seems to be the number of items in that level of the tree |
| 15:01 | <BenMillard> | so you don't need title for that |
| 15:03 | <hsivonen> | BenMillard: my point is that "item x of y" should probably be read in the chrome voice in screen readers that distinguish between content and chrome (like VoiceOver) |
| 15:04 | <hsivonen> | OTOH, untrusted content shouldn't be able to feed arbitrary text to the chrome voice for security reasons |
| 15:05 | <BenMillard> | if it were marked up as a nested list, announcements like that can be figured out by the screen reader without authors adding additional information |
| 15:05 | <BenMillard> | (or marked up as a new HTML form control) |
| 15:06 | <BenMillard> | aria-posinset and aria=setsize are made redundant by the structure of the markup if sensible elements are used as the basis, afaict |
| 15:08 | <hsivonen> | BenMillard: to me, aria-posinset and aria-setsize seem mostly redundant with native semantics, yes |
| 15:08 | <hsivonen> | BenMillard: if you are browsing a huge webmail inbox, it could make sense to allow a grid widget declare its starting offset, though |
| 15:18 | <BenMillard> | hsivonen, that makes sense. information like that can help everyone, so it might even be visible: "Messages 200-250 of 1,000" |
| 15:19 | <hsivonen> | BenMillard: I suggest posting your points about the setsize/posinset stuff to public-pfwg-comments |
| 15:20 | <BenMillard> | okies, I'll do that now |
| 16:10 | <othermaciej> | Lachy: I'm sure we have at least a couple, I'll ask around |
| 16:13 | <Lachy> | othermaciej, thanks |
| 17:03 | <BenMillard> | I've sent feedback: http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/0100.html |
| 23:02 | <Hixie> | i've updated http://wiki.whatwg.org/wiki/New_Vocabularies with some obvious ideas |
| 23:02 | <Hixie> | like embedding MathML and SVG in HTML using extensions to the parser |
| 23:03 | <Hixie> | and have marked which requirements get met by those solutions |
| 23:10 | <hsivonen> | what's the deal with the XHTML2/Forms WG CSS namespace objection? |
| 23:10 | <Hixie> | hm? |
| 23:12 | <Hixie> | i wonder if i can get the "Maintainability" requirement for equations by defining enough clever parsing rules, or if that really just makes it worse |
| 23:14 | <hsivonen> | http://lists.w3.org/Archives/Public/www-style/2008Mar/0417.html Why are the XHTML2 and Forms WGs suddenly interested in *removing* CSS namespace syntax? |
| 23:15 | <hsivonen> | Hixie: my guess is on makes it worse |
| 23:16 | <Hixie> | yeah i figure worse too |
| 23:16 | <Hixie> | can't see how else to make mathml maintainable, though, and latex in html just has so many other problems... |
| 23:17 | <Hixie> | hahaha |
| 23:17 | <Hixie> | they're using process issues on the css group |
| 23:17 | <Hixie> | that's funny |
| 23:17 | <annevk2> | it's annoying |
| 23:17 | <annevk> | but not that bad |
| 23:17 | <Hixie> | it's easy to ignore :-) |
| 23:17 | <hsivonen> | but why are the XHTML2 and Forms WGs suddenly so interested in backwards compat axioms? |
| 23:18 | <hsivonen> | in a CSS feature that was added for the kinds of languages those WGs are specifying |
| 23:18 | <Hixie> | because they got the wrong lesson from html5 |
| 23:19 | <Hixie> | same way that the css group thinks that being transparent is the lesson one should learn from html5 |
| 23:19 | <hsivonen> | Hixie: surely being transparent is *one* of the lessons? |
| 23:20 | <Hixie> | being transparent is a side-effect of soliciting feedback from all sources and attempting to address everyone's feedback |
| 23:38 | <jgraham> | Hixie: Re: maths I think this is one case where "the tools will save us" might be the most convincing argument (since *TeX in HTML doesn't make sense and MathML is so impossible to hand author) |
| 23:38 | <jgraham> | But it would be interesting to know what the MathWG think |
| 23:38 | <hsivonen> | Markdown+iTeX2MML |
| 23:39 | <Hixie> | the math wg sent their input to the whatwg list |
| 23:39 | <Hixie> | er |
| 23:39 | <Hixie> | the public-html list |
| 23:39 | <jgraham> | I have vague memories that they had plans for a human-editable MathML syntax |
| 23:39 | <jgraham> | Hixie: In more detail than that post |
| 23:40 | <jgraham> | (which I thought was very positive as they are willing to have text/html compatible parsing rules for MathML without a fight) |
| 23:40 | <Hixie> | http://lists.w3.org/Archives/Public/public-html/2008Mar/0255.html |
| 23:40 | <Hixie> | (for those who care) |
| 23:40 | <Hixie> | jgraham: yeah |
| 23:40 | <Hixie> | jgraham: dunno |
| 23:40 | <nickshanks> | does webkit support calc() in CSS? |
| 23:41 | <nickshanks> | oops, wrong tab |
| 23:48 | <hsivonen> | bed time. nn |
| 23:49 | <jgraham> | goodnight |