emailed Access Module comment requests to UbiWeb, UAAG and SVG

IFRAME Accessibility Inquiry: http://lists.w3.org/Archives/Public/wai-xtech/2008Jun/0061.html

RM: review of yesterday; new review of CURIE received today

CURIEs

<Steven> http://lists.w3.org/Archives/Public/www-html-editor/2008AprJun/0048.html

RM: model response on that submitted on behalf of XForms?

<Steven> http://lists.w3.org/Archives/Public/www-html-editor/2008AprJun/0049.html

RM: personal comment from leigh: "We will clear up the wording to help reduce any potential confusion. We will also clarify that host languages are only required to use XMLNS for prefix definition if the language supports XML Namespaces. Thanks!"

SM: saw new comments last night; no DTD because the DTD is in M12n -

RM: we make it clear that there is a separate pointer to one or the other
... put pointer to say definitive definition is pointed to and provide pointer
... defined in one place - need to reference elsewhere

SM: ok
... comment continues - confused as to why normative - perhaps whole section should be informative

RM: normative schema can be found here and the normative DTD can be found here, but section not normative itself

SP: normative bit is syntax - DTDs and schemas just informative

RM: mixture in section

SP: either make DTD and schemas normative both or informative both

RM: normative reference in M12n

SM: and point to it from informative section
... in the m12n implementation, but is not in modularization itself
... didn't went m12n have dependency on CURIEs

SP: think good not to link to m12n - people should be able to use CURIEs regardless of implementation method
... DTD and schema informative is ok

SM: don't mind relaxNG thing

RM: more general point on what to do with RelaxNG for future - syntax for constraint, not type definitions

SP: Relax uses schema datatypes to find datatypes - used for program structure

RM: avoid RelaxNG now

SP: XHTML2 spec has RelxNG - future will include, but too late to add now

RM: informative definition of RelaxNG might enhance readability - very editorial, not real request for RelaxNG

SM: intend to do work on RelaxNG in future, but want to address in cohesive fashion in very near future
... should i redirect comment into tracking system so is logged as LC comment

RM & SP: yes

XHTML Mime Type

RM: draft available; email about new tool from olivier

<Steven> http://www.w3.org/MarkUp/2008/ED-xhtmlmime-20080423/

SM: how to approach

RM: work our way through document

http://www.w3.org/MarkUp/xhtml2/wiki/2008-06-FtF-Agenda

<Roland> http://www.w3.org/MarkUp/2008/ED-xhtmlmime-20080423/

SM: took old one, put in pub system; made least number of changes possible; added appendix and that's where things stand
... diff marked version from previous

http://www.w3.org/MarkUp/2008/ED-xhtmlmime-20080423/xhtmlmime-diff.html

SM: will help other people
... should approach as new document today

RM: start at introduction and work our way forwards

http://www.w3.org/MarkUp/2008/ED-xhtmlmime-20080423/#intro

SP: see part of our implementation strategy for XHTML2 going via script route; scripts that implement XHTML2 part and runs down tree making necessary changes so works within existing HTML browsers
... in that case, many UAs will have to receive as text/html just to serve, so...
... when we say "use of text/html should be limited to HTML-compatible..." -- wonder if that is too strong
... media type is being used to deliver stuff to UA just to get it in there, then - due to scripting - deliver XForms - UA thinks is HTML, and then script does what is necessary to compile into HTML
... want to deliver documents to UAs as text/html, but want to be very careful about definition of HTML-compatible

RM: distinction not between documents, but capacities of browser;

SM: browsers that explicitly accept that mime-type

RM: focus on document negotiating with browser and serving most appropropriate - if wants text/html, give it
... this is XML and that is what we are

SM: disconnect by the way Roland & Steven

RM: UA only meant to parse well formed XML, should deliver xml mime-type - you take XML, we have XML, here it is

SM: if FF claims to accept XML and XHTML, why serve text/html

SP: no if UA accepts application/xml give it that
... hiccup is use of text/html should be limited to HTML-compatible family documents

SM: right -- it does say that

<ShaneM> the use of 'text/html' SHOULD be limited to HTML-compatible XHTML Family documents intended for delivery to user agents that do not explcitly accept 'application/xhtml+xml'.

<Steven> "the use of 'text/html' SHOULD be limited to HTML-compatible XHTML Family documents"

SM: a SHOULD not a MUST
... thought intent was not to irritate constituencies using XHTML1 - transitional thing; has to be HTML-compatible, or target UA may not accept it

SP: depends on our definition of HTML-compatible

SM: try to explain in Appendix C of XHTML 1.0 - Appendix A of this document

RM: if UA asks for page and prefers XML, serve as XML; if UA doesn't support XML only HTML, then serve text/html
... document agnostic - can do either thing and respond based on what UA wants
... not document constraint per se, but browser constraint, which we handle

SP: explicitly mention cases where people doing stuff - implementing XML based languages via scripting; in that case, acceptable to deliver as text/html just to get to UA

RM: not sure right justification - doc should state what should be done, not justify

SP: don't want to get into current situation where people claim not XML because being delivered via text/html
... in past didn't care about media types

RM: this is where should be strong - not about media types, but whether passes series of constraints
... mandating particular doctypes wrong approach

SP: doctype only current way to declare restraints

RM: can make assertion against a document through validation -
... can write a doc where all markup valid against mobile profile, xhtml10 and xhtml11 - why have to pick one

SM: possible to craft doc that can validate against any of our markup family, but this WG has said "have to have doc type"

SP: if want to declare doc as mobile OK, document has to have basic DTD in front - if someone else declares as foo, need another DTD even if document satisfies both standards, can't validate as both
... rule about doctype to use constrains authors from authoring once and declaring valid for a number of profiles

RM: correct

SM: not clear how relevant to document or what we can do

RM: perfectly acceptable to deliver as XHTML1.0, XHTML1.1, Mobile Profile, HTML5 -- pipe stream can then use text/html or application/xml
... assertion part of document not metadata
... is byte stream acceptable as text/html in HTML4x browser; same byte stream delivered to valid mobile device, then deliver as application/xml; not implicit to byte stream

SM: media type tells the consumer how to evaluate document - what internal engine to use

RM: that's not intrinsic to document, but how bind 2 together
... can take same byte stream into FF and whether served as text/html or application/xml works

SM: side-effects: changes the DOM
... is there anything in doc that is in conflict with your points

RM: turn around question - how respond to request from UA, not something intrinsic in document - document can legitimately be multiple form (valid in more than one langauge)

SM: hope that that behavior is encouraged by this doc

RM: document-centric approach (what to push to browser) rather than responding to UA requests - push-pull or pull-push
... what UA asks for or is capable of understanding determines how we act

SM: first paragraph of abstract says that

RM: if browser asks for application/xml send as that - serve what UA prefers; negotiation in pike
... XML higher fidelity, but if only understands one or other, then that is the constraint, not the document
... response from negotiation with UA; this is what i can accept, give me the highest fidelity

