XHTML2 WG FtF, Venice, Italy, Day 2 -- 19 Feb 2008

<Steven> Scribe: Steven

.me 12.30ish

yep

I was just about to thank you

<oedipus> no need

Role (brief return)

<scribe> Scribe: Yam

<scribe> scribenick: yamx

Steven: Bratt will review M12N modularization transition request.
... Bratt asked about XHTMLBasic 1.1 (but it is not delayed by M12N from our perspective).

Shane: an issue for Role.
... I would like to capture the resolution correctly.

Roland: It SHOULD have dereferenceable, and one of them should be RDF.

Steven: we added "some is beyond the scope of role (it is vocab issue)".

Roland: Another vocabulary.
... yesterday of action is action for Roland to reply to the guy raising the original issue.
... Leave the action for Roland.
... we talked xFrames, equivalent iFrame.

Yesterday refresh (xFrames)

Steven: Populating URI with ids, and extends to XHMTL2.

<Steven> home.xframes#frames(one=a.xhtml,

<Steven> So we could say that this works for XHTML2 as well

Roland: We will retain the notion of subclases of object like iFrame, src value matching.

<Steven> and the URI replaces the src attribute

<Steven> on the element that matches the id

Roland: Could we do the sme thing to document?

Steven: question is matching with id, not match src attribute, do we create one?
... Replacing can lead to some unintended security risk.. just thinking...

Roland: thinking about killing three birds in one stone, bookmarking, frame flow, ...

Steven: I am going for some flipchart to think about it.

(Steven went out , seeking for flipchart)

(Steven returned with a flipchart.)

Steven: [[summarizing frame requirements]]

Roland: maybe some attributes to distinguish "replace-able", "bookmark-able" srcs.

Shane: it may resolve many comments we received about people's concerns what content can be covered.

Roland: "static" and "iframe-type-src (replace-able)".
... Ability to change (bookmark, if changed, it is reflected as URL).

Rich: changing the value will automatically refresh?
... We have to think about scripting environment.
... Does the page automatically reloaded when managed by scripts?

Roland: Default action is reload, but it can be cancellable.

Roland described body-object-iframe on flipchart.

<body>

</body>

http://example.org/home.xframes#frames(f2=myothersutff.html,...)

Roland: bookmark will go to "myStuff.html".

Steven: http://exmaple.org/home.xframes#src(f2=myotherstuff.html, ..); Roland agreed.
... the resulting URl is not changed from <object> use.

Roland: the first one can be <div> (not only <object>).
... "target" as "iframe"...

Steven: Frame does not have "id", it is not bookmarkable.

Roland: bookmarkability, inline capability, fall-back capability, flow, ...

Rich: some next step issues, widgets, ...

(Pens arrived for scribing flipcharts.)

<ShaneM> (Prior to this scribing in blood - dedicated group!)

(We are blood-tied-group)

<Roland_> http://example.org/home.xframes#src(f2=myotherstuff.html,f1=img.jpg...)

<Roland_> <body>

<Roland_> <div id="f1" role="navigation" src="nav.html" />

<Roland_> <iframe id="f2" role="main" src="myStuff.html" />

<Roland_> </body>

<Steven> Rules: If there is no @src, then there is no assignment

<Steven> ... changes in an iframe get reflected in the top-level URL

Roland: We will think if we come down anything more this afternoon.

<Steven> Shane: We need to run this past Mark who has a similar mechanism in his implementation

Roland: Id, embed content, iframe content itself id duplicate, any qualifying identification. Things arise..

Steven: talking with Shane to clarifying document-load-event (image loading is not complete).

<Steven> The question is: is the *document* ready after or before all the <div src=..>s are ready

<Steven> Does it act like img does now, or not

<oedipus> shouldn't it act as OBJECT was intended?

Shane: Scripting should be executed inline?

Steven: Declarative.
... Probably executed in document order, but not during parsing.

<Steven> Shane think that document ready occurs *after* all the sub documents are ready

<Steven> .... they are very different from images, which do not have presence in the DOM

<Steven> Alessio: I just tried some iframes in current browsers and the sub documents in an iframe get executed script and all as you would expect

<ShaneM> When they are executed are the executed in the context of the parent document? Or in their own context? From a javascript security perspective I mean?

<Steven> good question

Roland: It is something we have to sort out.

<alessio> I'm trying to do it in the parent document now, shane

