| 04:37 | <heycam> | Hixie, i'd use sequence<any> rather than sequence<Object> for executeSql() |
| 04:38 | <heycam> | to avoid unnecessary conversions of Number/String/etc. values to their object equivalents |
| 05:52 | <Hixie> | heycam: can you send me that by e-mail? i'm in the middle of the namespace stuff right now |
| 06:12 | <heycam> | Hixie, ok |
| 06:13 | <Hixie> | thanks |
| 06:13 | <Pavlov_> | hrm |
| 06:13 | <Pavlov_> | Hixie: know anyone who knows stuff about css font things? |
| 06:13 | <Pavlov_> | spec things |
| 06:13 | <Hixie> | elaborate? |
| 06:14 | <Pavlov_> | well, for example, opentype doesn't really define font weights very well aside from giving 100-900 names |
| 06:14 | <Pavlov_> | there are a bunch of fonts with weights of say 950 or 1000 |
| 06:14 | <Pavlov_> | (not many with 1000, but a few. quite a few 950s) |
| 06:15 | <Pavlov_> | (and i've seen other x50 ones) |
| 06:16 | <Pavlov_> | just trying to understand what the best thing to do is/if the spec should change |
| 06:17 | <Pavlov_> | like, if i have a 900 and a 1000, i should probably ignore the 1000 (or use it/support it?) but if i don't have a 900 i should probably round the 950/1000 down |
| 06:18 | <Pavlov_> | if i have 100, 150, 200, 250, 300, ... 950 should i support them all? bolder/lighter do what? |
| 06:23 | <Pavlov_> | imho, supporting more than that is feasable |
| 06:23 | <Pavlov_> | like, the spec says "If the font family already uses a numerical scale with nine values (like e.g. OpenType does), the font weights should be mapped directly." |
| 06:24 | <Hixie> | yeah if you have more than 2 weight above bold (700) then the spec just says to drop some |
| 06:24 | <Pavlov_> | except that OpenType doesn't specify just 9 steps |
| 06:24 | <Hixie> | well, 9 weight is probably enough for now -- most pages don't bother with more than 2 levels anyway |
| 06:24 | <Pavlov_> | yeah |
| 06:25 | <Pavlov_> | 1000 is pretty rare |
| 06:25 | <Hixie> | if there really are fonts that have more weights, i would invent keywords -moz-1000, -moz-1100, etc |
| 06:25 | <Pavlov_> | think i've seen 2 fonts with it? |
| 06:25 | <Pavlov_> | 950 is pretty common thouhg |
| 06:25 | <Hixie> | so i would say map the boldest one to 900 |
| 06:25 | <Hixie> | map the main bold one to 700 |
| 06:25 | <Hixie> | and if there are any between those to, map the middle one of those to 800 |
| 06:26 | <Pavlov_> | which direction would you map x50s to if you don't have an exact number for it? |
| 06:26 | <Pavlov_> | like, say you have 100, 250, 400 |
| 06:27 | <Pavlov_> | maybe you map both 200 and 300 to that |
| 06:27 | <Pavlov_> | if you have 100, 200, 350, 400, i guess you could round 350 down |
| 06:28 | <Pavlov_> | and if you have 100, 200, 300, 350, 400, just skip 350? |
| 06:28 | <Hixie> | map the main medium weight to 400 |
| 06:28 | <Hixie> | map the lightest one to 100 |
| 06:29 | <Pavlov_> | i'm saying if i have 5 opentype fonts of the same family that have all 5 of those weights |
| 06:29 | <Pavlov_> | or 3 or 4 of them |
| 06:29 | <Hixie> | then just drop one |
| 06:29 | <Pavlov_> | what should I do with x50 weights? |
| 06:29 | <Pavlov_> | what i suggested? |
| 06:30 | <Hixie> | so, map the main medium weight to 400, the lightest one to 100, and for 200 and 300 just pick some that are equidistant from lightest to medium |
| 06:30 | <Hixie> | soif you just have one extra, just drop one of them, doesn't matter which |
| 06:30 | <Hixie> | i wouldn't map the opentype numbers straight to the 100-900 numbers like the spec says, if you have any x50 weights |
| 06:31 | <Pavlov_> | well, there is no other concept of "main medium weight" face |
| 06:31 | <Pavlov_> | you either have 400 or you don't |
| 06:32 | <Pavlov_> | many bold faces if you treat them as a family only have a 700 weight |
| 06:32 | <Hixie> | i'd just sort them per weight, pin 100, 400 (the "regular" weight), 700 ("bold"), and 900, and fill the others in a linear way so that they are distributed uniformly |
| 06:32 | <Pavlov_> | k |
| 06:32 | <Hixie> | well if you have fewer weights, the spec defines how you fill things in |
| 06:32 | <Pavlov_> | right |
| 06:32 | <Pavlov_> | fewer isn't the problem as much |
| 06:32 | <Hixie> | k |
| 12:42 | <hsivonen> | Hixie: table is no longer in ARIA |
| 16:19 | <hsivonen> | http://blog.ianbicking.org/2008/03/23/html-accessibility/ |
| 16:25 | <jgraham> | http://blog.ianbicking.org/2008/03/23/html-accessibility/#comment-16200 is particularly interesting |
| 16:26 | BenMillard | is reading through |
| 16:30 | <hsivonen> | jgraham: regarding ARIA and outline integration, it seems to me that aria-level may be a bigger issue than role=heading |
| 16:35 | <BenMillard> | comment #7: "the web is filled with bad HTML and we are stuck with it, so let’s learn to deal with it instead of despise it." |
| 16:36 | <BenMillard> | some of it is too broken to work unless authors make adjustments, such as using <td> with no attributes or <b> or <strong> for table headers |
| 16:37 | <BenMillard> | in general, inline-level markup can be anything you want and it will adapt well enough |
| 16:38 | webben | tries to work out how to create a "succint" alt attribute for a complex chart or diagram. |
| 16:39 | <BenMillard> | providing sensible alt for graphical links and buttons is something you can't really get around...unless we require such images to have readable filenames :P |
| 16:41 | <annevk> | hmm, over 600 e-mails |
| 16:43 | hsivonen | has been sending email mostly to http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/ instead of public-html... |
| 16:43 | <annevk> | 80 marked as spam |
| 16:44 | <BenMillard> | http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/author.html#msg54 - hsivonen's messages |
| 16:46 | <annevk> | ah, my e-mail was not just since yesterday though :) |
| 17:12 | <BenMillard> | hsivonen, http://hsivonen.iki.fi/aria-html5/ times out for me (tried 3 times) |
| 17:19 | <annevk> | works now |
| 17:19 | <BenMillard> | yep |
| 17:29 | <jgraham> | hsivonen: <h1 aria-level=2></h1><h2 aria-level=1></h2>? Fun fun fun. |
| 17:30 | <jgraham> | "In many cases the user agent may be able to calculate the level of an item if it can be determined correctly from the document structure. This property may be used to provide an explicit indication of the level if that is not possible from the document structure. User agent automatic support for automatic calculation of level may vary; it is recommended that authors test with user agents and assistive technologies to determine whether this property |
| 17:30 | <jgraham> | is needed." |
| 17:31 | <jgraham> | What kind of spec text is that? |
| 17:32 | <jgraham> | "You might want to consider using this property in some undefined set of circumstances when some undefined other mechanisms for achieving the same thing fail in some undefined set of software you have access to" |
| 17:35 | <jgraham> | Possible steps to fixing this: |
| 17:35 | <BenMillard> | perhaps: "The aria-level property must not be used on elements which are specified to indicate a level natively." |
| 17:35 | <jgraham> | a) identify the set of circimstances in which aria-level is needed |
| 17:36 | <jgraham> | b) try to reduce that set to 0 by adding features to HTML |
| 17:36 | <jgraham> | dunno if that will work though |
| 17:36 | <BenMillard> | followed by: "If it is used on such elements, it is ignored." |
| 17:37 | <webben> | jgraham: Note that if support for those new features trails support for aria-level, web developers may be forced to use both to support older UAs. |
| 17:37 | <jgraham> | webben: Sure |
| 17:39 | <BenMillard> | ARIA is itself a new feature which older UAs don't support, though? |
| 17:39 | <jgraham> | (for some definition of "forced") |
| 17:39 | <jgraham> | BenMillard: Well it looks like ARIA will be supported faster than e.g. <datagrid> |
| 17:39 | <webben> | BenMillard: older UAs being the current crop (IE8, Fx 2-3, Opera 9.5) |
| 17:40 | <webben> | + the current crop of AT of course |
| 17:41 | <jgraham> | webben: The nice thing is that browser upgrade cycles are much faster than AT upgrade cycles. |
| 17:41 | <jgraham> | And exposing e.g. <datagrid> is a browser problem |
| 17:42 | <webben> | jgraham: That doesn't help if the browser upgrades require AT upgrades (as IE7 did, for example) |
| 17:42 | <jgraham> | That sucks. I assumed they all used these standard APIs. |
| 17:43 | <webben> | if all that changed between releases was the browser recognized more native HTML5 elements and treated them the same as the aria attributes when exposing to accessibility frameworks, all would be well. But that's not all that changes. |
| 17:43 | <webben> | jgraham: Well part of the underlying problem is MSAA is old and crusty; and UI Automation isn't widely used. |
| 17:44 | <webben> | jgraham: And with Apple, you need to upgrade your entire OS to get the full benefits of accessibility improvements in WebKit. |
| 17:44 | <jgraham> | In any case, what BenMillard said is a more viable short-term solution (i.e. change the wording to forbid using aria-level where it isn't appropriate and make native semantics take precedence) |
| 17:44 | <webben> | the most stable system is perhaps GNOME AT-SPI, oddly enough. |
| 17:44 | <webben> | (Firefox3+Orca basically) |
| 17:45 | <webben> | jgraham: But how do you define "where it isn't appropriate" in a way that doesn't exclude using aria attributes for backwards compatibility? |
| 17:45 | <BenMillard> | jgraham, yay a useful contribution. :) |
| 17:45 | <Philip`> | webben: The most stable system is a dead one :-) |
| 17:45 | <jgraham> | the first part of that (conformance criteria) should be easy. The second part (browser behavior) goes against current thinking |
| 17:46 | <webben> | Philip`: well, Apple would be much the same if the upgrades were free. |
| 17:46 | <webben> | but the unfreeness creates a longer upgrade cycle |
| 17:47 | <webben> | jgraham: I can't see the point of forbidding web developers from doing stuff that doesn't break newer browsers and makes old browsers work. It's a dead letter conformance requirement. |
| 17:47 | <jgraham> | webben: What sort of back-compat scenario requires html-headings (for example) to be labelled with explicit aria-levels |
| 17:48 | <webben> | jgraham: Well, the spec could list a specific set of /currently/ widely supported elements not to use it on. |
| 17:48 | <webben> | that's a bit messy though |
| 17:49 | <webben> | jgraham: Oh actually. There might be one. |
| 17:49 | <jgraham> | webben: The problem is that you want a consistent view of the document regardless of whether you view it through AT or through a normal browser |
| 17:49 | <webben> | jgraham: HTML5 changes how headings should be ordered (thanks to section). |
| 17:49 | <webben> | Browsers and AT don't support that yet. |
| 17:49 | <webben> | AFAIK. |
| 17:49 | <annevk> | we should allow text/html with root-<svg> |
| 17:49 | <annevk> | that'd be cool |
| 17:49 | <webben> | If they already support aria-level, then there would be rationale for allowing aria-level on headings. |
| 17:50 | <BenMillard> | webben and jgraham, the important thing for AT users is the text use an element somewhere between <h1> and <h6>. the exact number is less important |
| 17:50 | <BenMillard> | (inclusive) |
| 17:50 | <webben> | BenMillard: It's /less/ important. It's not irrelevant. |
| 17:51 | <webben> | But don't take my word for it: http://video.yahoo.com/video/play?vid=514676 (on importance of heading levels in understanding structure of page) |
| 17:51 | <BenMillard> | I saw that months ago, thanks :) |
| 17:52 | <BenMillard> | considering how rare it is for content to use *any* heading element, we should not forget what's important |
| 17:52 | <webben> | I see no reason as a web developer to make content less accessible in order to satisfy arbitrary conformance criteria. |
| 17:52 | <BenMillard> | me neither. do you have any examples where that is happening? |
| 17:53 | <webben> | BenMillard: I just posited one. |
| 17:53 | <jgraham> | webben: The conformance criteria aren't arbitrary. It's needed for logical consistency. |
| 17:54 | webben | doesn't really see how. |
| 17:54 | <webben> | I'm more worried about the logical inconsistency between heading levels in different versions of HTML, myself. |
| 17:55 | <webben> | Sounds like aria-level would provide a way to work around that. |
| 17:55 | <jgraham> | I suppose theoretically you could make the criteria "aria-level used on heading elements must produce an outline structure that is identical to that produced by the html5 algorithm" |
| 17:55 | <jgraham> | but hsivonen might kill you ;) |
| 17:56 | <webben> | I think we're in different countries, so I'm probably safe for the moment. ;) |
| 17:56 | <jgraham> | webben: There is no logical inconsistency between HTML versions |
| 17:56 | <jgraham> | HTML4 had no structure |
| 17:56 | <jgraham> | except one that you inferred the authors probably meant |
| 17:56 | <webben> | It didn't have "no structure". |
| 17:57 | <webben> | Certainly not once you take WCAG and actual implementations into account. |
| 17:57 | <BenMillard> | webben, if you want backward-compatible headings (as do I) you just choose the correct number for each heading (whatever your feeling of "correct number" is). there is no need for aria-level in this respect, afaict. |
| 17:57 | <jgraham> | webben: There is no text anywhere in HTML 4 that says what heading structure <h1>, |
| 17:57 | <jgraham> | erm.. |
| 17:57 | <jgraham> | <h1><h2> corresponds to, let alone <h2><h1><h6~> |
| 17:57 | <jgraham> | s/~// |
| 17:58 | <webben> | BenMillard: Yeah, I'd believe that more if HTML5 authorial conformance criteria required Hx headings to be used that way. |
| 17:59 | <webben> | jgraham: "There are six levels of headings in HTML with H1 as the most important and H6 as the least." (http://www.w3.org/TR/html401/struct/global.html#edef-H1) |
| 17:59 | <jgraham> | define "important" |
| 17:59 | <jgraham> | many web authors think headings in side bars are "less important" |
| 17:59 | <webben> | define "structure" |
| 17:59 | <jgraham> | eh? |
| 17:59 | <webben> | Headings in side bars may well be less important. |
| 18:00 | <webben> | And to that extent, putting them at a lower level is fine. |
| 18:00 | <jgraham> | I guess I should have said "outline structure" |
| 18:01 | <Philip`> | BenMillard: "considering how rare it is for content to use *any* heading element" - I see <h1> on over a fifth of pages, so it doesn't seem that rare |
| 18:01 | <webben> | Does HTML5 say that h1s in different positions of the "outline structure" have the same "importance"? Are the notions of "importance" and "outline structure" incompatible anyways? |
| 18:01 | <jgraham> | Which I define as a tree-like view of the document in which only the text of headings is visible and the headings of subsections are children of their parent headings (and probably some more stuff to deal with siblings) |
| 18:02 | <BenMillard> | Philip`, that means it isn't used on somewhere nera 80% of pages, then. :) |
| 18:02 | <jgraham> | webben: The problem with having "less important" headings in sidebars is that it breaks this outline view |
| 18:02 | <jgraham> | So putting them at a lower level isn't fine |
| 18:02 | <webben> | jgraham: That's debatable. |
| 18:03 | <webben> | It's not ideal, sure. |
| 18:03 | <Philip`> | BenMillard: Compared to most other HTML features, that's hugely popular :-) |
| 18:03 | <webben> | But I don't think it breaks the view. |
| 18:03 | <jgraham> | webben: That's not what I found |
| 18:04 | <webben> | what was your test for breakage? |
| 18:04 | <BenMillard> | Philip`, consider it's popularity from a user's perspective: 80% of the time they can't get around the page easily |
| 18:04 | <BenMillard> | fixing that 80% so they use heading elements *at all* is the priority, as I see it |
| 18:05 | <webben> | BenMillard: That doesn't follow necessarily. Maybe they just stick with webpages that are coded better. |
| 18:05 | <a-ja> | hsivonen: ping |
| 18:05 | <BenMillard> | webben, the research I want to do into use of headings on the web would throw light on this. haven't quite secured sponsorship for it, yet |
| 18:06 | <BenMillard> | despite taking this whole month off work, I might add :( |
| 18:06 | <webben> | BenMillard: Well, good luck getting sponsorship from whomever you're trying to get it from :) |
| 18:08 | <jgraham> | webben: My test for breakage was whether it made sense in my Firefox outliner extension |
| 18:08 | <webben> | jgraham: I think I more meant your test for "making sense" then ;) |
| 18:08 | <Philip`> | BenMillard: Hmm, how much harder does a lack of headings make it to use a page? (I'm wondering if that's more/less of a problem than ~50% of images not using alt) |
| 18:08 | <webben> | Philip`: That very much depends on the complexity of the page doesn't it? |
| 18:09 | <webben> | (and what /else/ is on the page to navigate by) |
| 18:09 | <webben> | (oh and what else the user knows (s)he can navigate by) |
| 18:09 | <jgraham> | webben: Well the harshest test is whether there was ever a "subsection" in the outline that clearly wasn't a logical child of the parent |
| 18:09 | <BenMillard> | Philip` and webben, absence of headings is similarly problematic to absence of sensible alt |
| 18:09 | <Philip`> | webben: That sounds sensible; I've got no idea how that works out in practice, though |
| 18:10 | <jgraham> | That often happened when the sidebar came out as a child of the last "content" section |
| 18:11 | <webben> | jgraham: Was the sidebar only a sidebar to the last content section? |
| 18:11 | <webben> | If not, maybe the choice of level didn't really reflect its importance |
| 18:11 | <jgraham> | No, to the whole page |
| 18:11 | <jgraham> | Also, things around the page header often broke |
| 18:12 | <jgraham> | with subtitles often causing confusion |
| 18:12 | <BenMillard> | http://projectcerbera.com/web/articles/heading-numbers - this article I wrote was well received by website developers on Accessify Forum. |
| 18:12 | <BenMillard> | Basically, authors interpret the vague specs differently. So I think a strict, tree-based outline algorithm is doomed to failure for web content, sadly. |
| 18:12 | <webben> | Philip`: Well, in the simplest case, if you only have one heading on a gallery page, alt is going to be more crucial than <h1> |
| 18:13 | <webben> | Yeah, I don't think strict, tree-based algorithms need to be 100% successful for the lousy semantics established by HTML4 and common practice to be useful |
| 18:14 | <BenMillard> | I think we should let authors use heading numbers however they want, because at least they're actually using heading elements that way |
| 18:15 | <webben> | If using heading numbers in some sort of meaningful logic helps, I don't see any reason to do that. |
| 18:15 | <webben> | in practice, authors are going to make mistakes anyways |
| 18:15 | <BenMillard> | encouraging them to be consistent throughout the website is wortwhile, as WCAG 1.0 requires |
| 18:16 | <jgraham> | In principle HTML 5 solves all these problems with <section> and <header> |
| 18:16 | <BenMillard> | you trust authors to get that right? I wouldn't :) |
| 18:17 | <jgraham> | BenMillard: No, but at least the results when they get it wrong will be well defined |
| 18:18 | <jgraham> | So it will be wrong in the same way for everyone - easier for people to complain, easier for a conformance checker to provide an outline view |
| 18:18 | <jgraham> | (or an accessibility checker, for that matter) |
| 18:18 | <webben> | BenMillard: If Joe Bloggs gets it wrong on a minor website, it's less crucial than Google, Yahoo!, MSN, the New York Times, the BBC etc getting it right on theirs. |
| 18:19 | <webben> | because people spend more time on big websites than small ones |
| 18:20 | <BenMillard> | more people use one big website than use one small website. the time each person spends on each website is random |
| 18:20 | <BenMillard> | I hardly spend any time on big websites, for example |
| 18:20 | <webben> | BenMillard: I don't think that's typical. |
| 18:20 | <webben> | Don't know of any market research to back that up off-hand though. |
| 18:21 | <BenMillard> | webben, are you saying I'm weird? |
| 18:21 | <BenMillard> | actually don't answer that... |
| 18:21 | <webben> | BenMillard: No! :) |
| 18:21 | <webben> | just a different "demographic" ;) |
| 18:22 | <webben> | somebody must have done some actual research on this though |
| 18:23 | <BenMillard> | the goal is to make *every* website accessible as soon as possible? |
| 18:23 | <jgraham> | http://blog.compete.com/2007/01/25/top-20-websites-ranked-by-time-spent/ |
| 18:24 | jgraham | postulates that facebook has risen somewhat |
| 18:24 | <webben> | jgraham: Hmm... is that collective time. |
| 18:24 | <webben> | Because that's slightly different. |
| 18:25 | <jgraham> | webben: It's hard to see how to get meaningful data without averaging large groups |
| 18:25 | <webben> | "Read as: Of all time spent online by all US Internet users" |
| 18:25 | <webben> | jgraham: sure, but that's still measuring something very different. |
| 18:25 | <jgraham> | Unless you start trying to subdivide the data based on real/imagined patterns |
| 18:25 | <webben> | what one would want to do is establish which sites are big, then average how much time is actually spent on those by each person. |
| 18:26 | <webben> | so let's say myspace is big |
| 18:26 | <webben> | but how much time does the average person spend on Myspace (as opposed to everywhere else) |
| 18:26 | <jgraham> | How do you define "big" in an independent way? |
| 18:26 | <BenMillard> | hang on, we are trying to make *everything* accessible. not just the big, time-consuming sites? |
| 18:26 | <webben> | jgraham: It can be arbitrarily defined, e.g. top 100 websites by traffic |
| 18:26 | <webben> | jgraham: might get better if you subgrouped more |
| 18:27 | <webben> | e.g. maybe everyone spend's most of their time on like 10 websites. |
| 18:27 | <webben> | BenMillard: Yes. But that doesn't mean the accessibility of every site is equally important. |
| 18:28 | <jgraham> | So one definition which would fit handily with the data that I happened to turn up is that we define "bigness" by time spent and define "big" sites to be those which are in the top 20 by bigness. If we do that we find that 39% of all time is spent on big sites |
| 18:28 | <jgraham> | ;) |
| 18:28 | <webben> | BenMillard: So one wouldn't needn't get too depressed by figures suggesting inaccessibility is widespread in absolute terms. |
| 18:29 | <webben> | BenMillard: But would need to get very depressed by figures showing inaccessibility is common on highly popular sites (which of course it is). |
| 18:29 | <BenMillard> | in practice, site owners decide if accessibility is important enough to them to pay for it |
| 18:30 | <webben> | Well sure, but only if the developers charge them extra for it. |
| 18:30 | <webben> | Rather than just doing it right. |
| 18:30 | <BenMillard> | FWIW, sdesign1, the company I work for, doesn't charge extra for accessibility |
| 18:30 | <jgraham> | webben: Arguably technologies like aria encourage that because doing it right is considerably more effort than just doing it |
| 18:31 | <BenMillard> | prioritising the important things, like using heading elements at all, is what site owners need to know about |
| 18:31 | <webben> | (There are edge cases where that's not the case, where site owners need to stump up for accessible content though) |
| 18:31 | <webben> | jgraham: ARIA was mainly designed to build accessibility into div-based widgets systems. |
| 18:31 | <webben> | Once built into those systems (like Dojo), the cost of using an ARIA-fied widget is the same as using a non-ARIA-fied widget. |
| 18:32 | <jgraham> | webben: I know. Your argument works iff everyone is using off-the-shelf widgets |
| 18:32 | <webben> | people who actually build widgets are already a very select grouo |
| 18:32 | <webben> | *group |
| 18:33 | <BenMillard> | I've used widgets. they are built terribly, on the whole |
| 18:33 | <jgraham> | Does e.g. the new bbc design use entirely off the shelf widgets? |
| 18:33 | <webben> | I wouldn't /expect/ the BBC design to use entirely off-the shelf widgets. |
| 18:33 | <webben> | I'd expect Joe Bloggs building his intranet app in a hurry to use them etc |
| 18:35 | <webben> | I'd expect the BBC to be the sort of place which would hire web developers who could build custom widget sets. |
| 18:35 | <jgraham> | I'm sure the bbc, in particular, is since they have a very strong commitment to such things |
| 18:36 | <BenMillard> | expectations are irrelevant. resistance is futile. you will be laid out in a <table> |
| 18:36 | <BenMillard> | if HTML5 makes accessibility seem hard, that will just put people off |
| 18:36 | <BenMillard> | we need basic accessibility to be dead simple |
| 18:36 | <BenMillard> | refined accessibility can be harder, if necessary |
| 18:36 | <webben> | There's no point in making accessibility seem simpler than it is. |
| 18:37 | <webben> | I do see your point about quick wins. |
| 18:37 | <webben> | But I don't think the place to encourage quick wins is in the conformance criteria. |
| 18:37 | <webben> | Most people don't care about conformance criteria. |
| 18:38 | jgraham | suggests there is a high correlation between caring about conformance criteria and caring about accessibility |
| 18:38 | <webben> | sure. |
| 18:38 | <BenMillard> | caring about either is rare |
| 18:38 | <jgraham> | Not that I have evidence to back that up or anthing |
| 18:38 | <webben> | but people who really care about accessibility aren't going to be put off because it needs thinking |
| 18:38 | <BenMillard> | we need accessibility to be more accessible :) |
| 18:38 | <webben> | Hmm maybe. |
| 18:39 | <jgraham> | webben: Not true. People might want to be accessible but fail because it's too hard |
| 18:39 | <webben> | The biggest obstacles to making stuff accessible tend to be further down the chain though. |
| 18:39 | <webben> | e.g. "What? Blind people can use computers? But how?" etc |
| 18:39 | <jgraham> | which way is down? |
| 18:39 | <BenMillard> | s/down the chain/up the chain, imho |
| 18:39 | <BenMillard> | i.e. managers rather than developers |
| 18:40 | <webben> | jgraham: Down is managers/commissioners of websites. Down is a million miles away from the spec and conformance criteria and the HTML. |
| 18:40 | <jgraham> | and up is users? |
| 18:40 | <webben> | no up is implementors, developers, testers |
| 18:40 | <webben> | and the spec and the code |
| 18:41 | <jgraham> | where are users in this chain |
| 18:41 | <jgraham> | Where is AT? |
| 18:41 | <webben> | they're not. |
| 18:41 | <jgraham> | Browsers? |
| 18:41 | <webben> | (users aren't anyhow) |
| 18:41 | jgraham | envisioned a chain connecting content to users |
| 18:41 | <webben> | I'd say for AT and browsers there's a similar chain. |
| 18:41 | <BenMillard> | ah, I think webben is talking about the process of building websites, rather than the process of using websites? |
| 18:41 | <BenMillard> | and that these are 2 different chains? |
| 18:41 | <webben> | Sorry, yeah, I thought we all were. |
| 18:42 | <BenMillard> | my approach to building websites involves users, which is what threw me |
| 18:42 | jgraham | suggests a chain is too 1D |
| 18:42 | <webben> | jgraham: If you're talking about, the end-product (users being able to access content/functionality) then yes. |
| 18:43 | <webben> | users/disability organizations/governments/AT/browsers/operating systems - all sorts of factors |
| 18:44 | <webben> | Also, down is in people's level of interest. A lot of sitepoint comments on the target case were from apparent webdevs surprised/outraged that blind people can use the internet. |
| 18:45 | <webben> | *down is people's level of knowledge rather. |
| 18:45 | <webben> | remembering that a lot of people developing websites aren't very interested in the front-end |
| 18:47 | <BenMillard> | making accessibility seem like a grand and difficult struggle puts devs off, in my experience (I am often contracted by other companies) |
| 18:48 | <BenMillard> | showing a code sample where <p><font size face><span style><b> is replaced by <h1> has a more positive reaction |
| 18:48 | <webben> | I don't think accessibility has to be made grand and difficult. |
| 18:48 | <webben> | Actually, I'm not sure accessibility at the HTML level is /that/ difficult. |
| 18:49 | <webben> | it gets a lot trickier with scripting and CSS. |
| 18:49 | <webben> | and there's only a limited amount HTML5 can do about either. |
| 18:50 | <gsnedders> | We need CSS5 and ECMAScript5. |
| 18:50 | <webben> | gsnedders: Well, a lot of accessibility problems produced through CSS derive from implementations. |
| 18:51 | gsnedders | closes implied sarcasm element |
| 18:52 | <BenMillard> | Hixie's e-mail "several messages about tables and related subjects" says: "I also looked in detail at the information that Ben and James provided, which was incredibly useful." yay us! |
| 18:52 | <jgraham> | :) |
| 18:52 | <webben> | scripting ... well maybe if HTML5 comes up with a nice solution for exposing shortcuts to functionality or something. |
| 19:07 | <annevk> | hsivonen, http://hsivonen.iki.fi/rdf/ s/is assumes/assumes/ |
| 19:18 | <jgraham> | http://www.openplans.org/projects/opencore/blog/2008/03/24/accessibility-on-our-site/ does he just have something wrong with his NVDA installation? |
| 19:19 | <jgraham> | s/just/"just"/ |
| 19:30 | <andersca> | Hixie? |
| 19:39 | <webben> | jgraham: he helpfully doesn't say what version he's using |
| 19:40 | <jgraham> | webben: I would presume he just got 0.5 |
| 19:45 | <hsivonen> | a-ja: pong |
| 19:45 | <a-ja> | hi henri |
| 19:46 | <a-ja> | hsivonen: re: your "ARIA in HTML5" strawman "Strong Native Role—No Override" section |
| 19:46 | <a-ja> | thing like article only allowing region, e.g. |
| 19:47 | <a-ja> | should those also be allowed the "landmark" roles? |
| 19:47 | <a-ja> | like main or secondary? |
| 19:47 | <Hixie> | andersca: here |
| 19:47 | <Hixie> | BenMillard: i don't believe i've ever looked at so many tables before :-) |
| 19:48 | <Hixie> | BenMillard: i ended up covering two whiteboards with little table diagrams |
| 19:48 | <andersca> | Hixie: correct me if I'm wrong, but |
| 19:48 | <andersca> | Hixie: manifest lines can't have leading whitespace, right? |
| 19:49 | <BenMillard> | hixie, I can well imagine! |
| 19:49 | <hsivonen> | a-ja: I don't know. |
| 19:49 | <a-ja> | possibly secondary for aside, e.g. vs just note possible? |
| 19:49 | <hsivonen> | a-ja: could make sense. I'm not sure. |
| 19:49 | <BenMillard> | hixie, I think I looked at thousands overall because I wanted to see how consistent each site was |
| 19:50 | <andersca> | Hixie: brb |
| 19:50 | <hsivonen> | a-ja: in any case, I think eventually a good outcome is that if the landmarks are really important, they have native HTML5 elements |
| 19:50 | <Hixie> | BenMillard: thanks for that, it made my life much easier :-) |
| 19:50 | <hsivonen> | a-ja: those would be good questions to raise on the public-html and public-pfwg-comments lists |
| 19:51 | <BenMillard> | hixie, I'm happy to be useful. not bad for a noob :P |
| 19:51 | <hsivonen> | a-ja: the problem is that the landmarks and native HTML5 elements don't have a one-to-one mapping |
| 19:51 | <hsivonen> | a-ja: I gather landmarks are more controversial than ARIA widgets. I wouldn't be surprised if landmarks changed still. |
| 19:52 | <a-ja> | yeah,,,know what you mean |
| 19:52 | <Hixie> | BenMillard: :-) |
| 19:53 | <a-ja> | hsivonen: was it decided one role allowed or multiple? been a while |
| 19:54 | <hsivonen> | a-ja: (I can't associate your IRC nick with an email name) |
| 19:54 | <Hixie> | andersca: 4.6.3.2. Parsing cache manifests |
| 19:54 | <hsivonen> | a-ja: It's only one role per element in ARIA 1.0 |
| 19:54 | <Hixie> | andersca: steps 13 and 15 |
| 19:54 | <hsivonen> | a-ja: multiple values are for later extensions |
| 19:54 | <a-ja> | ajabanyon at gmail |
| 19:54 | <a-ja> | ah |
| 19:55 | <jgraham> | Is there a reasonable mailing list to subscribe to to keep track of aria? |
| 19:55 | <andersca> | Hixie: ah |
| 19:55 | <BenMillard> | hixie, what specifically did you find useful about it? was it just having links to lots of genuine data tables in one place? |
| 19:55 | <hsivonen> | jgraham: public-pfwg-comments |
| 19:55 | <hsivonen> | jgraham: the main list in Member-only |
| 19:56 | <jgraham> | hsivonen: Can you actually subscribe to that? Maybe I've ben misled by the archve page which only had unsubscribe links |
| 19:56 | <jgraham> | s/b en/been/ |
| 19:56 | <hsivonen> | jgraham: I don't know. |
| 19:57 | <hsivonen> | jgraham: I'm not subscribed to any ARIA lists. |
| 19:57 | <hsivonen> | jgraham: I go with CCs and the Web archive interface |
| 19:57 | <jgraham> | The problem with the web archive interface is that it's hard to guess when there will be interesting content |
| 19:57 | <annevk> | I think you can subscribe |
| 19:58 | <andersca> | Hixie: thanks |
| 19:59 | jgraham | tries subscribing |
| 20:00 | <a-ja> | hsivonen: don't think header should necessarily always have banner role....since aisdes/sections/articles can all have header |
| 20:01 | <a-ja> | s/aisdes/asides/ |
| 20:01 | <jgraham> | Well that appears o have worked |
| 20:02 | <Hixie> | BenMillard: that was a big part of it |
| 20:02 | <Hixie> | BenMillard: but also your analyses were useful to clue me in to what was important and useful |
| 20:02 | <hsivonen> | a-ja: what use case does role='header' fulfill that HTML native h1...h6 don't? |
| 20:03 | <Hixie> | BenMillard: also your stats were very useful as a way to quantify the qualitative experience of the many tables and the anecdotal impression of the distribution of the types of tables |
| 20:03 | <annevk> | jgraham, sure? |
| 20:03 | <annevk> | doesn't look like it |
| 20:04 | <a-ja> | well....as container for h1 title, h2 subtitle, p slogan sorta thing |
| 20:04 | <jgraham> | annevk: No, I'm not sure but I got a "reply to this to confirm" type message |
| 20:04 | <BenMillard> | hixie, that's good to know. if/when I do more research, I'll concentrate the resulting document(s) on these useful aspects |
| 20:05 | <Hixie> | BenMillard: awesome |
| 20:07 | <andersca> | Hixie: haha, I had implemented the parser according to your steps and it already handled leading whitespace :) |
| 20:08 | <annevk> | jgraham, ah |
| 20:08 | <Hixie> | andersca: nice |
| 20:09 | <othermaciej> | Hixie: can I give you an acid3 bug report? or should I send mail? |
| 20:09 | <Hixie> | whats the bug report? |
| 20:11 | <othermaciej> | Hixie: test 79, two of the advances are wrong, it expects there to be an advance before the first code point of a surrogate pair and the second |
| 20:11 | <Hixie> | dude, get with the program |
| 20:11 | <othermaciej> | Hixie: the advance should be after the second |
| 20:11 | <Hixie> | i fixed that ages ago |
| 20:11 | <Hixie> | :-P |
| 20:11 | <othermaciej> | oh |
| 20:11 | <othermaciej> | I wasn't sure if Cc-ing you would be enough |
| 20:11 | <Hixie> | (i commented on the bug and everything) |
| 20:11 | <othermaciej> | thanks |
| 20:12 | <Hixie> | actually so long as the bug says "acid" somewhere in the bugmail, it ends up in my inbox |
| 20:12 | <othermaciej> | that test revealed 6 webkit bugs (well, missing features in some cases) |
| 20:12 | <Hixie> | bugmail that doesn't say "acid" anywhere gets read much later |
| 20:12 | <othermaciej> | Hixie: thanks for the fix |
| 20:12 | <Hixie> | np |
| 20:13 | <Hixie> | thank _you_ for finding it! |
| 20:13 | <othermaciej> | that test case is pretty evil |
| 20:13 | <othermaciej> | I mean, not to someone who actually knows anything about SVG or text layout |
| 20:13 | <othermaciej> | but I know very little about either |
| 20:14 | <Hixie> | heh |
| 20:14 | <Hixie> | i didn't write it |
| 20:14 | <Hixie> | though i did introduce the aforementioned error |
| 20:14 | <othermaciej> | Yeah, I gather heycam did originally, I wrongly blamed him for the error |
| 20:17 | Hixie | decides to use a wiki page to note down the problems raised in the namespace folder |
| 20:19 | <jgraham> | Hixie: Some super-secret Hixie wiki or...? |
| 20:19 | <Hixie> | whatwg.org |
| 20:19 | <hsivonen> | a-ja: that use case works with HTML5 <header> but does it work with role=header? |
| 20:21 | <hsivonen> | BenMillard: apparently my server had a maintenance break earlier |
| 20:24 | <a-ja> | hsivonen: i'd think yes for header, no for heading....OIW not all headers are banners, but all banners are headers |
| 20:24 | <hsivonen> | annevk: typo noted. thanks. (I'll fix when connectivity to the server comes back) |
| 20:27 | <Hixie> | http://wiki.whatwg.org/wiki/New_Vocabularies |
| 20:27 | <hsivonen> | a-ja: yeah, the implicit role mappings aren't perfect matches |
| 20:28 | <a-ja> | hsivonen: i'm no ARIA experts by any means though...just a site dev trying to make sense of landmarking mapping to html5 elements |
| 20:29 | <hsivonen> | Actually, I don't like the introduction of the landmark stuff when implementing the HTML5 new landmark containers would be relatively low-hanging fruit |
| 20:29 | <hsivonen> | Hixie: I think typography comes before maintainability when it comes to math markup |
| 20:29 | <hsivonen> | Hixie: maintainability is abstracted behing itex2mml |
| 20:30 | <hsivonen> | behind |
| 20:30 | <Hixie> | it wasn't an ordered list |
| 20:30 | <Hixie> | :-) |
| 20:31 | <Hixie> | and to be honest, i wouldn't necessarily agree that quality comes first |
| 20:31 | <Hixie> | one of the main pieces of feedback i got from the video discussion was that in reality, contrary to common belief, the priority was sustainable frame rate, not video quality |
| 20:31 | davidb | wave to BenMillard |
| 20:31 | <Hixie> | i imagine the same applies here |
| 20:31 | <jgraham> | I think ease-of-creation is paramount and that ease of creation means LaTeX syntax |
| 20:32 | <a-ja> | hsivonen: e.g. been taking hyml4 sites with landmarking incorporated in link rels and trying to shoehorn them to html5 elements with roles instead |
| 20:32 | <jgraham> | (because that's what authors already know) |
| 20:32 | <Hixie> | jgraham: i am continuously amazed that nobody seems to be able to say anything in these discussions without linking the problem with the solution :-) |
| 20:32 | <jgraham> | Hixie: I know. |
| 20:32 | <jgraham> | :-p |
| 20:33 | <jgraham> | OK, let me rephrase. The problem is that the primary body of content authors has no interest in learning a new authoring format to create content. |
| 20:33 | <hsivonen> | a-ja: do you mean using an HTML5 element *and* a role attribute on it? |
| 20:34 | <jgraham> | I don't see how to fully explain that problem without reference to the extant widely known formats |
| 20:34 | <hsivonen> | Hixie: I'm linking the solution to it, because I think one of the problems is minimizing the implementation delta from here to there in certain Web engines |
| 20:35 | <a-ja> | hsivonen: yeah, like role=main on article |
| 20:35 | <a-ja> | instead of link rel=main pointing to a div |
| 20:35 | <Hixie> | hsivonen, jgraham: wiki page updated |
| 20:35 | <jgraham> | In particular ease of authoring doesn't cover the problem I referred to because a new easy format would still not leverage the bias toward the old format |
| 20:35 | <hsivonen> | a-ja: OK. my sense of language design aesthetics revolts at that, but practically speaking we should probably allow explicit declaration of the implicit role |
| 20:36 | <jgraham> | Hixie: I suppose the parenthetical covers it |
| 20:36 | <Hixie> | jgraham: if a new format is easier to author than the known format, including cost of switching, then it'll most likely win |
| 20:37 | <jgraham> | Hixie: Tell that to all the scientists who insist on using Fortran for everything |
| 20:37 | <Hixie> | jgraham: the cost of switching is probably high for them |
| 20:39 | <jgraham> | Indeed. But given the large timescales involved (decades) and the possibility of integrating old and new solutions (by calling old fortran from new whatever) there has to be an element of unwillingness |
| 20:39 | <jgraham> | beyond the purely rational |
| 20:40 | <a-ja> | hsivonen: maybe an outer article needs to automagically have main role, and inner articles secondary, or somesuch...less generic than region |
| 20:41 | <jgraham> | biab |
| 20:41 | <BenMillard> | hsivonen, you say "[...] we should probably allow explicit declaration of the implicit role" but that is likely to make authors think they must always supply it just in case their markup would be too vague if they omit it |
| 20:42 | <hsivonen> | BenMillard: that's why I don't like this landmark stuff at all |
| 20:44 | BenMillard | waves back to davidb, somewhat belated! |
| 20:45 | <BenMillard> | I have an urgent appointment with a cottage pie. bye all! |
| 20:46 | Hixie | blogs on the whatwg blog |
| 20:47 | <hsivonen> | Opera on S60 is already pretty good at guessing what the "main" content is without role=main |
| 20:47 | <hsivonen> | Hixie: typo: tablular |
| 20:48 | <Hixie> | fixed thanks |
| 20:50 | <a-ja> | hsivonen: just curious...screenie of the S60 UI for that, perchance? |
| 20:51 | <hsivonen> | a-ja: I don't know how to take screenshots on S60. the UI is a one-pixel horizontal line in the scrollbar and a keybinding that jumps to that point, to the end and to the start |
| 20:52 | <a-ja> | sounds nice & simple |
| 20:57 | <a-ja> | well, gotta go, too. hope your draft gets feedback from the aria gurus, so discussion to nail some/most of it down can occur in reasonable timeframe |
| 20:57 | <a-ja> | ttfn |
| 20:57 | <hsivonen> | see you |
| 21:02 | <hsivonen> | jgraham__: are you going to send feedback about aria-level? |
| 21:18 | <hsivonen> | it seems to me that ARIA treegrid may kill <datagrid> as a native element |
| 21:19 | <Hixie> | how so? does aria treegrid have any effect on non-screen-reader software? |
| 21:19 | <hsivonen> | I predict the <datagrid> API will resurface as a JS library written on top of HTML <table role=treegrid> |
| 21:19 | <hsivonen> | Hixie: It doesn't but a JS library changing a table would have |
| 21:19 | <Hixie> | i think you've been breathing the accessibility koolaid for too long and have come to the mistaken assumption that most people care about accessibility |
| 21:20 | <Hixie> | and even consider it a priority in any sense |
| 21:20 | <hsivonen> | I think they care about compat with browsers that don't have native <datagrid> |
| 21:20 | <othermaciej> | breathing kool-aid, hah |
| 21:20 | <Hixie> | othermaciej: these days it's distributed in aerosol form |
| 21:20 | <othermaciej> | my impression is that the average content author does not care much about accessibility, *but* |
| 21:21 | <othermaciej> | some people have a business need to have their apps in some way "certified" for accessibility |
| 21:21 | <Hixie> | hsivonen: i'd hope we'd see libraries implement <datagrid>, yes, just like i hope to see the same for WF2 |
| 21:21 | <othermaciej> | for instance for government use |
| 21:22 | <othermaciej> | and toolkit developers therefore want their toolkits to be able to enable compliance |
| 21:23 | <Hixie> | sure |
| 21:23 | <othermaciej> | and browser developers want JS library developers to like them |
| 21:23 | <othermaciej> | sorry about spotty connectivity |
| 21:23 | <Hixie> | sure |
| 21:23 | <Hixie> | but the point is that it's not aria that would drive library development |
| 21:23 | <Hixie> | it might be added on afterwards as an afterthought |
| 21:23 | <othermaciej> | that's basically what drives ARIA, the dependency chain of gov't contract requirements |
| 21:23 | <Hixie> | but that's wholly different |
| 21:23 | <othermaciej> | I don't think anyone would code ARIA-first, no |
| 21:24 | <othermaciej> | but toolkits like Dojo seem hot on adding it |
| 21:24 | <Hixie> | sure |
| 21:24 | <Hixie> | i'm just disagreeing with hsivonen's original statement |
| 21:24 | <hsivonen> | what's a "pivot table"? |
| 21:25 | <hsivonen> | "Note: If the expanded property is provided, it applies only to the individual cell. It is not a proxy for the container row, which also can be expanded. The main use case for providing this property on a cell is pivot table type behavior." |
| 21:26 | <hsivonen> | oh. it's on wikipedia |
| 21:30 | <jgraham> | hsivonen: Sure I'll email about aria-level |
| 21:30 | <hsivonen> | jgraham: great |
| 21:42 | <jgraham> | Is aria using RFC 2119 terminology? Section 6.2 seems to be using it but it's not clear if the rest of the document is or not |
| 21:45 | <hsivonen> | jgraham: that would merit another comment :-) |
| 21:46 | <jgraham> | hsivonen: Yeah, I'm starting o accrue a stack of comments |
| 21:47 | <jgraham> | (reading the introduction to try and work out what terminology was being used reminded me of several minor issues I thought merited attention there) |
| 21:48 | <jgraham> | argh, pushed the send buton by mistake :( |
| 21:48 | <Philip`> | Press "undo" quickly |
| 21:49 | <Hixie> | so |
| 21:49 | <Hixie> | many |
| 21:49 | <Hixie> | e-mails |
| 21:50 | <gsnedders> | Hixie: mind if I send you a message, broken into one character per email? |
| 21:50 | <Hixie> | yes |
| 21:50 | <Hixie> | but these e-mails are long |
| 21:50 | <Hixie> | that's the real problem |
| 21:51 | <gsnedders> | "What is the most widely known language for authoring mathematics?" — Can I take a guess at LaTeX? |
| 21:51 | <Hixie> | no guesses |
| 21:52 | <jgraham> | gsnedders: In principle it could be MS-Word or ascii art of something |
| 21:53 | <jgraham> | s/of/or/ |
| 21:53 | <hsivonen> | the answer might depend on what kind of math |
| 21:53 | <zcorpan_> | pen/paper? |
| 21:53 | <gsnedders> | jgraham: Issue one: What is a language? |
| 21:53 | <hsivonen> | I expect Word to be used less and LaTeX more as the math gets more complex |
| 21:53 | <gsnedders> | We're lacking a good enough definition of what the question actually means to be able to answer it. |
| 21:53 | <jgraham> | I guess there's also a lot of math typeset in high end publishing programmes |
| 21:53 | <zcorpan_> | 42 |
| 21:54 | <gsnedders> | I mean, is pen/paper well enough known? :P |
| 21:54 | <jgraham> | s/programmes/programs/ |
| 21:54 | <hsivonen> | jgraham: does InDesign have a decent math typesetter? |
| 21:54 | <gsnedders> | zcorpan_: that's definitely the correct answer. |
| 21:54 | Hixie | removed the word language from the wiki a few minutes ago |
| 21:54 | <hsivonen> | or is it all TeX and Frame? |
| 21:54 | <zcorpan_> | gsnedders: yeah. but what's the question? :) |
| 21:54 | <hsivonen> | what about Quark |
| 21:54 | <gsnedders> | zcorpan_: 6 times 9 |
| 21:55 | hsivonen | isn't sure what the "high end publishing programme" landscape looks like these days |
| 21:55 | <jgraham> | hsivonen: I dunno. All I know is that with Blackwells publishing all one's carefully typeset mathematics gets redone in some way |
| 21:55 | <jgraham> | (usually introducing errors in the process) |
| 21:55 | <Hixie> | Processing namespace e-mail... [## ] 10% |
| 21:55 | <hsivonen> | jgraham: do you mean you send in LaTeX and they do something else? |
| 21:56 | hsivonen | though TeX was the high end when it comes to math typesetting |
| 21:56 | <jgraham> | hsivonen: Yep. Although I don't know what "something else" is |
| 21:56 | <hsivonen> | thought even |
| 21:56 | <gsnedders> | hsivonen: it is |
| 21:56 | <jgraham> | (the final thing still says 'this document was prepared from a manuscript typeset by the author' or somesuch) |
| 22:00 | <BenMillard> | jgraham said "gsnedders: In principle it could be MS-Word or ascii art of something" and that possibility is somewhat supported by me finding ASCII-art data tables for astronomy |
| 22:01 | gsnedders | notes that's jgraham's subject |
| 22:03 | <hsivonen> | I'm tempted to take the ostrich approach to aria-owns |
| 22:06 | jgraham | notes that the common forms for expressing maths are undoubtedly different to those for authoring it |
| 22:06 | <jgraham> | on the web |
| 22:09 | <Hixie> | Processing namespace e-mail... [#### ] 20% |
| 22:09 | Hixie | goes to get a drink |
| 22:11 | jgraham | considers complaining that the aria spec expressing its conformance requirements in RDF makes it inaccessible to people who don't think that RDF is human-readable |
| 22:14 | <hsivonen> | jgraham: I'm reading the tables. I'm not reading RDF. |
| 22:15 | <hsivonen> | I figured it wouldn't be cost-effective to try to generate stuff from the RDF |
| 22:16 | <jgraham> | hsivonen: I'm reading the tables too. But section 6.1 is clear that documents must conform to the RDF but doesn't seem to mention the tables |
| 22:17 | <Philip`> | As far as I've seen, computer science seems to be almost exclusively LaTeX, but areas like biology use Word a lot more, so you can draw very different conclusions depending on what subset of math-writers you look at |
| 22:18 | <jgraham> | Philip`: Undoubtedly there are far more biologists than physical+computer scientists but they probably generate fewer equations each, on average |
| 22:37 | <annevk> | Hixie, fwiw, using the wiki more would be great |
| 22:37 | <annevk> | (as you're doing now) |
| 22:38 | <annevk> | it seems that people are missing some kind of entry point to find arguments for and against certain ideas that have already been discussed and "resolved"; having that documented somewhere other than in piles of e-mail is nice :) |
| 23:03 | <BenMillard> | oh, about author mathematics |
| 23:03 | <BenMillard> | *authoring |
| 23:03 | <BenMillard> | at the HTMLWG meeting in Boston I just remembered talking to a couple of MathML guys |
| 23:04 | <BenMillard> | when I asked them what people used before MathML, they immediately said "LaTex" |
| 23:04 | <BenMillard> | one of them was working on version 3 of it, IIRC |
| 23:05 | <jgraham> | BenMillard: LaTeX3 or Mathml 3? |
| 23:06 | <BenMillard> | LaTeX 3 |
| 23:06 | <BenMillard> | http://www.latex-project.org/latex3.html - I think one of them was David Carlisle, the other names don't ring a bell |
| 23:07 | <jgraham> | Yeah, David Carlisle is in the MathML-WG |
| 23:07 | <Hixie> | i wish the person who posted http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-June/006518.html would have finished their sentence in para5... what does it mean it is important for us to do??? |
| 23:13 | Hixie | giggles at http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-June/006711.html |
| 23:14 | <Hixie> | according to my calculations there, a tag name costs $31,790 |
| 23:16 | <BenMillard> | $10 per hour is about £5 per hour which I think is below minum wage in the UK |
| 23:18 | <Hixie> | yeah the numbers are a bit dubious |
| 23:18 | <Philip`> | It's right to an order of magnitude, though |
| 23:18 | <Philip`> | which is more accurate than many of the other numbers |
| 23:20 | <othermaciej> | that's the cost of a tag name to who? |
| 23:20 | <BenMillard> | the industry in general, afaict |
| 23:20 | <Hixie> | othermaciej: humanity |
| 23:20 | <othermaciej> | hahahahahaha |
| 23:21 | <BenMillard> | oh, there's also the time delay of the extra bytes being transferred over the wire :) |
| 23:21 | <BenMillard> | if you're on company time that would count |
| 23:23 | <Philip`> | If the feature adds maybe a kilobyte to the size of the browser download, and there's a billion web users, then that's about an extra hundred dollars of bandwidth charges |
| 23:23 | jgraham | recalls this entire thread on mathematics becoming less than pleasant |
| 23:24 | <BenMillard> | I meant the bytes for the tags in the document, but that's interesting as well |
| 23:25 | <Hixie> | the cost can only be in terms of time and non-renewable resources |
| 23:25 | <Hixie> | money that goes around the circle doesn't affect the total cost |
| 23:27 | <Philip`> | Time doesn't seem like a non-renewable resource - you can always just employ an extra person, and it will not make the world poorer |
| 23:28 | <Hixie> | it's time that that person would not spend doing what they want to do, one presumes |
| 23:31 | <BenMillard> | anyway, it's just a bit of fun :) |
| 23:42 | <Hixie> | so far, out of 133 e-mails of mathematics discussion, a grand total of 2 lines, in just 2 separate e-mails, actually discussed what problem was being solved. |
| 23:42 | <Hixie> | that's an even worse ratio than the tables discussions |