XHTML2 Working Group Teleconference

03 Dec 2008


See also: IRC log



Gregory_Rosmaita, Roland, ShaneM, Markus_Gylling, Alessio, Tina_on_IRC
Mark_Birbeck, Steven




<trackbot> Date: 03 December 2008

Previous: http://www.w3.org/2008/11/26-xhtml-minutes.html

<scribe> scribe: Gregory_Rosmaita

<scribe> ScribeNick: oedipus

Agenda Planning Tracker: http://www.w3.org/MarkUp/tracker/agenda

<ShaneM> bluetooth problems mbe omp

Announcements, News, Hot Topics, Agenda Review

Agenda Planning Tracker: http://www.w3.org/MarkUp/tracker/agenda

<ShaneM> having difficulties with headset

RM: brief update on CURIE syntax - had transition call yesterday, got ok to transition, still paperwork to be done, should move forward

Oustanding Actions - http://www.w3.org/MarkUp/tracker/actions/open

RM: XML Events 2 haven't done; DOM discussed yesterday - will include action 40 in status update for HTC
... features document?

SM: none are completed unless marked "pending review"

RM: http://www.w3.org/MarkUp/tracker/actions/11 - policy statement on migration and inclusion

SM: started to do, but could decide where to put

RM: isn't there another action for that
... close action 11
... http://www.w3.org/MarkUp/tracker/actions/18 - changes in Mime document
... substantive note from Tina - http://lists.w3.org/Archives/Public/public-xhtml2/2008Nov/0032.html

SM: would rather do when tina here

RM: if no tina at meeting, please respond on-list
... action 18 should be closed
... http://www.w3.org/MarkUp/tracker/actions/33 - should be closed

RESOLUTION: Actions 11, 13 and 18 are closed

RM: action 13 might be worth some discussion

SM: delegated it; will ping and update

RM: action 15 - not have separate implements module - fold into XHTML2 - is that correct?

SM: made note to that effect in action
... leave action until finished

RM: action item from GJR - http://lists.w3.org/Archives/Public/public-xhtml2/2008Dec/0000.html

GJR: pf said: "The word "similar" was inserted to satisfy general requirements for HTML processing, since the Role module includes low-level processing specifics, which can't be ported to HTML5; therefore, in order to enable ARIA in HTML5 it is necessary to define low-level DOM parsing whilst still accepting same content, with same accessibility result. Of course, if one is using XHTML2 to author a document, then that author would and SHOULD use the Role Module

RM: all ARIA attributes can be used without prefix; defined for us and in XHTML vocab
... for ARIA terms there is no namespaced vocabulary

GJR: agree with RM, think that PF punted

SM: don't know what is going to be in HTML5

GJR: HTML5 e.t.a. is 2012 at earliest

RM: carry on and ignore -- given WAI everything asked for; shouldn't waste our cycles on this
... de facto implementation of HTML5 by developers
... happy to consider item complete

<mib_jqd0sf> ops

SM: during LC review, can submit formal objection because should be using Role attribute PF helped define

GJR: would support that

RM: any other actions finished?

Access Module

RM: waiting for comments

GJR: i18n issues?

<Tina> I'll send my comments on the ACCESS module by Monday

SM: comment from forms; Steven brought up in Forms WG - John Boyer (chair) supposed to send us note; can live with it if multiple IDs in XForms and XHTML2 synced; thing XForms comment closed

RM: can close XForms comment
... action 35 is complete

SM: everything regards Access closed out; implementation report and disposition of comments all ready; need to wait until CURIEs reaches CR for this to reach CR because references CURIE

RM: same with Role?

SM: yes, not certain if SP has sent in transition request for the 3