<alessio> but the security issues remain, naturally

(coffee break, a point of success.)

Roland: next agenda after coffee break will be "longdesc".

<Steven> we are off to the cafe for a coffee Gregory

<oedipus> thanks steve

<oedipus> Equivalent Content for Images (HTML wiki page by GJR): http://esw.w3.org/topic/HTML/LongdescRetention

<oedipus> there is a lot of material related to short and long descriptors (PF asked HTML WG for retention of longdesc or a superior mechanism) in the Equivalent Content for Images (HTML wiki page by GJR): http://esw.w3.org/topic/HTML/LongdescRetention

<Steven> Did you write all that page Gregory?

<oedipus> i wrote most of it, and then added comments and proposals by others, but, yeah, that's my baby

<Steven> Do you list Google (or search engines) as a consumer of alternate content?

<oedipus> one thing that is missing is use of a tree (expand/collapse all) or accordion (expand/collapse individual branches) widget as a long descriptor providing the user with the ability to follow all or selected branches -- gives the equivalent "eureka!" moment that sighted users get from schematics, flow charts, tree grids, etc.

<oedipus> steven, yes, there is discussion of search engines and flickr-type sites on the page (it is quite a long page)

<Steven> I personally believe that the only solution is to have the longdesc content in the page, near the equivalent object, otherwise authors will never provide it, nor update it

<oedipus> that should be up to the user -- display inline, display as block/iframe/object, display in parallell -- there are a lot of use cases for side-by-side description/image couplets as there is for a linked descriptor (which could always be yanked into a document instance)

<oedipus> long ugly wiki uri on exposition options:

<oedipus> http://esw.w3.org/topic/HTML/LongdescRetention#head-b737a38d23d16c3474b7a9204a7b70507f30d69a

<Steven> The reason that longdesc has failed to date is that it is too difficult to do, keeping parallel documents

<oedipus> that and a lack of support and freaky implementation -- JAWS opens longdesc in a new pop-up window, which pop-up blockers block!

<Steven> The HTML5 group has the disadvantage of having to be backwards compatible

<Steven> We can adopt better solutions, for instance by allowing img to have content

<oedipus> true, but the underlying issues remain -- that's what the esw wiki page is an attempt to do -- outline the needs/use cases and come up with a better mousetrap

<oedipus> IMG as a container would be a consummation devoutly to be wished

<oedipus> OBJECT is my preferred solution, only it is broken

<Steven> Actually in XHTML2 all elements behave like object.

<oedipus> that's why i joined the WG!!!

<Steven> <div src="whatever">fallback<.div>

<Steven> good on yer Gergory!

<oedipus> thanks

<oedipus> the name of the wiki page is a relic of issues past -- it should be "Long and Short Descriptors for Static Images" or some such

<oedipus> to quote myself from the page:

<oedipus> What is needed, therefore, is a normative list of recommended/expected actions that allow multi-modal interaction with the long description. Treating LONGDESC as HREF isn't the only means of exposing the content of the long description page; the contents -- or the main portion thereof -- could be rendered inline instead of the image or in an IFrame (which has its own accessibility issues) or any other number of means of exposure. The key is that the UA should

<oedipus> * expose in new browser instance

<oedipus> * expose in new browser tab

<oedipus> * expose inline (insert content as object)

<oedipus> * expose inline through the use of IFrame

<oedipus> * expose the contents of the longdesc document in a side-bar,

<oedipus> aligned with the image it describes

<oedipus> and there are many other options, provided a user knows what to do when encountering a long description, then it matters not what assisstive technology she is using, for there is an expected action in the case of browser x for exposing LONGDESC

<oedipus> GJR notes that some of the best examples of LONGDESC are in CSS 2.0 -- 46 longdescs in all!

Shane: "longdesc" attribute is available even when src does not fail.

<oedipus> right: it isn't necessariliy an either/or proposition -- some user groups need guidance through an image

Steven: "longdesc" is the content of element, we don't need "longdesc" attr.

<Steven> http://www.w3.org/TR/xhtml2/mod-embedding.html#s_embeddingmodule

<oedipus> GJR: point of reference -- are we discussing M12N section 5.7 "Image Module"

Shane: once resource is obtained, the rest of content is not processed.

Steven: a question: not processed or not presented?.

