# [02:28] <Lachy_> from the article: "The whole thing is supposed to be of help to deaf-blind people, who were never surveyed for their preferences, an action I recommended to WAI at a face-to-face meeting in 2003. Nor was any user testing carried out. (That’s all I can tell from published evidence, anyway. I sent e-mail inquiries to deaf-blind organizations in several countries asking if they’d been surveyed or had any opinions, with no response.)"

# [06:01] <mpilgrim> (c.f. their techniques document on using the image @alt attribute)

# [06:01] <mpilgrim> (which cites a grand total of 2 examples, both trivial)

# [06:02] <karlcow> mpilgrim: I was just trying to see if Dashiva's assertion was true or not "[23:01] <Dashiva> Also interesting that Roy thinks summary will be required by government when existing government advice actually discourages it..."

# [07:56] <mpilgrim> "The TABLE element contains all other elements that specify caption, rows, content, and formatting. Authors should use the title attribute to provide a summary of the table for non-visual user agents, covering its purpose and structure."

# [07:56] <mpilgrim> "Note. A new attribute for the table summary is needed because the caption for visual users is generally insufficient. The title attribute is inappropriate because browsers render this as a "tool tip" which is limited to a single line of text. In some user agents, long lines are clipped."

# [07:57] <mpilgrim> this is the sum total of the "research" done on the table summary attribute

# [07:58] <mpilgrim> the summary attribute first appeared in the 1997-09-17 working draft of html 4

# [08:12] <mpilgrim> quote of the day (from http://lists.w3.org/Archives/Public/www-html/1997Jul/0066.html ): "Deprecating a tag doesn't make it obsolete right away, but clearly indicates that there is a 'better' (or at least, more consistent) way of doing things. Any deprecated elements in HTML4.0 won't be obsolete until HTML5.0, probably - and even then they may still be included."

# [08:55] <MikeSmith> hsivonen: so for now, maybe one thing worth considering is to add an Info message saying, "<meta charset="utf-8"/> found in XML document. Make sure your document is actually encoded in UTF-8."

# [09:06] <MikeSmith> hsivonen: so, anyway, what I'm getting at is, I'm going to try to make a non-broken gcj build for jing

# [09:07] <MikeSmith> and if I can get it to work, I'll send a patch and if it looks OK, maybe you can talk with James and George about committing it to the trunk in place of that thing that's there now

# [10:32] <MikeSmith> annevk2: not sure if it's worth noting in the diff doc, but the restriction in HTML5 that the target attribute and iframe name attribute must be at least one character is a change vs HTML4

# [10:32] <MikeSmith> in HTML4, it's just CDATA, with no further restrictions stated in the spec

# [10:48] <Dashiva> There was an ALA article about "unwebbable" content a while ago. One of the examples [in a comment] was poetry, which "In fact, this is text that deliberately defies conventions and structure."

# [10:49] <Dashiva> Doesn't that imply adding syntax for poetry is by definition an impossible task?

# [10:56] <MikeSmith> annevk2: it's probably not worth the effort to list them individually, but maybe adding a general statement that "a number of attributes values now how further restrictions; for example, some values that were allowed to be empty in HTML4 are not allowed to be empty in HTML5, ..."

# [13:38] <MikeSmith> hsivonen: thinking about the microsyntaxes scraping.. the fact that getting those messages current depends stopping and restarting v.nu seems to really cry out for actual API to grab those in real time, and then some kind of simple DB instead

# [13:39] <MikeSmith> the technical limitations of wikis seem like a big deficiency in this case

# [13:40] <MikeSmith> or maybe there's some wiki that's capable of storing content as names and values in a db

# [13:45] <annevk2> I believe that if someone writes the software we'll take it

# [13:45] <annevk2> but note that having it on the wiki has advantages; e.g. spam control, accounts are sorted out, etc.

