Joint Meeting (HTML, XHTML 2, SVG, WAI PF) ARIA states and properties -- 31 Oct 2007

<Rich> scribe: oedipus

<hsivonen> hmm. How do I tell whether I'm ??P2 or ??P8?

<Rich> http://lists.w3.org/Archives/Member/w3c-wai-pf/2007OctDec/0108.html

zakime, i am Gregory_Rosmaita

<Rich> http://lists.w3.org/Archives/Member/w3c-wai-pf/2007OctDec/0108.html

<anne> Zakim:

RS: how to support aria states and properties among different markup languages; linked agenda announcement contains background
... currently ARIA spec uses namespaces for aria properties -- problem porting back and forth from HTML to XHTML/XML
... HTML WG contingent proposed aria- workaround; colon prevents style application in IE -- triggers visual UI off of properties -- if could leverage, CSS attribute selectors, would be far less javascripting
... XHTML 1.x DOM processing must be the same as text/html
... not considered sensible to alter the processing of the DOM depending on the mime type so namespace colon not thte solution; SVG also wants to use ARIA;
... requirements - content that works in older and newer UAs -- want consistent usage in XHTML namespace no matter what the mime type; not place unecessary burden on authors or developers
... how do we deal with cross-cutting technologies -- current proposal on table -- feedback?

<Zakim> Steven, you wanted to discuss colon

<anne> xml:lang doesn't work in text/html

Steven: yet to be convinced about unsuitability for colon; deliberately chosen in NS spec as allowable; should work same in HTML and XHTML (lang/xml:lang) -- problem of CSS in IE not a design feature, it is a bug in one version; doesn't apply to IE6 (no support for selectors); future IE versions should be able to handle colon;

<Zakim> ChrisWilson, you wanted to ask about role

Steve: shouldn't base decision on bugs in legacy technology

Chris: role not being discussed -- marc silbey told me XHTML WG using role for things other than ARIA; root of concern about namespacing; want to work consistently across languages

RS: role is used not just for accessibility in XHTML; cross-cutting technology

Steve: use is same; how ARIA keys off it is ARIA specific

CW: values of role can be different in XHTML than other MLs

Steve: role attribute takes value, those values interpreted in accordance with host language

CW: matter of interpretation, or does it take diff values in XHTML

Steve: role attribute from XHTML WG; WAI using XHTML Role to define elements with ARIA properties -- other attributes on elements then come into play

RS: currently, it is a CURIE
... intended to be cross cutting and extensible; for accessibility using wairole namespace and landmarks as roles to support ARIA

<Zakim> hsivonen, you wanted to talk about colon in text/html

HS: response to steven - text/html browsers (top 4: IE, Gecko, Webkit, Opera) none of them put xml:lang in a place where a namespace capable UA can handle it; local name becomes namespace in terms of DOM; not just about one version of IE having a bug, but whole text/html being unaware of XHTML namespace; HTML and XML parsers act differently; colon not an XML delimiter in text/html

MB: technical issue with colon: if use character and process literally (aria-somethingKnown) might as well use colon: valid character in HTML and XHTML/XML; just because isn't processed in HTML, doesn't mean can't be used as a delimiter; how to approach more general problem of integrating these technologies and how they are applied to HTML and XHTML;

DougS: understand not wanting to code to a specific flaw in specific browser, but no telling when flaw going to be fixed; is already content out there that could benefit from ARIA; colon doesn't work with CSS Selectors in IE7, but can with other attribute name schemae; don't see colon as possibility from practical point of view; would like it, but afraid not realistic; still not convinced that dash is right way to go -- would like some justification for namespa

<Zakim> hsivonen, you wanted to say it creates a scripting discrepancy between text/html and application/xhtml+xml

HS: mark said colon gets into DOM -- if colon there, DOM looks different from DOM parsed from text/html from DOM parse of apprilication/xhtml+xml; colon not useable -- if isn't prefix ariadisabled would collide with HTML5 native disabled

DougS: no one arguing that

<hsivonen> shepazu, sorry I misunderstood your point then

