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;

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

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

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

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."

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

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

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:07:47 [Tina]

oedipus: I would *include* inline elements and possibly lists. Other block level elements are structurall illogical in a paragraph.

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"

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."

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'

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

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"

"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

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

"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."

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"

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].

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.

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

"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

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

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