# [13:47] <MikeSmith> annevk2: I understand all that. But I'd really think there'd be an simple online DB with those same features and almost the same ease of use as a wiki, but with a real rest API for retrieving data from it.

# [13:48] <MikeSmith> I guess to me the lack of the network API is the real issue

# [13:49] <MikeSmith> I guess it would be possible to have some kind of thing that scrapes the wiki in real time and exposes an API

# [14:06] <Philip`> jgraham: The ones in the tutorial screencasts where you make a user-editable database with two lines of code using the user-editable database scaffolding which conveniently happens to have been written already for precisely this purpose, I guess

# [14:06] <jgraham> Because I guess most k-v stores are designed to be efficient rather than to keep records

# [14:11] <MikeSmith> jgraham: you know, for me at least, it really is all about the API. I'd think whatever Wiki could easily have some kind of standard markup for indicating a string on the page that's a key, and whatever chunk of text is its associated value

# [14:11] <MikeSmith> and then the Wiki's own backend could expose an API for that

# [15:38] <Philip`> jgraham: I think I read somewhere that CouchDB happily throws away old revisions when you're compacting the database, which doesn't sound good when you want a reliable version control system

# [15:42] <jgraham> Philip`: Ah. Well I guess you would have to build a seperate version control layer then :(

# [15:44] <jgraham> (or you could just use something totally different like a hg backend that stored json files assuming that querying wasn't a priority)

# [15:52] <pablof> there doesn't seem to be that much interest for that other from toy wikis apparently

# [16:47] <gsnedders|work> jim_c: A while ago there was a decision made to make the Twitter account open, knowing it could potentially be used for spam, but thinking being open would all-in-all be more useful

# [17:55] <jgraham> MadAtWork2: That's an oversimplification but <section> or <article> depending on what you mean

# [17:56] <MadAtWork2> jgraham: I'm starting a new webapp, and I'm creating a login page, I have a header I have a footer, and I have a login box, I'm trying to see what would uncle html5 suggest to use in this case.

# [17:56] <jgraham> Lachy: I know that you can take some measures to cover your tracks, but in practice many people don't bother and find that actions that they took believing that they would be free of consequences are not actually as anonymous and as free of consequences as they had assumed

# [17:59] <jgraham> MadAtWork2: It sounds like it might be <section> and maybe you could move the fieldset label to a <h1> or so

# [18:00] <Lachy> I'm not disputing the fact that most people don't have total anonynimity on the net in all cases, but for all practical purposes in the case of the whatwg status updater, they do, because we have absolutely no way of finding out who's who just from an IP address

# [20:57] <Hixie> if it's still not abused in a few hours we'll post something

# [20:59] <jgraham> othermaciej: I have heard that the kind of structural information that blind users like would also be helpful to people with some cognitive disabilities although I don't know if that is really true

# [21:00] <othermaciej> jgraham: I don't personally know the details of what is useful to different handicap groups - I would expect there is a lot of overlap, perhaps not 100%

# [21:56] <jgraham> It was on the subject of organic food and made reasonable criticisms of a Soil Association press release that claimed that a report saying organic food provided no health benefits was bogus

# [21:57] <takkaria> ah, yeah, the book's like that but more in-depth and will a lot of depth on general scientific methology

# [21:57] <jgraham> But seemed to go futrther and claim that organic food in general has no benefits

# [23:53] <Lachy> Hixie, in the interest of getting the publication of a Working Draft for the heartbeat requirement out of the way and decoupling the resolution of the summary issue from that process, would you be willing to agree to a short term compromise solution, leaving the group to continue debating the details of othermaciej's proposal?

# [23:55] <othermaciej> Hixie: I made a proposal for what I think is a compromise (not sure if that's what Lachy has in mind)

# [23:55] <Lachy> specifically, remove summary from the Obsolete but Conforming features list, and add a big note to The table Element section stating that there has been a proposal to include the summary attribute as conforming, but the issue is not yet decided