| 00:16 | <TabAtkins> | Woo, I like <audio>. Much easier to work with than my flashplayer thing. |
| 01:02 | <JonathanNeal> | TabAtkins, has anyone written a script that checks for audio tags, support for audio tags, and swaps them out with flash players for incompatible versions? |
| 01:04 | <TabAtkins> | I'm certain they have. |
| 01:04 | <TabAtkins> | But I can't point you to any. |
| 01:04 | <TabAtkins> | Should be basically the same as the many scripts that do so for <video>. |
| 01:07 | <JonathanNeal> | Oh they've done video, you have an example of that one? |
| 01:10 | <JonathanNeal> | Well, a beautiful girl is waiting for me in Fullerton and I gotta go. Have a great weekend, TabAtkins. |
| 02:09 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#annotations-for-assistive-technology-products |
| 02:10 | <othermaciej> | I'll have to review later |
| 02:10 | <othermaciej> | looks like a good start |
| 02:13 | <TabAtkins> | Hmm, you sure you want <div> to default to role=presentation? |
| 02:13 | <Hixie> | pretty sure |
| 02:13 | <Hixie> | why? |
| 02:14 | <TabAtkins> | That seems to imply that the content has *no* semantics, rather than just that the content doesn't have defined semantics. |
| 02:14 | <Hixie> | isn't that exactly what <div> means? |
| 02:15 | <TabAtkins> | It means the latter, not the former. |
| 02:15 | <Hixie> | i don't understand the distinction |
| 02:15 | <TabAtkins> | presentation means that the content is *entirely* decorative, without any hope of semantics being applied. |
| 02:16 | <Hixie> | role=presentation just means "skip the element when mapping it to the accessibility API" |
| 02:16 | <othermaciej> | as I understand it, role=presentation means that even things inside the element are considered to have no semantics |
| 02:16 | <TabAtkins> | <div>, on the other hand, just has no semantics - it's a default for when the language fails, not an active declaration that something is inherently void of semantics. |
| 02:16 | <TabAtkins> | ::points to othermaciej:: |
| 02:16 | <othermaciej> | i.e. skips the element and its contents |
| 02:16 | <othermaciej> | but my understanding could be wrong |
| 02:16 | <Hixie> | your understandings both seem to contradict the spec |
| 02:16 | <Hixie> | i can't see where it says anything abotu descendants |
| 02:17 | <Hixie> | and (notwithstanding that i've made the example invalid in html5) they have an example showing this: http://www.w3.org/WAI/PF/aria/#presentation |
| 02:17 | <TabAtkins> | Hrm, you're right. The spec does allow accessibility APIs to still read the contents. |
| 02:17 | <TabAtkins> | Never mind, then. That seems appropriate. |
| 02:17 | <othermaciej> | Hiyou are right |
| 02:17 | <othermaciej> | er |
| 02:17 | <othermaciej> | Hixie: you are right |
| 02:18 | <TabAtkins> | Dur, they even have a good example right there, with an <li role=presentation> containing an <a role=listitem>. |
| 02:19 | <Hixie> | well it's a moderately good example, since as i said, i just made that example invalid in html5 |
| 02:19 | <TabAtkins> | Ah, because you've constained <li> to be either listitem or treeitem |
| 02:19 | <Hixie> | (<li role=presentation> and <a role=treeitem> both violate the "strong native semantics") |
| 02:21 | <Hixie> | i wonder if i should make all the inline elements have No Role, instead of leaving them open like now |
| 02:23 | <othermaciej> | Hixie: why don't you allow lists as menus? |
| 02:23 | <TabAtkins> | Hmm. At the very least, make <span> role=presentation with an override, same as <div> |
| 02:24 | <Hixie> | othermaciej: lists as menus? |
| 02:24 | <TabAtkins> | <ul>/<ol> as role=menu |
| 02:24 | <TabAtkins> | presumably |
| 02:24 | <othermaciej> | <li> with a menuitem role for instance |
| 02:24 | <othermaciej> | and <ul> with role=menu |
| 02:24 | <othermaciej> | since people commonly use list markup for things that are in fact menus (but not either context menus or toolbars) |
| 02:25 | <Hixie> | othermaciej: i meant to allow that with <menu> <li> |
| 02:25 | <TabAtkins> | Hm, I wonder if that works anywhere yet? |
| 02:25 | <Hixie> | but i appear to have forgotten to allow the <li> part of that |
| 02:25 | <Hixie> | <menu><li> works in everything back to like netscape 1 |
| 02:26 | <othermaciej> | the <li> part was the aspect I noticed |
| 02:26 | <TabAtkins> | Oh, right, isn't that just a reclaiming of an old element? |
| 02:26 | <othermaciej> | <menu><li> seems reasonable |
| 02:26 | <TabAtkins> | Agreed. |
| 02:26 | <Hixie> | TabAtkins: yeah |
| 02:26 | <othermaciej> | and I forgot about <menu>'s no-type state |
| 02:26 | <othermaciej> | all right, I'm off |
| 02:26 | <othermaciej> | later folks |
| 02:27 | <Hixie> | later |
| 02:27 | <Hixie> | actually, turns out i don't have to do anything for <menu><li> |
| 02:27 | <Hixie> | well, i suppose i should make it role=presentaitonal |
| 02:29 | <Hixie> | hmm |
| 02:29 | <Hixie> | actuall making <div> and <span> vanish is going to cause issues with the many global attributes |
| 02:29 | <TabAtkins> | Hm. Is the only difference between dialog and alertdialog that the latter should act modal? |
| 02:29 | <Hixie> | i guess i'll remove the role=presentation after all |
| 02:29 | <Hixie> | TabAtkins: something to do with focus, it seems |
| 02:30 | <TabAtkins> | nah, that's between alert and dialog (dialog should have focus). |
| 02:30 | <TabAtkins> | i think alertdialog is just dialog but modal |
| 02:31 | <TabAtkins> | The aria spec I'm reading recommends that, when the entire document is itself a role=document, that should be placed on <body>, not <html> |
| 02:32 | <TabAtkins> | same with role=application |
| 02:32 | <Hixie> | it says "root note for content" |
| 02:32 | <Hixie> | root node, rather |
| 02:32 | <TabAtkins> | But then explicitly gives <body> as an example |
| 02:32 | <TabAtkins> | http://www.w3.org/TR/wai-aria/#document |
| 02:32 | <Hixie> | yeah, i see the example |
| 02:32 | <Hixie> | not sure what to make of it |
| 02:33 | <Hixie> | the <head> is content too |
| 02:33 | <Hixie> | the root node is <html> |
| 02:33 | Hixie | shrugs |
| 02:33 | <Hixie> | also, that should is not bold and capitalised... |
| 02:33 | <Hixie> | i wonder if it is meant to be a SHOULD or not |
| 02:34 | <TabAtkins> | Well, <title>, <meta>, <style> all have strong semantic of "no role" |
| 02:34 | <TabAtkins> | presumably <script> and <link> would be similar? |
| 02:34 | <Hixie> | oh did i not add <script>? |
| 02:34 | <TabAtkins> | So what content would remain in <head> that would be meaningful? |
| 02:34 | <Hixie> | <link> is not no-role, it's link |
| 02:34 | <TabAtkins> | Oh, duh. |
| 02:34 | <Hixie> | i'm gonna remove the no role ones, i think |
| 02:34 | <Hixie> | at least some of them |
| 02:35 | <TabAtkins> | Add that too, then. |
| 02:35 | <TabAtkins> | <link>, that is |
| 02:35 | <Hixie> | <link> is a link, i'm not removing that |
| 02:35 | <Hixie> | why would we remove it? |
| 02:35 | <TabAtkins> | I know, but it's not in the document right now at all. |
| 02:36 | <Hixie> | how so? |
| 02:36 | <Hixie> | it's the first entry in the table |
| 02:36 | <Hixie> | a, area, link |
| 02:36 | <TabAtkins> | Gah, of course, the *one* entry with multiple elements. |
| 02:36 | <Hixie> | i'll split them into three |
| 02:36 | <Hixie> | :-) |
| 02:36 | <TabAtkins> | Yeah, the <h1>-<h6> block made me expect one element per line |
| 02:36 | <Hixie> | yeah |
| 02:37 | <Hixie> | i was originally going to just have "elements that are hyperlinks" |
| 02:37 | <Hixie> | and added the element names explicitly, not sure why |
| 02:40 | <TabAtkins> | I'd keep <style> and <script> as No role, but either remove <title> or give it heading. |
| 02:40 | <Hixie> | why keep them as no role? |
| 02:40 | <Hixie> | i've removed title |
| 02:40 | <TabAtkins> | I can't think of any reason to ever have any accessibility guide on them. |
| 02:41 | <TabAtkins> | Or wait, does No Role mean they're read as part of the text or something? |
| 02:41 | <Hixie> | No role means that you're not allowd to set role="" on them |
| 02:42 | <Hixie> | i think we should set no role on <script> if we set it on, say, <var>, but otherwise, I don't see much point |
| 02:42 | <TabAtkins> | For ATs that pay attention, how does a lack of role affect them? |
| 02:43 | <Hixie> | not 100% sure |
| 02:44 | <TabAtkins> | If they then treat it like normal content, then I don't think <script> should be No Role. You don't want to know the contents of script when using a page - they're not relevant except through their effects. |
| 02:45 | <Hixie> | well "treat as normal content" can mean several things |
| 02:45 | <Hixie> | it can mean "hide things display:none" |
| 02:45 | <TabAtkins> | Hmm, suppose that's true. |
| 02:46 | <TabAtkins> | Well, assuming that's true, I don't think I have any problems. Looks good, Ian. |
| 02:46 | <Hixie> | cool |
| 02:46 | <Hixie> | ok well i should go get dinner |
| 02:46 | <TabAtkins> | Now we just need ARIA to provide better semantics so it can catch up html's native stuff. |
| 02:47 | <TabAtkins> | Later. |
| 02:47 | <Hixie> | i'll reply to more mail later |
| 02:47 | <Hixie> | heh yeah |
| 02:47 | <Hixie> | later |
| 04:46 | <TabAtkins> | In light of the recent Sears and Kmart category-changing debacle (which was awesome), I have temporarily added a similar facility to my own company's website. |
| 04:47 | <TabAtkins> | I am struck by extreme giggles at seeing familiar pages advertising "Baby Launchers" and "Big Ass Tools, Fuck Yeah". |
| 05:39 | <heycam> | jgraham, yeah at the current rate of progress on web idl maybe i should just update it to es5 and not bother having an es3 version :) |
| 05:52 | <Lachy> | Hixie, have you had any thoughts about the proposed <content> element? I'm writing an article explaining everything authors need to know about sectioning, and if that is to be added, it would change how I need to write a fairly significant part of it |
| 06:02 | <Hixie> | Lachy: i haven't read the thread, but off-hand i don't understand what problem it's solving |
| 06:02 | <Hixie> | (i haven't read the thread so maybe the problem was described there) |
| 06:07 | <Lachy> | yeah, the problem was described in the thread |
| 06:08 | <Lachy> | basically, authors are misusing <section> as a generic wrapper to group content together, and the idea is that <content> would map to role=main (when its nearest setioning element ancestor is the body element) |
| 06:09 | <Hixie> | isn't <body> the relevant element for wrapping the contents of the page? |
| 06:09 | <Lachy> | e.g. authors do stuff like this: <article><header>...</header><section>...</section><footer>...</footer></article> where the <section> itself is just a wrapper around the content area, and doesn't actually have a heading of its own |
| 06:10 | <Hixie> | it seems like a better solution than a new element would be to point out they can just remove the element altogether |
| 06:11 | <gavin_> | it was proposed as an alternative to <div id="main">/<div id="content"> |
| 06:11 | <gavin_> | which is a pretty common pattern |
| 06:11 | <Hixie> | isn't no element at all a suitable alternative to that? |
| 06:11 | <Hixie> | i really don't understand what this is for |
| 06:12 | <Lachy> | e.g. This is a better example: <body><header>...</header><section id="content">...</section><aside id="sidebar">...</aside><footer>...</footer></body> |
| 06:12 | <Hixie> | why is this not enough: <body><header>...</header>...<aside id="sidebar">...</aside><footer>...</footer></body> |
| 06:13 | <Lachy> | Hixie, generally, the element can be omitted, but authors have expectations that aren't being met by the current model, and in this case it seems better to meet those expectations, rather than fight against them which is proving only to lead to the abuse of other elements |
| 06:13 | <gavin_> | I don't know why it's a common pattern |
| 06:13 | <Hixie> | i'm not just going to add features to fill cargo cult expectations without understanding why |
| 06:13 | <Hixie> | that's a dumb way to design a language |
| 06:13 | <gavin_> | easy styling would be one reason, I guess |
| 06:14 | <Hixie> | if the only semantic is as a styling hook, that's what <div> is for. |
| 06:14 | <aho> | which browsers support the audio tag already? ff seems to work, opera (9.x) says it doesn't know about it... chrome says it does support it, but it doesnt want to play my ogg |
| 06:14 | <Lachy> | (personally, I have recommended using <div> for those purposes, but the implied semantics of role=main make it slightly more useful |
| 06:15 | <Hixie> | i don't really understand the semantic of role=main either |
| 06:16 | <Lachy> | from ARIA: "The main role is a non-obtrusive alternative for "skip to main content" links" |
| 06:17 | <Hixie> | that's what <nav> is for |
| 06:17 | <Hixie> | so that's already handled |
| 06:17 | <Hixie> | (in an imho better way) |
| 06:19 | <Lachy> | nav identifies the navigation, and the main content is currently just assumed to be the content after <header> (if present) that isn't either <aside> or <nav>. (I'm not entirely sure why some people don't find that adequate) |
| 06:19 | <aho> | "ff seems to work" <- ehm... or not... it's pretty buggy there :/ |
| 06:20 | <Lachy> | but I'm fine with just recommending the use of <div> or nothing in the article. I'm not really decided either way on whether <content> is a good idea |
| 06:21 | <Hixie> | aho: it's early days yet |
| 06:21 | <aho> | yo Hixie... well, the specs for play() are troublesome either way |
| 06:21 | <gavin_> | how is ff buggy? |
| 06:21 | <Hixie> | Lachy: off hand i think no element (or <div> for those who need a comfort blanket here) is the way to go, but i'll have to study the thread |
| 06:22 | <Hixie> | aho: the spec for play()? |
| 06:22 | <aho> | the way it's written there means that it wouldn't be possible to play the same thing several times simultaneously... you'd have to create some cyclic buffer thing on the js side for that to work |
| 06:22 | <Hixie> | how do you mean? |
| 06:22 | <aho> | gavin_, first time play is called it works fine... after that the sound is played twice each time |
| 06:23 | <gavin_> | do you have a testcase? |
| 06:23 | <aho> | media . play() |
| 06:23 | <aho> | Sets the paused attribute to false, loading the media resource and beginning playback if necessary. If the playback had ended, will restart it from the start. |
| 06:23 | <aho> | if it's done like that each audio thingy can be only played once... then you gotta wait till it's done... and then you can play it again |
| 06:24 | <Hixie> | aho: are you using this for soundeffects or for, like, a podcast player? |
| 06:24 | <aho> | so, right now... if you want to play the same thing several times at the same time you'd have to check if it ".ended"... if not use a new one and play that |
| 06:24 | <aho> | sfx |
| 06:25 | <aho> | otherwise it wouldnt matter, would it? ;) |
| 06:25 | <Hixie> | aah, yeah, you need to have one Audio per instance of the sound you want to play at once |
| 06:25 | <aho> | gavin_, i can upload it |
| 06:26 | <aho> | http://kaioa.com/k/ct/audio1.html |
| 06:27 | <aho> | hover one of those rects... hear how it sounds... wait till it's done... hover the next and then you get something like 30% of the sample and then the complete sample |
| 06:27 | <aho> | it sorta stutters |
| 06:27 | <aho> | (on winxp at least) |
| 06:28 | <aho> | it will continue to behave like that until you reload... then it works fine again... well... once :> |
| 06:29 | <gavin_> | aho: thanks, I'll file a bug |
| 06:29 | <Lachy> | Hixie, are the terms "strong native semantics" and "implicit ARIA semantics" meant to be defined somewhere? |
| 06:29 | <aho> | if you put some console.log thingies there you'll see that the in function (first thingy in hover) is indeed only called once |
| 06:29 | <aho> | gavin_, thanks |
| 06:30 | <aho> | i actually wanted to write some cyclic buffer thing... but it's sorta hard if the sound is broken :) |
| 06:30 | <Hixie> | Lachy: i'm told ARIA is going to make them magic |
| 06:30 | <Hixie> | Lachy: i was going to wait until the ARIA spec was ready so that i could make sure i used these magic terms properly |
| 06:30 | <aho> | maybe i should try a longer stereo sample (the used one is mono) |
| 06:30 | <Hixie> | Lachy: as one would, if one were writing a spec responsibly |
| 06:31 | <Hixie> | Lachy: but various people decided that i should just make shit up instead, so that's what i did |
| 06:32 | <aho> | since chrome claims it knows about the audio tag... which formats does it support? is there any way to query this stuff? |
| 06:32 | <Lachy> | ah, ok. |
| 06:33 | <Lachy> | I was wondering why ARIA suddenly got added despite you waiting for the ARIA spec to be adjusted |
| 06:33 | <gavin_> | aho: oh, turns out it's already fixed |
| 06:33 | <aho> | :o |
| 06:33 | <aho> | any eta for when it will be in stable? |
| 06:34 | <Hixie> | Lachy: i realised i was wasting significantly more time explaining to people why it was stupid to do it prematurely than i would waste from fixing the resulting mess from doing it prematurely |
| 06:34 | <Lachy> | can you explain what the difference between the two terms are? |
| 06:36 | <Lachy> | the spec says "The following table defines the strong native semantics and corresponding implicit ARIA semantics that apply to HTML elements." |
| 06:37 | <Lachy> | but the table below that only contains 2 columns: one for the elements and the other for the "Implied ARIA semantics". Where are the strong native semantics defined? |
| 06:37 | <Hixie> | Lachy: i was basing it on http://lists.w3.org/Archives/Public/public-html/2009Aug/0962.html |
| 06:37 | <gavin_> | aho: in firefox 3.6 at the very least |
| 06:37 | <aho> | aw |
| 06:37 | <Hixie> | Lachy: everything in that table is both an implied aria semantic and a strong native semantic |
| 06:38 | <gavin_> | note: "at least" - could potentially be in a 3.5.x release as well |
| 06:38 | <Hixie> | of course then we have http://lists.w3.org/Archives/Public/public-html/2009Aug/1001.html |
| 06:38 | <Hixie> | so who the heck knows |
| 06:38 | <Hixie> | but worry not! for aria is ready! even though they haven't actually figured out what it should be yet |
| 06:38 | <Hixie> | (i may be bitter :-P) |
| 06:39 | <Lachy> | so are the roles in the first of the two tables meant to be the strong native semantic roles that aren't allowed to be overridden, and those in the second table are just the implied roles that can be, subject to the listed restrictions? |
| 06:40 | <aho> | ah meh... chrome wants mp3 :f |
| 06:41 | <Hixie> | Lachy: isn't the paragraph above the first table clear enough about that? i thought i'd said that in at least three different ways just to be sure it was crystal clear... |
| 06:41 | <Lachy> | if so, I would change "The following table defines the strong native semantics and corresponding implicit ARIA semantics that apply to HTML elements." to "The following table defines the strong native semantics that apply to HTML elements." and change the table's second column heading to "Strong native semantics" |
| 06:42 | <Hixie> | the term "strong native semantics" can't be the column header because it's an "impl"-only term |
| 06:42 | <Hixie> | turn on the highlight mode |
| 06:42 | <Hixie> | you'll see what i mean |
| 06:43 | <Lachy> | I have highlighting turned on, and it's not impl only |
| 06:44 | <Hixie> | oh, it's the other way around |
| 06:44 | <Hixie> | man i'm confused |
| 06:44 | <Hixie> | this is exactly why i didn't want to do this before i had some spec to refer to |
| 06:45 | <Hixie> | wait so you're proposing just not mentioning that these are implicit aria semantics? |
| 06:45 | <Hixie> | wouldn't that, like, fail at what we're trying to do here |
| 06:47 | <Hixie> | reload, tell me if that's better |
| 06:47 | <Lachy> | I thought "strong native semantics" and "implicit aria semantics" were two different, mutually exclusive types of semantics. I'm proposing you clarify which is which |
| 06:48 | <Hixie> | "strong native semantics" is the authoring criteria side, "implicit aria semantics" is the UA conformance criteria side. |
| 06:48 | <Hixie> | at least according to the fictional spec text that i'm assuming will one day be written |
| 06:48 | <Lachy> | oh? That wasn't at all clear from the spec |
| 06:48 | <Hixie> | which spec? |
| 06:48 | <Lachy> | your spec |
| 06:48 | <Hixie> | the spec defining these terms doesn't exist yet |
| 06:48 | <Lachy> | I know |
| 06:48 | <Hixie> | i don't define the terms |
| 06:48 | <Hixie> | i just use them |
| 06:49 | <Lachy> | but still, the way in which you used them didn't make it clear that one only applied to implementors |
| 06:49 | <Hixie> | i thought it was pretty clear though since one of the terms is only used in UA-only text |
| 06:51 | <Lachy> | alright, that's slightly better. I guess I'll wait for those terms to be defined properly before I can understand this better |
| 06:51 | <Hixie> | you and me both |
| 10:44 | <aho> | so... for mp3... "audio/mpeg; codecs=???" |
| 10:44 | <aho> | google yields a whopping 5 non-helpful hits |
| 11:05 | <foolip> | aho: no codecs parameter for mp3 |
| 11:07 | <aho> | in chrome 'audio/mpeg' (the right mime) returns an empty string. whereas 'audio/mp3' returns a 'maybe' |
| 11:07 | <aho> | should i resort to agent sniffing like everyone else? :f |
| 11:13 | <foolip> | file a bug on chrome I guess |
| 11:14 | <foolip> | but can chrome in fact play mp3? |
| 11:14 | <aho> | ye, works if i just do it |
| 11:14 | <aho> | (i.e. w/o any checking) |
| 11:15 | <foolip> | do you have several formats? |
| 11:16 | <foolip> | otherwise just use it without checking |
| 11:18 | <Lachy> | this is a few days old, but it was just pointed out to me that Google Image Search is encouraging the use of RDFa :-( http://googlewebmastercentral.blogspot.com/2009/08/specifying-images-license-using-rdfa.html |
| 11:22 | gsnedders | doesn't think Lachy would like what he's playing with now |
| 11:23 | <aho> | foolip, i *need* several formats. firefox does ogg but doesn't mp3. chrome does mp3, but doesn't ogg. |
| 11:27 | <Lachy> | gsnedders, I have no idea what toys you kids play with these days. |
| 11:28 | <foolip> | aho: chrome plays ogg vorbis |
| 11:28 | <gsnedders> | Lachy: RDF data exchange |
| 11:28 | <Lachy> | why? |
| 11:28 | <foolip> | gsnedders: I'm also having a blast with RDF! |
| 11:29 | <aho> | doesnt work here... mp3 works fine tho |
| 11:29 | <foolip> | aho: strange, sounds like you need to file 2 bugs at chrome |
| 11:30 | <foolip> | aho: chrome claims "maybe" for "audio/ogg" |
| 11:31 | <foolip> | I'd just do <audio><source src="audio.ogg"><source src="audio.mp3"></audio> and let the browser figure it out if canPlayType is too broken still |
| 11:32 | <aho> | http://kaioa.com/k/ct/audio4.html |
| 11:32 | <aho> | firefox and chrome behave differently |
| 11:32 | <aho> | not sure which one is right |
| 11:32 | <aho> | (ff's behavior makes sense to me though) |
| 11:33 | <foolip> | in which way are they different except for supporting different formats? |
| 11:33 | <foolip> | I've filed bugs on Chrome's canPlayType before and they fixed it |
| 11:33 | <aho> | chrome wont restart the sound and will throw an error |
| 11:33 | <foolip> | what, if you call play() after playback has ended? |
| 11:34 | <aho> | it doesnt play it again |
| 11:34 | <foolip> | that would be a bug in chrome, the spec says it should seek to the beginning |
| 11:35 | <aho> | eg the second one got 5 sounds... so, i can play a sound 5 times there... but then it's dead |
| 11:35 | <foolip> | you can always hack it by creating a new audio element for each time: new Audio("audio.mp3").play() |
| 11:37 | <aho> | i fear that might clutter up the ram |
| 11:37 | <foolip> | chrome should have a good enough garbage collector, try it |
| 11:38 | <foolip> | or you could try calling load() after each time, although that should be pretty much equivalent to creating a new element |
| 11:39 | <aho> | using load works for a little bit... then it dies... mh... cant even reload my (local) test page anymore |
| 11:39 | <aho> | tab died |
| 11:39 | <aho> | :> |
| 11:40 | <foolip> | well, that's 3 bugs you need to report |
| 12:12 | <Dashiva> | Is this ietf-honest thing just a storm in a teacup? |
| 13:11 | <gsnedders> | http://www.google.se/search?client=opera&rls=en&q=standard+grade+results&sourceid=opera&ie=utf-8&oe=utf-8 |
| 13:11 | <gsnedders> | That's somewhat disturbing. |
| 15:18 | <Dashiva> | Sure hope role=presentation doesn't end up as another content-type-and-we-really-mean-it-this-time |
| 16:25 | <Lachy> | Dashiva, what do you mean? |
| 16:26 | <Dashiva> | Used because alt="" isn't a reliable indicator of presentational images. Then it itself becomes misused, and a few years down the road we'll need yet another way to really mark an image presentational |
| 16:34 | <TabAtkins> | Wow, just noticed that whether or not a checkbox is checked is referred to as its "checkedness state". Awesome. ^_^ |
| 21:23 | gsnedders | does backflip, then hides |
| 21:26 | <Hixie> | anyone seen hsivonen around? |
| 21:27 | <TabAtkins> | Not for the past 5 hours. |
| 21:38 | <cying> | whoa, full house today |