RM: haven't seen them
... resolved to request CR Transition [http://www.w3.org/2008/10/23-xhtml-minutes.html#item06]

XML Events 2: status?



RM: discussed last week - going back to DOM2 - have to inspect DOM2 spec - anyone done that?

SM: no

GJR: no

XHTML MIME type: Status?


RM: need to get done for XHTML 1.0 SE and 1.1 PER will point to that

SM: issue: XML 1.0 Fifth Edition became a rec yesterday
... changes rules / definition of ID - changes what chars are legal in ID; historically have just transitioned to current version of XML (any recs we put out use current XML edition), but what are rammifications of changing @id to make more inclusive - with our documents, some point to fourth edition, some to fifth

RM: reads errata for fourth edition

<mgylling> Before the fifth edition, XML 1.0 was explicitly based on Unicode 2.0. As of the fifth edition, it is based on Unicode 5.0.0 or later. This effectively allows not only characters used today, but also characters that will be used tomorrow.

RM: due to unicode changes?

SM: previously malformed documents now ok; invalid documents now valid -- don't understand

RM: main characters has changed

<mgylling> http://blog.jclark.com/2008/10/xml-10-5th-edition.html

MG: there is a blog entry from James Clark explaining why he thinks fifth edition broken - was controversial

SM: jame's blog is exactly what i thought/concluded
... good news (sort of) - always made dated references to 1.0 (reference edition numbers); we are dependent upon namespaces, and they are not referenced
... don't understand rammifications, but they keep me awake at night

RM: if stay with Fourth Edition, and say that those in Fifth Edition are ok, but a SUB-SET of those in Fourth Edition

SM: hope change is forward compatible

RM: should leave the pointer alone for XML Fourth Edition
... if get through PR review and asked why not Fifth, we say "prove to us won't cause problems"

SM: reasonable

GJR: plus 1

<alessio> +1

RM: keep status quo: publish our specs pointing to XML 1.0 Fourth Edition, until becomes an issue, if becomes and issue


<Roland> http://lists.w3.org/Archives/Public/public-xhtml2/2008Nov/0032.html

SM: major change is unicode related

Notes from Tina on XHTML Mime

RM: same mistakes i had found

SM: fixed broken internal links
... compatibility guidelines: i know what problem i was trying to solve with sentence in question: remind validation people at W3C that shouldn't validate against this

RM: could be useful to remind of constraints

<alessio> for tina and all... I write a note (in italian) on IWA Italy's blog related to tina's article: http://blog.iwa.it/varie/xhtml-basta-con-la-mitologia/

SM: don't like suggested wording: is a non-sequitor
... "TOPIC: XHTML MIME type: Status?


Tina's comment: ""It contains no absolute requirements, and should NEVER be used as

the basis for creating conformance nor validation rules of any sort.


RM: constraint over and above language definition; could write style guide
... replace paragraph with something less dogmatic

SM: accept suggestion for example 3 - don't use P

RM: "A.4. Embedded Style Sheets and Scripts
... didn't we originally say to avoid inline style and scripts?

SM: she's attempting to make more assertive, i believe
... trying to explain why suggested trick for embedding works
... we can explain that

RM: make clear that is explanation; don't have to if don't want to

SM: A.5 - generic advice; i think has to do with XML versus HTML

"This sounds like generic advice for writing markup, rather then something relevant to the differences between XHTML and HTML. I could be mistaken and would welcome pointers to the relevant parts of the specifications if so."

RM: might be useful if each of these assertions in A.5 are linked

SM: they are

RM: don't show in ToC

SM: no don't show in ToC

RM: linebreak attribute values

SM: in XML attribute values are ...

MG: whitespace neutralized?

SM: yes

RM: isn't that part of rationale? ensure on single line isn't bad advice

SM: don't remember why did in first place - tina wants rationale - thought had to do with whitespace normalization

<mgylling> If the attribute type is not CDATA, then the XML processor MUST further process the normalized attribute value by discarding any leading and trailing space (#x20) characters, and by replacing sequences of space (#x20) characters by a single space (#x20) character.

MG: section 3.3.3 of XML spec
... depends on type of attribute; if not CDATA discusses discarding leading and trailing space

RM: option for collapse as well?

MG: 3.3.3 says replace XML def of whitespace by single space only; linebreaks "normalized" to single space, leading or trailing

SM: section 2.1.1 on end of line handling
... end of lines normalized even if inside attribute value
... turns linefeeds into spaces

RM: read section 3.3.3 and 2.1.1 and best to avoid those situations since don't know what non-XML parsers would do
... A.11 - "Perhaps an example showing how to convert to lower case before checking would help clarify this for some people?"

SM: do ensure that attribute names ... are case insensitive
... can show people how to call to lower

RM: ok

SM: A.25 - i know answer and will send it to her
... A.26. - "to justify removing accessiblity feature..." -- we aren't removing, we are telling people not to do it -- same problem as NOSCRIPT

RM: deal with NOSCRIPT in whatever answer you send to tina

SM: Example Document concerns: good point about style element (no bad stuff to escape) - rather than remove CDATA markers, should put bad stuff in
... final comment - grouping selector -

RM: because HTML and BODY elements are identical, can define style once using "html,body { }"

<Roland> html, body {background-color: #e4e5e9; }

RM: list, not heirarchy

SM: right
... have bunch of changes to make - between last publication and now, pub rules have changed for Notes - additional reqs on Note we need to satisfy; will make process changes along with changes stemming from tina and our discussion of it

RM: use of ABBR or ACRONYM

GJR: have proposed INIT (initialism)

SM: will fold in WG's response to Tina's comments into Mime today along with other pub-related stuff


RM: question on "do we need nl?" - motivation, wanted navigation, but maybe use "nav" as a section - more than list - complete block, like a section

GJR: similar to Role/ARIA concept of "nav"

RM: yes, big major area, not just detail, but block of navigational options
... look at way NAV is defined when return to question:
... would nav obviate need for NL via specialized container

SM: had action to send out conversation starter


RM: ol role="nav" versus nl - will reply and through into mix that this is bigger question: NAV as structural element; will kick off conversation by replying to shane's note

<Tina> I have a half-finished reply to Shane's conversation starter

SM: point i was trying to make is have diff mechanisms to satisfy diff needs; should think about needs

GJR: positive "yes!" reaction to shane's post


Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/01/13 13:54:58 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/XML Events/XML Events 2/
Succeeded: s/class/collapse/
Succeeded: s/low tech crap/having difficulties with headset/
Found Scribe: Gregory_Rosmaita
Found ScribeNick: oedipus
Default Present: Gregory_Rosmaita, Roland, ShaneM, Markus_Gylling, Alessio
Present: Gregory_Rosmaita Roland ShaneM Markus_Gylling Alessio Tina_on_IRC
Regrets: Mark_Birbeck Steven
Agenda: http://lists.w3.org/Archives/Public/public-xhtml2/2008Dec/0001.html
Found Date: 03 Dec 2008
Guessing minutes URL: http://www.w3.org/2008/12/03-xhtml-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.
[End of scribe.perl diagnostic output]