<ShaneM> we say: If accessing the remote resource fails, for whatever reason (network unavailable, no resource available at the URI given, inability of the user agent to process the type of resource) or an associated ismap attribute fails, the content of the element must be processed instead.

<ShaneM> http://htmlwg.mn.aptest.com/htmlwg/xhtml-m12n-2/abstraction.html#dt_ContentTypes

Shane: I did not look into public version.
... Issue persists. What happens content nested after a document is resolved?

<Steven> I think that the alternate text is in the DOM

<Steven> ... I think we can define the behaviour with CSS

<Steven> .... in fact I'm sure that Jonny Axelsson once demonstrated that

<oedipus> it should be in the DOM so it can be reused/accessed by assistive technology/regular users

<Steven> ACTION: Steven to add text to embedding module saying how it works [recorded in http://www.w3.org/2008/02/19-xhtml-minutes.html#action01]

<Steven> Rich says we need some events that say what happens

<Steven> ... 'load' when a src works I think

<Steven> Steven: What should you get if the src fails though?

<oedipus> GJR: need to ensure that if user needs side-by-side image and descriptor to process the image (limited viewport, congnative issues, etc.) it is readily and easily available

Steven: reasons for src failing: (1) network down, (2) 404 or similar.
... reviewed error code 406 for HTTP.

Roland: you did not get any event in image load finished.
... DOM3 don't have anything different.

Steven: DOM went to WebAPI, Rich.

Stenven: DOM3 said images are loaded before you get load event.

<Steven> "The DOM Implementation finishes loading the resource (such as the document) and any dependent resources (such as images, style sheets, or scripts). "

<Steven> http://www.w3.org/TR/DOM-Level-3-Events/events.html

<Steven> Event "error": A resource failed to load, or has been loaded but cannot be interpreted according to its semantics such as an invalid image, a script execution error, or non-well-formed XML.

Roland: Let's see new charter for WebAPI to check DOM3s...

<Steven> http://www.w3.org/2008/02/06-webapi-minutes.html

<Steven> minutes of a recent call

<Steven> Zakim: leaving. As of this point the attendees were Carmelo, Andrew_Emmons, anne, shepazu

Shane: DOM3 Events use qnames?

Roland: no search result for qname.

Steven: But they have namespaced events.

Roland and Steven: We don't need "longdesc" attr. Steven will add clarifying text for embedded context. (already ACTION for Steven)

Roland: alternative to src.

Steven: Added (3) images switched off, at flipchart.
... after (2) 404/406 or similar.

<Steven> In css, you say img[src] {content: attr(src)}

<Steven> so in principle you can switch between displaying the image and the content

<oedipus> GJR: that "principle" needs to be explicitly stated

<Steven> (but the CSS doesn't give you control over @srctype)

<Steven> In any case the alternate content is in the dom, so is available for use as necessary

<oedipus> amen

Steven: poping stack for a few levels, back to "longdesc".

Roland: how we can style both?

Steven: in CSS, content: means replacement with external resource. (Steven went to flipchart to argue)

Roland: CSS cannot do fallback at failure.

Steven: *[src]:error, you can invent pseudo-class in that case.
... We don't know it is allowed, but let's assume it allowed...
... *[src]:before
... {content: attr(src)}
... *[src]{display:none}
... body.nosrc *[src] {display:block}
... body.nosrc *[src]:before
... {content: ""}
... *[src]:error

<oedipus> steven, will that {content: "foo";} make it into the DOM? currently, CSS-generated text isn't in the DOM and isn't accessible to assistive tech

Steven described an error case with src="foo.xdiv" srctype="vide/xdiv"

<oedipus> UAAG (user agent accessibility guidelines WG) is trying to address CSS- and script-generated text, UAAG2 has a proposed requirement that ALL text, no matter what its source, must be made available via the DOM or directly to an accessibility API (such as MSAA, IAccessible2, ATK/AT-SPI, etc.

Roland: we will talk XML Events 2 after lunch break.

<oedipus> when will we resume? how much time are you breaking for lunch?

<Steven> Gregory, I expect lunch will be an hour

<oedipus> thanks - now if only i had a left-over canoli (sp?) to eat for breakfast...

<Steven> Gregory, wrt your content: question

<oedipus> yeah

<Steven> I didn't put any real content there

<Steven> in one case it is the embedded image

<Steven> in the other case, the embedded image is overwritten with 'nothing' (empty string)

<Steven> the dom remains the same in both cases

<Steven> (I think)

<Steven> and the DOM contains the URL of the image, and the alternate content, both of which reside in the DOM without change

<oedipus> do you think the UAAG2 req unreasonable?

<Steven> and so is accessible to any software that wants to make use of it

<oedipus> ok

<Steven> I have no problem with the UAAG2 requirement

<oedipus> that's certainly good to hear

<Steven> In fact it is a pain when you copy a numbered list, and don't get the numbers in the copy buffer

<oedipus> the tricky bit is wording it correctly

<Steven> because of the generated content problem

Rich: Guideline for browser for markup?

<oedipus> if CSS is used to control list styling, one doesn't get that info from an assistive tech - it uses the "dumb" nesting default algorithm

Shane: we provided default CSS for XHMTL2.

<Steven> But for instance Gregory, XForms which also generates content, amongst other places via repeats talks of a shadow tree (or DOM)

<Steven> so you have two DOMs

<oedipus> that's the tricky bit UAAG is trying to deal with -- multiple DOMs

Shane: Browser people complained "don't constrain browsers".

<oedipus> browser people are always complaining -- just like their users!!!

<oedipus> steven, your point about copying content with CSS-generated text is a mirror of the AT user's problem, only it is constant, not situational

Shane: I have an action item to turn OWL into RDFa.
... at the end of role spec.

<Steven> ack that Gregory

<oedipus> rich, i'm not sure i understand your question -- UAAG guideline would be markup agnostic -- if something's writing to the visual palette, capture it in the DOM or expose it directly to an accessibility API is what UAAG is discussing

Steven: at the end of vocab, RDFa is readable for human and machine, everyone happy.

<ShaneM> Creative Commons stuff in RDFa: http://creativecommons.org/ns#

Lunch break.

<Steven> Pity that they use the wrong DOCTYPE. Otherwise COOL!

(we really go to lunch, now...)

<oedipus> goda del pranzo, tutto

<Steven> back finally

<Steven> sorry, slow service

<oedipus> no comment...

(People are back from Lunch)

<ShaneM> Mark sent belated regrets for today. I have not yet determined if he might be available tomorrow.

<oedipus> Shane, thou art the bearer of bad news, but since i took a vow not to shoot the messenger...

<Steven> RDFa is rather eating up his time

<Steven> shane, ringing

<oedipus> but it tastes SO GOOD

<Steven> shane? ShaneM?

<Steven> Simone is an IWA member

<Steven> ... and a member of SWD

<Steven> ... and is involved with RDFa

<Steven> ... attends the RDFa calls

XML Events 2

<Roland_> http://www.w3.org/MarkUp/2007/ED-xml-events-20071114/

<oedipus> i know what the WG has said, and what Section 3.3. "Attaching Attributes Directly to the Handler Element" says, but isn't there still a need for a "purpose" element/property for event handler? shouldn't that be part of the core architecture? it is needed for, amongst other things, providing a foundation on which to build "expert handlers for specialized markup" for assistive technologies:

<oedipus> http://accessibility.linux-foundation.org/a11yspecs/handlers/uuc1.html

<oedipus> and http://www.linux-foundation.org/en/Accessibility/Handlers/UseCases/Unified/ScratchPad

<oedipus> (don't let the domain name fool you -- this is a proposal from the Open Accessibility Workgroup formerly of the FreeStandards Group (FSG) which is platform agnostic

<ShaneM> cant we just use "role" for that Gregory?

<oedipus> thinking...

<oedipus> RichS?

Roland: I have a suggestion, found in a thread...

<Roland_> I commented on this topic a while ago: http://lists.w3.org/Archives/Public/public-xhtml2/2007Nov/0020.html

<oedipus> thanks for pointer - am checking

<oedipus> roland, i am intrigued by your ideas, and would like to subscribe to your newsletter...

<Steven> Another two long pages for us to digest Gregory :-)

<oedipus> seriously, you raise an excellent point

<oedipus> steven, i guess i speed listen

Shane: Purpose disapeared thanks to "role".

Roland: adding info for human is complementary.

<oedipus> but, shane, isn't there a case for defining a specific role for the task? roland's example of a <hint> is a good example of author abuse, like saying "go get a real browser" in a NOFRAMES (sorry roland)

<oedipus> it doesn't tell anything human or machine parseable, is what i mean

<ShaneM> well - @role should be machine parseable. human readable is another, potentially important area

<Steven> Gregory, how do you see the purpose element being used in accessible software?

<oedipus> the expert handler will probably be an ontological interpreter that facillitates read/write access for users of AT (assistive tech) - it needs to communicate to the AT info that allows for meaningful 2-way communication with specialized markup languages, so that each AT doesn't have to implement specific handlers for specific SMLs (specialized markup languages)

<oedipus> it is specialized middle-ware that will rely on OWL or RDF, most likely (er, if i had my way)

<Steven> So if a handler had a label element (for instance), that briefly described the purpose, is that enough?

<oedipus> yes

<oedipus> what does rich think?

<Steven> He just said "That'll work"

<oedipus> i think so too

Roland: talked about xForms, hint, label, and role.

<oedipus> problem with assistive tech is that everything is done through keyboard overlays -- case in point -- i have to go into "table navigation" mode to make sense of anything in a TABLE, but when i ReadAll, the table is read from top lefthand corner to bottom righthand corner, forcing me to stop at EVERY table in a document if i am to understand what probably should have been in a DL in the first place

<oedipus> it is even worse when there is an HTML form in the table, as FIELDSET, LEGEND, and LABEL aren't legal in HTML4x/XHTML1.0 tables

Shane: table discussion does not relate to event handler.

<oedipus> there is a separate "forms mode" which doesn't tell you anything about the table containing the form, so one has to switch to "table navigation" which means one no longer knows what state (or even what INPUT type) the form control he/she is attempting to contextualize

<oedipus> ok, i'll get off my high horse, shane...

<Steven> (Shane's comment was an explanation, not a complaint)

<oedipus> should have added a <wink>

Shane: separate module, scope event, qname in DOM3. that leading to this, Roland.

Roland: DOM Level 2 interface, rather than Level 3.

<oedipus> GJR: just want to re-iterate that i am open to a label or some other named element that briefly described the purpose of the handler

Steven: We originally put script only when it does not support following name spaces.
... for legacy cases.

<ShaneM> This might be useful for understanding what is different: http://www.w3.org/MarkUp/2007/ED-xml-events-20071114/xml-events-rec-diff.html

(Steven wrote an example for script element in a flipchart.)

<oedipus> yam, you are doing an EXCELLENT job of minuting

thank you.

<oedipus> thank you!

Steven: should we put into XHTML2 or hander spec?

<oedipus> can i raise both hands?

<Steven> So I propose adding in XML Events 2 <script src="xforms.js" type="..." implements="... NS URI ..." />

<oedipus> i think that would work, steven

<Steven> @implements tells the system that if they have an implementation of that NS, ignore this scrpt

<Steven> Shane: We can also do that with an @if that checks HASFEATURE

<Steven> ... so @implements is then a shorthand

<oedipus> that makes sense to me (which should alarm you, shane!)

<gshults> Good morning

Roland: this XML Events 2 defines two modules (events, handler).

<Steven> Shane will skype you Gerrie

<Steven> to save bandwidth at this end

<gshults> OK

<Steven> Yam: I have a minor comment

Yam: new version of HTML in "introduction" is umbiquious now. To XHTML.

<Steven> ... we should s/a new version of HTML/a new version of XHTML/ in the intro

Yam: All XML applications in W3C follows this "XML Event 2"?

Steven: Probably.

<Steven> Not all XML applications use it, though they all could (if they use DOM Events)

Steven: In the past, some groups mentioned they had some special requirements, but no, they had a same problem.

Roland: Introduction needs updating, covering handlers.

<Steven> ... which was that parts of the DOM tree can be unavailable at times

<ShaneM> ACTION: Shane to update intro to XML Events to reflect its current scope of Handlers and Events. [recorded in http://www.w3.org/2008/02/19-xhtml-minutes.html#action02]

<Steven> ... and when the part of the tree is unavailable, they musn't generate events, nor handle them

Steven: XHTML2 says that it uses XML Events 2. XML Events 2 will decide whether DOM2 or DOM3 event.

Roland: fall-back is in XHTML2.
... DOM2 did not have load error.

<Steven> It sounds like we need DOM3 events since it has the new-style load event, and the error event

Roland: how about just put a note in XHTML2.
... put a note in XML Event 2.

Shane: It says DOM2 and qname in the current spec.

Steven: last week, Form group met.
... hopefully seriously going, now.

Roland: propose to switch for DOM 3 Event.
... let's refer to the last published.

RESOLUTION: XML Event 2 will be based on DOM 3 Events.

Shane: the current DOM 3 spec has how to map qname in DOM2 compatible.

<scribe> ACTION: Shane to update "Introduction"(HTML->XHTML) and references to DOM3. [recorded in http://www.w3.org/2008/02/19-xhtml-minutes.html#action03]

Shane: XML Event 1 shortname will result in the same doc..

Roland: no suffix, XML Event shortname.
... green part, chameleon namespace at the end of 2.1 Document Conformance.

Shane: conceptually supercedes any markup language. implementers can magically deal with? That is an issue.
... It is Mark's issue, he is not here.

Roland: regardless of markup language, general processor does. built-in does.
... we are not sure about what the implications are for implementors.
... do we have proforma text, highlighting features for assertions?
... machine extracting assertiosn for conformance testing, it is not available now.
... proforma text, it will be dealt separately.

<ShaneM> new shortname should be xml-events2 whilst we are developing.

Shane: we need xml id in an explicit way? Steven?

Steven: We definitely need it.

Roland: default action, can we stop it? decision in listner?

Shane: we have it in handler section.

Roland: precedence issue, perform and prevent?

<Steven> We recommend this syntax for latest version URIs:

<Steven> When a Working Group follows this scheme, Director approval of short names is not required; the Communications Team can allocate them (provided they are reasonable, not offensive, etc.).

<Steven> http://www.w3.org/2005/05/tr-versions

Steven: it is XPath 1.

<ShaneM> Note that we explicitly only require a subset of XPath semantics: XML Events XPath expressions have no context node, and so the context position is 0 and the context size is 0. There are no variable bindings, and the function library contains the functions described below. It is not necessary to provide namespace declarations.

Shane: 3.1 Listener element, there is Editor's note, which we deferred.

Roland: URI is in the universe, security risk.
... keep id, for compatibility. Introducing URL later.
... Dispatcher element has target child attribute.

Shane: we defined them in global for target.

(Steven just came back)

Shane: observer can be URI? it is an issue.

Roland: I proposed we create observeuri attribute if we need one, later.
... I propose to remove the current Editor's note.
... I propose the text as it is (with removing Editor's Note).
... while.

<ShaneM> @ev:while has this note: EDITORS' NOTE: Can't think of an example that only makes use of what we have in this spec, i.e., the event() function. We may need to do something like delete a list in XForms.

Steven: Original use case is to repeat it until some condition is satisfied, in XForms.

(Steven went to a flipchart to describe an example for Roland.)

(delete all sort of dates, if they exists out of date nodes...)

<trigger ev:event="DOMActivate"

<label< delete all sort of datels </label>

</action>

Roland: Section 4, table there. action elements say..
... why we repeat the global "id" here. trouble to reconcile..

Steven: Action does, script doesn't, wierd.

Roland: put if and while on action and script.
... not having it in listener.

Shane: not in global attributes, which you can attach to anything.

<ShaneM> ACTION: Shane to migrate @if and @while from listener element to the handler elements [recorded in http://www.w3.org/2008/02/19-xhtml-minutes.html#action04]

Steven: @if refers to action only.

<ShaneM> Shane: is the Basic Profile still useful? Section 3.6

Shane: Yam, do we need mobile profile? From Panasonic request a while ago.

Yam: OMA currently has no plan to cutomize Events, with troubles with DOM2 events and DOM3 events, no more fragmentations or burdens to think about.
... restrictions will be good, but we need some good guidance, which we don't come up with now.

<Steven> I asked Kenneth Sklandler who is an implementor of XML Events on mobile devices.

<Steven> He said:

<Steven> "no i do not think it is needed. the normal xml events profile is not too complex for mobile"

Shane: XML Event 1, expressed in DOM2, DOMactivate.

Steven: we can use DOMactivate, it is illustrative example.

Roland: XForms, we use DOMactivate.

Shane: overflow. which we cannot find

Roland: we have click, activate. which should be DOMactivate.

Steven: capture, bubble, target. strictly speaking, the figure...
... capture stops at bubbling. Bubble does not start from target.

Roland: include link to introduction.

Steven: discussing arrows in exact defined meanings.

Roland: showing some definitions in DOM3 Events, to Steven.
... in event interface (1.4) DOM 3 Event.

<ShaneM> AT_TARGET

<ShaneM> The current event is in the target phase, i.e. it is being evaluated at the event target.

<ShaneM> BUBBLING_PHASE

<ShaneM> The current event phase is the bubbling phase.

<ShaneM> CAPTURING_PHASE

<ShaneM> The current event phase is the capture phase.

<Roland_> Event Interface: http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-interface

<Steven> http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-flow

<oedipus> thanks for pointers

Roland: we have to refer to it, not reproducing them.
... 1.2 Event dispatch and DOM event flow (in DOM 3 Events)

<Steven> I don't think I have *ever* needed to use the phase attribute

<Steven> ... the defaults are just right

<Steven> ... but I have no problem with adding a phase="target"

<Steven> ... as John Boyer requested

<Steven> ... or phase="attarget"

Roland: three options, if none specified, default (whatever DOM 3 event) applied.

Steven: Bubble includes target.
... Bubble is default.

<ShaneM> Just to be clear, what I think you are proposing is: phase ("bubble"* | "capture" | "target"),<br />

Roland: all of better descriptions and diagrams, better than we did.
... @phase has four values (3 phases + default). "default" is for backward-compatibility.
... No specified, default. default is synonim to "bubble".
... WML is little bit out of date in illustration.
... propose 3.5 Event Hander.

Steven: we don't need 3.6.

Shane: both gone.

Roland: we found section 4 new things.
... Chameleion to be applied to whole spec.
... back to earlier discussion, hint label and help, part of content?
... any consensus?
... Essentially identical to XForms, but we have to doublecheck.

<Steven> XForms: action Common, Events, Action Common (Action)+

<Steven> This module also defines the content set "Action", which includes the following elements:

<Steven> load||send|message)*

<Steven> http://www.w3.org/TR/xforms11/#action

Steven: some discrepancy from XForms, dispatch and dispatchevent.

<Steven> Here is dispatch in XForms 1.1:

<Steven> dispatch Common, Events, Action Common, name (xsd:NMTOKEN), target (xsd:IDREF), delay (xsd:nonNegativeInteger), bubbles (xsd:boolean), cancelable (xsd:boolean) name?, target?, delay? [in any order]

s/dispathevent/dispatchEvent/

<oedipus> roland, GJR gives strong +1 to Steven's earlier proposal: "So I propose adding in XML Events 2 <script src="xforms.js" type="..." implements="... NS URI ..." /> [...] @implements tells the system that if they have an implementation of that NS, ignore this scrpt" and to Shane's addition: "We can also do that with an @if that checks HASFEATURE so @implements is then a shorthand"

Steven: destid.

Shane: a conf call among Shane, Steven, Mark, over a year ago.
... some collision... we identified.

Steven: I am reluctant to go all this again...
... , but..

<Steven> <action event="foo"

<Steven> <action ev:event="foo"

Steven: equivalent way to same things.

Shane: we prohibit putting both in the same time.

Shane: do in assistive technology.

Steven: not to handler, dispatch event to element, handler is maybe listening.
... Document? Document means root element?
... reading dispatchEvent element.
... this is a syntactic bindint to DOM 3 Event. Let's read DOM 3 Events.

<Steven> In DOM3 it is:

<Steven> EventTarget.dispatchEvent(eventname)

Steven: destid is required attribute, not optional.

Roland: default works.

Steven: in DOM3, it is method, but here, it is not method in Section 4.
... use "action" insted of "method" in Section 4.

Shane: done.
... current words on destid... does it make sense?

Steven: "otherwise, the event is dispatched to "document". ???
... events should be dispatched to "element" , nowhere to go.
... in root element case, just hit root element. no other places to go.
... describing phases in root element.

Shane: whole bunches of handlers in head element?

Steven: load event can only in html and body, nowhere else.

Roland: dispatch in XForms and dispatchEvent in XML Event 2 , quite different attributes...

(Steven went to a flipboard...)

(describing "dispatchEvent" example.)

(highlighting differences between XML Event2 and XForms 1.1)

Steven: cancelable="cancelable" , that's the traditional way of boolean.

in XML Events 2 <dispatchEvent name="load"

destid="#foo"

bubbles="bubbles"

cancelable="cancelable"

s/cancelable"/cancelable" \/>/

in XForms 1.1 <dispatch name="load"

target="#foo"

delay="1"

bubles="true()"

cancelable="true()" />

<ShaneM> IanJ confirms that we need toi ask the domain lead for an extra short name xml-events2 before we can make the short name changes we discussed

<Steven> And yet I pasted a text above that says we don't

<Steven> When a Working Group follows this scheme, Director approval of short names is not required; the Communications Team can allocate them (provided they are reasonable, not offensive, etc.).

<ShaneM> IanJ refered me to this document: http://www.w3.org/2005/05/tr-versions

Shane: I will manage this shortname issue.

Steven: http://www.w3.org/2005/05/tr-versions says that we don't need Director(domain lead) approval.
... target is global in our spec, it is a problem.
... we can use name(as in XForms 1.1)

<Steven_> but we have a problem with @target

Steven: I have a sneaking feeling that we talked with XForms group...
... how about "targetid" instead of "destid", closest possible to XForms 1.1.

Shane: targetid is global.
... as in Section 3.

<Roland_> dispatchEvent should be changed to dispatch

<Roland_> the raise attribute should be changed to name

Shane: targetid means something different in Section 3.

<Roland_> bubbles attribute should be changed to an Xpath expression that evaluates to a boolean

<Roland_> cancelable attribute should be changed to an Xpath expression that evaluates to a boolean

Steven: both target and targetid are called away.
... how about "to"?

Roland: fine with me.

<Steven_> <dispatch name="DOMActivate" to="#foo"

Steven: OK?

Roland: let's check how much left.

<oedipus> ok by me

Steven: we did not resolve hint label and help.
... as a child of action.
... XForms does not do that.

<oedipus> i gave +1 to your proposal, steven

Steven: but we could.
... role is global attribute.

Roland: rather than xh:role..

Steven: two seperate modules, language designers will combine if necesary.
... event cancelable or not is defined where the event is defined.

<markbirbeck_> swdwg has just voted that rdfa should go to last call. :)

<Steven_> Woh!

<Steven_> Congrats all round!

<Steven_> Unfortunately we resolved today that it is not yet ready

<ShaneM> I will prepare a formal WD for publication. Who is sending the publication request?

<Steven_> ha ha

<markbirbeck_> lol

<Steven_> Good question. I suppose it needs to be a joint request

<Roland_> the destid attribute should be changed to "to"

Roland: addEventListener has four attributes, not described.
... 4.5 removeEventListener has similar problems.

Shane: they are all global, not duplicating.

Roland: just to make it helpful, to describe attributes.

Shane: addEventListener uses attributes(global attributes from Listner element).
... but not disagree, add them here.

<ShaneM> ACTION: Shane to ensure that all listener events are shown on all elements in the Handler module. [recorded in http://www.w3.org/2008/02/19-xhtml-minutes.html#action05]

Steven: it is done for today.

(because it is Steven's birthday)

<Steven_> Prosecco!

<oedipus> buon compleanno, steven -- goda il vostro pranzo!

<Steven_> Gracie

Roland: we will discuss some more comments on XML Event 2 tomorrow morning (3 comments).

<Steven_> Grazie

<Steven_> (From JohnB)

<oedipus> good night, grazie <wink>

<gshults> Happy Birthday, Steven. Please survive the night to return and participate tomorrow!

We have to survive.

<Steven_> If I must

<ShaneM> publication target date for rdfa-syntax is thursday

<oedipus> congrats

<Steven_> OK

<Steven_> Where do the rdfa comments get sent to?

<Steven_> html-editor?

<ShaneM> yes

<ShaneM> err..... I think so

<ShaneM> Ralph is doing pub request

<Steven_> Oh, then I will stop doing it

<Steven_> :-)

<Steven_> great

<ShaneM> thanks!

<Steven_> does he have the URL of our decision to go to last call?

<ShaneM> he should.

<ShaneM> no worries. I can find it if not

<Steven_> tx

XHTML Basic 1.1

<Steven_> scribe: Steven

<Steven_> Steven: I have had a message from Steve Brattt that he is OK with our option 1 (to accept a single implementation of inputmode).

<Steven_> ... so we can move to PR quickly

- DRAFT -

XHTML2 WG FtF, Venice, Italy, Day 2

19 Feb 2008

Attendees

Contents

Role (brief return)

Yesterday refresh (xFrames)

XML Events 2

XHTML Basic 1.1

Summary of Action Items

Scribe.perl diagnostic output