TH: without a DOCTYPE many tools beome impossible to write, such as accessibility checkers

<Tina> Without a DOCTYPE many tools becomes impossible to write such that they can deliver trustworthy results. Accessibility checkers is one such example.

<ShaneM> +1 to Tina's comment

Yam: as mobile UA manufacturer, don't want to be bound to any mime-type - process what we can; interested in using mime-type to advertise browser capability; media type specification or note?

<Tina> Wouldn't it be far more useful to continue the work on CC/PP instead of using the mime-type, since the mime-type, looked at pragmatically, doesn't really say anything about capability?

Yam: if note, emphasize 1.0 or 1.1 - from mobile UA viewpoint, this module will clarify how to handle XHTML Basic as well as other XHTML flavors; 2 editorial points: status of document (have to make sure consistent); second in 3.5 say HTML, should be HTML4 other places HTML-compatible; need to define HTML compatible or explicitly state HTML4-compatible

tina, yes to CC/PP

<Roland> My comment was not that DOCTYPE should not be used but that a single document can conform to more than one DOCTYPE.

Yam: profile

SM: need strategy for that - came up on RDFa discussion this week

Yam: mimetype profile should require specification of DTD -- can clarify have to use profile + foo; my assumption is have to use profile parameter and in doing so have to specify DTD

SM: haven't developed concrete strategy there; markB has other ideas; had other suggestions; reasonable to use mimetype but need to do in rec track document or m12n, otherwise, not normative

Yam: happy with informative

SM: issue with HTML-compatible and HTML4 - HTML4-compatible would explicitly exclude HTML5 for better or worse

GJR +1 to HTML4-compatible

SP: too early to say HTML5

Yam: don't know anything about HTML5 compatibility

SM: absolutely right
... HTML4-compatible ok?

GJR: yes

Yam: yes

RESOLUTION: in mimetype document use HTML4-compatible and HTML4-foo wherever appears in document to remove confusion

RM: what should abstract say that currently doesn't?
... how to make as easy as possible for authors to develop content so can be delivered in multiple mimetypes

SM: something about title?

RM: title itself doesn't get to heart of what trying to do - guide for authors on how to develop content so can be served as multiple media types

SM: understand, but title already well-know

RM: title - XML Media Type sub-title: Serving XML in an HTML World

SP: Serving XHTML in Legacy UAs?

RM: Serving XHTML to Multiple User Agents

<ShaneM> Delivering XHTML to XHTML and HTML User Agents

Serving the Most Appropriate Content to Multiple User Agents from a Single Document Source

RM: who is expected to read?

SP: olivier

<Steven> That was intended as a joke, for the record

SM: consumers of document: all people who hang out on freenode #web who say don't use XHTML because doesn't work
... if can get them to understand ok to serve XHTML to current UAs, then that is a huge win

Yam: reason document more implemented on mobile browser is no way to specify XHTML Basic or other/multiple host language support; W3C note will gratify my constituency

<Tina> I find that hard to agree to. Most authors appear not to know how to use XHTML. It wouldn't do the "XHTML Case" any good to have an even larger amount of invalid documents out there that people believe are "just fine" 'cause they render as HTML.

RM: that's what we were trying to discuss earlier - what UA is capable or ready to accept - i accept A, B, C, D, and E so give me the best one you have
... capability of browser and then if document fits multiple profiles; basic 1 and basic 1.1 - UA conforms to basic 1.0, takes that

SM: logical conclusion means need to specify somewhere a syntax for the accept headers profile parameter -- markB has proposal; UA has to say in precise and concise way all of the things it accepts
... tokens specified for implements in XML Events 2 - could be that sort of mechanism

Yam: no other document specifies that

SM: agree - might push into update of RFC if part of media spec

RM: should consult with UbiWeb and CC/PP
... break off as topic that needs attention - problem about UA advertising capabilities and preferences and serving the appropriate content

SM: markB should be in on discussion
... how to make abstract get to point RM wants reword "documents intended for delivery to user agents that do not explcitly accept 'application/xhtml+xml'. 'application/xml' and 'text/xml' MAY also be used, but whenever appropriate, 'application/xhtml+xml' or 'text/html' SHOULD be used rather than those generic XML media types."

RM: question of persepective - how to respond to UA's capabilities and preferences

<ShaneM> XHTML Family documents intended for delivery to user agents that do not explcitly state in their HTTP-Accept header that they

<ShaneM> accept 'application/xhtml+xml'

SM: that what you mean, Roland?

RM: yes

Tina: problem with it is that everyone knows that an accept head is often misleading - tend to ignore accept headers and HTTP requests; not a road we should formally go down - should not ignore accept
... understand pragmatic reasons, but uneasy with exception for HTML-family document; should talk with HTTP people

SP: don't understand what you think we are ignoring

Tina: UAs use accept header that says "i'll accpet everything no matter what" - then how to decide what to give it?

