Warning:
This wiki has been archived and is now read-only.
Chatlog 2009-03-26
From XHTML2
See original RRSAgent log and preview nicely formatted version.
Please justify/explain all edits to this page, in your "edit summary" text.
12:52:38 <RRSAgent> RRSAgent has joined #xhtml 12:52:38 <RRSAgent> logging to http://www.w3.org/2009/03/26-xhtml-irc 12:52:45 <Zakim> Zakim has joined #xhtml 12:52:52 <Steven> rrsagent, make log public 12:53:06 <Steven> Meeting: XHTML2 WG Virtual FtF 12:53:13 <Steven> Chair: Roland 12:54:47 <Steven> zakim, room for 8 at 13:00z for 240 mins? 12:54:49 <Zakim> ok, Steven; conference Team_(xhtml)13:00Z scheduled with code 26634 (CONF4) at 13:00z for 240 minutes until 1700Z; however, please note that capacity is now overbooked 12:55:00 <Roland> Roland has joined #xhtml 12:55:39 <oedipus> agenda: http://www.w3.org/MarkUp/xhtml2/wiki/2009-03-10-FtF-Agenda#2009-03-26 12:55:51 <oedipus> scribe: Gregory_Rosmaita 12:55:57 <oedipus> ScribeNick: oedipus 12:56:03 <oedipus> rrsagent, make minutes 12:56:03 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 12:56:10 <Steven> code is CONF4 12:56:24 <Steven> 26634 12:56:36 <Steven> Steven has changed the topic to: Code is CONF4 (26634) 12:56:59 <Zakim> Team_(xhtml)13:00Z has now started 12:57:01 <Zakim> +Roland_Merrick 12:57:17 <Roland> Zakim, Roland_Merrick is Roland 12:57:17 <Zakim> +Roland; got it 12:57:33 <Zakim> +Gregory_Rosmaita 12:57:35 <Zakim> -Gregory_Rosmaita 12:57:35 <Zakim> +Gregory_Rosmaita 12:58:17 <mgylling> mgylling has joined #xhtml 12:59:40 <Zakim> + +46.7.06.02.aaaa 12:59:58 <oedipus> previous: http://www.w3.org/2009/03/10-xhtml-minutes.html 13:00:10 <oedipus> zakim, aaaa is Markus 13:00:10 <Zakim> +Markus; got it 13:00:16 <oedipus> rrsagent, make minutes 13:00:16 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 13:00:30 <Steven> zakim, dial steven-617 13:00:30 <Zakim> ok, Steven; the call is being made 13:00:32 <Zakim> +Steven 13:01:40 <oedipus> TOPIC: Agenda Review 13:01:56 <Roland> http://www.w3.org/MarkUp/xhtml2/wiki/2009-03-10-FtF-Agenda#2009-03-26 13:02:40 <oedipus> 4 XHTML2 items: the P content model, Navigation (nl in or out?), Semantics and Elements versus Attributes, how to incorportate ITS 13:02:55 <oedipus> RM: start with news from the A.C. meeting once reach critical mass 13:03:08 <alessio> alessio has joined #xhtml 13:03:16 <oedipus> SP: would very much like to report, but want shane and mark to be here when i do 13:03:57 <oedipus> RM: brief update on PER 13:04:20 <oedipus> zakim, who is here? 13:04:20 <Zakim> On the phone I see Roland, Gregory_Rosmaita, Markus, Steven 13:04:21 <Zakim> On IRC I see alessio, mgylling, Roland, Zakim, RRSAgent, Steven, oedipus, trackbot 13:05:33 <Zakim> +??P17 13:05:41 <oedipus> MG: Shane said he'd be late yesterday 13:05:48 <oedipus> zakim, ??P17 is Alessio 13:05:48 <Zakim> +Alessio; got it 13:05:49 <alessio> zakim, ??P17 is Alessio 13:05:49 <Zakim> I already had ??P17 as Alessio, alessio 13:06:17 <oedipus> rrsagent, make minutes 13:06:17 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 13:06:53 <oedipus> scribe's note: [steven ping outliers] 13:07:43 <oedipus> minutes from last regularly scheduled meeting: http://www.w3.org/2009/03/25-xhtml-minutes.html 13:08:06 <oedipus> rrsagent, make minutes 13:08:06 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 13:08:46 <oedipus> RM: brief update with PER? 13:08:50 <oedipus> TOPIC: PER Update 13:09:34 <oedipus> SP: didn't make friday deadline due to AC meetings; have to get fiinished; still moritorium this week on publishing due to AC meeting, should be published next week, if all goes according to plan 13:09:45 <oedipus> RM: just matter of questoinnaires? 13:10:21 <oedipus> SP: PER has to be voted upon; extra administrivia - creating detailed questionnaires with pointers (creating now - have to go out simultaneously with PER anouncement) 13:10:26 <oedipus> RM: that's all we need do? 13:10:28 <oedipus> SP: yes 13:10:37 <oedipus> RM: any other administrivia? 13:10:57 <oedipus> scribe's note: deafining silence 13:12:27 <oedipus> GJR: in response to feedback and discussion at last virtual f2f i have updated the "for" attribute proposal 13:12:28 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/forAttribute 13:12:37 <ShaneM> ShaneM has joined #xhtml 13:13:11 <oedipus> GJR: changes: proposed for Text Attributes collection, not Core collection 13:14:10 <oedipus> 1. That the for/id mechanism, which is already broadly supported in user agents and assistive technologies, be repurposed and extended in XHTML2 to provide explicit bindings between labelling text and the object or objects that text labels; 13:14:10 <oedipus> 2. That the for/id mechanism serve as a means of re-using values for: ABBR, D (the single letter "dialogue" element), DFN; 13:14:10 <oedipus> 3. That the for/id mechanism serve as a means of binding a quotation, contained in the Q element, and a corresponding CITE declaration which identifies the source of the quote; 13:14:11 <oedipus> 4. That the for/id mechanism serve as a means of marking text which has been inserted, contained in an INS, and that which it is intended to replace, contained in a DEL tag, as illustrated below; 13:14:13 <Zakim> +McCarron 13:14:21 <ShaneM> zakim, McCarron is ShaneM 13:14:21 <Zakim> +ShaneM; got it 13:14:37 <oedipus> rrsagent, make minutes 13:14:37 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 13:15:18 <oedipus> TOPIC: News & Notes - AC Meeting Report 13:15:32 <oedipus> SP: much of AC meeting, but not all, in sphere of HTML5 and XHTML2 13:16:40 <oedipus> SP: started monday morning with panel - XHTML2 side represented by myself and ben adida (made cross-continental day trip); neutral people: Larry McMaster from Adobe; and HTML5 people represented mainly by David Baron 13:17:19 <oedipus> SP: nothing much to report about it; Hegeret was chair; put questions to panel; people in audience put questions as well -- no demos, just Q&A 13:17:24 <oedipus> RM: link to AC minutes? 13:17:58 <oedipus> http://www.w3.org/2009/03/23-ac-minutes.html 13:18:07 <Steven> http://www.w3.org/2009/03/23-ac-minutes#item02 13:18:09 <oedipus> http://www.w3.org/2009/03/22-ac-minutes 13:18:13 <oedipus> http://www.w3.org/2009/03/24-ac-minutes 13:19:21 <oedipus> SP: Chaals McN web standards oriented; Larry MM neutral; Sam Ruby co-chair of HTML WG; David Baron works for Mozilla, very much HTML5er; Henry Thompson, Ben Adida and myself (Steven Pemberton) 13:19:57 <oedipus> SP: at least 2 negative comments from audience: Daniel Glazman (not there physically but on IRC) - very anti-XHTML2 13:21:01 <oedipus> SP: Arun (represents mozilla) - need to ask why against XHTML2 in W3C? don't think mozilla is anti-XHTML2, but hard to separate personal opinions from corporate agendas; aim is to close down XHTML2 13:21:21 <oedipus> SP: good feedback after panel; lots of red herrings being spread in discussion; tried to expose falicies 13:21:40 <oedipus> SP: after that meeting had breakout groups - about 20 in XHTML2 breakout group 13:22:13 <oedipus> SP: not minuted in IRC, hand-made minutes - trying to find if up in w3c space yet 13:23:02 <oedipus> SP: 2 breakout groups: 1st day: discuss issues (extended panel) - on second day, discussion on what to do with situation 13:23:51 <oedipus> SP: second breakout more interesting; discussion unencumbered by knowledge of what XHTML2 is all about; Raman and Charlie Wiecha of IBM knes about XHTML2, but rest of participants very shallow knowledge 13:24:22 <Tina> Tina has joined #xhtml 13:24:25 <oedipus> SP: asked who is using 2 technologies; one person said, "since HTML5 seeks to make all pages conformant to HTML5, HTML5 is what people use 13:24:44 <oedipus> SP: explained modularization and the packaging of modules to create XHTML2 13:25:10 <oedipus> SP: because our charter has always been modularization, modules are deliverables; XHTML2 is a collectoin 13:25:39 <oedipus> SP: Arun surprised that there are big companies using XHTML and XForms 13:26:11 <oedipus> SP: meeting concluded with agreement that Sam Ruby and Steven Pemberton should work on merging HTML5 and XHTML2 13:26:52 <oedipus> SP: made it very clear in meeting that these aren't 2 slightly different markup languages, because underlying MVC architecture in XHTML2, that is laacking in HTMl5; would have to get HTML5 WG to accept that architecture so 2 can be merged 13:27:11 <oedipus> q+ 13:28:24 <oedipus> SP: if choice between merging and not merging, think should keep separate unless agree to accept XForms and extensibility 13:29:57 <oedipus> SP: SamR and i can discuss to ascertain options 13:30:08 <oedipus> SP: in conclusion, think that we are now in stronger position 13:30:44 <oedipus> SP: 2 things can happen: HTML5 people reject collaboration or we do merge and HTML5 people required to take our approaches on board (m12n, MVC, etc.) 13:30:56 <oedipus> SP: either of those 2 choices much better than shutting down XHTML2 13:31:03 <oedipus> q? 13:31:22 <oedipus> SP: SamRuby is new co-chair of HTML5 - very positive interaction with him 13:31:52 <oedipus> SP: Sam Ruby wants to work together, but a lot of work to herd that enourmous herd of cats in HTML WG 13:32:33 <oedipus> SP: doubt that core HTML5 people will accept collaboration 13:32:41 <ShaneM> zakim, code? 13:32:41 <Zakim> the conference code is 26634 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), ShaneM 13:33:08 <oedipus> GJR: did sam mention the initative at mozilla to produce a rival spec to HTML5? 13:33:08 <oedipus> http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/0c2bbb6ed726800b 13:33:08 <oedipus> https://bugzilla.mozilla.org/show_bug.cgi?id=478665 13:34:14 <Zakim> +??P15 13:34:28 <oedipus> RM: take more stable to have third version of HTML5 13:34:47 <oedipus> RM: pragmatic - how to achieve a deliverable 13:34:51 <Tina> Zakim, P15 is Tina 13:34:51 <Zakim> sorry, Tina, I do not recognize a party named 'P15' 13:34:55 <oedipus> SP: wasn't mentioned 13:35:04 <oedipus> zakim, +??P15 is Tina 13:35:04 <Zakim> sorry, oedipus, I do not recognize a party named '+??P15' 13:35:09 <oedipus> zakim, ??P15 is Tina 13:35:09 <Zakim> +Tina; got it 13:35:14 <Tina> Thank ye 13:35:16 <oedipus> rrsagent, make minutes 13:35:16 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 13:35:19 <Tina> Zakim, mute me 13:35:19 <Zakim> Tina should now be muted 13:35:54 <oedipus> GJR: previous pointers: Rob Sayre of IBM is producing a new draft which is hixie's draft minus new inventions plus all the stuff that was removed 13:36:18 <oedipus> RM: will be taking features from HTML5 spec and adding them on; means of incrementally deploying HTML5 13:36:19 <Steven> http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=978 13:36:26 <oedipus> GJR: being deployed by fiat now 13:36:29 <Tina> Zakim, unmute me 13:36:29 <Zakim> Tina should no longer be muted 13:36:41 <oedipus> SM: more socially acceptable 13:37:11 <oedipus> RM: extensibility already being done by implementation by fiat of HTML5 13:37:31 <oedipus> SP: one discussion at AC meeting in first day's breakout group was lack of extensibility 13:37:48 <oedipus> SP: consensus of breakout group was extensibility needs to be supported 13:37:51 <oedipus> q+ 13:38:01 <oedipus> SP: from POV of merging, extensibility essential 13:38:14 <oedipus> SP: long discussions about extensibility and what needs to be able to be done 13:38:30 <oedipus> SM: agreed upon definition of term "extensibility"? 13:39:23 <oedipus> SP: no definition or agreement on what would fall under rubric of extensibility; put forward strong view that people should be able to add own elements and attributes in standard way to foster new forms; cited XBL as example 13:39:34 <oedipus> SP: when i trace minutes for breakout groups will post link 13:39:38 <oedipus> ack oed 13:40:14 <oedipus> GJR: from WAI/PF's point of view extensibility and namespacing is essential, otherwise we will end up with ARIA 1.0 hard coded into HTML5, but we are already working on ARIA 2.0 13:41:05 <oedipus> GJR: WAI/PF needs to retain control over ARIA's vocabulary and definitions 13:41:22 <oedipus> SP: some people surprised that ARIA sprang from XHTML Role Module 13:41:54 <oedipus> SP: good to have BenA there on first day; would be wrong to give XML serialization to a group of people who fundamentally oppose and disllike XML/XHTML 13:41:59 <Zakim> -ShaneM 13:42:10 <oedipus> s/would be/Ben stated that it would be/ 13:42:13 <oedipus> rrsagent, make minutes 13:42:14 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 13:42:29 <oedipus> RM: return to this later - have a few comments 13:42:46 <oedipus> SP: worth watching discussion on AC forum; have to be on AC to contribute 13:43:03 <oedipus> GJR: one could always use www-archive for comments pointed at AC 13:43:25 <oedipus> SP: encouraged by meeting; interested in how the rest of the HTML WG responds to combining 2 groups 13:43:34 <oedipus> RM: should consider ramifications for XHTML 13:43:58 <oedipus> SP: LarryMM suggested i co-chair with Sam - not feasible 13:46:46 <Zakim> +ShaneM 13:46:56 <Steven> s/not feasible/not my idea of fun at the moment :-)/ 13:46:57 <oedipus> RM: first 2 topics also being worked on by HTML5 13:47:07 <oedipus> TOPIC: The P content model 13:47:13 <oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0014.html 13:47:28 <Steven> http://www.w3.org/2002/09/wbs/34257/ac2009-breakout1/results 13:47:32 <oedipus> RM: HTML5 doing much of what we are doing with P - placing limitations on it 13:47:54 <Tina> Zakim, mute me 13:47:54 <Zakim> Tina should now be muted 13:47:57 <oedipus> SP: pasted pointer to breakout session described above into IRC 13:48:07 <ShaneM> ShaneM has joined #xhtml 13:48:19 <Steven> http://www.w3.org/2002/09/wbs/34257/ac2009-breakout2/results 13:48:23 <oedipus> rrsagent, make minutes 13:48:23 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 13:48:38 <oedipus> SP: day 2 hasn't been posted yet - Sam Ruby making minutes 13:49:25 <Zakim> -ShaneM 13:49:48 <Zakim> +ShaneM 13:50:03 <oedipus> TH (from cited post): "I would argue that common concept of a paragraph is quite different 13:50:03 <oedipus> from that we currently use in the XHTML draft, and that we should 13:50:03 <oedipus> change it so that it reflect the way a paragraph is normally understood 13:50:03 <oedipus> by authors, namely the way it is currently defined in the XHTML 1.* 13:50:03 <oedipus> series languages." 13:50:47 <oedipus> TH (via post): "Note that I do not in any way claim there are no need to render, for instance, a paragraph on the side of, or even around, a table. What I am saying is that the structure of a paragraph does not admit itself to contain a table, a pre, or even a blockquote. A list is an edge case, but should we allow this I suggest the creation of an inline list element type." 13:51:06 <oedipus> RM: P content model as defined in present draft cause anyone a problem 13:51:38 <oedipus> SP: background: when originally designing text part of XHTML2, had a number of comments about the P content model not matching what perception of P is 13:52:12 <oedipus> SP: P defined in HTML4x too simple - could not embed images or table in paragraph; request was for things embedded in P be part of content model 13:52:50 <oedipus> SP: current content model of P is an attempt to do that - represent as much as possible the context of the paragraph, but also attempt to avoid P nested in P - P nested in TABLE cannot have child P 13:53:15 <oedipus> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-structural.html#edef_structural_p 13:53:46 <oedipus> from current Editor's draft: "In comparison with earlier versions of HTML, where a paragraph could only contain inline text, XHTML2's paragraphs represent the concept of a paragraph, and so may contain lists, blockquotes, pre's and tables as well as inline text. Note however that they may not contain directly nested p elements." 13:53:52 <Steven> (PCDATA | Text | List | blockcode | blockquote | pre | table )* 13:54:20 <oedipus> GJR notes he has proposal to deprecate TABLE for layout/style as BLOCKQUOTE for that use was deprecated in HTML4x 13:55:22 <oedipus> SP: always been opinion of this WG; don't explicitly say "deprecated", but agree that TABLEs are TABLEs and stylesheets should be used for layout 13:55:51 <oedipus> SP: proposed TABLE role="presentation" doesn't undo the damage, in fact almost encourages it 13:55:59 <oedipus> GJR: strong agreement - wrong approach 13:56:17 <oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0014.html 13:57:19 <oedipus> AC: no presentation - OBJECT should be used to embed video, audio, or presentation 13:57:42 <oedipus> AC: more like a user-modality for TABLE - agree with SP and GJR that layout tables should be banned 13:59:36 <oedipus> SP: understand TH's point of view - current model allows one to represent data in that way; there are also those who belive that a P can have an embeded table or list - content doesn't change because child of P - styling up to stylesheets; neither POV is disallowed - accomodates both- up to author to decide what to use 13:59:49 <oedipus> TH (from post) "But frankly I feel we have a problem. When humans communicate we do so by agreeing on the of words - and various other things outside the scope of this comment - so that when I say banana, you know its not an orange of which I speak." 14:00:12 <ShaneM> zakim, who is here 14:00:12 <Zakim> ShaneM, you need to end that query with '?' 14:00:16 <ShaneM> zakim, who is here? 14:00:16 <Zakim> On the phone I see Roland, Gregory_Rosmaita, Markus, Steven, Alessio, Tina (muted), ShaneM 14:00:18 <Zakim> On IRC I see ShaneM, Tina, alessio, mgylling, Roland, Zakim, RRSAgent, Steven, oedipus, trackbot 14:00:25 <oedipus> tina? 14:00:29 <Tina> I am, but noise in office 14:00:44 <oedipus> tina, can you explain your proposed changes to P content model 14:00:57 <Tina> oedipus: certainly. We keep the one currently in use for HTML. 14:01:12 <oedipus> RM: would like more examples - if want P element with example and discussion of this issue - could do this way (compatible with past) or new way 14:01:37 <oedipus> SP: TH wants to exclude people who believe P is something different than what she is proposing 14:01:53 <oedipus> RM: irritating when have to change prose into a list 14:02:25 <oedipus> RM: if write normal english: ingredients are: a) , b), c), but cannot style as list because is prose list 14:02:33 <oedipus> RM: that is standard natural language usage 14:03:10 <Roland> ingredients are: a; b; c. 14:03:14 <oedipus> s/a) , b), c), / a) ; b) ; c);/ 14:03:19 <oedipus> rrsagent, make minutes 14:03:19 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 14:03:32 <oedipus> SP: including a list in P is perfectly valid 14:03:39 <oedipus> RM: examples would help 14:04:24 <oedipus> SP: opened a book "a case in point is blogs:" followed by list of 10 items; i content that in natural language usage that is a single paragraph, but HTML doesn't allow the list to be part of the P 14:04:46 <oedipus> GJR: agree - whether list is prose or formatted as list, belongs to the P and should be inside the P 14:04:53 <alessio> +1 14:04:56 <Tina> A suggestion, as quoted from me, above would be to allow lists - possibly inline lists - but exclude other use. 14:05:05 <oedipus> RM: alternative: leave as is, insert 2 examples, and note asking for feedback 14:05:46 <oedipus> ACTION - Gregory: draft example of P with prose list and structural list 14:05:46 <trackbot> Sorry, couldn't find user - - 14:05:59 <oedipus> ACTION: Gregory - draft example of P with prose list and structural list 14:05:59 <trackbot> Created ACTION-65 - - draft example of P with prose list and structural list [on Gregory Rosmaita - due 2009-04-02]. 14:06:59 <oedipus> tina, could you provide examples of other uses of P? 14:07:16 <oedipus> or a list of what you would exclude from the P content model? 14:07:19 <Tina> No, I don't see any reason to continue the discussion, in particular if we are speaking merging the two WGs - HTML 5 design principles, if memory serve, insist on backward compatibility. Until it decided whether to merge or not the discussion is moot. 14:07:39 <oedipus> RM: only one causing difficulty with P content model is TABLE 14:08:07 <oedipus> RM: list, blockquote, pre and table 14:08:13 <Steven> (PCDATA | Text | List | blockcode | blockquote | pre | table )* 14:08:16 <oedipus> GJR: why blockquote and not blockcode? 14:08:30 <oedipus> SP: blockcode is part of content model 14:08:44 <oedipus> RM: what is normative? DTD or spec? 14:08:51 <oedipus> SM: spec always wins 14:09:03 <oedipus> RM: where spec doesn't include blockcode, bug in DTD 14:09:12 <oedipus> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-structural.html#edef_structural_p 14:09:18 <oedipus> SM: no DTD for XHTML2 14:09:26 <oedipus> SP: not from DTD but modulariztion code 14:09:40 <oedipus> RM: still looking at what we pointed to originally 14:09:48 <oedipus> RM: list, blockquote, pre and TABLE 14:10:00 <oedipus> SP: english text is wrong - should also include blockcode 14:10:19 <oedipus> SP: module text at top is definitive version 14:10:45 <oedipus> RESOLVED: fix XHTML2 prose to include blockcode 14:11:05 <oedipus> SM: shouldn't be in text 14:11:08 <oedipus> SP: plus 1 to that 14:11:20 <oedipus> GJR: following wiser heads like a lemming 14:11:29 <oedipus> SM: no other element describes content model in prose 14:11:47 <oedipus> SP: point of english text is to explain diff between XHTML2's P and earlier versions 14:11:55 <oedipus> RM: simple link-back to definition would help 14:12:09 <oedipus> SP: need to get that automated by shane 14:12:31 <oedipus> SP: spec written as small files - by element or attribute, which then get put together in standard way 14:12:46 <ShaneM> It should read: In comparison with earlier versions of HTML, where a paragraph could only contain inline text, XHTML2's paragraphs represent a richer content model more consistent with the concept of a paragraph. 14:13:02 <oedipus> GJR: plus 1 to shane's proposal 14:13:18 <oedipus> RM: talk about attributes, but not content model 14:13:39 <oedipus> SM: talk about content model elsewhere - may need to reinforce in this module because so large 14:14:03 <oedipus> SM: proposed text 14:14:31 <oedipus> SP: is example of P with embedded UL in it 14:15:00 <oedipus> RM: in contrast to what was done in previous versions P /P UL /UL rather than P UL /UL /P 14:15:13 <oedipus> SM: mistake for us to include references as to how things used to be 14:15:35 <oedipus> RM: alternative today - P can contain lists; put side-by-side explaining can do either of these 14:15:36 <oedipus> SM: ok 14:16:58 <oedipus> proposed RESOLUTION: "In comparison with earlier versions of HTML, where a paragraph could only contain inline text, XHTML2's paragraphs represent a richer content model more consistent with the concept of a paragraph" 14:17:18 <oedipus> RM: not sure need "more consistent" clause 14:17:27 <oedipus> proposed RESOLUTION: "In comparison with earlier versions of HTML, where a paragraph could only contain inline text, XHTML2's paragraphs represent a richer content model consistent with the concept of a paragraph" 14:18:02 <oedipus> RM: richer content model of paragraph should be sufficient 14:18:16 <oedipus> proposed RESOLUTION: "In comparison with earlier versions of HTML, where a paragraph could only contain inline text, XHTML2's paragraphs represent a richer content model. 14:18:59 <oedipus> RESOLVED: replace current explanation of P content model with "In comparison with earlier versions of HTML, where a paragraph could only contain inline text, XHTML2's paragraphs represent a richer content model." 14:19:18 <oedipus> TEN MINUTE BREAK - RECONVENE AT HALF-PAST HOUR 14:19:21 <Zakim> -Steven 14:19:22 <oedipus> rrsagent, make minutes 14:19:22 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 14:19:26 <Zakim> -Gregory_Rosmaita 14:19:28 <Zakim> -Tina 14:19:29 <oedipus> rrsagent, stop log 14:19:29 <RRSAgent> I'm logging. I don't understand 'stop log', oedipus. Try /msg RRSAgent help 14:19:31 <oedipus> rrsagent, stop 14:32:28 <Zakim> +Gregory_Rosmaita 14:32:59 <oedipus> TOPIC: Navigation 14:33:12 <oedipus> question: Do we really need four different types of lists in XHTML 2.0? 14:33:14 <alessio> zakim, code? 14:33:14 <Zakim> the conference code is 26634 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), alessio 14:33:21 <oedipus> http://lists.w3.org/Archives/Public/www-html/2008May/0005.html 14:33:21 <oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2008Nov/0015.html 14:33:22 <Steven> zakim, dial steven-617 14:33:23 <Zakim> ok, Steven; the call is being made 14:33:25 <Zakim> +Steven 14:33:35 <Zakim> +[IPcaller] 14:33:43 <alessio> zakim, IPcaller is Alessio 14:33:43 <Zakim> +Alessio; got it 14:33:50 <oedipus> zakim, who is here? 14:33:50 <Zakim> On the phone I see Roland, Steven, Markus, Gregory_Rosmaita, Alessio 14:33:51 <Zakim> On IRC I see ShaneM, Tina, alessio, mgylling, Roland, Zakim, RRSAgent, Steven, oedipus, trackbot 14:33:59 <Tina> oedipus: an exaggeration, surely. 14:34:31 <Zakim> +ShaneM 14:34:38 <Tina> My 2 whatsits: yes. We DO need a rich set of lists for various structures that needs to be marked up. I would propose we add an inline-list to the ones we have, plus, of course, a 'menu' or 'navigation' 14:35:01 <oedipus> current editor's draft definition of NL: http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-list.html#edef_list_nl 14:35:12 <oedipus> RM: do we need 4 kinds of list? 14:35:40 <oedipus> RM: discussed - fairly broad concept; item about elements versus attributes topic is related 14:35:45 <oedipus> RM: why did we create NL? 14:36:11 <oedipus> SP: in early days, 1 thing we did was observe web sites to identify things on web sites that represented concepts not represented in common HTML markup 14:36:32 <Zakim> -Markus 14:36:56 <oedipus> SP: one thing that we concluded was types of list purely for navigational purposes - semantic advantage (expecially from A11y POV) advantageous; developed before developed Role and RDFa 14:37:14 <oedipus> SP: new markup allows NL without new type of element] 14:37:27 <oedipus> SP: instead of NL, UL role="navigation" 14:37:54 <oedipus> RM: device independence group worked on this; large areas of page - are areas devoted to navigation 14:38:05 <Tina> OL, not UL. This is still a rather dramatic conceptual change. Why would we want to do that - and, on the flipside, not then simply have ONE list? 14:38:06 <oedipus> RM: not catered for inside markup; navigation is important property 14:38:08 <Zakim> +Markus 14:38:20 <mgylling> mgylling has joined #xhtml 14:38:23 <oedipus> RM: difference from my POV is navigation is more than list 14:38:50 <oedipus> RM: HTML5 has NAVIGATION element - useful notion: can be more to navigation than items; headings (primary navigation, secondary navigation) 14:39:05 <oedipus> RM: would like to reframe converstation from NL to NAVIGATION section 14:39:14 <Roland> HTML5 : http://www.w3.org/TR/html5/semantics.html#the-nav-element 14:39:20 <ShaneM> I agree with Steven that @role can be used to indicate that a section is related to navigation. 14:40:06 <oedipus> SP: definitely case that had proposal on table for NL but didn't find consensus in WG; made general decision to use elements for structuring and attributes for semantics; helps us fulfil many requests; if request is for semantics, answer should be use RDFa or Role and leave elements for marking up strcuture 14:40:13 <oedipus> RM: felt navigation was structure 14:40:31 <ShaneM> <section role="navigation">...</section> 14:40:34 <oedipus> SP: use SECTION role="navigation" is equivalent 14:40:53 <oedipus> SP: could also use UL role="navigation" or OL role="navigation" 14:41:05 <oedipus> SP: can be done by attaching role to SECTION or directly to list 14:41:11 <Tina> Have we agreed to leave *all* semantics to RDFa and @role? 14:41:29 <ShaneM> Tina: No, I don't think so. 14:41:36 <oedipus> RM: OL role="navigation" equals SECTION role="navigation" 14:42:14 <oedipus> SP: MarkB would say NL wrong because makes list with specific semantic meaning; sturcture is ordered list and structure is navigation; if want section on navigation, use SECTION role="navigation" 14:42:22 <Tina> ShaneM: that begs the question - which semantics do we leave to elements? We already have three different list types. If they are there for structure only, then why don't we simplify and make one? 14:42:46 <oedipus> SM: context - state of art when introduced NL in visual user agent wasn't possible without heavy scripting; but today, that can be achieved with CSS 14:42:51 <oedipus> SM: throw out NL 14:42:54 <oedipus> SP: can live with that 14:42:57 <oedipus> AC: me too 14:42:59 <oedipus> GJR: me too 14:43:03 <mgylling> +1 14:43:05 <ShaneM> Note that @role already has a predefined value for "navigation" 14:43:18 <oedipus> RM: would prefer a NAV element rather than just list 14:43:56 <oedipus> RM: no element whose specific role is navigation, can be satisfied by assigning role to other structural elements 14:44:37 <oedipus> SP: kept a lot of elements that aren't strictly necessary because of use-and-practice with list 14:44:46 <oedipus> SM: extended content model for DL by adding DI 14:44:51 <oedipus> SM: very positive move 14:45:14 <oedipus> SM: can't decide if TH making serious point or playing devil's advocate 14:45:16 <Steven> zakim, who is on the phone? 14:45:16 <Zakim> On the phone I see Roland, Steven, Gregory_Rosmaita, Alessio, ShaneM, Markus 14:45:18 <oedipus> zakim, who is here? 14:45:19 <Zakim> On the phone I see Roland, Steven, Gregory_Rosmaita, Alessio, ShaneM, Markus 14:45:21 <Zakim> On IRC I see mgylling, ShaneM, Tina, alessio, Roland, Zakim, RRSAgent, Steven, oedipus, trackbot 14:46:04 <oedipus> SM: appreciate that there is a significant presentational and semantic difference between OL, UL, and DL - DT and DD need to be grouped in order to make sense 14:46:19 <oedipus> SM: don't think a lot of value removing things people are already familiar with 14:46:31 <Tina> It is a serious point in so far as we need to be consistent in where we leave semantic interpretation on element types, and where we move it to roles. Right now the draft is a little bit of this and a little bit of both. If we say that "The markup is for structure" as a general rule then we need only one list structure and extended @role values. 14:46:46 <oedipus> SM: does beg the question: "does it make sense for us to do things in language that we know will not work right in existing UAs?" 14:47:00 <oedipus> RM: not on agenda, but could discuss when return to HTML5 discussion 14:47:16 <oedipus> RM: making incremental changes that make it hard to deploy - is it worth return on investment 14:47:29 <oedipus> RM: do we need to introduce DI type of thing to discuss later 14:47:35 <oedipus> RM: concrete example? 14:47:35 <Tina> Since we are already changing or removing things people are already familiar with. Consistency is key. 14:47:45 <oedipus> SP: resolution to remove NL? 14:48:02 <oedipus> proposed RESOLUTION: remove NL from XHTML2's List Module 14:48:08 <oedipus> RM: propose we remove NL 14:48:12 <Steven> and replace with use of @role="navigation" 14:48:20 <oedipus> GJR: plus 1 with SP's caveat 14:48:26 <Steven> as necessary 14:48:53 <oedipus> SM: we created "navigation" role 14:49:15 <oedipus> proposed RESOLUTION: remove NL from XHTML2's List Module and replace with use of role="navigation" 14:49:29 <oedipus> SP: current model for DL wouldn't break existing user agents 14:49:38 <Steven> I think 14:49:44 <oedipus> GJR: agree with SP - will make DL stronger and more useful 14:49:44 <Steven> +1 14:49:47 <Steven> on resolution 14:49:53 <mgylling> +1 14:49:54 <oedipus> proposed RESOLUTION: remove NL from XHTML2's List Module and replace with use of role="navigation" 14:49:59 <oedipus> plus 1 14:50:05 <ShaneM> Tina: I think there is a (new) trend toward NOT removing things that people are familiar with.http://www.w3.org/1999/xhtml/vocab/ 14:50:09 <ShaneM> oops... http://www.w3.org/1999/xhtml/vocab/ 14:50:51 <oedipus> definition of navigation from vocab document: "navigation indicates a collection of items suitable for navigating the document or related documents." 14:51:35 <oedipus> RM: seem to have gotten a bit mixed up - talking about multiple things 14:51:40 <oedipus> RM: resolution to remove NL 14:51:44 <oedipus> proposed RESOLUTION: remove NL from XHTML2's List Module and replace with use of role="navigation" 14:51:52 <ShaneM> +1 14:51:52 <Roland> +1 14:51:54 <Steven> +1 14:51:55 <alessio> +1 14:52:00 <oedipus> RESOLVED: remove NL from XHTML2's List Module and replace with use of role="navigation" 14:52:04 <oedipus> rrsagent, make minutes 14:52:04 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 14:52:16 <ShaneM> ACTION: Shane to remove the nl element from XHTML 2 14:52:16 <trackbot> Created ACTION-66 - Remove the nl element from XHTML 2 [on Shane McCarron - due 2009-04-02]. 14:52:46 <oedipus> SM: one related item is DL 14:52:53 <oedipus> SP: changes won't change deployment 14:52:58 <oedipus> SM: DI would be ignored? 14:53:04 <oedipus> MG: DI is optional 14:53:16 <oedipus> GJR: provides nice low-grade binding for DDs 14:53:35 <oedipus> RM: DI introduced to solve what particular problem? 14:53:55 <oedipus> "Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description. The term is given by the dt element. The description is given with a dd element. The term and its definition can be grouped within a di element to help clarify the relationship between a term and its definition(s)." 14:54:53 <mgylling> ... di solves a problem that could also be solved with @for... 14:55:30 <oedipus> SP: if 2 things are related, DI can express that; presentation: hard to put border around DT and DD; from semantic POV want them to be joined at head and not hip 14:55:47 <oedipus> markus, do you have more to say on "for" 14:56:09 <oedipus> RM: like paragraph - if don't want to use DI, don't have to 14:56:13 <mgylling> no - I am all for DI. 14:56:18 <oedipus> good 14:56:32 <oedipus> RM: any other potential pitfalls with lists? 14:57:05 <oedipus> SM: added in list module the caption element and hooked into content model for all lists 14:57:07 <ShaneM> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-list.html#s_listmodule 14:57:08 <oedipus> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-list.html 14:57:22 <oedipus> RM: lists allow caption 14:57:33 <oedipus> GJR: might want to consider LEGEND 14:59:12 <Steven> We need to consider the purposes of LEGEND LABEL and CAPTION 14:59:21 <oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeExamples 14:59:22 <Steven> and work out whether to merge 14:59:42 <alessio> yes, it's a very good point 15:00:09 <oedipus> SM: haven't addressed use of XForms inline content with other forms of inline content 15:00:23 <oedipus> Use of FIGURE, LEGEND, and @alt 15:00:23 <oedipus> Three Stages of A Butterfly's Life Example 15:00:23 <oedipus> Each of the images in the 3 stages of a butterfly's life REQUIRE alt text and/or labelledby to provide them with unique and appropriate short descriptions, just as each form control in a FIELDSET has its own LABEL defined for it, with the value of the LEGEND element providing a CAPTION-like function for the FIELDSET, so too does LEGEND provide a means of declaratively marking explicit bindings of groups of related objects, as in: 15:00:30 <oedipus> <FIGURE aria-labelledby="l1"> 15:00:30 <oedipus> <LEGEND id="l1">The Three Stages of a Butterfly's Life Cycle</LEGEND> 15:00:30 <oedipus> <IMG alt="Stage 1: The larval stage." src="butterfly1.svg" 15:00:30 <oedipus> longdesc="butterfly1.html"> 15:00:30 <oedipus> <IMG alt="Stage 2: The pupal stage." src="butterfly2.svg" 15:00:33 <oedipus> longdesc="butterfly2.html"> 15:00:35 <oedipus> <IMG alt="Stage 3: The adult stage." src="butterfly3.svg" 15:00:36 <oedipus> longdesc="butterfly3.html"> 15:00:39 <oedipus> </FIGURE> 15:00:41 <oedipus> the LEGEND applies to all three images as a collection of related objects, available, for example, in a screen reader situation, either through a verbosity setting or via an extended query, such as MagicKey+TAB reads the alt text of the individual graphic which has focus, MagicKey+TAB pressed twice rapidly (or with a moderator key) provides the user with the LEGEND which describes, tersely, the group to which the individual image belongs, so that the user can b 15:00:47 <oedipus> a) each individual image's short alternative text; 15:00:48 <oedipus> b) the grouping to which the image belongs (if it is one of a series presented in a FIGURE) or any other modality-specific content contained in HTML5's media-specific elements, including AUDIO, VIDEO, OBJECT and CANVAS; 15:01:03 <oedipus> TOPIC: Supplemental Document - Best Practices Guide? 15:01:51 <oedipus> RM: need to orient readers and contextualize use of XHTML2 to alter content and improve usability of content - how to pull pieces of m12n together 15:02:39 <oedipus> GJR: i will send "thoughts on LEGEND" used in PF deliberations over terse descriptors in HTML5 to XHTML2 list 15:02:57 <oedipus> RM: like examples - pick up as a template and build upon it 15:03:33 <oedipus> RM: christina once worked on something similar, but we haven't undertaken anything as a WG 15:03:38 <oedipus> SP: no, we haven't really 15:03:58 <oedipus> RM: continuing developing document, steven? 15:04:01 <Roland> Roland has left #xhtml 15:04:14 <oedipus> SP: received a lot of feedback at AC meeting on how should be structured 15:04:21 <Roland> Roland has joined #xhtml 15:04:26 <oedipus> rrsagent, make minutes 15:04:26 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 15:04:31 <Steven> s/feedback/input/ 15:05:06 <oedipus> rrsagent, make minutes 15:05:06 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 15:05:30 <oedipus> TOPIC: how to incorporate ITS 15:05:36 <oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2008Dec/0023.html 15:05:36 <oedipus> http://www.w3.org/MarkUp/tracker/actions/28 15:05:52 <oedipus> SM: does anyone understand the ITS question? 15:06:34 <oedipus> SP: background: googletranslate - when automatically translates page, ITS helps markup page to assist process; when i say "window" don't translate because is technical term; 15:07:01 <oedipus> SP: semantic markup with specific domain: meaning of words with respect to other languages 15:07:17 <mgylling> http://www.w3.org/TR/its/ 15:07:36 <oedipus> RM: who is driving this request 15:07:41 <oedipus> SP: i18n 15:08:15 <Steven> Then from there, run batch file <cmd 15:08:15 <Steven> its:translate="no">Build.bat</cmd>.</p> 15:08:29 <oedipus> MG: investigated ITS - 3 options to introduce rules into document - inline (similar to @style), xlink to external document, or put info in HEAD 15:08:44 <oedipus> MG: not just question of attribute, but should we support XLINK in HEAD, etc. 15:08:54 <oedipus> RM: can link to ITS definition, full stop 15:08:57 <oedipus> SM: not an option 15:09:05 <oedipus> SP: wouldn't let us do that? 15:09:22 <oedipus> SM: our architecture doesn't allow for arbitrary content models; need to specificy what goes where 15:09:56 <oedipus> SM: ITS was on rec track; asked us to do LC review; we said fine, but forgot M12n; listened to us and produced modules and went to REC 15:10:30 <oedipus> SM: should we incorporate into XHTML 1.2 - no, but i was given action item to put into XHTML2 - too many options, need to pick one 15:10:43 <oedipus> SM: should ask ITS WG how to use ITS in our module 15:10:48 <oedipus> RM: ITS WG closed 15:10:56 <oedipus> RM: ITS interest group still active 15:11:10 <oedipus> RM: should ping them to ask "how do you think this applies to us?" 15:11:24 <oedipus> SP: created something similar to CSS - create rules in HEAD or inline 15:11:50 <oedipus> SP: a lot of their stuff we have anyway - don't need @dir because took from us and put in their namespace 15:12:06 <oedipus> GJR: notes that this is a good trend - similar to timesheets 15:12:34 <oedipus> SP: translate rules - include their rules into HEAD and then in BODY only thing that is left is translate equals yes or no 15:12:53 <oedipus> MG: correct; have schema modules for ITS we can import 15:13:02 <oedipus> MG: external sheets via XLink 15:13:15 <oedipus> MG: should ask if can use LINK element instead 15:13:19 <oedipus> RM: sounds reasonable 15:13:52 <oedipus> SP: invite someone from ITS to join us on a call to discuss 15:14:06 <oedipus> GJR: sounds reasonable 15:14:17 <oedipus> SP: should be able to find someone courtesy of RichardI 15:14:47 <oedipus> ACTION: Steven - talk to Richard to ask if someone from ITS can join an XHTML2 call to discuss this further 15:14:47 <trackbot> Created ACTION-67 - - talk to Richard to ask if someone from ITS can join an XHTML2 call to discuss this further [on Steven Pemberton - due 2009-04-02]. 15:15:00 <oedipus> RM: is anyone recognizing ITS? 15:15:12 <oedipus> SP: if no one is producing content with it answer is no 15:15:26 <oedipus> RM: are we the best people to bootstrap this? 15:15:48 <oedipus> http://www.w3.org/International/its/tests/its2xquery 15:16:00 <oedipus> http://www.w3.org/International/its/itstagset/ImpReport 15:16:10 <oedipus> http://www.w3.org/International/its/tests/ 15:17:28 <oedipus> SM: should be bending over backwards to reuse W3C technologies and standards 15:17:52 <oedipus> GJR: first principle of WCAG - if pertinent technology exists (such as MathML) use it 15:18:01 <Steven> r12a suggests �10 �01yves savourel �01chair of the former WG 15:18:02 <oedipus> RM: doesn't sound too onerous 15:18:07 <Steven> and cc to Felix of W3C 15:18:47 <oedipus> RM: don't need its prefix, just "yes" or "no" 15:18:55 <oedipus> SM: does spec allow chameleon? 15:19:38 <oedipus> MG: published note on how to incorporate ITS into XHTML family 15:19:57 <oedipus> http://www.w3.org/International/its/itstagset/ImpReport#conftype1 15:20:10 <Steven> ysavourel at translate.com 15:20:14 <oedipus> processing expections for ITS: http://www.w3.org/International/its/itstagset/ImpReport#conftype2 15:20:25 <Roland> http://www.w3.org/TR/xml-i18n-bp/#its-plus-xhtml10 15:20:46 <oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3331#c8 15:20:55 <oedipus> http://www.w3.org/International/its/techniques/its-techniques.html#integration-its-xhtmlmod 15:21:12 <oedipus> "Three such markup schemes are described in section ITS Applied to Existing Formats of the latest public Working Draft of Best Practices for XML Internationalization: ITS and TEI, ITS and XHTML 1.0, and ITS and XML Spec. In response to comment Please use XHTML Modularization for defining ITS DTD and Schema, the Working Group has defined an ITS module for XHTML, using the XHTML modularization framework." 15:21:27 <oedipus> MG: roland's pointer the one i was thinking about 15:21:35 <oedipus> SM: last one GJR put in is what i was looking at 15:21:53 <oedipus> RM: XHTML M12n 1.1 - http://www.w3.org/TR/xml-i18n-bp/#its-plus-xhtml10 15:22:45 <oedipus> SM: our treatment of schema allows us to bring in elements and attributes from other namespaces; don't have to include in our namespace if already exists elsewhere and is in use 15:23:40 <oedipus> "1) ITS and TEI: ITS rules is allowed to appear in the TEI metadata section (the teiHeader). The local ITS attributes are added to the global attribute set for all elements. ITS span is added to the content pattern model.common (most inline contexts)." 15:23:40 <oedipus> "2) ITS and XHTML 1.0: ITS rules is allowed to appear in the XHTML head element (the group HeadOpts.mix has been redefined accordingly). The local ITS attributes are added to the global attribute set for all elements (the group Common.attrib has been redefined accordingly). Ruby is not used since the ruby specification already defines an XHTML module for ruby." 15:23:40 <oedipus> "3) ITS and XML Spec: ITS rules is allowed to appear in the XML Spec header element (rules has been added as the last element to the XML Spec entity header.mdl). The local ITS attributes are added to the global attribute set for all elements (they have been added to the entity common.att). ITS ruby is allowed to appear as an inline element (it has been added to the entity p.pcd.mix)." 15:26:18 <oedipus> SP: reading from spec: "one way to associate document with external ITS rules is to use optional XLINK" 15:27:16 <oedipus> http://www.w3.org/MarkUp/tracker/actions/28 15:27:41 <Steven> so it sounds optional 15:27:49 <oedipus> SM: questions we have: don't support XLink, so can we use LINK? leave in ITS space and use their suggested model? 15:28:23 <oedipus> SM: inclination is to invite someone to discuss XLink - for content model, take what proposed for XHTML 1.1 leave in ITS namespace and do what they said 15:28:57 <oedipus> proposed RESOLVED: XHTML2 WG will discuss ITS integration and use of LINK versus XLink with representative from i18n 15:29:06 <oedipus> RESOLVED: XHTML2 WG will discuss ITS integration and use of LINK versus XLink with representative from i18n 15:29:10 <oedipus> SP: already invited them 15:29:12 <oedipus> SM: thank you 15:29:21 <oedipus> rrsagent, make minutes 15:29:21 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 15:29:38 <oedipus> RM: anything else on ITS? 15:30:18 <oedipus> TOPIC: Clearing Out Old Action Items 15:30:24 <oedipus> RM: quantity values question 15:31:24 <oedipus> SP: when we have href type and src type which allows one to define what values are suitable; in HTML4 have type on HREF - comment that says what is on other end - just a claim, not firm basis for content negotiation 15:31:40 <oedipus> SP: in XHTML2 have list of types used for content negotiation 15:32:27 <oedipus> SP: comment that don't take into account QValues 15:32:53 <oedipus> SP: been boning up on QValues 15:33:28 <oedipus> RM: should add to traker 15:33:36 <oedipus> s/traker/tracker 15:34:34 <oedipus> SP: if say "here is an image" may be in 10 diff formats, but want SVG or PNG to be first choice, if user agent can't handle SVG or PNG, have to provide something UA says can accept 15:35:14 <oedipus> SP: answer may be no qvalues in source 15:35:19 <oedipus> SM: think that is the answer 15:35:38 <oedipus> SM: QValue responsibility of UA; intersection of what UA wants and what author can offer 15:35:55 <oedipus> s/what UA wants/what UA can handle/ 15:36:10 <oedipus> SP: order of things in specification important - take first or highest q? 15:36:33 <oedipus> SP: when UA specifies what is willing to accept does it mean willing to accept them equally 15:36:38 <oedipus> SM: have to check HTTP spec 15:36:48 <oedipus> SM: order is probably significant - will check 15:38:10 <Steven> ACTION: Steven to work out how to merge q values in the specification of content negotiation with hreftype etc. 15:38:10 <trackbot> Created ACTION-68 - Work out how to merge q values in the specification of content negotiation with hreftype etc. [on Steven Pemberton - due 2009-04-02]. 15:38:52 <oedipus> http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/XHTML-2.0?user=guest;statetype=-1;upostype=-1;changetype=-1;restype=-1 15:39:26 <oedipus> RM: work through 16 open issues on shane's tracker? 15:39:28 <oedipus> SM: not now 15:39:31 <oedipus> RM: when? 15:39:46 <oedipus> SM: not sure what to do with 5 year old comments 15:39:54 <oedipus> RM: are any of the issues still relevant? 15:40:22 <oedipus> RM: how to deal with them? 15:40:35 <oedipus> GJR: port them to W3C tracker and close those that are moot? 15:41:11 <oedipus> "QNames are the way that the working group, and indeed the W3C, handle having 15:41:11 <oedipus> data that comes from differing sources. The working group is not willing to 15:41:11 <oedipus> change course at this time 15:41:32 <oedipus> SM: http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/XHTML-2.0?id=7659;user=guest;statetype=-1;upostype=-1;changetype=-1;restype=-1 needs to be split up 15:41:37 <oedipus> SP: some just comments 15:41:46 <oedipus> SP: several of these things don't need to do 15:41:58 <oedipus> SP: can answer, but no action necessary 15:42:07 <oedipus> SP: real issues: keep BR (which i think we do) 15:42:15 <oedipus> SM: were instructed by TBL to keep BR 15:42:32 <oedipus> SP: a lot of editorial comments 15:43:03 <Tina> What is the structural purpose of BR? That should be the only reason why we keep it or toss it. 15:43:42 <Tina> Yes. What's our use case for keeping it? 15:43:49 <oedipus> SP: could say that WG received this remark and is not required to answer; get input from more recent suggestions 15:44:35 <Zakim> -Gregory_Rosmaita 15:44:45 <Tina> Then I suggest we get rid of BR as more-or-less physical markup. 15:44:57 <Zakim> -Steven 15:45:52 <Zakim> -Alessio 15:46:16 <Zakim> +Gregory_Rosmaita 15:46:45 <oedipus> tina, do you want to work on a proposal to eliminate BR? 15:47:06 <oedipus> deprecate in favor of use of L ... /L 15:48:18 <oedipus> anne van k on L: "Didn't BLOCKCODE preserve whitespace by default? What do we need the L 15:48:18 <oedipus> element for here? And as mentioned before, BR is still needed. I also 15:48:18 <oedipus> think that a better use case for L should be presented, this one is bad." 15:48:28 <Tina> oedipus, I don't have the time to write up anything formal, I'm afraid. 15:48:44 <oedipus> me neither, but i might as well take a whack at it right now 15:50:44 <oedipus> GJR's take: BR is a presentational concept; to express that a line of content is intended to be interpreted as single line of content, authors should use the L element to mark the beginning and end of a line. 15:50:51 <oedipus> zakim, who is here? 15:50:52 <Zakim> On the phone I see Roland, ShaneM, Markus, Gregory_Rosmaita 15:50:55 <Zakim> On IRC I see Roland, mgylling, ShaneM, Tina, alessio, Zakim, RRSAgent, Steven, oedipus, trackbot 15:51:48 <Steven> zakim, dial steven-617 15:51:48 <Zakim> ok, Steven; the call is being made 15:51:50 <Zakim> +Steven 15:51:56 <oedipus> RM: keep differences from status-quo to a minimum - makes easier to deploy in existing browsers 15:52:27 <Tina> oedipus: I agree with that. 15:52:36 <oedipus> SM: "1.1.2. Backwards compatibility 15:52:50 <oedipus> SM: will update as appropriate 15:53:00 <oedipus> SM: 1.1.2. Backwards compatibility 15:53:06 <Tina> We are already deviating from that, however, by changing content models. Removing presentational markup is surely a good idea. 15:53:14 <oedipus> SM: wants BR back; instructed to do it, but haven't done it 15:53:16 <oedipus> q+ 15:53:22 <oedipus> GJR's take: BR is a presentational concept; to express that a line of content is intended to be interpreted as single line of content, authors should use the L element to mark the beginning and end of a line. 15:53:53 <oedipus> SM: agree 15:54:31 <oedipus> RM: back to pragmatic - authors need to understand what to do - how much benefit from being purists, how much from being practical - can we live with either or 15:54:48 <oedipus> SP: can live with keeping it, but with a note stating that L is preferred method 15:54:59 <oedipus> ack oe 15:55:03 <ShaneM> ACTION: Shane to put br element back into XHTML 2 with a note that there are better ways to mark up lines. 15:55:03 <trackbot> Created ACTION-69 - Put br element back into XHTML 2 with a note that there are better ways to mark up lines. [on Shane McCarron - due 2009-04-02]. 15:55:20 <oedipus> proposed Resolution: restore BR 15:55:25 <oedipus> SP: objections? 15:55:27 <oedipus> GJR: object 15:55:42 <oedipus> SP: if objections, don't have resolution 15:56:48 <oedipus> RM: GJR, do you believe we should not do this? 15:57:23 <Zakim> +??P3 15:57:29 <alessio> zakim, ??P3 is Alessio 15:57:29 <Zakim> +Alessio; got it 15:57:32 <oedipus> GJR: willing to compromise on BR if we add note on use of L 15:58:00 <Tina> I see no good reason to put a presentational element back in. This isn't as much about pragmatic solutions - CSS can do the visual if need be. 15:58:08 <oedipus> GJR: is there any override mechanism for BR? 15:58:23 <oedipus> SP: compromise: include BR but mark as deprecated 15:58:25 <oedipus> GJR: yes 15:58:40 <ShaneM> deprecated? in a legacy br module? 15:58:52 <oedipus> proposed RESOLUTION: re-introduce BR, marking as deprecated, and point out that for accessibility, is much better to use L 15:59:02 <Steven> +1 15:59:07 <ShaneM> +1 15:59:07 <oedipus> GJR: plus 1 15:59:16 <oedipus> AC: yes 15:59:18 <Roland> +1 15:59:19 <mgylling> +1 15:59:21 <alessio> +1 15:59:27 <oedipus> RESOLVED: re-introduce BR, marking as deprecated, and point out that for accessibility, is much better to use L 15:59:33 <oedipus> rrsagent, make minutes 15:59:33 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 16:01:37 <oedipus> RM: next one is ADDRESS element 16:02:01 <oedipus> SM: request is make content model for address richer, or introduce a BLOCKADDRESS element 16:02:12 <oedipus> GJR: isn't this covered by role="contentinfo" 16:02:39 <oedipus> vocab doc: " 16:02:39 <oedipus> contentinfo has meta information about the content on the page or the page as a whole. 16:03:01 <Steven> By the way, there is a new rrsagent in the works: http://www.w3.org/2009/CommonScribe 16:03:13 <oedipus> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-structural.html#edef_structural_address 16:03:31 <oedipus> SM: not inclined to change from block to inline or to add blockaddress 16:03:41 <oedipus> SP: non-structural element that only adds semantic information 16:03:56 <oedipus> SP: semantic info is terribly vague - can't extract much sensible out of ADDRESS 16:04:15 <oedipus> RM: HTML5's ADDRESS is not block 16:04:55 <oedipus> SM: problem is content model restricted; 16:05:09 <oedipus> http://www.w3.org/TR/html5/semantics.html#the-address-element 16:05:38 <oedipus> 'The address element represents the contact information for the section it applies to. If it applies to the body element, then it instead applies to the document as a whole" 16:06:07 <Tina> That does appear fairly clear, if not detailed. What is the use case for changing it? 16:06:15 <oedipus> "The address element must not contain information other than contact information." 16:06:27 <ShaneM> Tina: the request is to make the content model richer 16:07:02 <oedipus> GJR: HTML5 Address is a child of FOOTER 16:07:07 <Tina> If so, do we need to change the element or simply add other elements which go inside it that allows an author to define up the various pieces? 16:07:09 <oedipus> http://www.w3.org/TR/html5/semantics.html#the-footer-element 16:07:51 <oedipus> GJR: address is part of FOOTER, but restricted to contact info onlly 16:07:58 <oedipus> s/onlly/only 16:08:05 <oedipus> GJR: in HTML5 16:08:29 <ShaneM> Tina: I think we just could make the content model richer. 16:09:07 <oedipus> Content model for FOOTER in HTML5: "Flow content, but with no heading content descendants, no sectioning content descendants, and no footer element descendants." 16:09:45 <oedipus> SM: either add blockaddress or fix rich content model 16:09:56 <oedipus> SM: objections to making content model of ADDRESS richer? 16:10:01 <oedipus> SM: need to define "richer" 16:10:11 <oedipus> SM: same as SECTION 16:10:13 <Tina> ShaneM: not a bad idea. We can keep ADDRESS, then add various elements for marking up specific sections of contact info. Or rely on namespaces for people to use elements from other XMLs. 16:10:21 <oedipus> RM: why not say SECTION role="address" 16:10:54 <oedipus> SP: on other hand, could just say ADDRESS is shorthand for SECTION role="address" 16:11:08 <oedipus> RM: no difference in semantics for ADDRESS and SECTION role="address" 16:11:17 <oedipus> RM: need to define semantics of ADDRESS 16:11:47 <oedipus> SM: DIV role="p" is not a substitute for using P - if element has semantics, use the element 16:12:27 <oedipus> SM: have ADDRESS element - could say "if need area of document with richer content model and address information, use SECTION role="address" 16:12:35 <oedipus> RM: no existing "address" role 16:13:06 <oedipus> GJR: when we did ARIA/HTML5 analysis decided that "contentinfo" more broad than HTML's ADDRESS 16:13:27 <oedipus> SM: defer to dublin core or VCard? 16:13:45 <Tina> Suggestion: keep <address> as is, and encourage authors to use other markup languages for the specifics. 16:13:52 <oedipus> SM: vocab collection for role is missing fundamental concepts - is that because we are deferring to DC 16:13:59 <oedipus> SP: do in RDFa instead of role 16:14:20 <oedipus> RM: on typical page, navigation area, content area, contact area very common - address related to contact info 16:14:29 <oedipus> SM: dublin core values we can use for that 16:14:42 <oedipus> RM: broke up page into appendix, content, copyright, etc. 16:15:02 <oedipus> SM: can add a role 16:15:35 <alessio> agree 16:15:38 <oedipus> RM: can state "not changed from HTML4; if want richer mechanism, create it according to the markup family's extension rules 16:15:49 <oedipus> SM: probably way to group all of this together 16:16:03 <oedipus> SM: should we introduce additional role values 16:16:05 <oedipus> GJR: yes 16:16:08 <oedipus> SP: good point 16:16:31 <oedipus> GJR: would like to differentiate between explanatory note and referential note 16:16:58 <oedipus> SM: in existing vocabulary 16:17:32 <oedipus> from vocab document: note: "note indicates the content is parenthetic or ancillary to the main content of the resource." 16:18:06 <oedipus> GJR: there are 2 types of note: referential (citation, endnote) and annotative (what the vocab doc says) 16:18:27 <oedipus> SP: resolution? 16:18:51 <ShaneM> Tina: I think that is where we are ending up. Thanks! 16:18:52 <oedipus> RM: leave address as-is, if want to create richer structures for that information, use SECTION 16:19:40 <oedipus> proposed RESOLUTION: leave ADDRESS as-is, add note that if author wants to create richer structures for that information, author can do so following langauge's extension mechanism (e.g. use SECTION) 16:20:04 <alessio> +1 16:20:07 <ShaneM> +1 16:20:09 <oedipus> proposed RESOLVED: leave ADDRESS as-is, add note that if author wants to create richer structures for that information, author can do so following langauge's extension mechanism, e.g. use SECTION 16:20:13 <Roland> +1 16:20:23 <oedipus> RESOLVED: leave ADDRESS as-is, add note that if author wants to create richer structures for that information, author can do so following langauge's extension mechanism, e.g. use SECTION 16:20:36 <oedipus> SM: need to discuss additional role values - add to next f2f agenda 16:20:41 <oedipus> rrsagent, make minutes 16:20:41 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 16:21:16 <oedipus> SM: heading element - "confusing" - example of use of both 16:21:27 <oedipus> SM: think addressed this by moving things around in document 16:21:45 <oedipus> SM: anne objects to P element content model that allows some block-level elements to be mixed in 16:22:12 <oedipus> GJR: reminder earlier RESOLUTION: replace current explanation of P content model with "In comparison with earlier versions of HTML, where a paragraph could only contain inline text, XHTML2's paragraphs represent a richer content model." 16:22:21 <oedipus> SM: PRE element comments 16:22:32 <oedipus> SM: changed example 16:22:46 <oedipus> GJR: PRE is a problem for accessibility 16:23:01 <oedipus> RM: editorial comment 16:23:19 <oedipus> SM: separator element - 16:23:44 <oedipus> SP: TBL has affection for HR 16:23:57 <Steven> unexplained affection 16:24:04 <Tina> Do we need HR when we have SECTION? 16:24:08 <oedipus> "There isn't mentioned a single use case. Only some presentational issues 16:24:08 <oedipus> that should be kept in CSS as mentioned in 1.1.1. Right?" 16:24:17 <Steven> no TIna, we don't 16:24:31 <oedipus> SM: don't understand point of comment 16:24:47 <oedipus> GJR: hell, lets deprecate all BLOCK* elements in favor of CSS 16:25:16 <oedipus> SM: lets disucss separator 16:25:43 <oedipus> SM: TBL has affection for HR - does that mean need HR deprecated in favor of SEPARATOR? 16:25:59 <oedipus> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-structural.html#edef_structural_separator 16:26:35 <oedipus> SP: from fundamental point of view, solves problems with HR - found use cases for separator, could do with SECTION, but SEPARATOR is useful markup 16:27:13 <oedipus> SP: problem with HR - presentational; rather than introduce VR, use SEPARATOR 16:27:40 <oedipus> RM: should say HR has no semantic meaning but is shorthand for SEPARATOR 16:28:12 <oedipus> proposal: rename SEPARATOR to HR and add note: "there is nothing horizontal or presentational implied by HR" 16:28:22 <oedipus> SP: first element not related to concept 16:28:49 <oedipus> RM: should be there for legacy, but if starting afresh use SEPARATOR 16:29:22 <oedipus> SP: reason for caring is that saying that won't change ingrained understanding of HR no matter what we say 16:29:41 <oedipus> RM: how do languages that want VR handle HR? 16:29:43 <Zakim> -Markus 16:30:15 <oedipus> SP: maybe HR only works horizontally and are using borders on DIV for visually approximations of vertical rules 16:30:27 <oedipus> SP: i18n complaint still valid 16:30:28 <Zakim> +Markus 16:30:44 <oedipus> RM: only if say HR has semantic meaning other than as shorthand for SEPARATOR 16:31:29 <oedipus> SP: have to provide standard stylesheet for XHTML2 - have to provide default style for SECTION, H, etc. 16:31:50 <oedipus> SM: don't think SEPARATOR an HR 16:32:02 <oedipus> SM: HR is a styled line running horizontally across page 16:32:26 <oedipus> SM: separator is semantic indication that one part of document different from another - can be reflected in style rules or not 16:33:06 <oedipus> http://www.w3.org/TR/html5/semantics.html#the-hr-element 16:33:22 <oedipus> HTML5: "The hr element represents a paragraph-level thematic break, e.g. a scene change in a story, or a transition to another topic within a section of a reference book." 16:33:48 <oedipus> RM: suggest we move on for now 16:34:26 <oedipus> "Contexts in which this element may be used: Where flow content is expected." 16:35:06 <oedipus> SM: next comment: ABBR should use something other than @title - we do, so that is moot 16:35:12 <oedipus> SM: next comment: CITE element 16:35:28 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/CITE_and_cite 16:36:09 <oedipus> "Precis: In XHTML2, any element may have a href attribute. Since href is global, would it not be logical to mandate use of the href attribute in those circumstances where the cite attribute is currently used: as a consistent means of pointing at a resource, thereby providing the author with a linking mechanism that endows the user with the possibility of reviewing the quote in context. Therefore, it is proposed that the cite attribute be redefined to contain hu 16:37:20 <oedipus> <section role="main"> 16:37:20 <oedipus> <q for="fdr3i" 16:37:20 <oedipus> href="http://www.hicom.net/~oedipus/exegesis/fdr-third-inaugural.html#fdr3ip36s1" 16:37:20 <oedipus> cite="Franklin Delano Roosevelt: Third Innaugural Address; January 20, 1941" 16:37:20 <oedipus> >In the face of great perils never before encountered, our strong 16:37:21 <oedipus> purpose is to protect and to perpetuate the integrity of democracy. 16:37:23 <oedipus> </q> 16:37:24 <oedipus> <!-- ... --> 16:37:26 <oedipus> </section> 16:37:28 <oedipus> <section role="secondary"> 16:37:31 <oedipus> <h id="biblio">Bibliography</h> 16:37:33 <oedipus> <ol> 16:37:34 <oedipus> <li role="contentinfo"><cite id="fdr3i" 16:37:36 <oedipus> src="http://www.fdrpapers.gov/fdr3i.html" 16:37:39 <oedipus> >Roosevelt, Franklin Delano. Third Inaugural Address. Delivered 16:37:40 <oedipus> before a joint session of congress, January 20, 1941. (official 16:37:42 <oedipus> White House transcript)</li> 16:37:44 <oedipus> </ol> 16:37:46 <oedipus> <!-- ... --> 16:37:49 <oedipus> </section> 16:37:59 <oedipus> GJR: Finally, a for/id relationship between the Q element and the CITE element, which allows the author to bind individual quotes to a common source. 16:38:28 <Steven> I think this is another element rendered unecessary by rdfa 16:38:34 <oedipus> GJR: should be able to point to CITE element with for/id relationship 16:38:37 <Steven> s/une/unne/ 16:38:59 <oedipus> GJR: if @cite is retained should be for human processing 16:39:18 <oedipus> SM: disagree 16:39:42 <oedipus> SM: src is used to identify external source that is only read-in; href is used for hyperlink; cite is something else 16:40:04 <oedipus> SM: in current XHTML2 @cite is an @href that is actionable through an alternate method 16:40:19 <oedipus> GJR: a quote is embedded content 16:40:41 <Steven> I think it is actually equivalent to rel="cite" href="...." 16:40:52 <ShaneM> <quote src="someURI" /> 16:41:01 <alessio> yep 16:41:11 <oedipus> SM: @src brings in a URI and replaces Q 16:41:47 <oedipus> GJR: "Since href is global, would it not be logical to mandate use of the href attribute in those circumstances where the cite attribute is currently used: as a consistent means of pointing at a resource, thereby providing the author with a linking mechanism that endows the user with the possibility of reviewing the quote in context. Therefore, it is proposed that the cite attribute be redefined to contain human parseable information -- such as the source of a 16:43:12 <oedipus> GJR: "Likewise, the globally available src attribute should be applied explicitly to the CITE element, so that an author can point to a standardized external reference profile for the resource encased in the CITE element. Finally, a for/id relationship between the Q element and the CITE element, which allows the author to bind individual quotes to a common source. " 16:43:40 <oedipus> SM: @cite is legacy - existed in HTML4; has different semantic than @href 16:43:48 <oedipus> SM: drop @src 16:43:58 <oedipus> SM: @href and @cite similar 16:44:07 <oedipus> SM: not sure how dovetails with RDFa 16:44:32 <oedipus> SM: arguable that @cite is something RDFa should process but didn't define rules for that 16:45:09 <oedipus> GJR: @href for Q points to content in context; @src for Q points to source of quote 16:45:13 <oedipus> SM: rel="cite" 16:45:32 <oedipus> s/SM: rel="cite"/SP: rel="cite" 16:45:39 <oedipus> SM: will bring up in RDFa telecon 16:47:21 <oedipus> "Currently, asssistive technologies are capable of speaking the contents of the cite attribute when one is reading a quote or blockquote and has quote identification turned on; however, the utility of a URL to provide context and continuity are exceedingly limited -- a URI should be the course of last resort. An example has been set by assistive technologies' handling of images: if no alt try title if no title, use the src value. For cite attribute, the cascade 16:47:55 <oedipus> cite in HTML4x http://www.w3.org/TR/html401/struct/text.html#edef-CITE 16:48:04 <oedipus> RM: are we done with AVK's comment on cite? 16:48:08 <oedipus> SM: fixed examples 16:48:18 <oedipus> SM: KBD element 16:48:34 <oedipus> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-text.html#edef_text_kbd 16:49:08 <oedipus> current XHTML2 wording: "The kbd element indicates input to be entered by the user." 16:49:21 <oedipus> SM: response: not in our scope 16:49:24 <oedipus> RM: agree 16:49:27 <oedipus> SP: agree 16:49:30 <oedipus> GJR: agree 16:49:31 <alessio> agree 16:49:36 <Zakim> -Steven 16:49:53 <oedipus> SM: AVK's next comment - use case for L is bad and doesn't BLOCKCODE preserve whitespace 16:49:56 <Steven> sorry, dropped the phone, just a moment 16:50:09 <oedipus> GJR: BLOCKCODE versus PRE 16:50:11 <Steven> zakim, dial steven-617 16:50:11 <Zakim> ok, Steven; the call is being made 16:50:13 <Zakim> +Steven 16:51:33 <oedipus> GJR: PRE literally as-is 16:51:52 <oedipus> GJR: BLOCKCODE can signal to assistive tech to respect and count whitespace 16:52:19 <oedipus> SM: BLOCKCODE doesn't preserve whitespace - layout attribute is irrelevant 16:52:48 <oedipus> GJR: point simply that whitespace is extremely hard to communicate to a non-visual user 16:53:19 <oedipus> GJR: python examples should be in BLOCKQUODE rather than PRE 16:53:38 <oedipus> s/BLOCKQUODE/BLOCKCODE 16:53:45 <oedipus> SM: made note to change example 16:54:04 <oedipus> SM: don't want to loose this thread 16:54:14 <oedipus> GJR: will try and explain more clearly 16:54:35 <oedipus> ACTION: Gregory - send post to list explaining concerns over PRE 16:54:35 <trackbot> Created ACTION-70 - - send post to list explaining concerns over PRE [on Gregory Rosmaita - due 2009-04-02]. 16:55:24 <oedipus> RM: HTML5 backtracked on Q to HTML2 16:55:38 <oedipus> SM: comment "why should be done in text and not stylesheet" 16:55:47 <oedipus> http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/Q 16:56:16 <oedipus> GJR: "BLOCKQUOTE is nothing more than a presentational model taken from print conventions, rather than semantic meaning. If Q was ubiquitously implemented, one could use styling rules to create a Q instance with the properties of a block quotation -- that is, as a paragraph indented at least 5em on both left and right margins;" 16:56:33 <oedipus> GJR: favors a SINGLE quote element 16:56:44 <Zakim> -Roland 16:56:59 <oedipus> GJR: BLOCKQUOTE has no semantic meaning -- it is merely one means of many of demarcating any quote an arbitrary number of sentences long. 16:56:59 <oedipus> GJR: a quote is a quote is a quote - how it is demarcated as a quote is a presentational matter; what is important is that the material be logically and consistently marked up, so why have 2 forms of QUOTE, when only one is needed? 16:57:14 <oedipus> SM: next comment - why an A element - answer: backwards compatibility 16:57:23 <oedipus> SM: why can't one use more than one CAPTION in a list? 16:57:33 <oedipus> SP: CAPTION for entire list, not part of it 16:57:37 <oedipus> 26634 16:57:54 <Zakim> +Roland 16:58:23 <oedipus> GJR: so are we in effect setting up a cascade that says CAPTION for whole item, LEGEND for components? 16:58:50 <oedipus> SM: don't have LEGEND element anymore 16:59:10 <oedipus> GJR: i've been working within PF to reuse the LEGEND element in HTML5 16:59:44 <ShaneM> (confirmed - we no longer have a legend element in XHTML 2) 16:59:55 <oedipus> GJR: since XForms carries LABEL, and LEGEND is no longer needed for the FIELDSET model that LEGEND be reused as an organizational grouping desceriptor 17:00:26 <oedipus> RM: labelling a different discussion 17:01:16 <Steven> zakim, status? 17:01:16 <Zakim> I don't understand your question, Steven. 17:01:24 <oedipus> some thoughts on LEGEND: http://lists.w3.org/Archives/Public/www-archive/2009Mar/0015.html 17:01:29 <Steven> zakim, ports? 17:01:29 <Zakim> I see 92 ports in service, 76 ports idle 17:01:48 <oedipus> SM: 10 more items in AVK's list 17:01:56 <oedipus> http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/XHTML-2.0 17:02:31 <Zakim> -Steven 17:02:32 <oedipus> RM: next address 13.1 17:02:32 <Zakim> -ShaneM 17:02:33 <Zakim> -Markus 17:02:34 <Zakim> -Roland 17:02:39 <oedipus> rrsagent, make minutes 17:02:39 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 17:02:42 <Zakim> -Gregory_Rosmaita 17:02:44 <Steven> thanks Gregory!~ 17:02:45 <Zakim> -Alessio 17:02:46 <Zakim> Team_(xhtml)13:00Z has ended 17:02:47 <Zakim> Attendees were Roland, Gregory_Rosmaita, +46.7.06.02.aaaa, Markus, Steven, Alessio, ShaneM, Tina 17:02:50 <oedipus> my pleasure 17:02:55 <oedipus> rrsagent, make minutes 17:02:55 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 17:02:59 <oedipus> rrsagent, stop 17:03:53 <oedipus> present- [+46.7.06.02.aaaa] 17:03:59 <oedipus> rrsagent, make minutes 17:03:59 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 17:04:18 <oedipus> present- +46.7.06.02.aaaa 17:04:22 <oedipus> rrsagent, make minutes 17:04:22 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 17:04:49 <oedipus> rrsagent, stop 17:05:17 <oedipus> ==== ADJOURNED ==== 17:05:25 <oedipus> rrsagent, make minutes 17:05:25 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-xhtml-minutes.html oedipus 17:05:28 <oedipus> rrsagent, stop 17:09:34 <oedipus> zakim, please part 17:09:34 <Zakim> Zakim has left #xhtml 17:09:39 <oedipus> rrsagent, stop # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000862