See also: IRC log
<scribe> scribe: Gregory_Rosmaita
<scribe> ScribeNick: oedipus
<Steven> code is CONF4
<Steven> 26634
previous: http://www.w3.org/2009/03/10-xhtml-minutes.html
<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?
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;
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
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."
<Steven> (PCDATA | Text | List | blockcode | blockquote | pre | table )*
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
<Steven> (PCDATA | Text | List | blockcode | blockquote | pre | 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
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
<ShaneM> <section role="navigation">...</section>
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:
<FIGURE aria-labelledby="l1">
<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;
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
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?
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].
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
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.
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
<section role="main">
<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>
<section role="secondary">
<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="...."
<ShaneM> <quote src="someURI" />
<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 ====
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/would be/Ben stated that it would be/ Succeeded: s/not feasible/not my idea of fun at the moment :-)/ Succeeded: s/a) , b), c), / a) ; b) ; c);/ Succeeded: s/feedback/input/ Succeeded: s/traker/tracker/ Succeeded: s/what UA wants/what UA can handle/ Succeeded: s/onlly/only/ Succeeded: s/une/unne/ Succeeded: s/SM: rel="cite"/SP: rel="cite"/ Succeeded: s/BLOCKQUODE/BLOCKCODE/ Found Scribe: Gregory_Rosmaita Found ScribeNick: oedipus Default Present: Roland, Gregory_Rosmaita, +46.7.06.02.aaaa, Markus, Steven, Alessio, ShaneM, Tina Present: Alessio Gregory_Rosmaita Markus Roland ShaneM Steven Tina Agenda: http://www.w3.org/MarkUp/xhtml2/wiki/2009-03-10-FtF-Agenda#2009-03-26 Got date from IRC log name: 26 Mar 2009 Guessing minutes URL: http://www.w3.org/2009/03/26-xhtml-minutes.html People with action items: - gregory post send shane steven talk WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]