XHTML2 WG Virtual FtF -- 26 Mar 2009

<scribe> scribe: Gregory_Rosmaita

<scribe> ScribeNick: oedipus

<Steven> code is CONF4

<Steven> 26634

previous: http://www.w3.org/2009/03/10-xhtml-minutes.html

Agenda Review

<Roland> http://www.w3.org/MarkUp/xhtml2/wiki/2009-03-10-FtF-Agenda#2009-03-26

4 XHTML2 items: the P content model, Navigation (nl in or out?), Semantics and Elements versus Attributes, how to incorportate ITS

RM: start with news from the A.C. meeting once reach critical mass

SP: would very much like to report, but want shane and mark to be here when i do

RM: brief update on PER

MG: Shane said he'd be late yesterday

scribe's note: [steven ping outliers]

minutes from last regularly scheduled meeting: http://www.w3.org/2009/03/25-xhtml-minutes.html

RM: brief update with PER?

PER Update

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

RM: just matter of questoinnaires?

SP: PER has to be voted upon; extra administrivia - creating detailed questionnaires with pointers (creating now - have to go out simultaneously with PER anouncement)

RM: that's all we need do?

SP: yes

RM: any other administrivia?

scribe's note: deafining silence

GJR: in response to feedback and discussion at last virtual f2f i have updated the "for" attribute proposal

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/forAttribute

GJR: changes: proposed for Text Attributes collection, not Core collection

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;

2. That the for/id mechanism serve as a means of re-using values for: ABBR, D (the single letter "dialogue" element), DFN;

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;

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;

News & Notes - AC Meeting Report

SP: much of AC meeting, but not all, in sphere of HTML5 and XHTML2
... 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
... 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

RM: link to AC minutes?

http://www.w3.org/2009/03/23-ac-minutes.html

<Steven> http://www.w3.org/2009/03/23-ac-minutes#item02

http://www.w3.org/2009/03/22-ac-minutes

http://www.w3.org/2009/03/24-ac-minutes

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)
... at least 2 negative comments from audience: Daniel Glazman (not there physically but on IRC) - very anti-XHTML2
... 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
... good feedback after panel; lots of red herrings being spread in discussion; tried to expose falicies
... after that meeting had breakout groups - about 20 in XHTML2 breakout group
... not minuted in IRC, hand-made minutes - trying to find if up in w3c space yet
... 2 breakout groups: 1st day: discuss issues (extended panel) - on second day, discussion on what to do with situation
... 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
... asked who is using 2 technologies; one person said, "since HTML5 seeks to make all pages conformant to HTML5, HTML5 is what people use
... explained modularization and the packaging of modules to create XHTML2
... because our charter has always been modularization, modules are deliverables; XHTML2 is a collectoin
... Arun surprised that there are big companies using XHTML and XForms
... meeting concluded with agreement that Sam Ruby and Steven Pemberton should work on merging HTML5 and XHTML2
... 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
... if choice between merging and not merging, think should keep separate unless agree to accept XForms and extensibility
... SamR and i can discuss to ascertain options
... in conclusion, think that we are now in stronger position
... 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.)
... either of those 2 choices much better than shutting down XHTML2
... SamRuby is new co-chair of HTML5 - very positive interaction with him
... Sam Ruby wants to work together, but a lot of work to herd that enourmous herd of cats in HTML WG
... doubt that core HTML5 people will accept collaboration

GJR: did sam mention the initative at mozilla to produce a rival spec to HTML5?

http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/0c2bbb6ed726800b

https://bugzilla.mozilla.org/show_bug.cgi?id=478665

RM: take more stable to have third version of HTML5
... pragmatic - how to achieve a deliverable

SP: wasn't mentioned

<Tina> Thank ye

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

RM: will be taking features from HTML5 spec and adding them on; means of incrementally deploying HTML5

<Steven> http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=978

GJR: being deployed by fiat now

SM: more socially acceptable

RM: extensibility already being done by implementation by fiat of HTML5