Steven: 2 of Doug's points: 1) bug only relates to CSS as i understand it, CSS aspect of IE7 not essential for functioning of ARIA, so when bug fixed would still work; namespaces not limited to stakeholders present here -- SMIL would be natural place to extend via namespacing; either we throw away namespacing altogether or say that every langauge has to have same mechanism, or maybe do both; namespace is W3C way of doing extensibility on XML based languages

Mark: not wedded to use of colon, HS said that processing in DOM would be different, but would be different anyway if allowed XML namespacing to work with these feature sets and a dash or underscore; lots of different technologies build on W3C namespacing -- parse local name and look for colon -- just another function call -- have to do for a dash anyway

<hsivonen> markbirbeck, a script library could use hyphenated names only for both text/html and application/xhtml+xml

Mark: need for namespacing in this context -- could argue not needed for ARIA, except for giving names; bigger problem is extensibility of role in MLs worth talking about in broader context

RS: 1) even if fix colon issue in IE8 (theoretically), bottom line, companies not going to switch to it for a long time; a lot of companies still using IE6

Steven: not going to work either -- no attribute selectors on IE6

RS: want something to work now, not in a few years; second, there are a lot of cross-cutting techs that we all ought to consider how to make easy to pull into host language

DougS: namespacing in XML sense -- question as to why namespacing considered superior? not saying don't need namespacing, asking for justification for namespacing; agree that colon is not pragmatic at momement, which is why i have the following 2 opinions: 1. role should be incorporated into host language without namespacing but with reference; 2) if have technologies that cross-cut, need means of indicating this is not a native part of ML; when reference ARIA

Steven: isn't that namespacing?

DougS: broader idea than xml namespacing; why proposed underscore -- not part of schema, but distinctive enough to mark as role -- something other than native ML;

<Zakim> ChrisWilson, you wanted to address the bug in IE

ChrisW: highlight few things: bug in IE specifically in dynamic support of namespacing; not firing events on attributes, so don't change stylesheets applied to them if namespace changes in IE7; caution people not to focus on IE6 support -- usage drastically on decline; namespacing not used in HTML -- other UAs don't support; not goal to make all work in text/html; in meeting invite, statement that SVG didn't like dash or hyphen; thought context was hyphen used

DougS: not actual conflict -- not aria- properties in SVG; technically possible to use it, but if ever to do NDVL dispatching based on prefix, if prefix were aria_ would be easier to locate than aria- ; the dash also makes it appear to be part of SVG

CW: define all ARIA properties, allow individual host languages to determine embedding mechanism

DougS: ease of authoring across HTML, XML, XHTML and SVG -- common format; easier for implementors to implement single scheme

CW: understand authoring across schemae, but is just one scheme

Mark: think that is proposal i was suggesting on list; others suggested same: define what these things mean, but retain syntax flexibility -- nothing wrong with having alternatives; if use role attribute in SVG need to use xml:role otherwise very quirky; nothing wrong with disabling aria: -- not appropriate to HTML; SVG in HTML muddies waters; in regular HTML don't want to mix technology of namespaces; suggestion is xh-role or xh:role -- xh: doesn't mean anythi

AVK: don't see value in having diff syntax for different MLs -- why should HTML use xh:role? why would aria: need to be used in SVG? would allow SVG inside HTML serialization

DS: how more convenient?

AVK: less namespace processing in parser

Steven: like what mark suggested; no real problem with pure SVG -- uses mechanism anyway; question of SVG in HTML is a different issue; XML-based lang uses namespacing mechanism, since can't use in HTML, use same syntax -- fact that doesn't get processed as namespace doesn't matter; achieve separate syntax

<hsivonen> Steven, that would lead to DOM discrepancies between the text/html and application/xhtml+xml serializations

Mark: agree; on AVK's points, doesn't mean anything to be more convenient; have to face fact that there are XML languages that already exist and a tool structured around those tools; asking SVG to change for HTML doesn't make sense today; a way off from that -- could do things now to set up for future, and one is using colon in both situations; can't simply throw away things -- need to try and find solution that begins where we are now

RS: having 2 vehicles may be way to do it -- dash and colon

Mark: in other technologies imported into MLs, set of attributes and elements that can be integrated; definition of language could provide for both ways -- why not xh: and xh- and let diff MLs parse as proper

