/irc-logs / w3c / #html-wg / 2007-06-07 / end

Options:

# Session Start: Thu Jun 07 00:00:00 2007
# Session Ident: #html-wg
# [00:03] * Joins: dbaron (dbaron@63.245.220.242)
# [00:04] <zcorpan> Thomas Broyer has a point -- the table model in html5 isn't good enough
# [00:07] <hsivonen> headers='' needs to be included for backwards compat
# [00:08] <hsivonen> but it has the worst possible burden placement properties of possible solutions
# [00:08] <Dashiva> Included for UAs or in conforming documents too?
# [00:09] <hsivonen> Dashiva: both
# [00:10] <zcorpan> <table><tr><th>A<td>1<th>B<td>2</table> should work
# [00:10] <Dashiva> That's one of the table things... tables that really are multi-columned
# [00:11] <zcorpan> i don't know if THs to the far right should be taken into account
# [00:12] <zcorpan> i haven't seen a table on the web with headers on the right, but i have seen it in print
# [00:12] <zcorpan> (i.e. both on the left and on the right)
# [00:21] <Dashiva> Well, that was the counter-case for scope, two superimposed tables, using all four borders for headings
# [00:22] <zcorpan> i didn't have gez's overlaid table in mind
# [00:23] <zcorpan> i should probably scan it and put it online
# [00:27] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [00:34] * Quits: Sander (svl@71.57.109.108) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [00:49] * Quits: mw22 (chatzilla@84.41.169.151) (Quit: Chatzilla 0.9.75.1 [SeaMonkey 1.1.2/2007050918])
# [00:56] * Quits: tH (Rob@87.102.12.3) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
# [01:01] * Joins: hyatt (hyatt@17.255.100.216)
# [01:05] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [01:08] * Parts: hasather (hasather@81.235.209.174)
# [01:10] * Joins: gavin (gavin@74.103.208.221)
# [01:20] * Quits: billmason (billmason@69.30.57.156) (Connection reset by peer)
# [01:30] * Parts: zcorpan (zcorpan@84.216.42.186)
# [01:31] * Joins: zcorpan (zcorpan@84.216.42.186)
# [01:34] * Quits: heycam (cam@203.214.95.190) (Quit: bye)
# [01:36] <zcorpan> http://simon.html5.org/temp/periodic-table.png
# [01:52] * Joins: heycam (cam@130.194.72.84)
# [01:54] * Joins: sbuluf (zonu@200.49.140.249)
# [01:57] * Quits: mjs (mjs@17.255.97.147) (Connection reset by peer)
# [02:07] * Quits: hyatt (hyatt@17.255.100.216) (Quit: hyatt)
# [02:08] * Quits: inimino (inimino@75.71.88.233) (Client exited)
# [02:14] * Joins: inimino (inimino@75.71.88.233)
# [02:27] * Joins: mjs (mjs@17.255.97.147)
# [02:28] * Joins: karl (karlcow@128.30.52.30)
# [02:34] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
# [02:36] * Quits: kingryan (rking3@208.66.64.47) (Quit: kingryan)
# [02:46] * Quits: mjs (mjs@17.255.97.147) (Quit: mjs)
# [03:05] <karl> Laura Carlson made an excellent job
# [03:05] <karl> very deep bow
# [03:10] * Joins: Lachy (chatzilla@203.206.247.10)
# [03:11] <karl> [00:11] <zcorpan> i don't know if THs to the far right should be taken into account
# [03:11] <karl> # # [00:12] <zcorpan> i haven't seen a table on the web with headers on the right, but i have seen it in print
# [03:11] <karl> hmmm
# [03:11] <karl> I guess it would be easier to find such tables (if there are) on pages written in arabic or hebrew
# [03:11] <zcorpan> i meant in LTR tables
# [03:12] <karl> yes
# [03:12] <zcorpan> [01:35] <zcorpan> http://simon.html5.org/temp/periodic-table.png
# [03:12] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [03:13] <karl> hmm table with multiple entries
# [03:13] <zcorpan> that's a separate issue
# [03:13] <karl> your headers on the right is another way of reading, what I call multiple entries
# [03:14] <karl> and there is the funny thing at the top left, which has never been solved in HTML tables :) tricky
# [03:14] <zcorpan> oh, ok, i thought you referred to each cell containing multiple data
# [03:14] <zcorpan> and indeed
# [03:15] <karl> nope :) even more complex :p not going there for now :)
# [03:15] <zcorpan> good :)
# [03:16] <zcorpan> the funny thing at the top left can be solved by having one colspanned TH at the top and one rowspanned TH on the left
# [03:16] <zcorpan> semantically
# [03:17] <zcorpan> or moving the vertical header one cell upwards and the horizontal header one cell to the left
# [03:17] * Joins: gavin (gavin@74.103.208.221)
# [03:32] <zcorpan> doing the latter means that the headers on the left won't be in the first column
# [03:33] <Dashiva> For the periodic table, there's a 1:1 mapping between period and orbit, isn't there?
# [03:34] <zcorpan> yeah
# [03:36] * Quits: h3h (bfults@66.162.32.234) (Quit: |)
# [03:46] * Joins: hyatt (hyatt@24.6.91.161)
# [03:48] <zcorpan> http://simon.html5.org/temp/periodic-table.html
# [03:49] <hyatt> didn't you paste that earlier today? :)
# [03:49] <zcorpan> no
# [03:49] <zcorpan> .html
# [03:51] <Lachy> wikipedia does it slightly differently from your examples http://en.wikipedia.org/wiki/Periodic_table
# [03:51] <zcorpan> yeah
# [03:54] <zcorpan> added
# [03:54] * karl wonders if a nested list is possible for this table, not sure
# [03:54] <karl> if I have time later, I will see
# [03:55] <Lachy> zcorpan: why are you spelling "group" as "grupp"?
# [03:55] <zcorpan> swedish
# [03:55] <Lachy> ok
# [03:56] <karl> http://www.la-grange.net/2003/09/08-calendrier-list
# [03:57] <karl> I guess it must fall apart in IE6 at least
# [03:58] <zcorpan> falls apart without css
# [03:59] <karl> well not really it depends on what you want to do
# [04:00] <karl> ah time for the lecture. bbl
# [04:00] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [04:11] <zcorpan> hmm
# [04:12] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
# [04:12] <zcorpan> if a row contains only THs, and there is a <th scope=row>, then that is a heading for the headings on the same row
# [04:13] <zcorpan> similar for a column
# [04:15] <zcorpan> that would make the wiki periodic table work by just adding scope="" to the "Group" and "Period" cells
# [04:17] <zcorpan> still not sure how to solve the right hand side headers, if at all
# [04:32] * Joins: Lachy_ (chatzilla@203.217.56.97)
# [04:33] * Quits: Lachy (chatzilla@203.206.247.10) (Ping timeout)
# [04:33] * Lachy_ is now known as Lachy
# [04:33] * Quits: Lachy (chatzilla@203.217.56.97) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007030919])
# [04:35] * Quits: zcorpan (zcorpan@84.216.42.186) (Ping timeout)
# [04:45] * Joins: Sander (svl@71.57.109.108)
# [04:49] * Joins: hyatt (hyatt@24.6.91.161)
# [04:55] * Joins: Lachy (chatzilla@203.217.56.97)
# [05:08] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
# [05:54] * Joins: karl (karlcow@128.30.52.30)
# [06:03] * Joins: mjs (mjs@64.81.48.145)
# [06:11] * Joins: hyatt (hyatt@24.6.91.161)
# [06:17] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
# [06:59] * Joins: Grigoris (runbaby@213.7.67.137)
# [07:00] <Grigoris> Hello
# [07:00] <Grigoris> Can div tags be displayed inline ?
# [07:00] * Quits: schepers (schepers@84.73.168.194) (Quit: Free at last!)
# [07:09] <karl> Grigoris: yes, but it is not the appropriate channel for this. :) display: inline;
# [07:12] <Grigoris> oh sorry
# [07:17] * Quits: Sander (svl@71.57.109.108) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [07:17] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [07:22] * Joins: gavin (gavin@74.103.208.221)
# [07:31] <Grigoris> bye
# [07:31] * Quits: Grigoris (runbaby@213.7.67.137) (Quit: Grigoris)
# [07:43] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
# [08:01] * Joins: Zeros (Zeros-Elip@69.140.48.129)
# [08:07] * Quits: laplink (link@193.157.66.93) (Quit: Leaving)
# [08:15] * Joins: heycam (cam@203.214.95.190)
# [08:47] * Parts: bdash (bdash@72.36.164.203)
# [08:55] * Joins: schepers (schepers@129.132.127.228)
# [09:01] <karl> I wonder where the style element appears in the page. If someone has a MySpace account
# [09:01] <karl> http://blog.jobamatic.com/2007/06/how_to_hide_the.html
# [09:01] <karl> <style>
# [09:01] <karl> #post_link_container{visibility:hidden;}
# [09:01] <karl> #no-jobs-message{visibility:hidden;}
# [09:01] <karl> #backfill-rule{visibility:hidden;}
# [09:01] <karl> </style>
# [09:02] <anne> doesn't matter
# [09:02] <anne> if it appears in the page it will be used
# [09:02] <karl> anne: I still have a question :) I wonder where they put it in the page.
# [09:03] <karl> your answer is interesting but not the one I was looking for :)
# [09:03] <anne> oh, dunno
# [09:03] <anne> view a myspace page I suppose
# [09:04] <karl> with loud music and images everywhere ;)
# [09:06] <karl> anne: oooh and yesterday you asked about geomap, it wast just a name made like this. thinking out loud. but with the number using maps with the same basic features: flag a part, zoom out/in, tiles loading, etc.
# [09:07] <karl> the source code of MySpace is… interesting
# [09:08] <karl> </style><br><br>
# [09:08] <karl> <br><br>
# [09:08] <karl> </style>
# [09:08] <anne> I suppose that's the better part?
# [09:09] <karl> ;)
# [09:09] <karl> ooooh sweet the ending is quite cool too
# [09:09] <karl> after the </body>, we have an iframe, a script, another script and a...
# [09:09] <karl> <style type="text/css">
# [09:09] <karl> body, html {visibility:visible !important; display:block !important}
# [09:09] <karl> </style>
# [09:09] <karl> </html>
# [09:10] * Joins: schepers_ (schepers@129.132.127.228)
# [09:10] * Quits: schepers (schepers@129.132.127.228) (Connection reset by peer)
# [09:10] <anne> "The HTML working group, according to Juicy Studio, has concluded that the headers attribute for complex tables is unnecessary for HTML5."
# [09:10] <anne> blogs are a great source of information
# [09:10] <mjs> heh
# [09:10] <mjs> still, I am glad actual research and testing was finally done on "headers"
# [09:11] <karl> on blogs your life will be longer, on blogs you will read all kind of craps from informed and uninformed people, on blogs you will save cats
# [09:12] <Zeros> karl, looks like that's a cheap way for them to prevent people from making the entire page invisible?
# [09:12] <karl> "Hi! my name is Karl. I was a blogger. I have stopped on December 31, 2007", "Hiiiii Karl"
# [09:13] <hsivonen> karl: you still have relapses of blogging at the QA blog and the WG blog ;-)
# [09:13] <anne> http://www.mistermartin75.net/?p=29
# [09:13] <karl> hsivonen: sssshhhhhhhh ;) don't tell anyone, it is my secret :p
# [09:13] <anne> (about W3C losing its way)
# [09:14] * Joins: tH (Rob@87.102.12.3)
# [09:16] <karl> "Well, I’ll hear that from the WhatWG (they at least have an idea what they’re doing, and are clear about that to the public)."
# [09:16] <karl> funny
# [09:16] <karl> it is interesting to see people going on their rants
# [09:17] <hsivonen> it is also interesting to see how some people feel betrayed when the W3C adjusts its stance instead of staying the course no matter what
# [09:17] <karl> yes
# [09:18] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Quit: Leaving)
# [09:19] <karl> hsivonen: W3C is a wonderful target for everyone.
# [09:20] <karl> It makes your life as an employee interesting. You are always on the wrong side :) even if you just try to make the communities talking to each other. Kind of interesting exercise after a while.
# [09:20] <karl> It develops the zen part in you.
# [09:24] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [09:29] * Joins: gavin (gavin@74.103.208.221)
# [09:34] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [09:50] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [09:52] * Joins: edas (edaspet@88.191.34.123)
# [10:21] <anne> what's 10am LA time here?
# [10:21] <anne> 8:40 hours from now
# [10:24] * Quits: mjs (mjs@64.81.48.145) (Client exited)
# [10:24] * Joins: mjs (mjs@64.81.48.145)
# [10:38] <MikeSmith> anne - http://timeanddate.com/worldclock/meeting.html
# [10:58] * Quits: inimino (inimino@75.71.88.233) (Ping timeout)
# [11:00] * Joins: frippz (frippz@193.15.86.51)
# [12:17] * Quits: edas (edaspet@88.191.34.123) (Client exited)
# [12:21] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [12:26] * Joins: gavin (gavin@74.103.208.221)
# [12:46] * Quits: frippz (frippz@193.15.86.51) (Quit: frippz)
# [12:49] * Joins: ROBOd (robod@86.34.246.154)
# [12:55] * Quits: sbuluf (zonu@200.49.140.249) (Ping timeout)
# [12:57] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [13:10] * Joins: edas (edaspet@88.191.34.123)
# [13:45] <anne> w3.org down?
# [13:45] <anne> hmm, just slow
# [13:53] <MikeSmith> anne - I think there might be some problems ... tried to do a commit to cvs.w3.org and got an error that seems to indicate it's out of tmp file space
# [13:58] * Quits: olivier (ot@128.30.52.30) (Quit: This computer has gone to sleep)
# [14:02] * Quits: anne (annevk@213.236.208.22) (Ping timeout)
# [14:28] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [14:33] * Joins: gavin (gavin@74.103.208.221)
# [15:26] * Joins: anne (annevk@213.236.208.22)
# [15:53] * Joins: icaaq (icaaaq@217.13.228.226)
# [16:11] * Joins: tH_ (Rob@83.100.251.60)
# [16:11] * Quits: tH (Rob@87.102.12.3) (Ping timeout)
# [16:12] * tH_ is now known as tH
# [16:26] * Joins: hasather (hasather@81.235.209.174)
# [16:36] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [16:36] * Joins: billmason (billmason@69.30.57.156)
# [16:41] * Joins: gavin (gavin@74.103.208.221)
# [16:44] * Quits: xover (xover@193.157.66.5) (Ping timeout)
# [16:46] * Joins: xover (xover@193.157.66.5)
# [16:51] * Joins: robburns (robburns@208.54.95.1)
# [16:53] * Joins: robburns_ (robburns@208.54.95.1)
# [16:53] * Quits: robburns (robburns@208.54.95.1) (Connection reset by peer)
# [16:53] * Quits: robburns_ (robburns@208.54.95.1) (Connection reset by peer)
# [17:00] * Joins: zcorpan (zcorpan@84.216.41.183)
# [17:02] * Quits: xover (xover@193.157.66.5) (Ping timeout)
# [17:05] * Joins: h3h (bfults@66.162.32.234)
# [17:06] * Joins: Sander (svl@71.57.109.108)
# [17:08] * Joins: xover (xover@193.157.66.5)
# [17:14] * Joins: nickshanks (nicholas@195.137.85.17)
# [17:18] * Parts: icaaq (icaaaq@217.13.228.226)
# [17:19] * Quits: tH (Rob@83.100.251.60) (Ping timeout)
# [17:22] * Quits: nickshanks (nicholas@195.137.85.17) (Quit: nickshanks)
# [17:22] * Joins: nickshanks (nicholas@195.137.85.17)
# [17:33] * Joins: robburns (robburns@208.54.95.1)
# [17:34] * Joins: robburns_ (robburns@208.54.95.1)
# [17:34] * Quits: robburns (robburns@208.54.95.1) (Connection reset by peer)
# [17:38] * Parts: robburns_ (robburns@208.54.95.1)
# [17:40] * Joins: tH (Rob@83.100.251.60)
# [17:44] * Joins: rburns (robburns@208.54.95.1)
# [18:06] * Quits: schepers_ (schepers@129.132.127.228) (Quit: Free at last!)
# [18:13] * Quits: edas (edaspet@88.191.34.123) (Quit: http://eric.daspet.name/ et l'édition 2007 de http://www.paris-web.fr/ )
# [18:17] <DanC> I just added a menu of sections to review to the tasks survey. I'd like quick review before I send it out: http://www.w3.org/2002/09/wbs/40318/tasks83/
# [18:21] <anne> maybe you should exclude "forms" for now
# [18:21] <anne> dunno
# [18:21] <anne> rest looks fine
# [18:21] * Quits: jgraham (jgraham@81.86.210.0) (Ping timeout)
# [18:21] <DanC> why exclude forms?
# [18:22] <anne> hmm, I guess Web Forms 2 was accepted as well
# [18:22] <anne> however, it's not integrated in the spec so the forms section is mostly empty
# [18:22] <DanC> ah. right. I suppose folks who want to review it can figure that out, though
# [18:23] <DanC> i.e. they can find http://dev.w3.org/cvsweb/html5/web-forms-2/
# [18:23] * Joins: rburns_ (robburns@208.54.95.1)
# [18:23] <anne> I guess
# [18:23] * Quits: rburns (robburns@208.54.95.1) (Connection reset by peer)
# [18:23] <rburns_> s
# [18:24] <DanC> I suppose lumping it all into one section is probably not optimal
# [18:24] <anne> ah, the spec already points to Web Forms 2
# [18:24] * anne wonders when the forms TF will start
# [18:25] <zcorpan> DanC: looks good
# [18:27] <rburns_> greetings. questionnaire looks good to me too.
# [18:30] * Joins: hober (ted@68.107.112.172)
# [18:33] * Quits: heycam (cam@203.214.95.190) (Ping timeout)
# [18:38] * Quits: rburns_ (robburns@208.54.95.1) (Client exited)
# [18:42] * Joins: rburns (robburns@208.54.95.1)
# [18:43] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [18:48] * Joins: gavin (gavin@74.103.208.221)
# [18:48] <anne> "Note that if we don't say anything, some will assume our endorsement." what exactly does that imply?
# [18:49] <anne> http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#test_character_encoding_support is wrong
# [18:51] * Joins: oedipus (oedipus@71.250.74.215)
# [18:51] * Quits: oedipus (oedipus@71.250.74.215) (Quit: #html)
# [18:51] * Joins: heycam (cam@203.214.95.190)
# [18:52] * Joins: oedipus (oedipus@71.250.74.215)
# [18:53] <DanC> anne, if W3C publishes mobileOK tests that say "make all your HTML documents purple," some readers will assume that the W3C HTML WG agrees.
# [18:53] <anne> also, they make requirements on content that mobile UAs typically not implement correctly
# [18:53] <anne> such as using XML...
# [18:53] <DanC> where?
# [18:53] <anne> which causes problems for UAs that do support XML
# [18:54] <anne> http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#test_content_format_support
# [18:54] * Joins: dbaron (dbaron@63.245.220.242)
# [18:54] <anne> requires the media type to not be text/html
# [18:54] <DanC> #test_character_encoding_support ... is it straightforward to make a test that shows it's wrong?
# [18:55] * Joins: Chris (cwilso@131.107.0.105)
# [18:55] <anne> it says "application/xhtml+xml"
# [18:55] <anne> UAs only recognize the "charset" bit
# [18:56] <DanC> hi Chris
# [18:56] <anne> the more relevant thing here however is that per HTML4 <meta> elements are a server thing
# [18:56] <anne> and XHTML should not follow <meta> for character encoding detection, it should simply follow the XML rules
# [18:56] <Chris> Hi Dan (and all
# [18:57] <DanC> I spent some time trying to get my list of agenda/issues updated (http://www.w3.org/html/wg/il16) . I made some progress (1.24), but didn't really get it into a tidy list of things to discuss.
# [18:57] <gsnedders> I guess we can't do anything about
# [18:57] <gsnedders> the mobile platform
# [18:57] <DanC> what do you mean? of course we can do something about the mobile platform.
# [18:58] <gsnedders> about having to treat application/xhtml+xml for backwards compat
# [18:58] <DanC> I don't think I follow you. I'd sure like to look at a test case.
# [18:59] <gsnedders> I've been unable to phrase myself all day :\
# [18:59] * Joins: mjs (mjs@64.81.48.145)
# [18:59] <anne> http://simon.html5.org/articles/mobile-results
# [18:59] <anne> (also has tests)
# [19:00] <DanC> hmm... yes, I recall those. Does one of those show that #test_character_encoding_support is wrong?
# [19:00] <anne> It basically indicates that some mobile browsers parse application/xhtml+xml as "text/html"
# [19:00] <anne> I'm not sure you'd show it's wrong
# [19:00] <anne> XML defines character detection, not XHTML
# [19:01] <anne> and XML doesn't take <meta> in the XHTML namespace into account last time I checked
# [19:01] <gsnedders> my point is that as current UAs treat application/xhtml+xml as HTML, there will be sites which will break if we change that (though it's probably negligibly small)
# [19:02] <anne> that's mostly walled-garden mobile content, but yes
# [19:02] <gsnedders> how walled-gardened is it?
# [19:02] * DanC can't see what's wrong with http://www.w3.org/TR/mobileOK-basic10-tests/#test_character_encoding_support
# [19:02] <anne> DanC, it says you can use the <meta> element in XHTML
# [19:03] <anne> gsnedders, enough to not affect desktop brows(ers|ing)
# [19:04] <DanC> if by "in XHTML" you mean "with the application/xhtml+xml media type", then OK, I see your point.
# [19:04] <mjs> <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8"/>
# [19:05] <Philip`> Does anyone have statistics on how many application/xhtml+xml sites are ill-formed? (maybe particularly on .mobi sites?)
# [19:05] <anne> DanC, they require application/xhtml+xml somewhere else
# [19:05] <anne> also, I'm not convinced that XHTML exists other than with an XML MIME type
# [19:05] <anne> all other "XHTML" mostly relies on HTML specific rules
# [19:05] <Philip`> Looking at the first hundred in Google I can find http://peterbe.mobi/plog/blogitem-040406-1/ and http://www.author-me.mobi/Item7.xhtml which make real browsers unhappy
# [19:06] * Joins: MikeSmith^ (MikeSmith@mcclure.w3.org)
# [19:06] * Quits: MikeSmith^ (MikeSmith@mcclure.w3.org) (Client exited)
# [19:06] <anne> "<span class=c_9>" in XHTML, awesome :)
# [19:06] <mjs> so far no desktop UA has chosen to process the application/xhtml+xml MIME type as text/html, so presumably the content requiring that is all mobile-specific
# [19:07] <DanC> what do you call stuff like http://www.w3.org/html/wg/ , anne ? i.e. it's served with text/html , but it's also XML-WF. I call it XHTML.
# [19:07] <Chris> I'd call it HTML, if it's served as text/html
# [19:07] <anne> mjs, end of 2005 I found a site that broke desktop sites except IE: http://annevankesteren.nl/2005/11/draconian
# [19:07] <gsnedders> I'd also call it HTML
# [19:07] <anne> DanC, all text/html is HTML
# [19:08] <anne> like all text/plain is text
# [19:08] <anne> actually, I retract that last statement
# [19:08] <DanC> well, I could argue a different position. But OK, I can live with that.
# [19:08] <Chris> heh
# [19:08] <anne> there's content sniffing going on for text/plain
# [19:08] <mjs> anne: oh yes, any site that uses content negotiation to serve as HTML or XHTML is likely to do that - I think the only reason desktop UAs haven't changed is because the number of sites using the XHTML MIME type is trivial and none is an important site
# [19:09] <mjs> the situation is rather sad
# [19:10] <anne> s/desktop sites/desktop browsers/
# [19:11] <anne> I believe text/html is also sniffed
# [19:11] <anne> for feeds
# [19:11] <DanC> hmm... I recommend authors use XHTML+CSS, by which I mean XHTML 1.0 Transitional, served as text/html . I hear from consultants that interop is pretty good that way, and I hear from educators that students grok. If I shouldn't use "XHTML" for this, the slogan gets longer. hm.
# [19:11] * Joins: olivier (ot@128.30.52.30)
# [19:11] <gsnedders> anne: yes, many feeds are incorrectly served
# [19:11] <anne> use HTML4 strict + CSS?
# [19:11] <DanC> no, HTML4 strict isn't XML-WF. doesn't work with XML tools.
# [19:12] <anne> most XML toolchains have an HTML parser somewhere
# [19:12] <mjs> XML tools presumably need a special tool anyway to output Appendix C conforming XHTML 1.0
# [19:12] <anne> that too
# [19:12] <mjs> if they can have a mode for that, they can have a mode for HTML output
# [19:13] <anne> <script/> or <textarea/> in text/html won't work for instance
# [19:13] <DanC> well, yeah, an HTML parser that sorta works. maybe when libhtml5 and the like are ubiquitously deployed, it won't matter much... no... I think authors want their tools to report poorly nested tags.
# [19:13] <anne> as mentioned before character encoding stuff is different
# [19:14] <anne> authors use PHP, Perl, Python and a good dosis of string concatenation to generate (X)HTML
# [19:14] <anne> mostly
# [19:14] <rburns> so, if I understand correctly, anne, your concern about http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#test_character_encoding_support is that the page uses a meta element to set the character encoding (which should already be set through other means)?
# [19:14] <anne> no tools that properly build up trees and then serialize
# [19:14] <DanC> anne, you're talking about what most people do. I'm talking about what I recommend.
# [19:15] * anne likes the ease of string concatenation
# [19:15] <mjs> rburns: using a <meta> element to set the encoding is supposed to be ignored by XML processors
# [19:15] <mjs> rburns: http://www.w3.org/TR/xhtml1/#C_9
# [19:15] <Chris> I think the point is that it's problematic to serve XML-WF HTML as text/html - the tools would need to enforce the HTML compatibility rules too.
# [19:16] <DanC> well, if that's the point, I disagree with it. I've been doing XML-WF HTML as text/html for years and years, quite happily.
# [19:17] <anne> HTML5 allows "XML-WF" as text/html btw
# [19:17] <DanC> about which I am greatly relieved.
# [19:17] <anne> it allows a meaningless / in <br> like <br /> (and similar elements)
# [19:17] <mjs> it's not a world-ending thing to put some slashes in your empty element tags
# [19:17] <anne> and allows a meaningless xmlns attribute on <html> with the XHTML namespace as value
# [19:17] <mjs> the main problem with sending XML with text/html MIME type is that a lot of things will work differently than in real XML
# [19:18] <DanC> meaningless? I don't think so. but no matter.
# [19:18] <hsivonen> anne: doesn't Opera sniff for a certain bogotic mobile spec doctype to reconcile XML rules and Mobile Web b0rkedness?
# [19:18] <anne> it's not quite serialized the same way and especially if you don't follow the rest of the HTML syntax rules things start get icky
# [19:18] <anne> hsivonen, I don't know the details
# [19:18] <mjs> so you'll either try XML constructs and be confused that they fail, or you'll be confused the first time you try processing your document as XHTML and it behaves differently than you expected
# [19:19] <DanC> "a lot of things"? care to be less handy-wavy and more specific, mjs? I can't think of one that matters.
# [19:19] <Chris> I didn't say meaningless or that it should be recommended against - I think it can be problematic if you blindly use XML tools to generate XHTML, then serve it as text/html.
# [19:19] <rburns> I would agree with DanC. I think there's a lot of misunderstanding about authroing xhtml and serving it as text/html. The dangers are much exaggerated.
# [19:19] <mjs> DanC: using self-closing syntax on elements that aren't empty per DTD
# [19:19] <DanC> yes, if you use XML tools to generate HTML, the occasional <blockquote /> can slip in, which doesn't work.
# [19:19] <mjs> <div/>
# [19:19] <anne> DanC, http://wiki.whatwg.org/wiki/HTML_vs._XHTML
# [19:19] <hsivonen> anne: "WML 2.0 and DOCTYPE Switching" in http://www.opera.com/docs/specs/doctype/
# [19:19] <mjs> not the same thing in XHTML and HTML
# [19:20] <mjs> document.write works in HTML but not XHTML (currently)
# [19:20] <gsnedders> <script/> is the worst
# [19:20] <mjs> CSS rules are different
# [19:20] <mjs> case sensitivity rules are different
# [19:20] <gsnedders> (IMO)
# [19:20] <anne> hsivonen, I think that's mostly "namespace defaulting" and some additional entities
# [19:20] <hsivonen> anne: plus the $ utter bogosity
# [19:20] <anne> oh yes
# [19:20] <mjs> in the DOM, elt.tagName uppercases for HTML
# [19:20] <anne> that's evil :)
# [19:21] * DanC has never gotten to the bottom of the uppercase situation
# [19:21] <mjs> HTML is case insensitive and some DOM APIs are required to return uppercase for HTML
# [19:22] <mjs> XHTML is case sensitive and tag names are all in lowercase; DOM APIs do not alter the case for XHTML
# [19:22] <mjs> that's basically the main thing
# [19:22] <DanC> and when you say "for XHTML" there, do you mean "for content labelled application/xhtml+xml"?
# [19:22] <anne> or any other XML MIME type
# [19:22] * Quits: gsnedders (gsnedders@86.139.123.225) (Quit: Don't touch /dev/null…)
# [19:22] <mjs> well yes, to me content labeled text/html is not XHTML
# [19:23] <mjs> if it's labelled text/html, it will be treated with all HTML rules applied
# [19:24] <DanC> and yet it still conforms to the XHTML spec, so it _is_ XHTML. (I said I could accept anne's terminology earlier, but I'm interested to discuss the differences now)
# [19:24] <DanC> maybe I'll try "WF-HTML" or something.
# [19:25] <anne> there's such a thing as syntax error-free HTML
# [19:25] <rburns> the case sensitivity issues are very significant (the CSS differences are significant but easily handled). Just as scripts use feature checks to branch, they could likewise use checks for application/xhtml+xml v text/html for handling case-sensitivity issues (if the document needed to be handled in both environments).
# [19:25] <oedipus> question from gregory: i added an HTML Wiki Space Index / Table of Contents by searching ESW for HTML/* and then adding them to the index; does anyone know of other pages that need to be included?
# [19:26] <mjs> HTML5 could even define a subset of conformance criteria to be well-formedness criteria if that made people happy
# [19:26] <DanC> that would make me happy
# [19:26] <mjs> rburns: a lot of content has a CSS background on the body
# [19:26] <rburns> me too
# [19:26] <anne> that would be difficult
# [19:26] <anne> it would require weird ifdefs in the parsing section
# [19:26] <oedipus> forgot to give the wiki URI: http://esw.w3.org/topic/HTML/TableOfContents
# [19:26] <mjs> anne: it would?
# [19:27] <mjs> what I meant was you could have a concept of "well-formed HTML5 HTML serialization" that would parse without parse errors, but may be nonconforming in other ways
# [19:27] <anne> mjs, maybe you could do it in another way... like saying that if the document is conforming HTML5 and well-formed XML it is super-duper HTML5
# [19:27] <mjs> I didn't mean HTML/XHTML chameleon documents
# [19:28] <anne> oh ok
# [19:28] <mjs> the way to do that in HTML5 would be to validate as HTML5 and validate as XHTML5
# [19:28] <anne> but I don't think people want optional tags in that new serialization
# [19:28] <mjs> if it passes both, that's the rough equivalent of Appendix C, machine-checked for the first time ever
# [19:28] <anne> and don't want characters in there that are not allowed in XML 1.0
# [19:28] <anne> but maybe I'm mistaken
# [19:29] <anne> re CSS differences: we should fix that by making them the same
# [19:29] <rburns> yes, I think that would be ideal. Especially since the draft already abstracts the HTML5 DOM from its two serializations
# [19:29] <mjs> I think reducing the differences is good, where possible
# [19:30] <anne> rburns, what's the advantage over simply using XHTML5 though?
# [19:31] <anne> Other subject, will HTML5 be published as a spec?
# [19:31] <anne> like a snapshot on the TR/ page?
# [19:32] <DanC> yes, but I think it's worth having the WG go over it in some detail 1st.
# [19:32] <DanC> i.e. to swap it in
# [19:33] * Quits: rburns (robburns@208.54.95.1) (Connection reset by peer)
# [19:33] * Joins: rburns (robburns@208.54.95.1)
# [19:33] <DanC> for 1st WD, I currently lean toward a mixture of "what's new in HTML5?" and design princples.
# [19:34] <anne> is there a document for the former?
# [19:35] <DanC> http://wiki.whatwg.org/wiki/Differences_from_HTML4 has been nominated a few times
# [19:35] <anne> Since I wrote that it hasn't really been updated by people...
# [19:36] <DanC> well, it's still better than a blank page
# [19:37] <DanC> hmm... "HTML5 also integrates a new version of DOM Level 2 HTML so the element-specific APIs are defined along with the rest of the language." I have been sorta head-in-the-sand about that sort of thing, assuming that the DOM WG took care of that stuff. I wonder how the WebAPI WG is doing these days.
# [19:39] <anne> http://wiki.whatwg.org/wiki/Talk:Differences_from_HTML4 has some stuff that needs adding
# [19:39] <Chris> heheheh
# [19:39] <DanC> re "This XML serialization is called XHTML5", I've been asked to not use "XHTML5" to save confusion with XHTML2. I replied that XHTML2 should have a name that doesn't have H-T-M-L in that order.
# [19:39] * Joins: gsnedders (gsnedders@86.139.123.225)
# [19:39] <anne> HTML specific APIs are probably best in the HTML spec itself as they directly integrate with the semantics of the language
# [19:39] <anne> DanC, :)
# [19:41] <mjs> DanC: modern w3c language specs include the language-specific DOM
# [19:41] <mjs> (SVG, XForms, etc)
# [19:42] <rburns> Regarding DOM inclusion in the spec, many of the other workgroups define DOM related APIs as they relate to the specific recommendations.
# [19:42] <DanC> yes, as I say, it's somewhat head-in-the-sand to think that the API is Somebody Else's Problem
# [19:42] <rburns> mjs beat me to the punch
# [19:42] <anne> except for CSS :(
# [19:42] * anne works on the CSS Object Model
# [19:42] <nickshanks> do you? or are you just supposed to be doing that? :)
# [19:43] * hsivonen likes DanC's stance on the naming "confusion" with XHTML2.
# [19:43] <mjs> later
# [19:43] <anne> nickshanks, http://dev.w3.org/cvsweb/csswg/cssom/Overview.html has a list of changes
# [19:44] <anne> nickshanks, it's not my full time job
# [19:44] * anne isn't sure it's part of his job...
# [19:44] * DanC noodles on an HTML5 document-checking service
# [19:45] <nickshanks> anne: hey, cool, good to see it's alive and being worked on
# [19:45] <nickshanks> i figured you had so much other stuff to do that it night get left untended
# [19:45] <anne> DanC, like http://hsivonen.iki.fi/validator/html5/ ?
# [19:46] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [19:46] <DanC> somewhat like that, yes... does it integrate libhtml5 stuff yet? does it pass the 200 or so tests?
# [19:47] <hsivonen> DanC: I'm writing an HTML5 parser in Jav
# [19:47] <hsivonen> a
# [19:47] <hsivonen> DanC: so does not but will
# [19:48] <DanC> hmm... trying it on the WG homepage, I get "Fatal Error: XHTML public id seen. " hmm... I thought I was using <!DOCTYPE html> there.
# [19:48] <DanC> ah. no... let's try my homepage...
# [19:48] <anne> http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fwww.w3.org%2F2006%2Fwebapi%2F
# [19:48] <DanC> #
# [19:48] <DanC> Error: Element div from namespace http://www.w3.org/1999/xhtml not allowed in this context.
# [19:48] <DanC> Line 99, column 22 in resource http://www.w3.org/People/Connolly/
# [19:49] <anne> you can not mix inline level and block level
# [19:49] <anne> you're mixing <a> and <div> within a single parent
# [19:51] <anne> to be honest, I'm not entirely sure why that requirement it is there although it does make some sense to me to not allow <blockquote> test <p>test </p> </blockquote>
# [19:51] <anne> (and similar constructs)
# [19:51] <DanC> is that requirement in the html5 spec, or just in a schema that approximates it?
# [19:51] <anne> req from HTML5
# [19:51] <DanC> is that listed in the differences from HTML4?
# [19:51] * DanC checks...
# [19:52] <anne> it's in "things to possibly add"
# [19:52] <hsivonen> DanC: %Flow has become bimorphic
# [19:52] <DanC> once more, please, hsivonen , in english?
# [19:53] <gsnedders> DanC: it can have one of two states, not both at once
# [19:53] <hsivonen> DanC: what was mix of block and inline in html4 is either block or inline in html5
# [19:53] <DanC> any reason why?
# [19:54] <anne> what does "<div>test<p>test</p></div>" mean?
# [19:54] <anne> was one of the reasons I think
# [19:54] <hsivonen> DanC: I could guess but Hixie knows
# [19:54] <DanC> it means a div element with some text followed by a p element.
# [19:56] <hsivonen> DanC: http://intertwingly.net/blog/2007/05/08/Dont-Break-The-Web#c1178698369
# [19:56] <DanC> the http://wiki.whatwg.org/wiki/Differences_from_HTML4 page gets "Fatal Error: XHTML public id seen." too. doesn't HTML5 just ignore stuff in the <!DOCTYPE >?
# [19:57] <anne> It's a conformance error though...
# [19:57] * anne wonders if http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#whitespace implies that mobile browsers are supposed to support XML 1.1 too...
# [19:58] <hsivonen> DanC: it is a prototype parser that predates the spec. working on a real parser. will announce when ready
# [19:58] * Quits: rburns (robburns@208.54.95.1) (Connection reset by peer)
# [19:58] <DanC> "Writing a WYSIWYGish editor for HTML is harder if one is to support anything that browsers handle." is arguable, but not justified there. I wonder if tinyMCE and the like use this constraint
# [19:58] * Joins: rburns (robburns@208.54.95.1)
# [19:59] <nickshanks> hsivonen: could you estimate an ETA for tha
# [19:59] <nickshanks> t
# [19:59] <hsivonen> nickshanks: "soon"
# [20:00] <nickshanks> before my kettle boils?
# [20:00] <DanC> java isn't my cup of tea; I'm a little bummed that sam ruby has switched to ruby; I was hoping the python libhtml5 would be sorta the leading implementation. I like python. But I suppose as long as it's *a* leading implementation, I'm fine.
# [20:00] <anne> We'll fix it when needed
# [20:01] <hsivonen> java has the best lib ecosystem for this sort of thing
# [20:01] <DanC> I'm interested to start test-driven validator development, a la http://www.tbray.org/ongoing/When/200x/2007/01/30/XML-2#c1170426928.971842
# [20:01] * anne has hopes for a standalone C parser
# [20:02] <rburns> DanC, I wanted to understand the recent email to the list serv. You said: "I'd like at least two people to do thorough reviews of each section of the spec, and send their comments for discussion in the WG". Does that mean you want those two to thoroughly review the entire draft. Or does it mean you want at least two members to review each section (chapter or subsection) where a different two or more would review each section?
# [20:02] <DanC> java and debian don't get along well yet. I'm trying out ubuntu; maybe I could get modern and take Java seriously. dunno.
# [20:02] <DanC> the latter, rburns
# [20:02] <hsivonen> DanC: I can implement to tests if someone else contributes tests
# [20:02] <DanC> (forall ?section (exists ?person (reviewed ?section ?person))
# [20:03] <rburns> OK :-)
# [20:03] <anne> html5lib has lots of tests that can be reused
# [20:03] <hsivonen> anne: that's the plan
# [20:03] <DanC> yes, html5lib is proceeding nicely in test-driven fashion
# [20:04] * hsivonen will write to spec first to tests second
# [20:04] <anne> that's a good way to find bugs in the tests :)
# [20:04] <DanC> I've been noodling on how to use a wiki to build/maintain the diagnostics used by a checking tool
# [20:08] <DanC> when a checking tool gives a user some bogus message, once the user finds out what it was trying to tell them, they should be able to tweak the message, wiki-style
# [20:10] * hsivonen has been thinking of that style for translating messages
# [20:14] <Philip`> Hmm, the mobile XHTML scene doesn't seem entirely dreadful - out of an arbitrary collection of 4000 .mobi pages of which 109 use application/xhtml+xml, ignoring the totally broken http://peterbe.mobi/ which is in my list lots of times for some reason, only one isn't well-formed XML (and that's only because it's got © and real browsers should work on it) and all have the right xmlns
# [20:14] <Philip`> (though that's far too few pages to get particularly meaningful results)
# [20:15] <DanC> I go around changing   to   , but it seems a little silly.
# [20:16] * DanC noodles on a ftf meeting in late July or Aug ...
# [20:17] <rburns> If &copy is in the portion of the XML in the HTML namespace, shouldn't the reference be recognized? (probably isn't required if the UA doesn't retrieve the DTD, but really).
# [20:18] <DanC> for all the talk of suveying top web sites, I haven't seen much progress. have I missed something?
# [20:18] <DanC> XML entities have nothing to do with namespaces, currently.
# [20:19] <Philip`> rburns: I wasn't retrieving the DTD - just passing the document to Python's minidom, which seems to use Expat and ignores DTDs
# [20:20] <anne> XML should just gain a bunch of HTML entities
# [20:20] <anne> and get decent error handling
# [20:20] <gsnedders> users. don't. like. parse. errors.
# [20:20] <Philip`> XML needs a much bigger version number too
# [20:20] <rburns> DanC, yeah when I think about it I realize that they're not, but that's seems like an oversight of the xml namespace / xml recommendations
# [20:20] <anne> Philip`, :)
# [20:21] <DanC> users don't like parse errors in somebody *else's* content. but authors like good diagnostics.
# [20:21] <DanC> if I wrote <b><i>..</b></i>, I want my computer to tell me asap. (I love nxml-mode)
# [20:22] <rburns> Its these character reference entity parse errors that are much more frustrating to authors than genuine well-formedness errors.
# [20:22] <anne> http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#test_non_text_alternatives_1 seems also broken
# [20:23] <rburns> No, I think there they're saying that non-semantic images should be added through CSS. All others should have an alt attribute with a meaningful description.
# [20:24] <rburns> or am I misunderstanding what you're flagging?
# [20:25] <anne> sometimes an image is just there it illustrate what the content already tells you
# [20:26] <anne> alt=something wouldn't help there
# [20:27] <oedipus> if an image is needed to illustrate a concept, there MUST be a textual equivalent
# [20:28] <anne> I'm not saying it's needed
# [20:28] <rburns> yeah, they acknowledge the problem of automagically testing for meaning. However, even if the image is described in detail in the surrounding prose, the alt should at least mention that, otherwise the reader will assume they're missing something in that image.
# [20:28] <hsivonen> does real AT support SVG <desc> these days?
# [20:28] <anne> do they support SVG at all?
# [20:29] <oedipus> a lot can be conveyed by describing Lord Cornwallis' portrait that isn't covered by "Portrait fo Lord Cornwallis" -- how he is dressed, the setting, the objects in view all add detail to the portrait (that's what longdesc is for!)
# [20:29] <anne> rburns, isn't that what alt="" is for?
# [20:29] <anne> oedipus, thinking that people will use longdesc for Flickr for instance seems unreastic
# [20:29] <oedipus> i have not been able to find a screen-reader that supports SVG, although the DAISY consortium is working on a CDF to integrate SVG illustrations into Digital Talking Books
# [20:30] <rburns> No, I think it would need to be something more like alt="this image portrays the blah blah blah described previously"
# [20:30] <billmason> Anyone using a screen reader would not thank you for that.
# [20:31] <rburns> alt="" would say to me that the author through that in there to stop the nagging from the vvalidator
# [20:31] <oedipus> i don't care what's on flicker (sp?) - it's when i'm trying to ascertain if, after 20 years, i remember the design, for example of a particular counrty's flag
# [20:32] * Joins: michelegera (michele@87.2.174.154)
# [20:32] <oedipus> to billmason - the key is enduser control - either follow a link to the longdesc, or choose to have it rendered in place of the image; plus with aural CSS, the end user can override any settings set by a (usually sighted) author
# [20:33] <billmason> My response was to rburns, not to longdesc.
# [20:33] <oedipus> sorry bill
# [20:33] <rburns> anne, searching for images requires elaborate descriptive text. So someone on flickr (especially as the library grows) will need to describe the image to find it and for others to find it. flickr (and other tools) need to make the task easier to help all consumers of images.
# [20:34] <rburns> billmason were you referring to the blah blah blah (thas was just a placeholder since its a hypothetical example and I didn't know what to say to describe it)
# [20:34] <anne> that's not the only way to enable searching of images or multimedia content for that matter
# [20:34] <anne> and as I said, it's unrealistic
# [20:34] <hsivonen> DanC: http://krijnhoetmer.nl/irc-logs/whatwg/20070607#l-339
# [20:34] <rburns> no, its not the only way, but its one of the better ways these days
# [20:34] <billmason> No, I was referring to the entire alt value you were proposing.
# [20:35] <rburns> billmason, ok
# [20:36] <anne> it's not the better way
# [20:36] <anne> it requires years of work to describe all photos on flickr
# [20:36] <oedipus> i need to put some of my photos from "did i leave the lens cap on again?" http://my.opera.com/oedipus/albums/ up on flicker and hear what happens - this is a longtime pet project of mine (http://my.opera.com/oedipus/blog/my-fifteen-minutes-of-fame) where i asked a community to describe photos i had taken
# [20:38] <DanC> hsivonen, the <div>test<p>test</p></div> changed is justified by "my[Hixies'] impression that the allowing of mixed inline and block content at the same level was a bug in HTML4"? Then there's no reason not to undo it.
# [20:38] <oedipus> i want to build a library of iconic images and have them described in a 2 field form: the first would be a terse description (for ALT text), the second would be an unlimited TEXTAREA - the name of the project is "Is a Picture Worth A Thousand Words?"
# [20:38] <Hixie> DanC: well, the question is, what does it mean? it really seems very wrong to me to have inline and block content as siblings.
# [20:38] <Hixie> DanC: everything in the design of html seems counter to this concept.
# [20:39] <DanC> <div>test<p>test</p></div> means a div element containing a bit of text and a p element.
# [20:39] <Hixie> what's the bit of text? a header? a paragraph?
# [20:39] <DanC> it's a bit of text.
# [20:39] <Hixie> that doesn't cut it for me
# [20:39] <Hixie> i don't know what to do with that
# [20:40] * hsivonen waits for this hit the semantic fan on the mailing list
# [20:40] <rburns> there aren't too many places that allow it in HTML 4: td, th, li, dd, div. Any others?
# [20:40] <Hixie> <div> means that anywhere allows it, basically
# [20:40] <anne> Hixie, implied paragraph?
# [20:40] <oedipus> in regards allowing mixed inline and block content, would it apply - in your opinion - to a single QUOTE element, as i've outlined on public-html?
# [20:40] <DanC> do in what sense? why do you have to do anything? the software and the people have consensus on what it means. the spec has no good reason to say otherwise.
# [20:40] <Hixie> if it's an _implied_ paragraph, then we should imply a <p> around it
# [20:40] <Hixie> DanC: i don't understand what "a bit of text" means
# [20:40] <anne> and break content?
# [20:41] <Hixie> anne: right, so we can't do that
# [20:41] * anne meant it in the "semantic" sense
# [20:41] <oedipus> what is an implied paragraph - things need to be explicitly bound (have definite start and end points for all types of processing)
# [20:41] <Hixie> i don't think i've ever seen inline and block content used next to each other in a legitimate way
# [20:41] <anne> much like <h1><h2> the <h2> there implies a section
# [20:41] <anne> we don't wrap <section> around it though
# [20:42] <DanC> what seems ligitimate to one person seems pretty irrelevant, to me. "everything in the design of html" is a hodgepodge anyway.
# [20:42] <oedipus> ok, anne and ian, then i'll settle for a reformed and strengthened Q element, with a for/id association with the CITE element
# [20:42] <Hixie> anne: i honestly don't think that it _is_ an implied paragraph, though
# [20:42] <Hixie> oedipus: see the spec, we've already done that
# [20:42] <Hixie> or maybe we've only done it for <blockquote>, i forget
# [20:42] <anne> i think for both, but without the need for for/id
# [20:43] <oedipus> i noticed implied fieldsets and no FIELDSET element - that is dangerous
# [20:43] <DanC> I tried introducing this constraint in HTML 2; couldn't justify it; took it out. It got added back into XHTML strict, but I'm not sure there's much value in it.
# [20:43] <DanC> maybe an uber-pedantic HTML5 subset could rule it out, but I see little grounds.
# [20:44] <anne> Hixie, don't you need to define the meaning anyway if content does it?
# [20:44] <Hixie> DanC: well, certainly we can review use cases and so on, but i haven't seen any use cases for inline and block content to ever be siblings
# [20:44] <Hixie> anne: the meaning can be "this makes no sense" if it's non-conforming
# [20:44] <DanC> the best argument I've seen is "it complicates implementation of direct-manipulation editors". If that claim is backed by some research, that would be more interesting.
# [20:44] <DanC> my homepage is a usecase. I've got an <li> with some text and then a <div>
# [20:44] <oedipus> the for/id model can be used to reuse abbreviations, though - optimally through reference to an external expansions document, so that - like a sitewide stylesheet - it can be appended once and reused anywhere else on the site; abbreviations, though, do need for/id associations for reuse purposes
# [20:45] <anne> oedipus, they have that implicitly in HTML5
# [20:45] <anne> oedipus, as well
# [20:47] <oedipus> sorry, anne - hard to keep up and listen to myself type and my screen reader spit back audio at me - to what were you referring re: implicitly in HTML5?
# [20:47] <Hixie> DanC: uri?
# [20:47] <Sander> Hixie: <div><img><p></p></div>? Or <h2><img>? Or... (etc). That's a pretty common pattern out there.
# [20:47] * Joins: mjs (mjs@17.255.104.72)
# [20:47] <anne> oedipus, HTML5 defines implicit association for <abbr> so you can reuse it within the same page
# [20:47] <Sander> <h2></h2><img> even
# [20:47] <Hixie> Sander: that's exactly the kind of thing we want to avoid -- the <img>, when replaced as text, is a paragraph.
# [20:48] <DanC> sorry, my homepage is http://www.w3.org/People/Connolly/ (uri was given before you tuned in)
# [20:49] <Hixie> DanC: i do not consider that markup to be legitimate. I think what you have there is a list item with two paragraphs. I don't even know how to describe what you have now, given that <div> doesn't have any meaning.
# [20:49] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [20:49] * Joins: dbaron (dbaron@63.245.220.242)
# [20:49] <Sander> Ah, I see your point. But can you really say that the alternate text for a logo image, or an icon, or things like that, is a "paragraph"?
# [20:49] <Hixie> DanC: in fact it looks very much like you're using the <div> to mean "line break"
# [20:49] <Hixie> which is completely bogus imho
# [20:50] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [20:50] <Hixie> Sander: if it's presentational it shouldn't be an <img>.
# [20:50] <Sander> I consider a logo - at least - to be content.
# [20:50] <Hixie> Sander: do you have a sample page showing what you mean? I'm not really following well.
# [20:50] <DanC> I'm using <div> to mean "a little block of stuff on its own"
# [20:51] <DanC> paragraphs are made of sentences and such. none of the stuff in my travel schedule is paragraphs
# [20:52] <Hixie> DanC: in fact imho your whole thing isn't an <ol>. It should be a <dl> with multiple <dd>s, or a <dl> with <dd>s containing <p>s followed by <aside>s.
# [20:52] <Hixie> imho.
# [20:52] <DanC> I get conflicting advice on whether to use dl or ol for schedules like this. Are we really expected to bake the aesthetic judgements of one person into the HTML 5 standard?
# [20:53] <Hixie> if we want to make html interoperably interpretable, yes, we need a clear definition.
# [20:53] * Hixie notes that he included <div> in the spec against his better judgement and only really considers it to be valid as an escape hatch when there really isn't anything better in HTML.
# [20:53] <DanC> in what way is interoperability at risk with <li>text<div>...</div></li>?
# [20:54] <Hixie> we haven't defined what that means.
# [20:54] <Hixie> and i don't see any sane definition.
# [20:54] <DanC> we have to the satisfaction of all concerned.
# [20:54] * Joins: hyatt (hyatt@17.255.105.178)
# [20:54] <Hixie> clearly not to the satisfaction of all concerned :-)
# [20:55] <DanC> lots of software groks, and lots of authors use it, and they agree. what's the problem?
# [20:55] * hsivonen finds it amusing if the hard-core semanticists accept <li>text<div>...</div></li> but not <i>text</i>
# [20:55] <Hixie> i've already explained the problem several times
# [20:55] <rburns> HTML5 would allow <li>text<div>...</div></li>, but its not any clearer what meaning that conveys
# [20:55] * Joins: gavin (gavin@74.103.208.221)
# [20:56] <Hixie> what rburns said
# [20:56] <DanC> well, your explanation of the problem is "it's unaesthetic"
# [20:56] <zcorpan> define it as being equivalent to <li><div>text</div><div>...</div></li>
# [20:56] <rburns> I meant to change it to: <li>text<span>...</span></li>?
# [20:57] <Hixie> zcorpan: that doesn't really help much :-)
# [20:57] <hsivonen> zcorpan++
# [20:57] <DanC> if you just take the constraint out of the spec, the spec stands just as well, and better. there's no reason to explain the specific case of <li>text<div>...</div></li> ; it gets its meaning from <li> and <div> and other parts of the spec.
# [20:57] <rburns> HTML5 allows that, but its not any clearer what that means than what DanC is using
# [20:57] <oedipus> one means of associating a diagram with detailed information containing equivalent text, there is use for <DIV><P></P><IMG></DIV> - especially when one cannot add a longdescription (or doesn't want to); making the DIV a visible box will help tie together the description and the photo (low vision users switching between the two, people with spacial relationship disabilities) - for a stronger visual and accessible binding, the DIV can be made a visible contai
# [20:57] <zcorpan> Hixie: then i don't see the problem really, since the latter is conforming
# [20:57] <Hixie> rburns: <li> text <span>...</span> </li> is exactly equivalent, per spec, to <li> text ... </li>
# [20:58] * Quits: hyatt (hyatt@17.255.105.178) (Quit: hyatt)
# [20:58] <hsivonen> oedipus: that's what <figure> is for
# [20:58] <oedipus> that WAI-ARIA syntax is: <div class-"caption-and-img" aaa:labelledby="#img1"><p aaa:owns="#img1"></p><p><img id="img1" alt="xxx" src="accessibleelement"></p>
# [20:58] <Hixie> DanC: imho that markup is bogus. it doesn't convey the meaning you are trying to convey, and the spec has multiple features that allow you to convey the right meaning. having the spec support your bogus markup doesn't help anything.
# [20:58] <hsivonen> oedipus: that's awful compared to <figure>
# [20:58] <oedipus> it's backwards compatible...
# [20:59] <DanC> I don't see the relevance of your opinion, given, the level of deployment of the idiom.
# [20:59] <DanC> having the spec support this idiom increases the consistency between the spec and the web.
# [21:00] <Hixie> changing what is conforming doesn't affect legacy content
# [21:00] <Hixie> the spec defines how to handle that case
# [21:00] <Hixie> it just doesn't condone it
# [21:00] * Quits: zcorpan (zcorpan@84.216.41.183) (Ping timeout)
# [21:01] <DanC> let's try another take... what should a document checking tool say to me when I write <li>text<div>text2</div></li>?
# [21:01] * Joins: zcorpan (zcorpan@84.216.43.3)
# [21:01] <DanC> i.e. what's some helpful advice? if it's considered less-than-fully-conforming, what's a useful diagnostic?
# [21:03] <Sander> Hixie: unsuccessful at finding a sample page; trying to construct something which holds together, I keep realizing it's either a list, or the image is part of the paragraph, or something else which means that you're right and the image shouldn't be a sibling of block-level content. I still feel there might be cases where this doesn't hold, but for the moment you've convinced me.
# [21:03] <oedipus> hsivonen: there is a world of difference between a caption alt-text and a long description; why is LONGDESC not part of HTML5, then? the average user wants to know, as quickly as possible what is being illustrated, so that they can make an educated decision to get more information from a LONGDESC - it's a question of granularity
# [21:03] <Hixie> DanC: "The meaning of this list item's contents are ambiguous. Consider wrapping the inline content ("text") with an appropriate block-level element such as <p>. Consider replacing the <div> with more a appropriate element such as <section> or <aside>."
# [21:04] <Hixie> Sander: :-)
# [21:04] <DanC> if I replaced <div> with <aside>, wouldn't the constraint still be violated?
# [21:05] <DanC> I think we disagree on when <p> is appropriate. Encouraging people to use <p> for things other than complete thoughts written out in sentences is pernicious.
# [21:05] <Hixie> (looking more closely, the <br> there is bogus too)
# [21:06] <DanC> hmm.... really? the br is probably there because I haven't really learned CSS, but I'm not sure; care to teach me?
# [21:06] <anne> oedipus, it requires too much from authors to do it correctly and they're not using it
# [21:06] <Hixie> DanC: I would say the correct markup of the <li> would, ignoring the inline elements for ease of typing here, be <li> <p> May 30-Jun 1 to Mountain View CA for TAG meeting </p> <nav> <a> trip stuff </a> </nav> </li>
# [21:07] <Hixie> DanC: or something along those lines
# [21:07] <DanC> you really think a <p> is appropriate? I don't think that's a paragraph.
# [21:07] <Hixie> a paragraph is typically a block of text with one or more sentences that discuss a particular topic, as in typography, but can also be used for more general thematic grouping
# [21:07] <Hixie> (according to both the html5 spec and the dictionary)
# [21:08] <oedipus> anne: i'm using it, and for reading a book on the web, such as jakob riis' "how the other half lives" is MEANINGLESS without detailed description of the photographs
# [21:08] <DanC> doesn't the <li> serve as a the thematic grouping here?
# [21:08] <Hixie> yes, but you have subgroups within the <li>
# [21:08] <Hixie> you are separating the event data with links about the event data
# [21:08] <Hixie> thus, two subgroups
# [21:10] <oedipus> How the Other Half Lives: http://www.cis.yale.edu/amstud/inforev/riis/title.html
# [21:10] * Joins: briansuda (briansuda@82.221.34.106)
# [21:10] <oedipus> Illustrations contained in How the Other Half Lives: http://www.cis.yale.edu/amstud/inforev/riis/illustrations.html
# [21:11] <oedipus> online courses and educational materails DEMAND longdescs (and i do know a handful of professors who do use them)
# [21:11] <DanC> hmm... I see the slug in <li>slug <p>desc</p></li> as analagous to the bit of text beneath one heading and above the subheading.
# [21:12] * oedipus when i capitalize i'm not shouting - it's the only formatting that doesn't keep my screen reader from reading "underline" or "asterisk" only, without the accented word
# [21:12] <anne> oedipus, :)
# [21:12] <anne> oedipus, would <object> extensive fallback </object> not help?
# [21:13] <oedipus> i have added emoticons to my screen reader's dictionary
# [21:13] <anne> I suppose longdesc could be added if there's enough demand for it. I suppose it hasn't been considered much yet.
# [21:13] <anne> much like headers=
# [21:14] <Hixie> DanC: ...which is a <p> :-) (typically inside a <header> if it's a subheading as opposed to a heading of a subsection, if you see what i mean)
# [21:14] <oedipus> i am constructing a case for and against LONGDESC which i hope to have up on the wiki today (fingers crossed)
# [21:14] * Quits: gsnedders (gsnedders@86.139.123.225) (Quit: Don't touch /dev/null…)
# [21:14] <anne> oedipus, cool
# [21:14] * Quits: rburns (robburns@208.54.95.1) (Connection reset by peer)
# [21:16] * Joins: rburns (robburns@208.54.95.1)
# [21:16] <rburns> I think for the sake of backwards compatibility we should be careful about removing things that are in HTML4. Adding semantic expression is not too troubling (like aside header and footer), but removing semantic expression (without cause) is a bad thing (like @headers, @summary and @longdesc),.
# [21:16] <anne> http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#test_style_sheets_use is also problematic given HTML5 as currently specced
# [21:16] <DanC> well, I can see your position, but I'm not convinced. I think <li>slug<p>more</p></li> is just fine. It's widly used and supported, with no interop issues. There's no hold left in the spec if you delete the constraint.
# [21:16] <DanC> hole
# [21:16] <anne> rburns, we should only add things with clear use cases
# [21:16] <oedipus> i'm also working on a wiki page for retention of the summary attribute
# [21:17] <rburns> anne, I'm more speaking to the removal of things
# [21:17] <Hixie> rburns: we're not removing anything from the implementation requirements. we are, however, making the language simpler where the extra complexity isn't a distinct win.
# [21:17] <anne> rburns, HTML5 started with a clean slate
# [21:17] <zcorpan> oedipus: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-June/006669.html
# [21:18] <rburns> anne, nothing starts a clean slate. And my understanding is that backwards compatibility is a goal for the spec
# [21:18] <Hixie> DanC: i understand that you think it's fine. i think it's ambiguous, i don't understand how to write the part of the spec that would define what it means, and i think there are significantly better ways of writing that kind of markup.
# [21:18] <anne> rburns, with the web and implementations, yes
# [21:18] <anne> rburns, not so much with conformance
# [21:18] <DanC> which part of the spec would you have trouble writing?
# [21:18] <anne> (mostly the web actually)
# [21:19] <anne> rburns, or HTML4
# [21:19] <Hixie> DanC: the part that defines what the meaning of markup that has mixed inline and block content is
# [21:19] <zcorpan> Hixie: what would authors gain by changing <img><p> to <p><img><p>? they have to do it if they want to switch to conforming html5, and i don't see what the win is
# [21:19] <DanC> care to help me find that part?
# [21:20] <DanC> oops; I read too fast.
# [21:20] <Hixie> DanC: that part isn't there now, because the mixing of inline and block isn't allowed.
# [21:20] <DanC> why would the spec need to define the meaning of that combination specially?
# [21:21] <DanC> if you just delete the constraint, why is the spec not OK?
# [21:21] <oedipus> anne: i think there is an equal need for a longdescriptor for both figures and embedded objects - the problem with the HTML5 WG's spec is that it is hard to determine precisely what element is being discussed - i would expect before hearing "contexts in which this element may be used" to hear (or, if i could, see or feel) the name of the element being addressed
# [21:21] <Hixie> zcorpan: it's basically the same win as not having <b> <i> </b> </i> -- ease of maintanence, unambiguous conveyance of the intended meaning, and so forth.
# [21:21] <anne> oedipus, the name of the element should be mentioned before that, it's part of the section heading
# [21:21] <Hixie> DanC: the spec has to define the meaning of what it allows.
# [21:22] <DanC> <p><label>Address: <textarea name="a"></textarea></label></p> is bogus. that's not a paragraph.
# [21:23] <Hixie> how is it not a paragraph?
# [21:23] <anne> If both inline and block level are within a single parent the meaning is identical when the inline level content would be wrapped in a <div>
# [21:23] <zcorpan> anne: yeah
# [21:23] <Hixie> anne: which is an open issues itself
# [21:23] <DanC> it's not written in sentences. it's not "A paragraph is a self-contained unit of a discourse in writing dealing with a particular point or idea, or the words of an author." -- http://en.wikipedia.org/wiki/Paragraph
# [21:24] <Hixie> DanC: sure it is
# [21:25] <Hixie> DanC: though if you're arguing that we should introduce a new element to separate sentence-based paragraphs as found in prose from thematic paragraphs as found in applications and dialog boxes, i suppose we could introduce such an element
# [21:25] <Hixie> it would be an expensive thing to do, and i'm not sure there's any advantage to it, but it's an option
# [21:25] <oedipus> anne: i have to make a text image of it using lynx - JAWS 8 can't handle the page in IE7 and FireFox, and i didn't have much more luck with FireVox
# [21:25] <zcorpan> if we do that, it could be called <div> :)
# [21:25] <DanC> exactly. <div>.
# [21:26] <zcorpan> although i think using <p> for such uses is fine
# [21:26] <DanC> I suppose I could live with a watered-down definition of <p>; it grates against me to use it in examples, though.
# [21:26] <Hixie> <div> isn't that
# [21:26] <Hixie> <div> is meaningless by definition
# [21:26] <zcorpan> the definition isn't set in stone, is it?
# [21:27] * anne likes the <p><label> stuff
# [21:27] <anne> don't break it!
# [21:27] <DanC> by what definition? how about changing the definitions so that <p> is a normal paragraph and <div> is a thematic grouping that isn't necessarily discourse?
# [21:27] <Hixie> <div> and <span> are the extension mechanisms of HTML. We need two elements that are by definition meaningless so that people can do stuff we haven't thought of.
# [21:27] <anne> <p> is much nicer because it has some default styling
# [21:28] <Hixie> they are, as it were, sacred in their virginity. ;-)
# [21:28] <anne> (besides display:block)
# [21:29] <zcorpan> another argument for changing bimorphic to flow is that it makes the rules simpler, so easier for authors
# [21:29] <DanC> wild.. <blockquote>xyz</blockquote> is also prohibited. ah. that's more of the stuff that gets old after you try to use XHTML strict for a while.
# [21:29] <rburns> Hixie and DanC, I can see what you're both saying (though I can't defend your markup DanC :-)). However, I wonder whether these types of fringe cases are beyond what the spec should seek to address. That is we should try to provide clear content models; clear implementation algorithms, and expressive semantics where reasonable. We might even have a non-nomrative chapter that uses DanC's homepage as an example (where its transformed into a prettier HTML5 mark
# [21:29] <Hixie> zcorpan: allowing any element anywhere makes things easier too :-)
# [21:30] <anne> DanC, I think <blockquote> should allow inline level content
# [21:30] <Hixie> DanC: that's a vestige of HTML4
# [21:30] <oedipus> why is there nothing analagous to LONGDESC or <OBJECT> extensive fallback </object> in the media element attributes for video and audio - one might want to slash need to read a transcript (either because one can't process sound, or one has only a reading knowledge of the natural language contained in the audio
# [21:30] <rburns> zcorpan, especially authors coming from an HTML4 background
# [21:30] <zcorpan> we wouldn't need the structural inline concept
# [21:30] <anne> DanC, basically making it switch between sectioning and paragraph level element
# [21:30] <anne> people use it that way already and it makes sense
# [21:30] <Hixie> rburns: i think we need to define the meaning of anything we allow, it would imho be irresponsible of us to do otherwise
# [21:31] <anne> it's not much different from <p><q>....</q></p> I suppose but I don't really care about that
# [21:31] <oedipus> zcorpan: thanks for the pointer
# [21:31] <Hixie> i don't have a strong opinion against making blockquote imply that it is a |paragraph| if it contains inline only
# [21:31] <anne> oedipus, <video> and <audio> both allow "extensive fallback" too
# [21:31] <anne> Hixie, good, fix it! :)
# [21:32] <oedipus> anne: thanks for clarification
# [21:32] <Hixie> anne: you sent e-mail about that, no? it's on the list if so
# [21:33] <DanC> that still wouln't allow <blockquote>Everything should be as simple as possible and no simpler. <address>Einstein</address></blockquote>, would it?
# [21:33] <oedipus> i still think there should be only one quote element, as a quote is a quote is a quote, and there is precedent <ins><del> for an element acting both as a block and as an inline element
# [21:34] <Hixie> DanC: correct. then again, that would be wrong use of <address> anyway. and wrong use of <blockquote> since einstein didn't say "einstein" after saying that.
# [21:34] <rburns> Hixie, that brings up my early counter-example. How is DanC's any more ambiguous in meaning than <li> text <span>...</span> </li> is exactly equivalent, per spec, to <li> text ... </li> which is allowed by the spec. In other words we're not going to allow that as <div>, but we will allow it as <span>. But I can't tell any more clearly what it means if DanC changes <div> to <span>.
# [21:34] <anne> I might have, I guess
# [21:34] <Hixie> oedipus: <ins> and <del> are the poster children of why having one element be both inline and block is a bad idea. :-)
# [21:35] <anne> DanC, I might be willing to volunteer for making a "working draft" out of that wiki page
# [21:35] <Hixie> rburns: the problem is that <span> really introduces absolutely no semantics, whereas <div> introduces the nebulous concept of it being "a different block".
# [21:35] <DanC> the diffs from html4?
# [21:35] <anne> If people think such a document would help to have on TR/
# [21:35] <oedipus> hixie: well, one finds precedent where one can... not my first choice of examples, either
# [21:35] * Quits: michelegera (michele@87.2.174.154) (Quit: michelegera)
# [21:35] <hsivonen> Hixie: for practical purposes, attribution inside blockquote is needed
# [21:35] <anne> DanC, yeah
# [21:35] <Hixie> rburns: whereas since there is no other block in the first place, it's not clear what "different block" means.
# [21:35] * DanC wonders if mjs is around
# [21:36] <Hixie> rburns: you can always remove <span> elements (that have no attributes) without making any difference to the meaning
# [21:36] <DanC> I'd like a combination of diffs-from-html4 and design principles. i.e. what's changed and why, mixing in some discussion of status.
# [21:36] <Hixie> rburns: but removing <div>s can change the meaning, e.g. it can merge two... "blocks"... into one sentence.
# [21:37] <Hixie> oedipus: precedent that shows that something works is good. precedent that shows what a disaster teh idea can be, is a strong argument against. :-)
# [21:37] <DanC> though separate design principles and diffs-from-html4 is prolly good too.
# [21:37] <Hixie> hsivonen: why? (given our definition of <blockquote><p><cite>)
# [21:38] <anne> styling
# [21:38] <hsivonen> Hixie: typographically, you want the attribution inside the same CSS box. It is easier to write using WYSIWYG tools. and <cite> has the wrong default presentation for people.
# [21:38] <DanC> I have trouble with the blockquote/cite discussion... it brings out the html2-editor in me; i.e. the guy who tried to design parts of HTML, who did at least as much harm as good.
# [21:38] <hsivonen> afk
# [21:38] <rburns> hixie, I would say removing <div> removes default presentation and meaning. Removing <span> removes meaning (granted under-specified meaning like <div>), but does not remove any default presentation. In both cases, the author had some meaning in mind. But I couldn't tell you what it was in either case.
# [21:39] <DanC> <cite> was supposed to capture the chicago-manual-of-style idiom for titles of works. I have lost track of what it means these days.
# [21:39] <anne> the guy who said it
# [21:40] * anne kind of likes the <blockquote> <address> construct
# [21:40] <anne> I believe mozilla.org uses that
# [21:40] <zcorpan> <blockquote>Everything should be as simple as possible and no simpler. <credit>Einstein</credit></blockquote>
# [21:40] <zcorpan> html 3.0
# [21:40] <Hixie> rburns: i'm not really talking about the presentation here, that's an entirely separate problem.
# [21:40] <Hixie> imho
# [21:40] <oedipus> if you don't have <span> how can you mark a natural language switch. assuming that the natural language declared for the document is "en": Obviously, although the object portrayed in <a href="pipe.html"><span lang="fr">La trahison des images</span> (The Treachery of Images)</a> is obviously a pipe, it is not, itself a pipe, but the representation of a pipe, which is an entirely different phenomenon.
# [21:40] <anne> zcorpan, what did HTML+ do?
# [21:40] <Hixie> hsivonen: it is true that there are limitations in CSS that we need to fix (just ask anne about <di>)
# [21:41] <zcorpan> anne: iirc html+ didn't have <credit> for <blockquote>
# [21:41] <anne> Hixie, I'm still not sure if making CSS that much more complex is really worth it though
# [21:42] <anne> Hixie, contrary to making some HTML constructs slightly more complex
# [21:42] * oedipus skip CSS21 and go straight to CSS3 - do not pass go, do not collect $200
# [21:42] <anne> (besides the fact that nobody is really working on tackling those issues)
# [21:42] <rburns> oedipus, if your comment about span referred to what I was discussing, we we're talking about the use by an author of <span> and <div> with no attributes (therefore under-specified semantics).
# [21:43] <DanC> use case: an excerpted quote, with attribution. Semantics have to be captured without CSS, since it's a blog article and it's going to get syndicated across stylesheets. I'd like to see an example in the html5 spec section on <blockquote>.
# [21:43] <anne> write one :)
# [21:44] <DanC> well, I just did, but Hixie said my <address> usage was bogus.
# [21:44] <DanC> I'm hoping the channel produces some advice.
# [21:44] <oedipus> rburns: thanks - can't wait until the WAI-ARIA politeness rules are implemented so that i can hear what's coming in as well as going out, so i'm often missing chunks of the conversation
# [21:44] <anne> DanC, ah HTML5 says to use <blockquote><p>quote</p><p>more of that</p></blockquote><p><cite>Einstein</cite></p>
# [21:44] <zcorpan> DanC: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-documents0.html#nav-bar
# [21:45] <DanC> <cite> is block-level?
# [21:45] <zcorpan> no
# [21:45] * Hixie notes that he's certainly open for better solutions to all this
# [21:45] * oedipus would be using chatzilla, for which FireVox implemented WAI-ARIA roles and states, but chatzilla always crashes on me when using FireVox
# [21:45] <anne> I like reusing <address> for attribution
# [21:45] <Hixie> i like the <blockquote> <credit> idea
# [21:46] <anne> Except that <address> doesn't work for <q>
# [21:46] <Hixie> reusing <address> might work if nobody has <address> elements in <blockquote> elements already, unless they are already doing it "wrong"
# [21:46] <oedipus> why <address> for attribution? why not <cite>?
# [21:46] <anne> So maybe <credit> is better
# [21:46] <DanC> zcorpan, what about #nav-bar?
# [21:46] <anne> Hixie, mozilla.org does it "wrong"
# [21:46] <zcorpan> DanC: oh, scroll down to the example
# [21:47] <DanC> (URIs alone on a line are often confusing.)
# [21:47] <hsivonen> Hixie: punctuation. Works for casual authors. Check out the quote at the top of http://hsivonen.iki.fi/producing-xml/
# [21:47] <Hixie> anne: we'll have to do a scan to see how widespread it is, and sample some of the uses
# [21:47] <zcorpan> DanC: #nav-bar is part of the uri if you click in the ToC
# [21:47] <anne> Hixie, http://www.mozilla.org/contribute/writing/markup#quotations
# [21:47] <zcorpan> DanC: you'll find an example of quotation
# [21:47] <rburns> In addition to Tables model, cite and address are two areas I'd like to see much more guidance on from HTML5
# [21:47] <Hixie> hsivonen: oh i agree there are issues here, don't get me wrong
# [21:47] * Philip` doesn't like the #nav-bar links now
# [21:48] <DanC> ah... you're pointing me at a quote with attribution in the html5 spec. thanks.
# [21:48] <DanC> is it too late to restore <cite> to its former glory?
# [21:48] <oedipus> it better not be...
# [21:48] <Hixie> hsivonen: i think the real issue is holes in css, and i don't consider presentation concerns to be that important in deciding the markup structure, but the markup structure itself isn't perfect yet either.
# [21:48] <zcorpan> imho... <cite> = title of work, <address> = any contact information
# [21:48] <DanC> <cite> is for http://en.wikipedia.org/wiki/Quotation_mark#Titles_of_artistic_works
# [21:48] * hsivonen treats <cite> as title of work
# [21:48] * Hixie has to go now
# [21:48] <Hixie> bbiab
# [21:49] <anne> Yeah, the default style of <cite> sucks for attribution
# [21:49] <anne> It's great for titles of work
# [21:49] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [21:49] <hsivonen> afk
# [21:49] <oedipus> <cite> needs to be able support Dublin Core as well as human parseable text
# [21:51] <oedipus> i still maintain that <Q> needs a for/id association with <CITE> and that the attribute
# [21:51] <rburns> my thought is that <cite> should also have a type attribute to indicate the type of the cite: person, book-title, article-title, etc. In this way the use of type as an element specific enumeration would be extended
# [21:51] <anne> for/id is too complex
# [21:51] <oedipus> "cite" should be changed to src to point at a target where the quote can be found in context
# [21:52] <oedipus> where does it say that for/id is too complex?
# [21:52] <oedipus> rburns: +1 on adding a "type" attribute to <CITE>
# [21:52] <DanC> so... who will lead the charge by reviewing 3.8.5. The blockquote element, 3.8. Sections, and 3.9. Prose in detail?
# [21:53] <rburns> oedipus, why not use the cite attribute to point to the referenced cite element id or to an isbn/issn uri?
# [21:53] <zcorpan> cite="" can perhaps be dropped altogether. use <a href> inside <credit> instead
# [21:54] <oedipus> rburns: that's something i've been thinking, but just couldn't articulate
# [21:55] <DanC> hmm... 3 volunteers to do detailed reviews so far... http://www.w3.org/2002/09/wbs/40318/tasks83/results#xwhichsec
# [21:56] <oedipus> <Q for="c12" src="../lincoln.html#p3s2"></Q> points to <CITE type="bibliographic" id="c12"></CITE>
# [21:57] <oedipus> DanC: i have apparently very unorthodox views on Q and BLOCKQUOTE, but i did make an argument for combining the 2 into a single QUOTE element, as well as arguments against BLOCKQUOTE, so i don't know if you want me to review BLOCKQUOTE
# [21:58] <rburns> oedipus I think that example works well (bibliographic type is good too, though perhaps it requires even a new element).
# [22:00] <anne> HTML should not go into that much detail I think
# [22:00] <DanC> if by saying "I have unorthodox views on Q and BLOCKQUOTE" you mean that a review by you of the BLOCKQUOTE section would not emphasize the deployed/implemented understanding of HTML, then indeed, such a review is less useful to the group, I think, than one based on more emperically-backed views.
# [22:00] <rburns> DanC, I think of the prose as the meat of the recommendation. I don't think unorthodox is necessarily a problem. an unorthodox reading is more likely to draw out latent issues with the current draft.
# [22:02] <DanC> indeed, it's not necessarily a problem
# [22:03] * Quits: mjs (mjs@17.255.104.72) (Quit: mjs)
# [22:03] <oedipus> DanC: judge for yoursef: BLOCKQUOTE deprecation: http://lists.w3.org/Archives/Public/public-html/2007Apr/0102.html ; preserving and strenghening Q: http://lists.w3.org/Archives/Public/public-html/2007Apr/0066.html
# [22:03] * Joins: inimino (inimino@75.71.88.233)
# [22:04] <oedipus> in any event, i will make my reaction to the review on list and on wiki
# [22:04] <anne> deprecating elements is not useful
# [22:05] * Joins: mjs (mjs@17.255.104.72)
# [22:05] <rburns> anne, I don't think oedipus' example is that much detail. This is a basic construct that anyone writing an academic paper must include (though it can be done independent of the presentation details). Every quotation or paraphrasing is expected to credit the creator of the idea and to point to a source and specific page numbers where it could be found. Since HTML hasn't provided clear guidance on this in the past, every author is left to develop their own ad
# [22:05] <anne> we should either not have them in the language (but have them as UA conformance criteria) or have them in the language
# [22:06] * Quits: Chris (cwilso@131.107.0.105) (Ping timeout)
# [22:07] * Quits: mjs (mjs@17.255.104.72) (Quit: mjs)
# [22:08] <oedipus> rburns: i have heard this complaint from innumerable academics
# [22:09] <oedipus> by which i mean, a standard way to insert or point to or identify a citation according to the rules their academy slash language slash cultural conventions slash manual of style
# [22:11] * Joins: mjs (mjs@17.255.104.72)
# [22:15] <rburns> yes, to me it seems like a major oversight for a document language (my first sentence above was supposed to say "anne, I don't think oedipus example is NOT that much detail").
# [22:15] <oedipus> rburns & anne: what about this formulation: <Q for="c12" src="../lincoln.html#p3s2"></Q>  <CITE type=:"bibliographic" id="c12" src="dcoreinfo-al.rdf"> </CITE> note that, in the CITE element, the src attribute to point to a structured external reference resource (such as dublin core, etc.)
# [22:15] <anne> it's not extensive document language by any means
# [22:16] <anne> it's supposed to cover the 80% scenarios (from all that you encounter on the web)
# [22:17] <oedipus> it is, more and more - educational institutions are relying on computers and intranets to facillitate remote slash distance learning (more profit for less expense) from pre-school through university
# [22:17] * zcorpan wonders whether <q> is worth keeping at all (the replacement being quotation characters)
# [22:18] * anne sort of concurs with zcorpan
# [22:18] <oedipus> speaking as a speech-only user, " conveys nothing to me or to my AT - a quote needs to be capable of being styled - aurally, so it is differentiatable from the rest of the text, easily identifiable, and ACTIONABLE
# [22:19] * Sander would be sad to see it go, since he uses it every other month or so
# [22:19] * anne uses it every other month or so too
# [22:19] * anne has yet to see tanginble benefits
# [22:21] <anne> DanC, let me know if the idea to publish something the "differences from HTML4" will go through
# [22:22] * anne has to go
# [22:22] <oedipus> the way to use emphatic quotes is with CSS: <style>@media screen { em.air-quote:before (content="open-quote") em.air-quote:after (content-"close-quote")</style>  that's a <em class="air-quote">really</em> good idea, oedipus!
# [22:23] * Joins: hyatt (hyatt@17.255.105.178)
# [22:23] <oedipus> the way to use emphatic quotes is with CSS: <style>@media screen { em.air-quote:before {content="open-quote"} em.air-quote:after { content="close-quote" } }</style>  that's a <em class="air-quote">really</em> good idea, oedipus!
# [22:24] <oedipus> i can also define @media aural or @media speech rules to em.air-quote, such as change in pitch, change in voice, change in voice characteristics, play an earcon, etc.
# [22:26] <DanC> will do, anne. thanks.
# [22:26] <oedipus> Q should be reserved for quotations, and not used as emphasis or to denote irony - you can achieve the desired result using CSS
# [22:27] * Quits: hasather (hasather@81.235.209.174) (Ping timeout)
# [22:28] <oedipus> which is why a <DIALOG> element is useful - when you are writing a work of fiction, you're not quoting your characters, they are speaking
# [22:30] * Quits: rburns (robburns@208.54.95.1) (Connection reset by peer)
# [22:30] * Joins: rburns (robburns@208.54.95.1)
# [22:31] <rburns> I have to go too. I will add my name to review some of the sections (3.8 and 3.9 and 9) probably for the end of the month. Talk to you all gain. rburns out.
# [22:32] <oedipus> good to speak with you rburns - "see" you on list
# [22:32] * Quits: rburns (robburns@208.54.95.1) (Quit: rburns)
# [22:34] <oedipus> i too, need to part, in part to work on the Retention of Summary wiki page and on a for/id binding between Q slash BLOCKQUOTE and CITE (quotes would point to CITE, CITE would have a type element and a src element to link to an external resource, such as a dublin core representation of the work being cited
# [22:34] * Joins: gsnedders (gsnedders@86.139.123.225)
# [22:35] * oedipus aloha, everyone
# [22:35] * Parts: oedipus (oedipus@71.250.74.215)
# [22:35] * Quits: briansuda (briansuda@82.221.34.106) (Quit: briansuda)
# [22:39] * Quits: hyatt (hyatt@17.255.105.178) (Quit: hyatt)
# [22:39] * Quits: mjs (mjs@17.255.104.72) (Quit: mjs)
# [22:40] * Joins: mjs (mjs@17.255.104.72)
# [22:40] * Quits: mjs (mjs@17.255.104.72) (Quit: mjs)
# [22:58] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [23:03] * Joins: gavin (gavin@74.103.208.221)
# [23:11] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
# [23:12] * Joins: schepers (schepers@84.73.168.194)
# [23:44] * Joins: briansuda (briansuda@82.221.34.106)
# [23:44] * Quits: heycam (cam@203.214.95.190) (Ping timeout)
# [23:45] * Joins: hyatt (hyatt@17.255.105.178)
# [23:46] * Joins: hasather (hasather@81.235.209.174)
# [23:48] * Joins: rburns (robburns@71.57.116.81)
# Session Close: Fri Jun 08 00:00:00 2007

The end :)