SP: one discussion at AC meeting in first day's breakout group was lack of extensibility
... consensus of breakout group was extensibility needs to be supported
... from POV of merging, extensibility essential
... long discussions about extensibility and what needs to be able to be done

SM: agreed upon definition of term "extensibility"?

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
... when i trace minutes for breakout groups will post link

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
... WAI/PF needs to retain control over ARIA's vocabulary and definitions

SP: some people surprised that ARIA sprang from XHTML Role Module
... good to have BenA there on first day; Ben stated that it would be wrong to give XML serialization to a group of people who fundamentally oppose and disllike XML/XHTML

RM: return to this later - have a few comments

SP: worth watching discussion on AC forum; have to be on AC to contribute

GJR: one could always use www-archive for comments pointed at AC

SP: encouraged by meeting; interested in how the rest of the HTML WG responds to combining 2 groups

RM: should consider ramifications for XHTML

SP: LarryMM suggested i co-chair with Sam - not my idea of fun at the moment :-)

RM: first 2 topics also being worked on by HTML5

The P content model

http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0014.html

<Steven> http://www.w3.org/2002/09/wbs/34257/ac2009-breakout1/results

RM: HTML5 doing much of what we are doing with P - placing limitations on it

SP: pasted pointer to breakout session described above into IRC

<Steven> http://www.w3.org/2002/09/wbs/34257/ac2009-breakout2/results

SP: day 2 hasn't been posted yet - Sam Ruby making minutes

TH (from cited post): "I would argue that common concept of a paragraph is quite different

from that we currently use in the XHTML draft, and that we should

change it so that it reflect the way a paragraph is normally understood

by authors, namely the way it is currently defined in the XHTML 1.*

series languages."

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

RM: P content model as defined in present draft cause anyone a problem

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

http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-structural.html#edef_structural_p

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

GJR notes he has proposal to deprecate TABLE for layout/style as BLOCKQUOTE for that use was deprecated in HTML4x

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
... proposed TABLE role="presentation" doesn't undo the damage, in fact almost encourages it

GJR: strong agreement - wrong approach

http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0014.html

AC: no presentation - OBJECT should be used to embed video, audio, or presentation
... more like a user-modality for TABLE - agree with SP and GJR that layout tables should be banned

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

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

tina?

<Tina> I am, but noise in office

tina, can you explain your proposed changes to P content model

<Tina> oedipus: certainly. We keep the one currently in use for HTML.

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

SP: TH wants to exclude people who believe P is something different than what she is proposing

RM: irritating when have to change prose into a list
... if write normal english: ingredients are: a) ; b) ; c);but cannot style as list because is prose list
... that is standard natural language usage

<Roland> ingredients are: a; b; c.

SP: including a list in P is perfectly valid

RM: examples would help

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

GJR: agree - whether list is prose or formatted as list, belongs to the P and should be inside the P

<alessio> +1

<Tina> A suggestion, as quoted from me, above would be to allow lists - possibly inline lists - but exclude other use.

RM: alternative: leave as is, insert 2 examples, and note asking for feedback

ACTION - Gregory: draft example of P with prose list and structural list

<trackbot> Sorry, couldn't find user - -