AVK: no real XML usage on web; don't think helps to have 2 ways of acheiving same thing; just because SVG supports namespaces does not mean we should add more
... keep things simple -- same between HTML and XHTML as can do with id, class, xml:foo etc. trying to solve specific problem, not global problem; SMIL could use same attributes; ARIA spec defined in fairly abstract way

<hsivonen> that was someone else

<anne> that was me oedipus

<Zakim> hsivonen, you wanted to say using aria- in SVG will be easier for authors if HTML uses it too

<Zakim> shepazu, you wanted to say that I'd like to see the same syntax for standalone SVG as for SVG in HTML

Henri: agree with anne; different markup languages shouldn't support same markup in different ways; keep DOM and UA consistent, HTML and XHTML needs to use aria- as well -- want to keep for text/html and application/xhtml+xml -- same type of authoring needed for SVG -- no value of doing different things in different places; just because SVG has hyphenated attributes, might as well use aria- in XML namespace in SVG; HTML5 parser that supports infoset to map HTML

DougS: agree with AVK that would be confusing for authors especially if try to do SVG in text/html; don't want to make harder for people to use SVG in HTML; if namespacing of role doesn't work in IE, that is a blocker for it working in SVG as well from authoring perspective

<hsivonen> oedipus, the last bit: the discrepancy between lang and xml:lang is a pain. We should avoid more of that

Doug: same things that keep namespace attribute content for use in HTML would apply to SVG as well -- if using SVG inside HTML, need to abide by current UA limitations

Mark: hearing strange mixed messages -- let's keep simple want solution yesterday, and then some saying want to retrofit SVG for today's UAs; forward thinking a good idea, but think need to break problem into smaller peices; with the events defined concepts and made them available for people to use -- can say "defined role -- if use MLx do this way if use MLy do that way; can sort out SVG in HTML problem later; if say only 1 way to do cross-cutting tech will ge

<Zakim> hsivonen, you wanted to say the two things lead to the same conclusion

Mark: best way to move forward is say: support both mechanisms and hope that as things go forward, one will emerge as the dominant usage; role defined as taking a CURIE -- syntaxically looks like qname; people would like to put straight URI there -- change role so takes URI and "safe" CURIE (CURIE with square brackets around it); could have role used in places without a:b syntax; wouldn't prevent people from using in namespaced environment; solve a number of di

HS: backwards compatible with DOM in old HTML UAs as well as integrating SVG into text/html -- different things, but both support same conclusion: avoid colon
... designing concept and syntax -- ARIA already defines concept; this discussion is about getting discrete syntax to achieve that

AVK: not about a generic solution, just trying to solve specific problem; not talking about infinite number of MLs, but just ARIA

Steve: no, talking about possible infinite range of markup languages

Mark: trying to change SVG to fit to your specific language
... simply declaring attribute in no namespace, that is adding to SVG language
... thought point of call was cross-cutting technology; anything generic, general responded to with want to fix specific problem, but then raise host of other issues -- adding attributes in no namespaces

AVK: if use SVG inside HTML, makes sense to use same syntax

Doug: cannot treat as a single problem with no generalazible trends -- whether people want to acknowledge or not, that is what is on the table -- cross-cutting technology use

RS: problem with aria- in HTML and XHTML?

Steve: can't say yea or nay -- have to look at whole picture

<markbirbeck> E.g., in XML Events we allow @ev:handler in *any* language, and @handler in a language that wants to import the attributes.

Steve: way for it to work as cross-cutting technology is most important bit; don't feel need for DOM to be same on 2 serializations, but that's bye-the-bye -- have to define problem space before we can reach consensus; declarations don't address all parts of problem space

<markbirbeck> But we could have said @ev-handler was allowed in any language, too.

RS: meeting of PF WG next week at TPAC -- can people attend that meeting?
... tuesday morning

Doug: don't know if will be there have to join call now

RS: XHTML2 meeting starting now too

<scribe> scribenick: oedipus

scribe+ Gregory_Rosmaita

scribe- oedipus

- DRAFT -

Joint Meeting (HTML, XHTML 2, SVG, WAI PF) ARIA states and properties

31 Oct 2007

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output