Weekly XHTML2 WG Teleconference -- 13 Aug 2008

http://lists.w3.org/Archives/Public/public-xhtml2/2008Aug/0036.html

[fyi] i formally proposed to PF that HTML5 add @role for IMG

<ShaneM> Scribe: ShaneM

Technical Plenary Registration

Registration is open. Who is planning to come? *crickets*

<oedipus> GJR: coming good lord willin' and the crick don't rise

Tina is unsure if she will have time.

Steven thinks it will be very sparsely attended. Will see about organizing a teleconference.

Outstanding Reviews

XSD - not due for another month yet. Mark is doing it hopefully.

XHTML M12N PR Status

We went to PR and it went to a vote.

*Steven stretches it out to increase the suspense*

There were a reasonable number of member companies who voted.

We did get somebody who sent comments that are not suitable at this point in the review. They are more last call comments.

The person asked for 5 changes to the spec.

1) Please define a clear path between CDF and XHTML M12N 1.1

2) What's the goal of referencing Unicode 4.1?

3) Please update the reference to the XML specification to 4th edition.

4) Update the reference to namespaces in XML to the second edition.

5) Informative references points to XLink PR instead of Rec.

<inserted> ScribeNick: oedipus

<inserted> ScribeNick+ oedipus

SM: not our responsibility to do anything with regard to spec in regards CDF
... reference unicode 3.1 and mention that it is updated; not sure that's a change

SP: normative reference - where referenced from?

SM: (checks) - reference in Special Character Entity Set defs as symbol set def; in the DTD implementation itself, defining unicode points that map to ASCII

SP: "new names do not clash with..." "names are unicode names" - that's the only place

TH: supposed to reference unicode per se? what does requestor want us to reference?

SP: comment based on references section - different from XHTML2 which references 3.2

SM: previous version referenced 3.1 - don't recall changing

SP: answer - no difference - just reference most up to date one

<ShaneM> We can reference 4th edition of XML.

TH: version we refer to, versus version requestor wants to reference
... if changed drastically in XML, then could understand change, but don't reference most up-to-date all the time

SM: provide links to latest version often
... these are a year-and-a-half old
... no diff marked version of namespaces spec

TH: see point, but as dev, prefer when document a refers to document b.x - can compare better knowing dates and changes

<inserted> ScribeNick+ ShaneM

<ShaneM> Shane: The second edition of namespaces is harmless

<ShaneM> Steven proposes we say we will not do the CDF thing, that it does not matter we reference 4.1, and that we will make the changes to the other references.

<ShaneM> Steven will get his OK on this.

