| 01:07 | <dglazkov> | no Hixie? |
| 01:28 | <Hixie> | dglazkov: here now |
| 01:28 | <dglazkov> | cool! |
| 07:35 | <Hixie> | anyone have IE? |
| 07:35 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Ctable%20border%3E%0D%0A%3Ctr%3E%3Ctd%20rowspan%3D1%3EX%3Ctd%20rowspan%3D2%3EY%3Cbr%3EY%3Ctd%20rowspan%3D3%3EZ%3Cbr%3EZ%3Cbr%3EZ%3Cbr%3EZ%0D%0A%3Ctbody%3E%0D%0A%3Ctr%3E%3Ctd%3Ezzz |
| 07:35 | <Hixie> | i need to know if the cells in the first row group are the same height |
| 07:36 | <Hixie> | or whether they do what safari does |
| 07:39 | <Pavlov_> | sec |
| 07:39 | <Pavlov_> | X YY and ZZZ? |
| 07:40 | <Pavlov_> | er, ZZZZ? |
| 07:40 | <Pavlov_> | if so, they are all the same height for me in IE6 |
| 07:41 | <Hixie> | oh i was hoping for IE8 |
| 07:41 | <Hixie> | sorry |
| 07:41 | <Pavlov_> | ah |
| 07:41 | <Pavlov_> | sorry |
| 07:41 | <Hixie> | np |
| 07:41 | <Hixie> | i doubt it changed anyway |
| 07:42 | <Hixie> | thanks |
| 08:09 | <Hixie> | maybe we should just drop xml:base altoegether |
| 08:48 | <hsivonen> | heycam: thanks. |
| 08:52 | <heycam> | np |
| 08:55 | <virtuelv> | Is the error handling well enough specified these days for there to be a reference resulting parse tree for http://virtuelvis.com/download/162/evilml.html ? |
| 08:55 | <Hixie> | yes |
| 08:59 | <virtuelv> | Ok. Results aren't too encouraging, then |
| 09:00 | <virtuelv> | I can't test the DOM Viewer outpout in Midori (Webkit-based GTK app), since it crashes the browser |
| 09:00 | <hsivonen> | heycam: would you consider it appropriate if I made Validator.nu complain about if pattern had a full URI instead of just a hashed ID ref? |
| 09:00 | <othermaciej> | DOM Viewer handles it ok in Safari 3.1 |
| 09:01 | <Hixie> | http://james.html5.org/cgi-bin/parsetree/parsetree.py?source=%3C%21DOCTYPE+HTML+PUBLIC+%22-%2F%2FW3C%2F%2FDTD+HTML+4.01%2F%2FEN%22+%0D%0A%22http%3A%2F%2Fwww.w3.org%2FTR%2Fhtml4%2Fstrict.dtd%22%3E%3Chtml%3Chead%3Ctitle%3EWhat+does+your+HTML+%0D%0Aparser+make+of+this%3F%3C%2F%3E%3C%2F%3E%3Cbody%3Ch1%3Cem%3EEmphasized%3C%2F%3E+in+%26lt%3Bh1%26gt%3B%3C%2F%3E%3Cp%3Ca+%0D%0Ahref%3D%22http%3A%2F%2Fwww.example.com%22%3Cem%3EEmphasis%3C%2F%3E+in+links+as+well%3C%2F%3E.+%0D |
| 09:01 | <Hixie> | er |
| 09:01 | <Hixie> | http://james.html5.org/cgi-bin/parsetree/parsetree.py |
| 09:01 | <virtuelv> | othermaciej: Midori isn't exactly stable, but it's the only reasonable way I can run it under Gnome |
| 09:01 | <hsivonen> | is there a bug here: http://parsetree.validator.nu/?doc=http://virtuelvis.com/download/162/evilml.html |
| 09:02 | <hsivonen> | apparently not |
| 09:03 | <hsivonen> | it's just confusing that "<" can become part of an element name |
| 09:03 | <othermaciej> | fwiw in WebKit we have made no attempt yet to better match HTML5 standard parsing |
| 09:05 | <hsivonen> | Hixie: what's the deal with allowing "<" in an element name? is it an IEism? none of Gecko, WebKit and Opera do it |
| 09:08 | <heycam> | hsivonen, that sounds fine for svg 1.1. but for tiny 1.2, i'd only do it if you also complain about other unsupported values, e.g. fill="blah" |
| 09:08 | <heycam> | since it's the same class of error as that |
| 09:08 | heycam | goes for dinner for sure this time |
| 09:08 | <hsivonen> | heycam: thanks |
| 09:14 | <Hixie> | hsivonen: someone asked for < not to end tags, so, it doesn't |
| 09:15 | <Hixie> | send mail if you want to have it changed (but do let me know what it should be changed to) |
| 09:25 | <hsivonen> | Hixie: email sent |
| 09:26 | <Hixie> | thanks |
| 09:28 | hsivonen | is unhappy that SVG uses URIs instead of honest IDREFs for references that must be intra-document |
| 09:43 | <othermaciej> | hsivonen: I believe it is on a theory of future extensibility |
| 09:46 | <hsivonen> | othermaciej: in that case, the Safari impl. isn't forward-compatible |
| 09:47 | <othermaciej> | you mean that we just treat is as an idref, not resolve as a URI and then check if it is the same document? |
| 09:47 | <hsivonen> | othermaciej: yes |
| 09:48 | <othermaciej> | probably a bug that we treat it that way, but SVG is not yet that huge an area of concern |
| 09:49 | <othermaciej> | so besides requiring the parser to create elements with "<" in the name, does current html5 consider that an error? |
| 09:59 | <hsivonen> | othermaciej: no, the error will be caught on the next layer. |
| 10:44 | hsivonen | doesn't like ARIA's XSD datatype dependency |
| 10:44 | hsivonen | would prefer Web Forms 2.0 datatypes |
| 11:05 | <hsivonen> | the conformance requirements for ARIA need some work |
| 16:23 | <hsivonen> | 3.4.3.1 Header Levels versus Nesting Levels in http://www.w3.org/TR/wai-aria-practices/ is just sad |
| 16:28 | <Lachy_> | hsivonen, is there anything in that document that isn't sad? |
| 16:29 | <hsivonen> | Lachy_: given that Ajax libraries are building widgets out of divs, annotating those with ARIA is better than putting one's head in sand and insisting that the div widgets aren't happening |
| 16:29 | <hsivonen> | Lachy_: but yeah, even the div widgets are kinda sad |
| 16:43 | <gsnedders> | http://gsnedders.html5.org/tests/content-type.php |
| 18:28 | <Hixie> | hsivonen: now's a good time to raise aria issues |
| 18:28 | <Hixie> | hsivonen: i agree with most of what you said |
| 18:28 | <Hixie> | hsivonen: i'd go even further, and say that you shouldn't make one element take the semantics of another when those semantics affect the wider page, e.g. making a paragraph into a header |
| 19:00 | <hsivonen> | Hixie: ok. I've been thinking I should draft an ARIA-in-HTML5 integration proposal from the document conformance point of view |
| 19:01 | <Hixie> | that'd be very interesting |
| 19:01 | <hsivonen> | once we converge on what's conforming, we can consider what behavior to prescribe for the non-conforming cases |
| 19:01 | <Hixie> | also from the point of view of a non-CSS UA |
| 19:01 | <Hixie> | well |
| 19:01 | <Hixie> | my perspective on things is that we should avoid giving authors rope to hang themselves with, generally |
| 19:02 | <Hixie> | hence how many of the things i design from scratch just don't have error conditions |
| 19:02 | <Hixie> | they just have well-defined semantics for everything possible |
| 19:02 | <jgraham> | Hixie: Unfortunately aria has lots of error conditions :) |
| 19:02 | <hsivonen> | I'm particularly concerned that the "best practices" doc has examples that fail to use semantics that have been in HTML for over a decade and that wouldn't be disruptive for Ajax libraries |
| 19:03 | <hsivonen> | also, from a selfish point of view, I'm not at all a fan of aria-datatype and aria-owns |
| 19:04 | <Hixie> | jgraham: do you recall what format i have to use for "ISSUE-20"-type markers in e-mails to make my e-mails get associated with tracker issues? |
| 19:04 | <Hixie> | "aria-owns"?! hah |
| 19:04 | Hixie | introduces "html5-is-da-hot-stuff" |
| 19:05 | <jgraham> | Hixie: No. I think you just put the ISSUE-20 in the subj. line |
| 19:05 | <hsivonen> | seriously, though, ARIA containment conformance checking would be super-simple without aria-owns |
| 19:05 | <hsivonen> | or with aria-owned-by |
| 19:05 | <hsivonen> | but having the relation go from parent to child sucks big time for me :-( |
| 19:05 | <Hixie> | jgraham: oh i have to put it in the subject? that's unfortunate |
| 19:06 | <jgraham> | I don't know what happens if you put ISSUE-20 ISSUE-30 etc. all in the same subject. Possibly tracker explodes ;) |
| 19:07 | <jgraham> | (I assume that is the problem) |
| 19:07 | hsivonen | thought they could be in the message body as well |
| 19:07 | <Hixie> | i'm just gonna mention them in the body and link them up later if required |
| 19:08 | <hsivonen> | "The keywords can be anywhere in the subject or text of the message. However, the tool only reads the text portions of an email, not HTML or PDF, so make sure you send emails either in plain-text or with an equivalent plain-txt attachment." |
| 19:08 | <Hixie> | i hope it reads all of the e-mail |
| 19:08 | <jgraham> | hsivonen: Where is that? |
| 19:08 | <Hixie> | this is one big mail |
| 19:08 | <hsivonen> | http://www.w3.org/2005/06/tracker/email |
| 19:09 | jgraham | didn't spot that link |
| 19:12 | <hsivonen> | also, I think aria-templateid may have bad effects on innovation and compatition |
| 19:13 | <hsivonen> | bad for innovation, because it makes changing sites break accessibility |
| 19:13 | <hsivonen> | and bad for competition, because some participants get a special boost |
| 19:13 | <hsivonen> | and as a competitor, you cannot get the same advantage by writing to an open spec |
| 19:14 | <hsivonen> | instead, you have to use a magic string and reverse engineer its effect |
| 19:17 | <Hixie> | you don't have to |
| 19:17 | <Hixie> | you can just hardcode uris |
| 19:17 | <Hixie> | and that way you're not dependent on the author to provide a hook |
| 19:19 | <hsivonen> | Hixie: I meant you are a competitor of a site whose templateid is getting preferential treatment |
| 19:20 | <Hixie> | [24~aah |
| 19:20 | <hsivonen> | Hixie: how do you gain the same advantage? |
| 19:20 | <Hixie> | ure |
| 19:20 | <Hixie> | sure even |
| 19:20 | <Hixie> | it's anti-competitive! |
| 19:20 | <Hixie> | must be dropped |
| 19:20 | <Hixie> | :-) |
| 19:21 | <hsivonen> | the innovation point is that you are yourself getting preferential treatment for you old version. can you change your app innovatively? |
| 19:22 | <Hixie> | yeah |
| 19:28 | <Hixie> | well i just closed a tracker issue with a rejection for the first time |
| 19:28 | Hixie | dons his asbestos suit |
| 19:28 | Hixie | just replied to 102 e-mails |
| 19:28 | <Hixie> | that should help the graph |
| 19:32 | <Hixie> | so i don't suppose anyone did go through my input-for-whatwg-html-parsing-rules-namespaces-discussion folder and summarise the problem descriptions, huh |
| 19:36 | <jgraham> | Hixie: Only 67kb. I'm disappointed ;) |
| 19:45 | <hsivonen> | Hixie: btw, aria-owns is supposed to address the case where a table has sub-rows but the table markup only allows consecutive rows |
| 19:48 | <hsivonen> | Hixie: did you talk markp into removing his summary attributes? |
| 19:49 | hsivonen | is almost sure there were summary='' instances on diveintomark a while ago |
| 21:05 | <Hixie> | hsivonen: no, but i doubt he'd be hard to convince :-) |
| 21:17 | <Hixie> | well that didn't take long... |
| 21:17 | <Hixie> | (re: www-archive/html4all) |
| 21:28 | <Lachy_> | wow, I'm surprised I ever said abbr="" should be retained. It's interesting how my opinion changed in the last 2 years |
| 21:32 | <gsnedders> | abbr=""? what's that? |
| 21:33 | <gsnedders> | when the top hit on google is actually the spec and not some tutorial, you know you're off to a bad start |
| 21:33 | <gsnedders> | what a pointless attribute. |
| 21:34 | <webben_> | Hixie: Does HTML5 have a way to a "provide a brief overview of how a data table is organized or a brief explanation of how to navigate the table", making "the information available to people who use screen readers" without displaying the information visually ( quotes from http://www.w3.org/TR/WCAG20-TECHS/H73.html )? |
| 21:34 | <webben_> | gsnedders: If you're trying to reduce table verbosity abbr can be useful. |
| 21:35 | <Hixie> | webben_: I don't understand why you would want to discriminate against people who can see. <p> fulfills the rest of the use case. |
| 21:36 | <Hixie> | any whatwgers got ssb brawl? |
| 21:36 | <webben_> | Hixie: That assumes that the information is useful to people who can see. |
| 21:36 | <webben_> | If it's useful to people who can see, it shouldn't be in summary. |
| 21:36 | <Hixie> | webben_: why would it not be? |
| 21:36 | <webben_> | Why would it be? |
| 21:38 | <webben_> | Hixie: e.g. in the WCAG example, is that information useful to people who can see? |
| 21:38 | <webben_> | at least assuming "Schedule for Route 7 going downtown" is obvious looking elsewhere on the page |
| 21:39 | <Lachy_> | Hixie, what's "ssb brawl"? |
| 21:39 | <Hixie> | sorry, playing brawl right now, can't look at the web :-) |
| 21:39 | <Hixie> | Lachy_: wii game |
| 21:39 | <Hixie> | Lachy_: i'm playing with allan |
| 21:40 | <takkaria> | webben_: I would say that information is useful for sighted users as well |
| 21:40 | <BenMillard> | the abbr attribute provides a short form of the headers in a data table |
| 21:41 | <BenMillard> | it would be useful in flexible layouts, as the short form could be disabled if the columns got too narrow for the long form |
| 21:41 | <webben_> | takkaria: So you reckon sighted people would need that explanation above the table (say) in order to understand it? |
| 21:42 | <BenMillard> | it's also intended to reduce the pain of long headers being repeated in the aural rendering of data tables |
| 21:43 | <BenMillard> | only 1 table in my survey used it |
| 21:44 | <BenMillard> | people who don't care enough about users to write short table header text probably don't care enough to write short table header text in a special attribute as well as their long table header text |
| 21:44 | <webben_> | I used abbr to try and cut down the verbosity of some of the tables in the Yahoo! UK Funds Centre: http://uk.biz.yahoo.com/16/sector.html |
| 21:44 | <webben_> | e.g. "Quartile Rank over 1 Year" => "Rank over 1 Year" |
| 21:45 | <webben_> | it's not much, but if it helps a little it's worthwhile |
| 21:47 | <takkaria> | webben_: I don't they need it, no, but it's a useful summary |
| 21:47 | <takkaria> | I don't see it doing any harm to sighted people |
| 21:48 | <takkaria> | the quick summary of the service times would be useful, for example |
| 21:48 | <hsivonen> | It turns out that trying to figure what makes sense when integratating HTML5 and ARIA is non-obvious |
| 21:49 | <hsivonen> | it would be much easier to leave it unspecified and make it Someone Else's Problem |
| 21:49 | <othermaciej> | hsivonen: if you take a baseline assumption of "ARIA always wins over native markup role, on a property-by-property basis", what else needs to be specified? |
| 21:49 | <othermaciej> | (honest question - I am not sure) |
| 21:50 | <Hixie> | that's a terrible design |
| 21:51 | <hsivonen> | othermaciej: I am assuming that it is a bad idea to let document conformance allow override of strong native semantics |
| 21:51 | <othermaciej> | Hixie: that is how the ARIA guys say it should work - it certainly has the advantage of being easy to implement |
| 21:51 | <hsivonen> | othermaciej: more importantly, there are some native semantics that could be augmented with states and properties |
| 21:52 | <othermaciej> | hsivonen: it does seem to me like a more careful integration design would not let use use anything but an <h?> element for a header, or let you make a checkbox appear to AT to be a radio button |
| 21:52 | <Hixie> | othermaciej: it's also a horrific abuse of semantics |
| 21:52 | <hsivonen> | othermaciej: and requiring a role in that case would just be silly |
| 21:52 | <hsivonen> | othermaciej: for example, I think <th> should allow aria-sort without having a role |
| 21:53 | <othermaciej> | hsivonen: aaron's statement on this (not sure it should be taken as official, since it was just an offhand remark on a list) is that it should work property by property, even if no explicit role is set |
| 21:53 | <othermaciej> | and that in fact, on elements that would have "native" state like a checkbox, it should show through even if you set the role to something else |
| 21:53 | <BenMillard> | hsivonen, you have an informal list of ARIA stuff which can be inferred for HTML5 elements? maybe create a document listing all the ARIA stuff which can be inferred by default |
| 21:53 | <othermaciej> | as an implementor I am pleased, as an architect I find this design distasteful |
| 21:53 | <othermaciej> | BenMillard: a list like that would be great |
| 21:54 | <hsivonen> | BenMillard: I'm writing the list right now |
| 21:54 | <othermaciej> | BenMillard: ARIA guys did not seem to think having one was very important |
| 21:54 | <webben_> | takkaria: Yes. That's a reasonable argument for removing some of that text from SUMMARY (although there's a risk of swamping the page in explanatory text). Whether designers would be persuaded that enough sighted users would be helped if it were included is a different matter; persuading designers to include some text that doesn't mess with their design is likely to be easier. (Of course, if sighted users are /equally/ helped then there's no argument that it sh |
| 21:54 | <othermaciej> | FWIW we are seriously considering implementing ARIA in WebKit soon, the only thing that makes me hesitate is HTML integration issues (not just HTML5 but even just HTML4 stuff) |
| 21:55 | <BenMillard> | yay, a useful contribution. with that I'll depart for dinner...cya! |
| 21:56 | <hsivonen> | othermaciej: the ARIA spec is written to allow certain states and properties with certain roles |
| 21:56 | <hsivonen> | othermaciej: so if Validator.nu only allowed those, it would proclaim <th aria-sort=ascending> as non-conforming |
| 21:56 | <othermaciej> | hsivonen: I see |
| 21:57 | <hsivonen> | and since I don't want to allow just any random stuff, this requires thinking |
| 21:57 | <othermaciej> | hsivonen: so even if the implementation is as I said, perhaps it would make sense to change conformance to take into account implied roles, and to perhaps in some cases make override of native role non-conforming |
| 21:57 | <hsivonen> | and the questions that thinking about this turns up are don't all have obvious answers |
| 21:58 | <othermaciej> | At least some of the WAI folks were very sympathetic to the argument that ARIA should not supersede or discourage proper semantic markup where that would work for the intended use |
| 21:58 | <hsivonen> | othermaciej: right. and someone has to figure that out |
| 21:58 | <hsivonen> | othermaciej: their best practice doc doesn't follow that policy |
| 22:00 | <othermaciej> | hsivonen: I wouldn't say all agree with it, and I don't think any of them has tried to fully think through the implications of such a policy |
| 22:20 | hsivonen | is puzzled with the assertion that people think 0 is positive |
| 22:21 | <Hixie> | wtf is aria-sort=ascending and why doesn't it just apply generally? |
| 22:22 | <Hixie> | as in, why is it an "aria" thing |
| 22:22 | <hsivonen> | Hixie: it makes a claim to the AT that a table column is sorted in an ascending order |
| 22:22 | <hsivonen> | it doesn't actually sort it |
| 22:22 | <webben_> | I'd assume because it's easy to tell at a glance whether something is sorted alphabetically if you can see it. |
| 22:22 | <Hixie> | hsivonen: ok so why don't we just have a "sort-order" attribute? |
| 22:23 | <webben_> | why don't you? |
| 22:23 | <hsivonen> | Hixie: because the whole ARIA thing assumes that whoever defines HTML is unresponsive and they have to do their thing in their own syntactic partition |
| 22:23 | <Hixie> | that's not going to fly well if they want it integrated with html5 |
| 22:23 | <hsivonen> | Hixie: also, ARIA assumes that the host language space is wider than HTML+SVG |
| 22:24 | <Hixie> | ah, overgeneralisation syndrome |
| 22:24 | <Hixie> | typical of w3c |
| 22:24 | <hsivonen> | yeah |
| 22:24 | <hsivonen> | in an ideal world, the language space would be clamped to HTML and SVG and the HTML WG and the SVG WG would be responsive |
| 22:25 | <Hixie> | i'm still baffled by this concept of wanting to annotate parts of svg with aria roles |
| 22:25 | <webben_> | well, people want to build controls out of SVG |
| 22:25 | <webben_> | so it's much the same as building controls out of divs and annotating those, I should think |
| 22:25 | <Hixie> | controls is one thing |
| 22:26 | <Hixie> | marking things as tables with a sort order is something else |
| 22:26 | <webben_> | If you're going to build controls out of SVG, why not tables too? |
| 22:26 | <Hixie> | because that's what <html:table> is for? |
| 22:27 | <hsivonen> | Hixie: also, one of the tacit assumptions of ARIA is that the a significant proportion of browsers is uncooperative |
| 22:27 | <Hixie> | seems to me that the underlying assumptions of the aria work are out of date |
| 22:27 | <hsivonen> | which doesn't hold for ARIA anymore but still holds for XBL2 |
| 22:28 | <Hixie> | how so? |
| 22:28 | <webben_> | Hixie: Dunno. It's like people building text in Flash I'd suppose. |
| 22:29 | <hsivonen> | Hixie: there's no indication of Microsoft wanting to implement XBL2, as far as I can tell |
| 22:29 | <webben_> | Hixie: or Canvas |
| 22:29 | <Hixie> | webben_: yes, it's exactly like that. and people building text out of flash (or tables out of svg) have already given up on accessibility, so why is providing aria attributes going to help? |
| 22:29 | <Hixie> | it's like people who want new features in spec to work around bugs in browsers |
| 22:30 | <Hixie> | hsivonen: microsoft never indicate anything. |
| 22:30 | <Hixie> | hsivonen: (of this kind of stuff) |
| 22:30 | <webben_> | Hixie: I'm not sure they have given up on accessibility. I think they're more likely to be privileging something else over accessibility. |
| 22:30 | <othermaciej> | building tables out of SVG seems like a weird concept |
| 22:30 | <hsivonen> | Hixie: right, so ARIA takes a strategy that works regardless of what MS does |
| 22:30 | <hsivonen> | Hixie: but then in this case it turns out that they implement it as well |
| 22:30 | <othermaciej> | on the other hand, at least some SVG-related thinking is based on the premise that your whole UI is SVG |
| 22:30 | <hsivonen> | Hixie: but that wasn't necessary for ARIA to be useful elsewhere |
| 22:31 | <Hixie> | hsivonen: i don't see how any of the dumb things in aria have anything to do with whether ms implements aria or not |
| 22:31 | <webben_> | othermaciej: exactly |
| 22:31 | <othermaciej> | I would rather stab myself in the eye with a fork than implement table layout using SVG |
| 22:32 | <hsivonen> | Hixie: the general idea of putting AT integration away in attributes instead of requiring new elements like <progress> and <datagrid> works without Microsoft's participation |
| 22:32 | <webben_> | othermaciej: already done I think: http://thomas.tanreisoftware.com/?p=42 |
| 22:32 | <hsivonen> | Hixie: the specifics of ARIA are specifics |
| 22:32 | <webben_> | (the implementing, not the eye-fork-stabbing ;) ) |
| 22:32 | <hsivonen> | Hixie: there are a number of specifics I quite dislike |
| 22:32 | <Hixie> | hsivonen: dude. <table> isn't new. |
| 22:32 | <othermaciej> | webben_: I read the phrase "SVG flow layout engine" and closed the window |
| 22:32 | <webben_> | hehe |
| 22:32 | <hsivonen> | Hixie: that's one part I seriously dislike |
| 22:33 | <hsivonen> | Hixie: to me, it makes no sense to have that there |
| 22:33 | <Hixie> | same with the header stuff |
| 22:34 | <othermaciej> | certainly some roles seem redundant in HTML |
| 22:34 | <othermaciej> | HTML4, not just 5 |
| 22:34 | <othermaciej> | I can see why, if you are a crazy AJAX guy, you might want to pretend a <div> is a checkbox |
| 22:34 | <othermaciej> | but not why you would want to pretend it is a table or header |
| 22:34 | <hsivonen> | Hixie: I already complained about the header "best practice" stuff |
| 22:34 | <othermaciej> | you can already customize the presentation of the real elements for those as much as you want |
| 22:34 | <hsivonen> | Hixie: tomorrow, I'm going to complain about the table stuff |
| 22:35 | <webben_> | othermaciej: not really |
| 22:35 | <hsivonen> | Hixie: and about templateid |
| 22:35 | <webben_> | not in current browsers anyway |
| 22:35 | <webben_> | there are more bugs with styling table elements than divs |
| 22:35 | <othermaciej> | webben_: h1 can be customized just as much as div |
| 22:35 | <webben_> | othermaciej: h1 probably can yes |
| 22:35 | <othermaciej> | table does imply row/cell structure |
| 22:35 | <hsivonen> | Hixie: I also want to complain about aria-owns, but I predict it is too late to fix that one in this browser release cycle |
| 22:36 | <hsivonen> | aria-owns scares me |
| 22:36 | <othermaciej> | but if you have something that does not follow that row/cell structure, how is it a table? |
| 22:36 | <othermaciej> | what is aria-owns? |
| 22:36 | <hsivonen> | othermaciej: aria-owns overrides the parent-child relationship induced by tree containment |
| 22:36 | <othermaciej> | does it replace it or add to it? |
| 22:36 | <hsivonen> | othermaciej: the scary part is that since it overrides what children a parent has, it can make cycles |
| 22:37 | <hsivonen> | letting the child point to a single new parent would be safer |
| 22:37 | <hsivonen> | othermaciej: I think it is supposed to replace the normal containment when computing what to tell AT |
| 22:37 | <othermaciej> | that's kind of a pain |
| 22:38 | <hsivonen> | my work would be much simpler without aria-owns |
| 22:38 | <othermaciej> | since to report children to AT, you have to know about all aria-owns attributes everywhere in the document |
| 22:39 | <hsivonen> | besides, I think the problem aria-owns is supposed to solve could be solved in a less disruptive way |
| 22:39 | <hsivonen> | the stated problem is that table has a flat list of rows |
| 22:39 | <hsivonen> | and aria-owns makes it possible to make some rows children of other rows |
| 22:40 | <hsivonen> | I think aria-level could be tweaked to solve that |
| 22:40 | <othermaciej> | so you can fake an outline view with a table? |
| 22:40 | <hsivonen> | right |
| 22:40 | <hsivonen> | like <datagrid> |
| 23:22 | <Hixie> | the links in http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-June/006498.html suggest that maybe presentational mathml is not an accessibility problem after all |
| 23:30 | <webben_> | Hixie: also http://firevox.clcworld.net/features.html |
| 23:34 | <webben_> | I'd guess http://www.nfbnet.org/mailman/listinfo/blindmath would be good folks to ask though |