<scribe> ACTION: Gregory - draft example of P with prose list and structural list [recorded in http://www.w3.org/2009/03/26-xhtml-minutes.html#action01]

<trackbot> Created ACTION-65 - - draft example of P with prose list and structural list [on Gregory Rosmaita - due 2009-04-02].

tina, could you provide examples of other uses of P?

or a list of what you would exclude from the P content model?

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

RM: only one causing difficulty with P content model is TABLE
... list, blockquote, pre and table

GJR: why blockquote and not blockcode?

SP: blockcode is part of content model

RM: what is normative? DTD or spec?

SM: spec always wins

RM: where spec doesn't include blockcode, bug in DTD

http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-structural.html#edef_structural_p

SM: no DTD for XHTML2

SP: not from DTD but modulariztion code

RM: still looking at what we pointed to originally
... list, blockquote, pre and TABLE

SP: english text is wrong - should also include blockcode
... module text at top is definitive version

RESOLUTION: fix XHTML2 prose to include blockcode

SM: shouldn't be in text

SP: plus 1 to that

GJR: following wiser heads like a lemming

SM: no other element describes content model in prose

SP: point of english text is to explain diff between XHTML2's P and earlier versions

RM: simple link-back to definition would help

SP: need to get that automated by shane
... spec written as small files - by element or attribute, which then get put together in standard way

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

GJR: plus 1 to shane's proposal

RM: talk about attributes, but not content model

SM: talk about content model elsewhere - may need to reinforce in this module because so large
... proposed text

SP: is example of P with embedded UL in it

RM: in contrast to what was done in previous versions P /P UL /UL rather than P UL /UL /P

SM: mistake for us to include references as to how things used to be

RM: alternative today - P can contain lists; put side-by-side explaining can do either of these

SM: ok

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"

RM: not sure need "more consistent" clause

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"

RM: richer content model of paragraph should be sufficient

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.

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

TEN MINUTE BREAK - RECONVENE AT HALF-PAST HOUR

Navigation

question: Do we really need four different types of lists in XHTML 2.0?

http://lists.w3.org/Archives/Public/www-html/2008May/0005.html

http://lists.w3.org/Archives/Public/public-xhtml2/2008Nov/0015.html

<Tina> oedipus: an exaggeration, surely.

<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'

current editor's draft definition of NL: http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-list.html#edef_list_nl

RM: do we need 4 kinds of list?
... discussed - fairly broad concept; item about elements versus attributes topic is related
... why did we create NL?

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
... 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
... new markup allows NL without new type of element]
... instead of NL, UL role="navigation"

RM: device independence group worked on this; large areas of page - are areas devoted to navigation

<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?

RM: not catered for inside markup; navigation is important property
... difference from my POV is navigation is more than list
... HTML5 has NAVIGATION element - useful notion: can be more to navigation than items; headings (primary navigation, secondary navigation)
... would like to reframe converstation from NL to NAVIGATION section

<Roland> HTML5 : http://www.w3.org/TR/html5/semantics.html#the-nav-element

<ShaneM> I agree with Steven that @role can be used to indicate that a section is related to navigation.

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

RM: felt navigation was structure

SP: use SECTION role="navigation" is equivalent
... could also use UL role="navigation" or OL role="navigation"
... can be done by attaching role to SECTION or directly to list

<Tina> Have we agreed to leave *all* semantics to RDFa and @role?

<ShaneM> Tina: No, I don't think so.

RM: OL role="navigation" equals SECTION role="navigation"

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"

<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?

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
... throw out NL

SP: can live with that

AC: me too

GJR: me too

<mgylling> +1

<ShaneM> Note that @role already has a predefined value for "navigation"

RM: would prefer a NAV element rather than just list
... no element whose specific role is navigation, can be satisfied by assigning role to other structural elements

SP: kept a lot of elements that aren't strictly necessary because of use-and-practice with list

SM: extended content model for DL by adding DI
... very positive move
... can't decide if TH making serious point or playing devil's advocate
... 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
... don't think a lot of value removing things people are already familiar with

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

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

RM: not on agenda, but could discuss when return to HTML5 discussion
... making incremental changes that make it hard to deploy - is it worth return on investment
... do we need to introduce DI type of thing to discuss later
... concrete example?

<Tina> Since we are already changing or removing things people are already familiar with. Consistency is key.

SP: resolution to remove NL?

proposed RESOLUTION: remove NL from XHTML2's List Module

RM: propose we remove NL

<Steven> and replace with use of @role="navigation"

GJR: plus 1 with SP's caveat

<Steven> as necessary

SM: we created "navigation" role

proposed RESOLUTION: remove NL from XHTML2's List Module and replace with use of role="navigation"

SP: current model for DL wouldn't break existing user agents

<Steven> I think

GJR: agree with SP - will make DL stronger and more useful

<Steven> +1