<ShaneM> ACTION: Shane to update the references. [recorded in http://www.w3.org/2008/08/13-xhtml-minutes.html#action01]

<ShaneM> ACTION: Steven to reply to the commentor. [recorded in http://www.w3.org/2008/08/13-xhtml-minutes.html#action02]

<ShaneM> ACTION: Steven get M12N published as a Recommendation with the changes applied. [recorded in http://www.w3.org/2008/08/13-xhtml-minutes.html#action03]

<ShaneM> ACTION2=Steven to reply to M12N commentor about how we will address their M12N objections.

XHTML Basic 1.1

<ShaneM> All good - everything is fine.

<inserted> ScribeNick: oedipus

SM: ian jacobs asked me to make a change so that our implementations are in markup space, but a fixed version in TR space; can do this and will do it before Rec
... fits in with "cool URIs don't change"
... have to do for M12n, anyway

SP: changes to XML 4th edition, and so on?

SM: just thought it was a friendly observation, so made change to references

<ShaneM> ACTION: Shane to update XHTML M12N DTD links so that there are versions in TR space and MarkUp space, as per XHTML Basic 1.1 [recorded in http://www.w3.org/2008/08/13-xhtml-minutes.html#action04]

Access and SVG Request

SM: 2 diff collections of SVG things - one bag not formally responded to; made most changes except for one request
... topic this week about adding @order to access - dougS was at last week's meeting; thought we had agreement, then reconsidered; took doug's wording and tweaked it and he didn' like it
... philosophic difference -
... i need to withdraw myself from decision path

http://lists.w3.org/Archives/Public/public-xhtml2/2008Aug/0031.html

SM: Doug thinks should describe positive behaviors, when docs written in conflict with standard, and i think we shouldn't - describe either no behavior or negative behavior

SP: agree - if conflict, just a bad doc and don't have to address

SM: traditional approach - could go further

SP: wants us to define what a duplicate id does

SM: positively, and that should work in violation of the principles of the ML

TH: if write broken documents, expect bad results

SM: always said that underlying protocols rule; if dependent on HTTP, can't define behavior that violates HTTP, and so on;

GJR: plus 1 to SM

SM: doug's other point is that access module is useful outside of XHTML and XML and should define it so can be used in other places; don't have scope, is an XHTML module,

SP: not chartered to do it; ocassionally extended boundaries (XML Events, for example) - not just to work with our stuff, but everyone's but that was within XML framework

TH: that is the problem - within XML framework; scope Doug talks about is use in theoretical MLs that don't exist or are not XML based

SM: what i heard was "how to use in HTML5" - want to use access in SVG, so should NOT be a problem with Access, because it is all XML

SP: should work with SVG, think we are good to go

GJR: plus 1

SM: doug proposed what happened when 2 diff IDs - added scenario to draft encased in @ signs

<ShaneM> http://www.w3.org/MarkUp/2008/ED-xhtml-access-20080809/#sec_3.1.3.

SP: sounds like we are all of one mind that should define rules for broken stuff

<ShaneM> in particular rules that have positive behavior.

TH: no - really should NOT define rules for both content within scope of XML to satisfy needs of HTML5

<ShaneM> The current wording reads "Also note: When processing an invalid document, if there are duplicate ids, element groups based on targetid values may contain multiple values, just like those of targetrole values."

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

SM: say wither "invalid document, behavior is undefined" or nothing

SP: strongly feel NOTHING

TH: agree

GJR: violently agree

SM: valid XML document shouldn't get to application layer anyway
... going to remove sentence

<Tina> ... that was fun

SP: agreed

GJR: agreed

<Tina> Agreed - tho I fell out.

SP: since speaking about Access, whole bunch of comments from i18n

<Steven> http://lists.w3.org/Archives/Public/public-xhtml2/2008Aug/0008.html

SM: one which most concerns me is keycodes and characters - isn't clear that this section (3.1.2.) didn't take into account keycode and key produced by pressing key (reads from post refered to above)

TH: that is an application / implementation problem

SM: character in document character set - how one gets to that is up to app

TH: implementation side - use access key with this symbol and do this action - how implementation triggers accesskey, may be through eye-blinking entry - may press key-combo - whether press key combo to create specific char in specific char set, is implementation decision
... cites opera model

GJR: agree that opera model best yet available

TH: shouldn't say "have to press these specific keys" to get action; don't specify how, but structural construct is path to useability and accessibility
... shouldn't be Access Module that tells one how to get keystroke generated, just provide means
... should NOT define specific mechanism

<ShaneM> The key attribute is an abstraction layer - how the user agent maps to that is up to the user agent. That's the whole point.

TH: asian characters and glyphs from non-western scripts - user can use shortcut command to optimize functionality

http://a11y.org/kafs

http://a11y.org/kafs-gta

SP: agree entirely - we speak of characters, not keys -- way to get particular character is application-dependent
... different entry methods to enter extended / accented characters
... nothing we can say about it, save that it is UA dependent

TH: use word "symbol" instead of "key"

http://gok.ca (GNOME on screen keyboard)

<Steven> The invocation of access keys depends on the implementation. For instance, on some systems one may have to press an "alt" or "cmd" key in addition to the access key.

TH: most often keypress, can be activated by other means, not in our scope, though

SP: change to "or anything else that might happen"

SM: or other user agent defined mechanisms for exposing shortcuts defined by access

TH: can configure opera to trigger access key with mouse gestures

<ShaneM> "or other user agent defined mechanisms that expose the abstraction made available by the access element and its key attribute."

GJR: Opera+Voice accesskey implementation works

TH: list of shortcuts in document

SP: target change

GJR: plus 1

TH: hard read at first, but covers it well, so ok

SP: good
... 2 other comments from i18n
... comment 2 and comment 4

<Steven> http://lists.w3.org/Archives/Public/public-xhtml2/2008Aug/0006.html

SP: emphasizing visually role of key in label - problematic in non-western text

SM: more basic problem with this text

GJR: from UAAG

SM: concern is we explicitly permit (and perhaps require) end users to over-ride mapping; how does that affect rendering if remap

GJR: programmatically not an issue

SM: agree, but have to state that

TH: key="x" include x in label text, user changes to p, UA should remap action to p
... should we reverse this text - if UA understands access keys and can identify the key in the label text, should emphasize it for user
... right now says, author should include key - if user overrides key, then UA needs to pick up on it; but what if new key not in label? loose benefit

SP: principle is to have keys all in one set and diff sets in diff modalities

GJR: not opposed to anything said about access -- "visibility" in non-modal sense is stress of UAAG 2.0 drafting

SP: more to discuss - continue on list

<ShaneM> ACTION: Shane to go through I18N comments and propose specific changes. [recorded in http://www.w3.org/2008/08/13-xhtml-minutes.html#action05]

TH: have to discuss on list - other potential problems

<ShaneM> ACTION: Tina to propose new text about how the access element @key value is exposed in labels. [recorded in http://www.w3.org/2008/08/13-xhtml-minutes.html#action06]

s/Access and SVG Request/Access Module: SVG and i18n Requests/Comments

s/Access and SVG Request/Access Module - SVG and i18n Requests/Comments

s/TOPIC: Access Module - SVG and i18n Requests & Comments/TOPIC: Access Module - SVG and i18n Requests/Comments

- DRAFT -

Weekly XHTML2 WG Teleconference

13 Aug 2008

Attendees

Contents

Technical Plenary Registration

Outstanding Reviews

XHTML M12N PR Status

XHTML Basic 1.1

Access and SVG Request

Summary of Action Items

Scribe.perl diagnostic output