SP: accept header should give list of what can actually accept, but with a terminal star to cache ("Save As.." dialog is an example - not refused, but check accept headers to check if can natively deal with it

SM: according to HTTP spec, permisible to accept *.* -- we're telling people to ignore that

Tina: formal point of view would mean we are telling people to ignore part of HTTP spec

SP: not saying that

SM: think we are, actually
... term "explicitly state" - unless UA explicitly says it accepts application/xhtml+xml don't give it xhtml - that's inconsistent with spirit of HTTP spec

SP: by saying *.* how do you get xhtml documents in to browsers and parse them correctly; all UAs accept *.*, which means "don't exclude anything"

RM: these are things UA might say - if this is X do Y, if this is Q do W

Tina: need to check on *.* support in UAs
... usual way of writing accept header parsers haven't come across many that accept anything
... need to investigate further - can we delay discussion so can dig into it a bit?

<Steven> Here Tina: http://pgl.yoyo.org/http/browser-headers.php

<Steven> Opera sends: Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1

<Steven> Safari sends: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

<Steven> Mozilla: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

<Steven> Amaya: Accept: */*;q=0.1,image/svg+xml,application/mathml+xml,application/xhtml+xml

<Steven> Lynx sends: Accept: text/html, text/plain, application/x-bittorrent, application/x-troff-man, message/partial, message/external-body, application/x-tar, application/x-gtar, application/msword, text/richtext, text/enriched, application/ms-tnef, text/*, application/x-debian-package, audio/basic, */*;q=0.01

<Tina> My local Lynx sends text/html, text/plain, text/css, text/sgml, */*;q=0.01

i often change my lynx settings in response to browser sniffing so i can get into certain sites

RM: piece that is missing; talk about things in abstract not covered in detail - detail goes into media type uses, but don't say what requests might come form UA; accept headers not mentioned in body, just in abstract

<ShaneM> in our list of explicit rules.... how about if we say "if an Accept header only contains */*, documents SHOULD be sent using media type text/html if they are HTML4 compatible, or as application/xhtml+xml if they are not" or something.

RM: in media type usage, should say "which is the most appropriate"

TH: worth noting that ones tested so far send a Qvalue with *.*
... who set up yoyo.org?

yoyo: "Welcome to Yoyo Internet Services. We pride ourselves on consistency of service and quality of workmanship. Founded in 1996 by Matt Saunders and Neil Levine, Yoyo has gone from strength to strength despite its overwhelming vacuousity."

"Our mission is to consistently conjugate through dynamism, surrealism and semanticism in order to further our goals of hysterical servlet hypotenae. This autonomy cultivates our duplicitous mercenary valetism in the eclectic dot org arena."

RM: accept header fallback for browser detect

Tina: not useable

GJR: easily forged

Tina: need to point out that should do that

<ShaneM> Lets add a section for dealing with content negotiation via accept headers explicitly

RM: process accept headers to determine which of possible types to send - not addressed in detail
... give accept header and respond

Yam: OMA specifies that UA should advertise their supported mimetypes - send QValues because of *.* - at end smallest QValue

RM: please send us a pointer

SM: i introduced that before OMA was OMA

SP: fifteen minute break?

=== 15 MINUTE BREAK ===

IFrame Accessibility Query: http://lists.w3.org/Archives/Public/wai-xtech/2008Jun/0061.html

first response (S Schnabel of SAP): http://lists.w3.org/Archives/Public/wai-xtech/2008Jun/0062.html

<ShaneM> FYI - updated CURIEs as per mail from Leigh and our discussion today.

RM: appendix on capacity guidelines for authors to deliver documents as valid XHTML or XML

TH: reread HTTP spec - no provision in 14.1 for accept header - only send if explicitly stated, so withdraw my objection

<Tina> Section 14.1 on the HTTP specification does not explicitly prohibit sending content to an UA which explicitly mention support for a MIME type

<ShaneM> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1

<Steven> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1

TH: content negotioation is feasible again - since accept explicitly, like to add - please convert XHTML to HTML when delivering to HTML UA; problem is that those using XHTML are doing so poorly in belief that if use XHTML, UA will alert them if something wrong, and then send as text/html

RM: how should one write one's content to minimize those problems

TH: do it on server before sending down the pipe; a lot of authors mis-using XHTML - no idea of concepts behind it

RM: a lot of content generated directly from databases as XML
... automatically emit XML, not XHTML

TH: technical limitation

RM: many database servers only support XML, not XHTML --

TH: can't send structured data to UA

RM: you can

TH: not if won't accept it
... won't be structured data you think it is; if send XHTML to HTML user agent will not be interpreted as XHTML
... won't help people structure data - the "out" is that XHTML will be ok when served as HTML and if something was wrong, something would notify me

SP: people so used to idea to check document source by loading into UA and seeing if looks "right"

TH: XHTML is an XML language - problem with not with code but delivery mechanism

SP: trying to say, if UA accepts XML media types, use that - fall back to HTML media type as a recourse of last resort

TH: if fall back to HTML, please transform it

SP: what to transform?

SM: if develop according to compatibility guidelines, no need to transform

TH: trying to up the ante so get people to send valid XHTML to HTML user agents

RM: document in general write as XHTML and if valid, XML-based browser will serve it

SM: if not going to follow guidelines, then ensure that you transform your content before delilvery to HTML browser?

TH: please transform to language browser supports - can automatically transform XML

<alessio> old test page with server content negotiation: http://www.terrafertile.ch/w3/xhtml2/index.php

SP: saying that, but not quite in those words; compatability guidelines - if serve as text/html, text should be in this form

RM: 2 alternatives: write to compatability GL to ensure XHTML can be parsed by HTML UA, if not, then need to transform into HTML

TH: want it to be VERY explicit

RM: can make explicit that one can write to GL or transform XHTML to HTML

TH: matter of finding good tech solution - which exist, so not the major problem

<ShaneM> ACTION: Shane craft text to about transformation of XHTML to HTML. [recorded in http://www.w3.org/2008/06/18-xhtml-minutes.html#action01]

SP: why an Appendix A and then Appendix 2?

SM: odd...
... first one Processing Instructions should be a 1
... attempted to take old guidelines, port them here, and clarify style - want to recast as clear instructions as to what should and should not do
... original text still in draft for WG review
... problem with way written previously, not clear what one supposed to do -- explained compatiblity risks and ways to work around them
... don't use processing instructions PERIOD etc.
... questions about approach or my take on problem?

RM: need good example illustrating all principles - second, when state "do not" include a "do"
... need to be crystral clear about what should do and not do

SM: not a corresponding "do" for first guideline

<Steven> http://www.w3.org/MarkUp/2008/ED-xhtmlmime-20080423/#compatGuidelines

RM: general principle: not leaving to people to infer what one should do and not do

SM: the "do" should come first

RM: yes

SM: objections to GL1?

SP: no objection - use of word of "legacy" potentially distraction

"Processing Instructions and the XML Declaration" should be A.1

RM: break out a warning - stronger than "remember, however..." - pull out and make clearer and stronger

SM: next one "A.2. Empty Elements" - Roland, you requested i change this

RM: can't remember what i said

SM: combined A.2 and A.3

SP: A.2 about elements that can only be empty and A.3 about elements that normally aren't empty, but can be

RM: have to know certain elements can only be empty
... about a dozen

SM: will paste in "live" URL

FYI: A.3. Element Minimization and Empty Element Content

Tina: no comments on A.1, and A.2 seems reasonable

SP: interesting to note that A.2 in "normal" UAs isn't an issue

Tina: older agents need space

SP: not advocating deletion, just noting a improvement

<ShaneM> http://www.w3.org/MarkUp/2008/ED-xhtmlmime-20080618/

http://www.w3.org/MarkUp/2008/ED-xhtmlmime-20080618/#compatGuidelines

SM: A.2 is now entitled: "Elements with no content" and combined with old A.3

RM: useful to have them there

SM: will have to update when introduce new elements

TH: big question: compatability GL for HTML4 and less
... won't be added in HTML5

SM: if introduce new elements in XHTML2 have to revisit this document
... don't want to discuss today, but need to think about how to serve to "classic" browsers

TH: probability of sending XHTML2 to legacy agents

SP: people do that nowadays
... XForms scripts convert XForm into HTML, but delivered XForms

TH: using javascript, i assume

SP: yes

TH: accessibility part of it - what to do with javascript

RM: are people happy with A.2 "Elements with no content"

SP: personally prefered old form with separation between empty elements and those which can be empty

TH: A.3 more of a problem - should keep separate;

SP: liked fact that pointed out that XML allowed <br></br> doesn't mean anything

RM: can go into rationale - doesn't change rules

Original A.3 text: "Include a space before the trailing / and > of empty elements, e.g. <br />, <hr /> and <img src="karen.jpg" alt="Karen" />. Also, use the minimized tag syntax for empty elements, e.g. <br />, as the alternative syntax <br></br> allowed by XML gives uncertain results in many existing user agents."

TH: clearer we are, the better the results when authors write it

RM: A.2 what should do is <br /> what should not do is <br></br>

SP: good example is script - if script src= have to have /script

Alessio: yes

SP: let's use scripts there - that is poster-child example of why have to do this way

RM: concrete do this and don't do this in CSS columns

<Tina> This was spotted "in the wild" last week: <div style="... "/>

SM: 2 votes for restoring A.3

RM: don't object, but understand distinction WG members making, but not sure authors care about

SP: then say "elements that can only be empty"

RM: some elements can only be empty; list them and what can do with them

SM: elements that can never have content?

SP: works for me

<alessio> +1

SM: Elements that can never have content versus Elements that may not contain content

<Tina> +1

GJR +1

RM: when do scripting, do certain things (but that topic for later)

SM: script example in restored A.3?
... trying to capture ideas in draft - will update later
... A.4 "A.4. Embedded Style Sheets and Scripts" say "do" but not "do not"

RM: needs balance

TH: why not say use external stylesheets and scripts - XHTML in HTML compatability mode, use external scripts

SM: unreasonable burden if all one is doing is adding a few localized styles

RM: override one style with another for single document instance
... example would be helpful - if use pointy brackets have to do like this in order to work, but easier to create and maintain external stylesheets

SP: problem can arise if content gets fed through XSLT first - protecting documents; what we warn about could happen - authors should be aware

GJR notes that FireVox cannot process external stylesheets but only embedded or inline CSS3-speech values

SM: A.5 A.5. Line Breaks within Attribute Values - dont' know why anyone would care

TH: some probably process new lines specially
... as long as is CDATA should ignore new lines

SM: so if datatypes IDREFs wouldn't be legal
... fine guideline, but don't know origin -- needs a do

RM: yes
... has this problem been mitigated over the years?
... perhaps confusion is that problem was limited and long time ago

SM: not a bad rule, but next rule is candidate for deletion
... A.6. isindex - who uses them?

GJR: deprecated in HTML4 anyway

SM: original text wrong - no more than one ISINDEX element is a no brainer
... would remove A.6

SP: ok

Alessio: ok

GJR: ok

SM: kept these consistent with Appendix C - even down to fragment IDs

RM: can log changed

SM: change number?

TH: use DEL to show A.6 no longer applicable

SM: renumber

SP: good

SM: A.7. The lang and xml:lang Attributes - may be controversial

TH: tool looks at doctype then tries to figure out lang attribute

<Steven> I have no problem with the lang and xml:lang

<Steven> scribe: Steven

TH: I'm worried that tools that see it's HTML: will go looking for @lang

<oedipus> dropped the phone - must have disconnected

<oedipus> ATs key off of lang - if try just xml:lang, won't switch natural langauges - can log as bug with GNOME's Orca

Yam: I'm not sure about this issue
... we are thinking about removing @lang
... but CSS selectors may use it (for instance)
... we have no strong position though

<scribe> scribe: oedipus

need to find CSS selector example that uses aria live regions to change language of text

SM: need portable way to indicated language change

Yam: existing UA implementations use @lang for CSS selectors - we discourage use of that for XHTML family of languages consistency of use

RM: people using lang specifically, can't write XHTML 1.1 or 1.2 document with @lang

SM: want to ensure rule works before ship XHTML2
... could reintroduce lang

RM: perhaps target

GJR: AT problem is DOM calls and limitations AT-side on what it relies upon to key natural language switches

SP: if need compatability GLs to serve as HTML need lang, but in XHTML lang means nothing and is just there for convenience

SM: normatively state allow @lang but if doc served as XHTML @lang must be ignored?

SP: yes, no meaning in XHTML - only there for convenience of being able to serve XHTML documents to legacy browsers

RM: synonyms?

SP: then people might stop using xml:lang

RM: ramifications?

SM: CSS selectors based on lang when have both lang and xml:lang - XHTML 1.1 document, for example, serving document in either media type, how to craft css selectors to make everything in latin pink and italic given i'm using lang and xml:lang

SP: no, use coma as delimeter -- CSS doesn't select on attribute - in HTML uses lang, in XHTML uses xml:lang, so only one rule in CSS

TH: could use CSS rule to key on @lang specifically

SP: CSS has knowledge of language text is in due to selector - language comes from parent element of current element; if current element is in latin, do this - only way to do in CSS anyway
... no selector that says if parent of current element has @blah ...

TH: selecing on lang attribute correct thing to do according to CSS

SP: can have select on lang and xml:lang

TH: people today select on lang - problem is HTML compatibility GLs

SP: why i'm suggesting we add lang back into the languages

GJR plus 1 to readding @lang

TH: if people transformed to HTML would be easier
... if transform from xml:lang to lang

SP: what is easier

TH: don't need to put lang into XHTML Base

SM: 2 sets of constituents to serve: one of them is "the great unwashed" - just have a simple site who want simple solutions; then there are sites such as amazon, which have FAR more resources can bring to bear

SP: but don't want to transform everytime serve page

SM: cache it

RM: can i? if getting weather updated every 5 seconds, may never be cached

SM: cached for 5 seconds

RM: a lot of transformation for 5 seconds

SM: if permit lang along lines SP discussed - technically, how do we do that?
... or introduce new lang module?

SP: yeah, or may need other attributes, in which case a "compatability module" would be the answer

Yam: have legacy module, right?

SP: don't want to allow BLINK along with @lang

SM: lang not in legacy module now, so wouldn't be conflict if introduced elsewhere
... could introduce an HTML compatibility module as update to 1.1

<yamx> i killed line by mistake

<yamx> OK, zakim, thanks.

SM: compatibility GLs wouldn't be useful for 1.1

SP: better off using 1.2 anyway

RM: definitely

SM: for this GL, "do use lang" - or "do use both" - realize can't if doing 1.1, Basic, +RDFa, etc

TH: need to put responsibility on author - use both

GJR: same thing authors do with name and id

SM: will update appropriately and then need to figure out how to help languages support both of these, but that is independent discusssion
... "A.8. Fragment Identifiers" - not controversial

TH: no

SP: when wrote A.8 there were UAs that didn't recognize ID, but that has changed

SM: and i changed the doc
... "A.9. Character Encoding"
... interesting problem

Yam: Japanese example would be useful

SM: true

SP: including mediatype and encoding in same metadata bad choice made way back when

RM: there is a default - if satisfied with default, don't need to do this

TH: back to HTTP spec - not possible - HTTP content type can be set as much as you want, but often receive US ASCII from server

SM: if accessing document in filesystem not possible

TH: author can't change content type served by server

<Steven> And some protocols don't support encodings, eg ftp, file:

TH: can't change content type set by server; practical problem; really ought to set on server - should stress

SM: if doc coming from server, character encoding is specified in response, so is authoritative, and may even override XML declaration

TH: yes

SM: telling people not to use XML declaratoin

TH: bigger problem if send as XHTML and don't have control over encoding and content type

SM: serious problem - compatability GLs and content negotiation only relevant when have access to server and ability to control headers otherwise nothing we say matters

TH: some think HTTP-EQUIV panacea; still sending as text/html

<alessio> really true

SP: HTML4 spec says that server should look at HTTP-EQUIV and send appropriate, but never implemented
... GL should be "when serving a document, putting anything in the document that is unlikely to help because server always has priority"

TH: also not to expect something else

SP: META unlikely to help you at all

SM: maybe not mention

SP: should to make explicit

RM: first item similar

SM: suggestion: could we have 2 rules: when document being sent from server, do this
... when document being accessed directly do this

<Steven> Default for XML is UTF-8, right?

TH: even when served by HTTP daemon, even if proper content type served, save as HTML

<alessio> yes, steven

TH: legacy issue; if not serving direct from server, use HTTP-EQUIV as per spec, but if set content type and char encoding on server

RM: not an isolated issue

SM: why don't we just say - ifyou want to be compatible encode as UTF-8 or UTF-16

RM: agree

SP: and state ensure that server serves it as UTF-8

<alessio> +1

plus 1

RM: happy with that solution

SM: if want docs to be portable, encode in UTF-8 or UTF-16

SP: people should use UTF-8 everywhere ideally

TH: make sure server announces correctly needs to be in GL

http://www.w3.org/html/wg/html5/#charset

HTML5: "If the document contains a meta element with a charset attribute or a meta element in the Encoding declaration state, then the character encoding used must be an ASCII-compatible character encoding. "

SM: HTML5 talking about default when no server - we say use META HTTP-EQUIV

HTML5: "If the document does not start with a BOM, and if its encoding is not explicitly given by Content-Type metadata, then the character encoding used must be an ASCII-compatible character encoding, and, in addition, if that encoding isn't US-ASCII itself, then the encoding must be specified using a meta element with a charset attribute or a meta element in the Encoding declaration state. "

SP: anyone actually look at HTTP-EQUIV

SM: browsers do

TH: most commonly used browsers do
... issue is what is use they make of it - some ignore content type based on extension

Yam: use META HTTP-EQUIV to ensure japanese encoding
... all Japanese encoding should be in meta http-equiv

SM: that overrides HTTP headers?

Yam: not sure; easier for carrier to serve

SM: A.10. Boolean Attributes
... controversy?

RM: looks good

SM: A.11. Document Object Model and XHTML

Alessio: can get to HTML DOM as well

SM: will remove "if is really true" editorial note

TH: as long as works with HTML4 UAs don;t have problem

SM: A.12. Using Ampersands

fine with GJR

SP: sentence difficult to read - AND in all caps
... change AND to lower case

TH: possibly STRONG?
... if possible, use semi-colon instead of ampersands in URIs

SM: made change to case of "and"

GJR: plus an abbr expansion for & <abbr title="ampersand">&</abbr>

SM: when using ampersand in URI use its escaped form
... A.13. Cascading Style Sheets (CSS) and XHTML
... may have over-simplified

RM: may want to make comment on lang here

SP: CSS selector on xml:lang rather than lang

SM: do nots needed?

RM: inverse fairly obvious

SM: added thing about style HTML element
... in HTML style on body becomes style for entire viewport; in XML does not

TH: change Do rule - if need to set, then...

SP: special rule in CSS is because early versions of IE didn't have style for HTML element, so CSS states, style BODY element

SM: do style HTML element?

SP: no, for compatability reasons, style BODY rather than HTML element

SM: style applies only to block not whole window

SP: if you want to remove styling put on HTML, have to define style for HTML, but this might be the ocassion to say "this is an old rule"
... when wrote, were browsers that didn't support HTML

SM: just added this

RM: implications - example of consequences - we need to make clear what consequences are

SM: good point, Roland; maybe not even necessary to say this; authors put style on BODY, not HEAD; and when served as HTML style on BODY apply to entire window

SP: what CSS spec says, but not reality; 2px margin around HTML element
... why can't i get rid of margin around my HTML document - reason: have to explicitly state padding:0;margin:0

SM: do we need this rule?

SP: no

TH: need rule to point this out

RM: rationale needs more work - particularly important for this appendix a section

SM: will try to update so can revisit later
... had been telling people to use xml style declarations, and i think we should tell people not to use them for compatibility
... A.15. White Space Characters in HTML vs. XML
... should change name from "white space"

SP: agreee

SM: A.16. The Named Character Reference &apos;

TH: typographcally, is right single quote - no problem with A.16, but shouldn't get into typography side of it

SM: ok

===== ADJOURN FOR LUNCH - RETURN in 77 Minutes (quarter to next hour ======

SP: complete discussion of media types?

SM: enough to create a new draft

RM: one other thing: validator thing olivier brought up

<ShaneM> Olivier says: Good. How about:

<ShaneM> - [now] updating the tool to match the draft guidelines in the ED of xhtmlmime

<ShaneM> - [soon] including the checks into the validator, mark them as [experimental], informative, whatever. That will provide us with better and more feedback than just a WD.

SM: his proposal to me this morning appears above

RM: something we'd like to see, isn't it?
... do we believe running through validator to get info if suitable to be served?

GJR thinks would promote awareness

<alessio> yes

SM: concern is "validator as holy writ" -- good or bad, depending upon whether it works; would be more comfortable if could provide WG resources to work on that

(that being validator and control over changes)

SP: depends on how they present information -- warnings versus errors

RM: that is what they did

SM: get document updated to reflect discussion today; respond to olivier that WG ok with warnings

GJR would like a STRICT mode where errors are reported as errors

SM: open source tool

RM: anyone can hack anytime want to; what is in w3c validator he takes care of

<ShaneM> ACTION: Shane to finish the updating the XHTMLMIME draft then respond to Olivier's proposal. [recorded in http://www.w3.org/2008/06/18-xhtml-minutes.html#action02]

RM: anything anyone wants to mention in closing on mime doc?

XHTML 1.n (Follow on to 1.1)

RM: have 1.1 spec waiting for modularization; proposed change adding target attribute back in, which is considered not in scope of what should do in new edition
... what do we do next?
... drop from second edition?
... release XHTML 1.n and if so what would be in it?

SP: adding @target to 1.1 is that Basic needs -- 1.1 should be considered full Basic with all facets of Basic

TH: @target to open frame or new window?
... no reason to put into declarative markup language

SM: why is target not useful

TH: authors shouldn't force new windows
... if in XFrames, ok, but not in Basic

GJR notes that handling of @target is user agent control issue being addressed in UAAG2.0

TH: opening windows outside scope of declarative language

Yam: against using target, but made compromise with CDF or another WG who demanded it be restored; don't think we need it

SP: SVG or CDF?
... doesn't SVG need it in some way?

RM: compatability guide question -- html mime --- inhibiter for those trying to move from HTML to XML

SP: reasonalbe use cases for @target
... list of search results - click on a search result to get result without changing underlying doc

TH: UA has built in
... those that can spawn new windows have that feature

GJR author proposes, user disposes

SM: @target has different semantics in SVG?

Yam: against @target in 1.2 -- agree that natural that have in 1.1, but from practical POV it is a mess -- HTML5, XHTML2, etc.

SP: talking about 1.1 -- issue 1.1 as proper superset of basic

SM: if don't add anything to 1.1 can release as PER

with schema

SM: would not be superset of Basic

SP: why not

SM: not including @target
... those who care about input mode and @target will be affected - who are they?

Yam: don't care if 1.1 is superset or not

SM: very good point: explanation of XHTML family would be fine to support 1.1 second edition or first edition -- basic 1.1 document
... @target is single-most requested feature in our public wish list

TH: any UA used today that allows user not to open @target-ed windows

RM: a lot of users don't know that can click on link and open new window

TH: @target specifies UA behavior in practice

SP: a "hook" for use by

<alessio> you're right, gregory

GJR: render unto User Agent what is user agent...

TH: going to be used to open new windows - removed to prevent that so shouldn't go back in

SP: didn't remove - never in STRICT and 1.1 is a revised version of STRICT, but didn't revise version of transitional DTD b/c nothing to revise
... one thing people have asked for is to use @target in 1.1
... not clear why we should say people shouldn't do that - perhaps should give arguments for people not opening windows

TH: why put back?

SP: popular demand

TH: what purpose does @target fill in XHTML?

<alessio> people reintroduces it with dom injection...

TH: know complaints, but purpose aren't for frames mostly but for forcing open new windows

SP: XFrames - target a document onto a frame
... XFrames does NOT need @target - that's why need in HTML - if environment that needs this, here are the hooks you use

Alessio: @target should not be in 1.1 -- regard @target as action

SP: SVG uses @target, i believe -- trying to locate

Alessio: 2 diff roles for target - 1. to open new window; 2. to point at a frame in a frameset or multimedia concept

RM: if we don't have @target, what is effect? going to write scripts to force open scripts
... inhibitor to go to 1.1 or will just write script

TH: include despite bad practice because people going to do it anyway

GJR notes that BLOCKQUOTE deprecated for layout purposes in HTML4x but you can find it used for layout on W3C site

TH: why @target in HTML? to open new windows - compromise: use to target fragments that already exist - not to open new windows because that is not role of markup langauge
... say "is NOT to be used to open new windows"

<Steven> "The target attribute is designed to be a general hook for binding to an external environment"

<ShaneM> see http://www.w3.org/TR/2007/CR-xhtml-basic-20070713/#s_xhtmlmodules for explanation of Target Module

<alessio> another use of "target" attribute: http://www.w3.org/TR/2005/REC-SMIL2-20050107/extended-linking.html

@target itself could be repurposed to a new tab, a sidebar by user agent

TH: user agent problem that persists - @target simply opens new window/browser instance
... why cave in to an illegitimate request?

SP: what is wrong with clicking on things to open windows

SM: explicit user action

GJR: that is point of UAAG1 and UAAG2

<alessio> target in SMIL: "This attribute defines either the existing display environment in which the link should be opened (e.g., a SMIL region, an HTML frame or another named window), or triggers the creation of a new display environment with the given name. Its value is the identifier of the display environment. If no currently active display environment has this identifier, a new display environment is opened and assigned the identifier of the target."

TH: open in same window or another window

SP: programming problem with browser

TH: support a11y by suppressing @target
... take stand that every problem due to poor user agents
... opens unpleasant can of worms

SP: agree with removing features that have no raison d'etre
... open windows all day long by clicking on things

GJR: @target should be treated as an option, not an absolute

TH: if going to say has good uses, have to also note problems

SP: both cases UA problem

TH: in one case SHOULD in other SHOULD NOT

<yamx> I don't think this argument is productive... If we don't like target (I am not a fan of target), we should discuss in XHTML Basic 1.1., not in XHTML 1.n 2nd edition...

@target should be treated as an option by UAs until explicit user action determines what to do

<yamx> Whatever it is. XHTML 1.n 2nd ed should be a super set of XHTML Basic 1.1., which is the starting point of this discussion.

RM: applications in windows environment still open windows that are accessible

TH: don't agree
... far larger probability if opens in new window won't know
... authors shouldn't make assumptions

GJR: author proposes, user disposes

SP: opposite is never open another link in another window - non sequitor

<alessio> maybe the UA could help, alerting when a new window is prospected

TH: problem include link and target to open in new window, have no idea what happens when link gets to user - author wants to open new window, user will be surprised by uncertainty and unexpected behavior

SP: filling in long form, don't understand something, click on help link, tells me what to do, but hasn't destroyed context of form and other helps open in same popup window

TH: if 800% magnification, where does window open?

<yamx> target has an interoperability problem in mobile domain, certainly, but we have to accept @target for compromising SVG group...

there is a queue

AT should alert the user that new window being opened or new pane / tab being opened

TH: shou ld be user's choice, not authors
... screen magnifiers - simply blow up what is on screen - too dumb an app

GJR: if no @target will end up with raw javascripted links which are a WCAG violation

RM: not language purity - from author and/or user -- what do constituents want: authors creating material, and users interacting with that
... if in there could treat @target as an option - if have javascript won't have single standard hook

TH: to this point no UA has implemented that
... user agents include options to open new windows and tabs from context menues; not bothered to use @target to give users an option

RM: will just use javascript to do anyway

The more things are forbidden, the more popular they become. -- Mark Twain

TH: why not restore MARQUEE

<Steven> We have had no requests to put marquee back in

TH: same rationale

<Steven> there is a queue

GJR: put @target in with strict limitations -- that is an option that should be a programmatic flag

<ShaneM> +1

<alessio> +1

<Steven> +1

RM: if target has characteristics, what hooks can we provide what options are available

SP: hear TH's problems with @target, also hear a lot of complaints that @target not in 1.1 so use 1.0
... thing i like about target is gives us control - can put conditions on its use
... can say, if use it user agent should do this and that -- XHTML Basic accepts but ignores it which is perfectly acceptable behavior
... serious and valuable use cases for @target - if in markup, is under control - if don't have it, people will use javascript to do it with all the rammifications of that

SM: UAAG exist - to extent they exist, don't know if UA devs pay any attention to or authors pay attention to or anyone pays attention to - no control over those guidelines, but do have control over our own spec; proposal in IRC to put limitations on target - need to define; value in doing that independent of decision vis a vis 1.1.; regardless of what we do with @target, poeplewil want to create new windows
... need to give authors a consistent way to do it, and provide documentation for UA devs
... people always going to be generating new windows - should put conditions on it

TH: keeping it out is a signal as much as putting it back in - shouldn't be allowing authors to engage in improper behavior under cover of standards

SP: for people to use "as they see fit"

TH: try other way around - put @target back in but say DO NOT use to open new windows

SP: can point to UAAG and WCAG

GJR: win win - WCAG also against raw javascripted links and stripping chrome

http://www.section508.gov/

RM: EU reference WCAG directly
... procurment in most european countries and will become EU wide

Yam: if prohibit use of @target to open new window, then ok to include

Alessio: some government sites forced to use XHTML 1.0 Strict so cannot open new windows declaratively

AC: people will use javascript to work around that though

<alessio> yes, the stanca act

RM: conclusions?
... looked at target but where to be reintroduced and how?

AC: @target for support of SVG elements - think need to point out how NOT to use @target
... need to know interoperability with UAs; what do UAs need to do to warn user?

http://www.w3.org/TR/uaag20

also a requirements document at http://www.w3.org/WAI/UA

<alessio> yes, thanks gregory

SM: Yam, you felt 1.1 could be superset of Basic 1.1

Yam: starting point of discussion, i think
... do we need second edition?

SM: need to republish to add schema implementation - no extension,

Yam: ambivalent

<yamx> Oh, I kill the line by mistake, too.

SP: don't care very much - 1.2 more interesting bit
... if issue as PER, people would rationalize that @target and input mode should be in 1.0 as well
... only counter argument is that XHTML2 coming to fix these things

<yamx> I am back.

SP: similar with Print - family of MLs trhat arent' constrained to each other either way

RM: second edition just add schema - or add schema and a couple of attributes?

SM: couldn't do in second edition

RM: 1.1 second edition that adds schema is only thing to do

SM: agree -- if want to reissue 1.1
... low-impact, so can do it logistically

SP: unchanged 1.1 a better approach; 1.2 where expend energy on combining existing specifications

SM: Yam not to interested in 1.2 - should go directly to XHTML2 - need to have discussion on that

RM: 1.1 take to second edition that simply adds schema and errata

<yamx> fine

SM: same thing with Print at same time

<yamx> no objection.

<Steven> +1

RM: objections?

<alessio> +1

GJR no objection

<Steven> my +1 was to the 1.1 suggestion

RESOLUTION: take XHTML 1.1 to Second Edition by simply adding Schema and Errata

<yamx> agree.

RM: can we/should we do a 1.2 and if so why and what would be in it?

SP: created something people using not backed up by spec XHTML1.1+RDFa

SM: references DTD

SP: oh - then it's not as bad as i thought
... option 1 is take all specs being produced seperately as part of m12n

SM: ARIA

RM: yes

<ShaneM> XHTML+RDFa is defined at http://www.w3.org/MarkUp/2008/ED-rdfa-syntax-20080616/#s_xhtmlrdfa

SP: wrap all those up into a language called XHTML 1.2 so people can refer to markup language that uses these things
... another reason, makes step to XHTML2 that much smaller
... community needs to be led step-by-step to XHTML2 rather than just being presented with it - get used to concepts

RM: XML Events and ????

SP: step to XHTML2 is XForms, HREF everywhere and SRC everywhere
... on the other hand, people out there already using XHTML11+ without doctype - not backed up by single spec, but rather widely used
... another option - do it all at one go

<ShaneM> I think stepping directly to XForms for xhtml 1.2 would be too far.

RM: how to introduce Access, ARIA, Role as first class citizen and validatable -- small step but huge gain - point release rationale is to add a11y features -- good advertising

plus 1

SM: anything put into XHTML 1.2 should work in browsers today

RM: agree with that

<alessio> idem

SP: wou ld mean not including Access

RM: right

SM: yep

SP: so 2 options there: 1. only bit remaining to be implemented

<ShaneM> XHTML2 also has meta and link everywhere

SP: could make effor to do implementation of Access in javascript

SM: started a few weeks ago

GJR: PF needs to submit support for Access to HTML5
... was in initial request to HTML5

<alessio> I'd done last year a test for Access

RM: XML Events - adding @implements on SCRIPT

SP: no problem because works already

SM: yes

GJR: huge plus 1

SM: not all XML Events

RM: no, just to enable @implements feature
... proposal for release and its content

SM: yes, and a timetable - dependencies on things not yet completed

RM: agree in principle to create proposal for XHTML 1.2 including @implements

Yam: don't object, but W3C may - agree under condition to make transition market for XHTML2 short, not long

<Steven> oedipus, alessio, please add agreemetns like that to the record!

RM: most definitely

GJR: @implements is going to be VERY useful

<Steven> @implements++

RESOLUTION: Proposal for XHTML 1.2 - Content and Timescale as outlined here

<scribe> ACTION: Steven - draft proposal for XHTML 1.2 - Content and Timescale [recorded in http://www.w3.org/2008/06/18-xhtml-minutes.html#action03]

<yamx> It is 23:00 in Japan.

RM: good discussion- made progress

<yamx> OK.

RM: XML Events 2 and Features after break?

<yamx> see you later.

===== 15 MINUTE BREAK ======

XML Events 2

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/

RM: XML Events 2 - http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/xml-events-rec-diff.html

RM: number of updates since last face2face - would like to get to LC - what needs to be done?
... did see some comments in XForms group, but don't know what happened to them - their status
... comments sent to XForms group, but not XHTML2 list(s)

SP: researches the matter

<Steven> http://www.w3.org/2008/06/11-forms-minutes.html#item03

RM: felt XML Events doc should be more self contained
... people shouldn't have to go to DOM3 spec, for instance charlie commented

SP: long discussion but no action item; most comments editorial, spec overall good
... will ping him to send comments to us

RM: editorial things not too much of a problem
... start with abstract

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#s_intro

RM: differences from DOM3 and @target

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#s_event_module_conformance

RM: conformance - not much change at all
... addition was to allow chameleon version should ML allow

SM: what does this mean given our new understanding of "null namespace"?
... bring in Events Module?

SP: not sure have new understanding of "null namespace"
... terminology used in certain circles not backed by any spec

SM: lets call it "no namespace"
... are we suggesting ok to bring XML Events into a language and use XML Event attributes in "no namespace"

RM: unless someone uses chameleon, including events

SP: not syntaxically the same, but semantically the same

SM: don't access from DOM in same way
... in a Compound Document, HTML uses Events in chameleon form - bring into HTML elements with no qualifiers, but SVG does not - in a Compound Document, do we expect the action attribute or event attribute will have same semantic on HTML p element as ev:event="circle"

<Steven> We will write <a href="..."><action event="DOMActivate"...>

<Steven> instead of

<Steven> this <a href="..."><action ev:event="DOMActivate"...>

<Steven> but the meaning will be the same

<Steven> We should coordinate with Forms WG on this

RM: been discussed at forms WG meetings i believe
... namespaces discussed in Forms f2f last week?

SP: consults minutes from Forms f2f
... not in detail

RM: specifics of what is in XML Events Module
... listener element

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#section-listener-element

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#section-listener-observer

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#section-listener-handler

RM: diff with DOM3 is QNames?

SM: essential difference

RM: observer element
... handler element

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#s_handler_module_elements

RM: default is target
... event propogates or continues - default should be performed or not
... not too diff from XML Events 1 - same principle

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#sec_3.2.1.

attributes for observer

RM: can add attribute to handler itself - http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#section-attributedefaulting
... not much different from XML Events 1 - comments?

<alessio> no

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#s_handler_module_elements

RM: XML Handlers

<scribe> ACTION: element to http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#section-action-element [recorded in http://www.w3.org/2008/06/18-xhtml-minutes.html#action04]

RM: similar to XForms, can use as container for potential actions
... condition - only true if XPath expression true
... can finally have xml:id

<Steven> action 4=

RM: script element - http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#section-script-element
... refined SCRIPT - important diff is @implements
... will discuss @implements in detail later

the dispatch element: http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#section-dispatchEvent-element

addEventListener: http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#section-addEventListener-element

RM: very similar - can register eventListener
... can stop bubbling
... can prevent default defined for event
... straightforward

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#section-removeEventListener-element

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#section-stopPropagation-element

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#section-preventDefault-element

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#section-event-naming

RM: XPath Expressions: http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#section-xpath-expressions

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#xpath-function-library

RM: XPath to describe context information (XPath context)

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#xpath-event-function

RM: @implements
... optional - this script should only be loaded if UA doesn't have implementation of feature
... key thing is how to describe features
... safe URI or safe CURIE ok, but how to define features

http://www.w3.org/MarkUp/2008/ED-xml-events-20080508/#xpath-event-function - names event and where dispatched to

RM: events predefined by DOM3, can create own events and dispatch those
... XPath Expressions ahs extra note
... not setting particular context mode
... what necessary to define context - what would someone find useful - don't currently have idea of context
... 6.1.1.XPath event Function
... "Function event returns the value of a property of the current event object, as determined by the string argument. "
... identify feature for @implements - URI but represents what?
... comments? observations? questions?

SP: anticipate fight over XPath
... last version didn't have XPath, now it is required

SM: some way to do that doesn't require XPath?
... conditionals without way of referencing?

RM: could do in script
... definition of what conditionals are

SP: conditionals need to be in some langauge
... maybe call section 6 "Expressions"
... expressions that happen to be the ones in XPath
... not asking to implement XPath, but syntax derived from XPath - serious difference

RM: what is the core we need? what subset of XPath
... not a big dependency on XPath

SM: 2 modules - XML Events and XML Handlers - do we envision world where one can have handlers without events

SP: people write scripts today without XML Events

SM: XML Handler Module needs all of what is defined in XML Events

RM: except for SCRIPT element

SM: true
... might be useful to have SCRIPT and @implements independent of XML Events - applies to Handlers as well

<Steven> +1

<alessio> +1

SM: wonder if shouldn't have a module in specificiation - XML Events, Handler Element, Script ELement

plus 1

RM: agree
... a convenience that in one document, but they are separate --

SM: imagin e there is a Script Module without dependency on other 2 modules

RM: does not appear so

SM: new Handler module without new Events module doesn't make sense

RM: some actions could be useful without events

SM: if anything has dependency on events, then depenency on events module

RM: yes
... only exception is script - no dependence on other 2

SM: then separate it out
... make sense to have XML Events Module without XML Handlers Module?

RM: XML Events 1 are used today and there are no handlers, so must have some value without handlers

SP: didn't define handlers because wanted people to use handlers already had on XML Events

SM: require people to use XML Events Module AND XML Handlers Modlue?

SP: no

SM: good

RM: proposal: split into 3 modules - XML Events, XML Handlers, and Script plus change in wording about use of XPath

SM: minor editorial stuff too

RESOLUTION: will break into 3 Modules: XML Events Module, XML Handlers Module, and Script Module

SM: accept Yam's proposal

Yam: change attribution/acknowledgement

RM: needs to describe who we are today and who is doing the work today

Feature identification in XML Events

RM: namespaces - should be dealing with someting more fine grained in namespace
... there is another namespace option

<Steven> scribe: Steven

RM: So a namespace is rather too coarse grain to define the features that will be implemented

SM: The spec says CURIEs are used for identification
... the CURIE spec allows for reserved values
... but doesn't allow for multiple default prefixes
... so if we are to define a separate vocab document, it *can't* be another default vocab

implements="m12n:hrefeverywhere"

SM: So you may as well just use the URI

<oedipus> thought was supposed to be able to use URI

RM: You're only going to write this once, so it isn't a major problem having to write it

<ShaneM> http://www.w3.org/1999/xhtml/modules#FEATURE

perfick

SM: That was what I had in mind

RM: Me too

implements="http://www.w3.org/1999/xhtml/modules#i18n"

RM: So if I implemented XML Events 2, what would it say?

<ShaneM> http://www.w3.org/1999/xhtml/features#xmlevents-2

<oedipus> implements="m12n:events m12n:handlers" ?

SM: Right, so we need to define the term for each module

RM: Can we agregate features?

Steven: I hope so; eg XForms
... or even XHTML2

<oedipus> me too

<oedipus> RM: core - first features XML Events

<oedipus> RM: XML Events not in xmlns

<scribe> scribe: oedipus

RM: URI probablly different

SM: keep conflating namespaces and vocabulary spaces

<ShaneM> http://www.w3.org/MarkUp/features#xmlevents-2

RM: would break linkage to NS
... using namespace name suggest something that isn't true - or a linkage that isn't there

SM: in feature space can put anywhere we want, but makes sense to coollect in single place
... is XForms in this document or will they incorporate?

RM: can go anywhere URI can point to

<ShaneM> ACTION: Shane create an initial features document that includes the features from XML Events 2. [recorded in http://www.w3.org/2008/06/18-xhtml-minutes.html#action05]

GJR: point about conflating namespaces and vocab spaces very pertinent (for building expert handlers)

SM: should point to XML Events - so good BP in document

RM: in script element, could show how to point to other parts of document -- could in fact, implement itself
... could be bootstrapped in

SM: could.... but not sure for first version

RM: showing how implments handler events
... any other thoughts on this topic?

SP: action shane has is list names of features and module feature represents, right?

RM: assign names to features and make clear that named features are modules in question

SM: have a vision of it - linked together and back to base spec
... want meaningful triples - should have best practices

RM: not just in spec, but in position to develop solution that does it

SM: definitely

RM: other comments?

<yamx> no from me.

RM: conclude this topic - anything else to go back over from earlier today?
... have some catch-up time tomorrow morning

Yam: yesterday mark mentioned HTML5 group have security issues - relevant for any ML - if devise good mechansim for wwindow shouold be seperate spec

http://www.w3.org/2008/06/17-xhtml-minutes.html

<Roland> http://www.w3.org/2008/06/17-xhtml-minutes.html#action02

RM: action number 2 - immediately after mark's comments

http://www.w3.org/2008/06/17-xhtml-minutes.html#action02

RM: idea was MarkB go back on items and our reply should be consistent with / coordinate with XForms response on this

SP: moved comments up into section where topic discussed

RM: Yam correct, do want to ensure coordinated response

Yam: don't agree with justifications

========= ADJOURN ============