<Steven> on resolution

<mgylling> +1

proposed RESOLUTION: remove NL from XHTML2's List Module and replace with use of role="navigation"

plus 1

<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/

<ShaneM> oops... http://www.w3.org/1999/xhtml/vocab/

definition of navigation from vocab document: "navigation indicates a collection of items suitable for navigating the document or related documents."

RM: seem to have gotten a bit mixed up - talking about multiple things
... resolution to remove NL

proposed RESOLUTION: remove NL from XHTML2's List Module and replace with use of role="navigation"

<ShaneM> +1

<Roland> +1

<Steven> +1

<alessio> +1

RESOLUTION: remove NL from XHTML2's List Module and replace with use of role="navigation"

<ShaneM> ACTION: Shane to remove the nl element from XHTML 2 [recorded in http://www.w3.org/2009/03/26-xhtml-minutes.html#action02]

<trackbot> Created ACTION-66 - Remove the nl element from XHTML 2 [on Shane McCarron - due 2009-04-02].

SM: one related item is DL

SP: changes won't change deployment

SM: DI would be ignored?

MG: DI is optional

GJR: provides nice low-grade binding for DDs

RM: DI introduced to solve what particular problem?

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

<mgylling> ... di solves a problem that could also be solved with @for...

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

markus, do you have more to say on "for"

RM: like paragraph - if don't want to use DI, don't have to

<mgylling> no - I am all for DI.

good

RM: any other potential pitfalls with lists?

SM: added in list module the caption element and hooked into content model for all lists

<ShaneM> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-list.html#s_listmodule

http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-list.html

RM: lists allow caption

GJR: might want to consider LEGEND

<Steven> We need to consider the purposes of LEGEND LABEL and CAPTION

http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeExamples

<Steven> and work out whether to merge

<alessio> yes, it's a very good point

SM: haven't addressed use of XForms inline content with other forms of inline content

Use of FIGURE, LEGEND, and @alt

Three Stages of A Butterfly's Life Example

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:

<LEGEND id="l1">The Three Stages of a Butterfly's Life Cycle</LEGEND>

<IMG alt="Stage 1: The larval stage." src="butterfly1.svg"

longdesc="butterfly1.html">

<IMG alt="Stage 2: The pupal stage." src="butterfly2.svg"

longdesc="butterfly2.html">

<IMG alt="Stage 3: The adult stage." src="butterfly3.svg"

longdesc="butterfly3.html">

</FIGURE>

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

a) each individual image's short alternative text;

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;

Supplemental Document - Best Practices Guide?

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

GJR: i will send "thoughts on LEGEND" used in PF deliberations over terse descriptors in HTML5 to XHTML2 list

RM: like examples - pick up as a template and build upon it
... christina once worked on something similar, but we haven't undertaken anything as a WG

SP: no, we haven't really

RM: continuing developing document, steven?

SP: received a lot of input at AC meeting on how should be structured

how to incorporate ITS

http://lists.w3.org/Archives/Public/public-xhtml2/2008Dec/0023.html

http://www.w3.org/MarkUp/tracker/actions/28

SM: does anyone understand the ITS question?

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;
... semantic markup with specific domain: meaning of words with respect to other languages

<mgylling> http://www.w3.org/TR/its/

RM: who is driving this request

SP: i18n

<Steven> Then from there, run batch file <cmd

<Steven> its:translate="no">Build.bat</cmd>.</p>

MG: investigated ITS - 3 options to introduce rules into document - inline (similar to @style), xlink to external document, or put info in HEAD
... not just question of attribute, but should we support XLINK in HEAD, etc.

RM: can link to ITS definition, full stop

SM: not an option

SP: wouldn't let us do that?

SM: our architecture doesn't allow for arbitrary content models; need to specificy what goes where
... 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
... 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
... should ask ITS WG how to use ITS in our module

RM: ITS WG closed
... ITS interest group still active
... should ping them to ask "how do you think this applies to us?"

SP: created something similar to CSS - create rules in HEAD or inline
... a lot of their stuff we have anyway - don't need @dir because took from us and put in their namespace

GJR: notes that this is a good trend - similar to timesheets

SP: translate rules - include their rules into HEAD and then in BODY only thing that is left is translate equals yes or no

MG: correct; have schema modules for ITS we can import
... external sheets via XLink
... should ask if can use LINK element instead

RM: sounds reasonable

SP: invite someone from ITS to join us on a call to discuss

GJR: sounds reasonable

SP: should be able to find someone courtesy of RichardI

<scribe> ACTION: Steven - talk to Richard to ask if someone from ITS can join an XHTML2 call to discuss this further [recorded in http://www.w3.org/2009/03/26-xhtml-minutes.html#action03]

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

RM: is anyone recognizing ITS?

SP: if no one is producing content with it answer is no

RM: are we the best people to bootstrap this?

http://www.w3.org/International/its/tests/its2xquery

http://www.w3.org/International/its/itstagset/ImpReport

http://www.w3.org/International/its/tests/

SM: should be bending over backwards to reuse W3C technologies and standards

GJR: first principle of WCAG - if pertinent technology exists (such as MathML) use it

<Steven> r12a suggests 10 01yves savourel 01chair of the former WG

RM: doesn't sound too onerous

<Steven> and cc to Felix of W3C

RM: don't need its prefix, just "yes" or "no"

SM: does spec allow chameleon?

MG: published note on how to incorporate ITS into XHTML family

http://www.w3.org/International/its/itstagset/ImpReport#conftype1

<Steven> ysavourel at translate.com

processing expections for ITS: http://www.w3.org/International/its/itstagset/ImpReport#conftype2

<Roland> http://www.w3.org/TR/xml-i18n-bp/#its-plus-xhtml10

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3331#c8

http://www.w3.org/International/its/techniques/its-techniques.html#integration-its-xhtmlmod

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

MG: roland's pointer the one i was thinking about

SM: last one GJR put in is what i was looking at

RM: XHTML M12n 1.1 - http://www.w3.org/TR/xml-i18n-bp/#its-plus-xhtml10

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

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

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

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

SP: reading from spec: "one way to associate document with external ITS rules is to use optional XLINK"

http://www.w3.org/MarkUp/tracker/actions/28

<Steven> so it sounds optional

SM: questions we have: don't support XLink, so can we use LINK? leave in ITS space and use their suggested model?
... 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

proposed RESOLVED: XHTML2 WG will discuss ITS integration and use of LINK versus XLink with representative from i18n

RESOLUTION: XHTML2 WG will discuss ITS integration and use of LINK versus XLink with representative from i18n

SP: already invited them

SM: thank you

RM: anything else on ITS?

Clearing Out Old Action Items

RM: quantity values question

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
... in XHTML2 have list of types used for content negotiation
... comment that don't take into account QValues
... been boning up on QValues

RM: should add to tracker

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
... answer may be no qvalues in source

SM: think that is the answer
... QValue responsibility of UA; intersection of what UA can handle and what author can offer

SP: order of things in specification important - take first or highest q?
... when UA specifies what is willing to accept does it mean willing to accept them equally

SM: have to check HTTP spec
... order is probably significant - will check

<Steven> ACTION: Steven to work out how to merge q values in the specification of content negotiation with hreftype etc. [recorded in http://www.w3.org/2009/03/26-xhtml-minutes.html#action04]

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

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/XHTML-2.0?user=guest;statetype=-1;upostype=-1;changetype=-1;restype=-1

RM: work through 16 open issues on shane's tracker?

SM: not now

RM: when?

SM: not sure what to do with 5 year old comments

RM: are any of the issues still relevant?
... how to deal with them?

GJR: port them to W3C tracker and close those that are moot?

"QNames are the way that the working group, and indeed the W3C, handle having

data that comes from differing sources. The working group is not willing to

change course at this time

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

SP: some just comments
... several of these things don't need to do
... can answer, but no action necessary
... real issues: keep BR (which i think we do)

SM: were instructed by TBL to keep BR

SP: a lot of editorial comments

<Tina> What is the structural purpose of BR? That should be the only reason why we keep it or toss it.

<Tina> Yes. What's our use case for keeping it?

SP: could say that WG received this remark and is not required to answer; get input from more recent suggestions

<Tina> Then I suggest we get rid of BR as more-or-less physical markup.

tina, do you want to work on a proposal to eliminate BR?

deprecate in favor of use of L ... /L

anne van k on L: "Didn't BLOCKCODE preserve whitespace by default? What do we need the L

element for here? And as mentioned before, BR is still needed. I also

think that a better use case for L should be presented, this one is bad."

<Tina> oedipus, I don't have the time to write up anything formal, I'm afraid.

me neither, but i might as well take a whack at it right now

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

<Tina> oedipus: I agree with that.

SM: "1.1.2. Backwards compatibility
... will update as appropriate
... 1.1.2. Backwards compatibility

<Tina> We are already deviating from that, however, by changing content models. Removing presentational markup is surely a good idea.

SM: wants BR back; instructed to do it, but haven't done it

SM: agree

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

SP: can live with keeping it, but with a note stating that L is preferred method

<ShaneM> ACTION: Shane to put br element back into XHTML 2 with a note that there are better ways to mark up lines. [recorded in http://www.w3.org/2009/03/26-xhtml-minutes.html#action05]

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

proposed Resolution: restore BR

SP: objections?

GJR: object

SP: if objections, don't have resolution

RM: GJR, do you believe we should not do this?

GJR: willing to compromise on BR if we add note on use of L

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

GJR: is there any override mechanism for BR?

SP: compromise: include BR but mark as deprecated

GJR: yes

<ShaneM> deprecated? in a legacy br module?

proposed RESOLUTION: re-introduce BR, marking as deprecated, and point out that for accessibility, is much better to use L

<Steven> +1

<ShaneM> +1

GJR: plus 1

AC: yes

<Roland> +1

<mgylling> +1

<alessio> +1

RESOLUTION: re-introduce BR, marking as deprecated, and point out that for accessibility, is much better to use L

RM: next one is ADDRESS element

SM: request is make content model for address richer, or introduce a BLOCKADDRESS element

GJR: isn't this covered by role="contentinfo"

vocab doc: "

contentinfo has meta information about the content on the page or the page as a whole.

<Steven> By the way, there is a new rrsagent in the works: http://www.w3.org/2009/CommonScribe

http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-structural.html#edef_structural_address

SM: not inclined to change from block to inline or to add blockaddress

SP: non-structural element that only adds semantic information
... semantic info is terribly vague - can't extract much sensible out of ADDRESS

RM: HTML5's ADDRESS is not block

SM: problem is content model restricted;

http://www.w3.org/TR/html5/semantics.html#the-address-element

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

<Tina> That does appear fairly clear, if not detailed. What is the use case for changing it?

"The address element must not contain information other than contact information."

<ShaneM> Tina: the request is to make the content model richer

GJR: HTML5 Address is a child of FOOTER

<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?

http://www.w3.org/TR/html5/semantics.html#the-footer-element

GJR: address is part of FOOTER, but restricted to contact info only
... in HTML5

<ShaneM> Tina: I think we just could make the content model richer.

Content model for FOOTER in HTML5: "Flow content, but with no heading content descendants, no sectioning content descendants, and no footer element descendants."

SM: either add blockaddress or fix rich content model
... objections to making content model of ADDRESS richer?
... need to define "richer"
... same as SECTION

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

RM: why not say SECTION role="address"

SP: on other hand, could just say ADDRESS is shorthand for SECTION role="address"

RM: no difference in semantics for ADDRESS and SECTION role="address"
... need to define semantics of ADDRESS

SM: DIV role="p" is not a substitute for using P - if element has semantics, use the element
... have ADDRESS element - could say "if need area of document with richer content model and address information, use SECTION role="address"

RM: no existing "address" role

GJR: when we did ARIA/HTML5 analysis decided that "contentinfo" more broad than HTML's ADDRESS

SM: defer to dublin core or VCard?

<Tina> Suggestion: keep <address> as is, and encourage authors to use other markup languages for the specifics.

SM: vocab collection for role is missing fundamental concepts - is that because we are deferring to DC

SP: do in RDFa instead of role

RM: on typical page, navigation area, content area, contact area very common - address related to contact info

SM: dublin core values we can use for that

RM: broke up page into appendix, content, copyright, etc.

SM: can add a role

<alessio> agree

RM: can state "not changed from HTML4; if want richer mechanism, create it according to the markup family's extension rules

SM: probably way to group all of this together
... should we introduce additional role values

GJR: yes

SP: good point

GJR: would like to differentiate between explanatory note and referential note

SM: in existing vocabulary

from vocab document: note: "note indicates the content is parenthetic or ancillary to the main content of the resource."

GJR: there are 2 types of note: referential (citation, endnote) and annotative (what the vocab doc says)

SP: resolution?

<ShaneM> Tina: I think that is where we are ending up. Thanks!

RM: leave address as-is, if want to create richer structures for that information, use SECTION

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)

<alessio> +1

<ShaneM> +1

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

<Roland> +1

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

SM: need to discuss additional role values - add to next f2f agenda
... heading element - "confusing" - example of use of both
... think addressed this by moving things around in document
... anne objects to P element content model that allows some block-level elements to be mixed in

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

SM: PRE element comments
... changed example

GJR: PRE is a problem for accessibility

RM: editorial comment

SM: separator element -

SP: TBL has affection for HR

<Steven> unexplained affection

<Tina> Do we need HR when we have SECTION?

"There isn't mentioned a single use case. Only some presentational issues

that should be kept in CSS as mentioned in 1.1.1. Right?"

<Steven> no TIna, we don't

SM: don't understand point of comment

GJR: hell, lets deprecate all BLOCK* elements in favor of CSS

SM: lets disucss separator
... TBL has affection for HR - does that mean need HR deprecated in favor of SEPARATOR?

http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-structural.html#edef_structural_separator

SP: from fundamental point of view, solves problems with HR - found use cases for separator, could do with SECTION, but SEPARATOR is useful markup
... problem with HR - presentational; rather than introduce VR, use SEPARATOR

RM: should say HR has no semantic meaning but is shorthand for SEPARATOR

proposal: rename SEPARATOR to HR and add note: "there is nothing horizontal or presentational implied by HR"

SP: first element not related to concept

RM: should be there for legacy, but if starting afresh use SEPARATOR

SP: reason for caring is that saying that won't change ingrained understanding of HR no matter what we say

RM: how do languages that want VR handle HR?

SP: maybe HR only works horizontally and are using borders on DIV for visually approximations of vertical rules
... i18n complaint still valid

RM: only if say HR has semantic meaning other than as shorthand for SEPARATOR

SP: have to provide standard stylesheet for XHTML2 - have to provide default style for SECTION, H, etc.

SM: don't think SEPARATOR an HR
... HR is a styled line running horizontally across page
... separator is semantic indication that one part of document different from another - can be reflected in style rules or not

http://www.w3.org/TR/html5/semantics.html#the-hr-element

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

RM: suggest we move on for now

"Contexts in which this element may be used: Where flow content is expected."

SM: next comment: ABBR should use something other than @title - we do, so that is moot
... next comment: CITE element

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/CITE_and_cite

"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

<q for="fdr3i"

href="http://www.hicom.net/~oedipus/exegesis/fdr-third-inaugural.html#fdr3ip36s1"

cite="Franklin Delano Roosevelt: Third Innaugural Address; January 20, 1941"

>In the face of great perils never before encountered, our strong

purpose is to protect and to perpetuate the integrity of democracy.

</q>

</section>

<h id="biblio">Bibliography</h>

<ol>

<li role="contentinfo"><cite id="fdr3i"

src="http://www.fdrpapers.gov/fdr3i.html"

>Roosevelt, Franklin Delano. Third Inaugural Address. Delivered

before a joint session of congress, January 20, 1941. (official

White House transcript)</li>

</ol>

</section>

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.

<Steven> I think this is another element rendered unnecessary by rdfa

GJR: should be able to point to CITE element with for/id relationship
... if @cite is retained should be for human processing

SM: disagree
... src is used to identify external source that is only read-in; href is used for hyperlink; cite is something else
... in current XHTML2 @cite is an @href that is actionable through an alternate method

GJR: a quote is embedded content

<Steven> I think it is actually equivalent to rel="cite" href="...."

<alessio> yep

SM: @src brings in a URI and replaces Q

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

SM: @cite is legacy - existed in HTML4; has different semantic than @href
... drop @src
... @href and @cite similar
... not sure how dovetails with RDFa
... arguable that @cite is something RDFa should process but didn't define rules for that

GJR: @href for Q points to content in context; @src for Q points to source of quote

SP: rel="cite"

SM: will bring up in RDFa telecon

"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

cite in HTML4x http://www.w3.org/TR/html401/struct/text.html#edef-CITE

RM: are we done with AVK's comment on cite?

SM: fixed examples
... KBD element

http://www.w3.org/MarkUp/2009/ED-xhtml2-20090205/mod-text.html#edef_text_kbd

current XHTML2 wording: "The kbd element indicates input to be entered by the user."

SM: response: not in our scope

RM: agree

SP: agree

GJR: agree

<alessio> agree

SM: AVK's next comment - use case for L is bad and doesn't BLOCKCODE preserve whitespace

<Steven> sorry, dropped the phone, just a moment

GJR: BLOCKCODE versus PRE
... PRE literally as-is
... BLOCKCODE can signal to assistive tech to respect and count whitespace

SM: BLOCKCODE doesn't preserve whitespace - layout attribute is irrelevant

GJR: point simply that whitespace is extremely hard to communicate to a non-visual user
... python examples should be in BLOCKCODE rather than PRE

SM: made note to change example
... don't want to loose this thread

GJR: will try and explain more clearly

<scribe> ACTION: Gregory - send post to list explaining concerns over PRE [recorded in http://www.w3.org/2009/03/26-xhtml-minutes.html#action06]

<trackbot> Created ACTION-70 - - send post to list explaining concerns over PRE [on Gregory Rosmaita - due 2009-04-02].

RM: HTML5 backtracked on Q to HTML2

SM: comment "why should be done in text and not stylesheet"

http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/Q

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;"
... favors a SINGLE quote element
... BLOCKQUOTE has no semantic meaning -- it is merely one means of many of demarcating any quote an arbitrary number of sentences long.
... 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?

SM: next comment - why an A element - answer: backwards compatibility
... why can't one use more than one CAPTION in a list?

SP: CAPTION for entire list, not part of it

26634

GJR: so are we in effect setting up a cascade that says CAPTION for whole item, LEGEND for components?

SM: don't have LEGEND element anymore

GJR: i've been working within PF to reuse the LEGEND element in HTML5

<ShaneM> (confirmed - we no longer have a legend element in XHTML 2)

GJR: since XForms carries LABEL, and LEGEND is no longer needed for the FIELDSET model that LEGEND be reused as an organizational grouping desceriptor

RM: labelling a different discussion

some thoughts on LEGEND: http://lists.w3.org/Archives/Public/www-archive/2009Mar/0015.html

SM: 10 more items in AVK's list

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/XHTML-2.0

RM: next address 13.1

<Steven> thanks Gregory!~

my pleasure

==== ADJOURNED ====

- DRAFT -

XHTML2 WG Virtual FtF

26 Mar 2009

Attendees

Contents

Agenda Review

PER Update

News & Notes - AC Meeting Report

The P content model

Navigation

Supplemental Document - Best Practices Guide?

how to incorporate ITS

Clearing Out Old Action Items

Summary of Action Items

Scribe.perl diagnostic output