IRC log of xhtml on 2008-02-19

Timestamps are in UTC.

08:09:44 [RRSAgent]
RRSAgent has joined #xhtml
08:09:45 [RRSAgent]
logging to
08:10:01 [Steven]
rrsagent, make log public
08:10:22 [Steven]
Meeting: XHTML2 WG FtF, Venice, Italy, Day 2
08:10:35 [Steven]
Chair: Roland, STeven
08:10:39 [Steven]
Scribe: Steven
08:11:45 [Steven]
08:12:42 [Steven]
.me 12.30ish
08:19:03 [Steven]
08:27:11 [yamx]
yamx has joined #xhtml
08:27:34 [alessio]
alessio has joined #xhtml
08:30:10 [Steven]
rrsagent, make minutes
08:30:10 [RRSAgent]
I have made the request to generate Steven
08:30:55 [Steven]
08:31:23 [Steven]
Present: Roland, Alessio, Rich, Yam, Steven, Shane
08:32:18 [oedipus]
present+ Gregory
08:33:27 [Steven]
I was just about to thank you
08:33:36 [oedipus]
no need
08:41:22 [Steven]
Topic: Frames (brief return)
08:41:35 [Steven]
Scribe: Yam
08:41:43 [Steven]
scribenick: yamx
08:42:17 [yamx]
Steven: Brat will review M12N modularization transition request.
08:42:57 [yamx]
Steven: Brat asked about XHTMLBasic 1.1 (but it is not delayed from M12N from our perspective).
08:43:14 [yamx]
s/from M12N/by M12N/
08:44:09 [Steven]
08:44:28 [OedipusWrecked]
OedipusWrecked has joined #xhtml
08:44:32 [yamx]
Shane: an issue for Role.
08:45:04 [yamx]
Shane: I would like to capture the resolution correctly.
08:46:07 [yamx]
Rolan: It SHOULD have dereferenceable, and one of them should be RDF.
08:46:14 [yamx]
08:46:51 [yamx]
Steven: we added "some is beyond the scope of role (it is vocab issue)".
08:46:57 [yamx]
Roland: Another vocabulary.
08:47:25 [yamx]
Roland: yesterday of action is action for Roland to reply to the guy raising the original issue.
08:47:41 [yamx]
Roland: Leave the action for Roland.
08:48:11 [yamx]
Roland: we talked xFrames, equivalent iFrame.
08:48:43 [yamx]
Topic: Yesterday refresh (xFrames)
08:50:19 [Steven]
<frame xml:id="one"/>
08:50:22 [yamx]
Steven: Populating URI with ids, and extends to XHMTL2.
08:50:30 [Steven]
08:51:03 [Steven]
So we could say that this works for XHTML2 as well
08:51:06 [yamx]
Roland: We will retain the notion of subclases of object like iFrame, src value matching.
08:51:18 [Steven]
and the URI replaces the src attribute
08:51:37 [Steven]
on the element that matches the id
08:51:59 [yamx]
Roland: Could we do the sme thing to document?
08:52:41 [yamx]
Steven: question is matching with id, not match src attribute, do we create one?
08:53:22 [yamx]
Steven: Replacing can lead to some unintended security risk.. just thinking...
08:54:45 [yamx]
Roland: thinking about killing three birds in one stone, bookmarking, frame flow, ...
08:55:01 [yamx]
Steven: going for some flipchart to think about it.
08:55:57 [yamx]
(Steven went out for flipchart)
08:56:18 [yamx]
s/going/I am going/
08:56:37 [yamx]
s/for/, seeking for/
08:57:07 [yamx]
(Steven returned with a flipchart.)
08:57:46 [yamx]
Steven: [[summarizing frame requirements]]
08:58:57 [yamx]
Roland: maybe some attributes to distinguish "replace-able", "bookmark-able" srcs.
08:59:51 [yamx]
Shane: it may resolve many comments we received about people's concerns what content can be covered.
09:00:33 [yamx]
Roland: "static" and "iframe-type-src (replace-able)".
09:02:09 [yamx]
Roland: Ability to change (bookmark, if changed, it is reflected as URL).
09:02:46 [yamx]
Rich: changing the value will automatically refresh?
09:03:07 [yamx]
Rich: We have to think about scripting environment.
09:03:29 [yamx]
Roland: Does the page automatically reloaded when managed by scripts?
09:03:37 [yamx]
09:04:12 [yamx]
Roland: Default action is reload, but it can be cancellable.
09:04:41 [yamx]
Roland described body-object-iframe on flipchart.
09:05:03 [yamx]
09:05:15 [yamx]
<object src="myStuff.smil" />
09:05:30 [yamx]
<iframe id="f2" srcc="myStuff.html" />
09:05:32 [yamx]
09:05:46 [yamx]
09:06:23 [yamx],...)
09:07:02 [yamx]
Roland: bookmark will go to "myStuff.html".
09:07:35 [yamx]
Steven:"src(f2=myotherstuff.html, ..); Roland agreed.
09:07:57 [yamx]
09:08:56 [yamx]
Steven: the resulting URl is not changed from <object> use.
09:09:27 [yamx]
Roland: the first one can be <div> (not only <object>).
09:10:31 [yamx]
Roland: "target" as "iframe"...
09:11:19 [yamx]
Steven: Frame does not have "id", it is not bookmarkable.
09:12:03 [yamx]
Roland: bookmarkability, inline capability, fall-back capability, flow, ...
09:12:29 [yamx]
Rich: some next step issues, widgets, ...
09:13:20 [yamx]
(Pens arrived for scribing flipcharts.)
09:13:40 [ShaneM]
(Prior to this scribing in blood - dedicated group!)
09:13:58 [yamx]
(We are blood-tied-group)
09:15:36 [Roland_]
Roland_ has joined #xhtml
09:15:39 [Roland_],f1=img.jpg...)
09:15:39 [Roland_]
09:15:39 [Roland_]
<div id="f1" role="navigation" src="nav.html" />
09:15:41 [Roland_]
<iframe id="f2" role="main" src="myStuff.html" />
09:15:43 [Roland_]
09:16:11 [Steven]
Rules: If there is no @src, then there is no assignment
09:16:35 [Steven]
... changes in an iframe get reflected in the top-level URL
09:18:38 [yamx]
Roland: We will think if we come down anything more this afternoon.
09:19:07 [Steven]
Shane: We need to run this past Mark who has a similar mechanism in his implementation
09:19:54 [yamx]
Roland: Id, embed content, iframe content itself id duplicate, any qualifying identification. Things arise..
09:25:45 [yamx]
Steven: talking with Shane to clarifying document-load-event (image loading is not complete).
09:26:38 [Steven]
The question is: is the *document* ready after or before all the <div src=..>s are ready
09:26:51 [Steven]
DOes it act like img does now, or not
09:27:13 [Steven]
09:27:25 [oedipus]
shouldn't it act as OBJECT was intended?
09:27:26 [yamx]
Shane: Scripting should be executed inline?
09:27:52 [yamx]
Steven: Declarative.
09:28:16 [yamx]
Steven: Probably executed, but not during parsing.
09:28:38 [Steven]
s/executed/executed in document order/
09:29:02 [Steven]
SHane think that document ready occurs *after* all the sub documents are ready
09:29:18 [Steven]
.... they are very different from images, which do not have presence in the DOM
09:29:25 [Steven]
09:30:49 [Steven]
Alessio: I just tried some iframes in current borwsers and the dub documents in an iframe get executed script and all as you would expect
09:30:59 [Steven]
09:31:09 [Steven]
09:31:43 [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?
09:33:18 [Steven]
good question
09:33:25 [yamx]
Roland: IT is something we have to sort out.
09:33:33 [yamx]
09:33:53 [alessio]
I'm trying to do it in the parent document now, shane
09:34:17 [alessio]
but the security issues remain, naturally
09:35:01 [yamx]
(coffee break, a point of success.)
09:35:49 [yamx]
Roland: next agenda after coffee break will be "longdesc".
09:36:23 [Steven]
we are off to the cafe for a coffee Gregory
09:45:01 [Lachy]
Lachy has joined #xhtml
09:56:51 [oedipus]
thanks steve
10:00:31 [oedipus]
Equivalent Content for Images (HTML wiki page by GJR):
10:06:57 [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):
10:07:00 [Steven]
Did you write all that page Gregory?
10:07:22 [oedipus]
i wrote most of it, and then added comments and proposals by others, but, yeah, that's my baby
10:08:04 [Steven]
Do you list Google (or search engines) as a consumer of alternate content?
10:08:56 [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.
10:09:05 [Roland_]
Roland_ has joined #xhtml
10:09:23 [Rich]
Rich has joined #xhtml
10:09:39 [oedipus]
steven, yes, there is discussion of search engines and flickr-type sites on the page (it is quite a long page)
10:10:19 [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
10:11:32 [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)
10:12:07 [yamx]
yamx has joined #xhtml
10:12:13 [oedipus]
long ugly wiki uri on exposition options:
10:12:14 [oedipus]
10:12:22 [Steven]
The reason that longdesc has failed to date is that it is too difficult to do, keeping parallel documents
10:12:57 [oedipus]
that and a lack of support and freaky implementation -- JAWS opens longdesc in a new pop-up window, which pop-up blockers block!
10:13:14 [Steven]
The HTML5 groups has the disadvantage of having to be backwards compatible
10:13:39 [Steven]
We can adopt better solutions, for instance by allowing img to have content
10:13:45 [Steven]
10:13:56 [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
10:14:31 [oedipus]
IMG as a container would be a consummation devoutly to be wished
10:14:49 [oedipus]
OBJECT is my preferred solution, only it is broken
10:15:17 [Steven]
Actually in XHTML2 all elements behave like object.
10:15:30 [oedipus]
that's why i joined the WG!!!
10:15:31 [Steven]
<div src="whatever">fallback<.div>
10:15:45 [Steven]
good on yer Gergory!
10:15:51 [oedipus]
10:16:27 [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
10:18:38 [oedipus]
to quote myself from the page:
10:18:40 [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
10:18:40 [oedipus]
* expose in new browser instance
10:18:40 [oedipus]
* expose in new browser tab
10:18:41 [oedipus]
* expose inline (insert content as object)
10:18:43 [oedipus]
* expose inline through the use of IFrame
10:18:45 [oedipus]
* expose the contents of the longdesc document in a side-bar,
10:18:47 [oedipus]
aligned with the image it describes
10:18:49 [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
10:20:01 [oedipus]
GJR notes that some of the best examples of LONGDESC are in CSS 2.0 -- 46 longdescs in all!
10:20:18 [yamx]
Shane: "longdesc" attribute is available even when src does not fail.
10:20:54 [oedipus]
right: it isn't necessariliy an either/or proposition -- some user groups need guidance through an image
10:20:55 [yamx]
Steven: "longdesc" is the content of element, we don't need "longdesc" attr.
10:22:00 [Steven]
10:22:06 [oedipus]
GJR: point of reference -- are we discussing M12N section 5.7 "Image Module"
10:22:13 [yamx]
Shane: once resource is obtained, the rest of content is not processed.
10:22:23 [yamx]
Steven: a question: not processed or not presented?.
10:22:35 [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.
10:23:44 [ShaneM]
10:24:15 [yamx]
Shane: I did not look into public version.
10:25:52 [yamx]
Shane: Issue persists. What happens content nested after a document is resolved?
10:26:00 [Steven]
I think that the alternate text is in the DOM
10:26:11 [Steven]
... I think we can define the behaviour with CSS
10:26:26 [Steven]
.... in fact I'm sure that Jonny Axellsson once demonstrated that
10:26:33 [oedipus]
it should be in the DOM so it can be reused/accessed by assistive technology/regular users
10:26:33 [Steven]
10:27:12 [Steven]
ACTION: Steven to add text to embedding module saying how it works
10:29:27 [Steven]
Rich says we need some events that say what happens
10:29:35 [Steven]
... load when a src works I think
10:29:47 [Steven]
10:30:37 [Steven]
Steven: What should you get if the src fails though?
10:31:11 [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
10:32:01 [yamx]
Steven: reasons for src failing: (1) network down, (2) 404 or similar.
10:34:11 [yamx]
Steven: reviewed error code 406 for HTTP.
10:35:05 [yamx]
Roland: you did not get any event in image load finished.
10:36:15 [yamx]
Roland: DOM3 have anything different.
10:37:33 [yamx]
s/have/don't have/
10:38:03 [yamx]
Steven: DOM went to WebAPI, Rich.
10:39:01 [yamx]
Stenven: DOM3 said images are loaded before you get load event.
10:39:10 [Steven]
"The DOM Implementation finishes loading the resource (such as the document) and any dependent resources (such as images, style sheets, or scripts). "
10:39:18 [Steven]
10:40:17 [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.
10:41:43 [yamx]
Roland: Let's see new charter for WebAPI to check DOM3s...
10:42:05 [Steven]
10:42:09 [Steven]
minutes of a recent call
10:42:47 [Steven]
Zakim: leaving. As of this point the attendees were Carmelo, Andrew_Emmons, anne, shepazu
10:45:36 [yamx]
Shane: DOM3 Events use qnames?
10:46:53 [yamx]
Roland: no search result for qname.
10:47:01 [yamx]
Steven: BUt they have namespaced events.
10:47:10 [Steven]
10:48:49 [yamx]
Roland and Steven: We don't need "longdesc" attr. Stenven will add clarifying text for embedded context. (already ACTION for Steven)
10:49:07 [yamx]
10:49:52 [yamx]
Roland: alternative to src.
10:50:13 [yamx]
Steven: Added (3) images switched off, at flipchart.
10:51:13 [yamx]
.. after (2) 404/406 or similar.
10:54:52 [Steven]
In css, you say img[src] {content: attr(src)}
10:55:29 [Steven]
so in principle you can switch between displaying the image and the content
10:55:51 [oedipus]
GJR: that "principle" needs to be explicitly stated
10:55:52 [Steven]
(but the CSS doesn't give you control over @srctype)
10:56:28 [Steven]
In any case the alternate content is in the dom, so is available for use as necessary
10:56:45 [oedipus]
10:57:26 [yamx]
Steven: poping stack for a few levels, back to "longdesc".
10:57:56 [yamx]
Roland: how we can style both?
10:58:58 [yamx]
Steven: in CSS, content: means replacement with external resource. (Stven went to flipchart to argue)
10:59:10 [yamx]
11:02:34 [yamx]
Roland: CSS cannot do fallback at failure.
11:03:06 [yamx]
Steven: *[src]:error, you can invent pseudo-class in that case.
11:03:40 [yamx]
Steven: We don't know it is allowed, but let's assume it allowed...
11:04:13 [yamx]
Steven: *[src]:before
11:04:27 [yamx]
Steven: {content: attr(src)}
11:04:41 [yamx]
Steven: *[src]{display:none}
11:04:55 [yamx]
Steven: body.nosrc *[src] {display:blank}
11:05:07 [yamx]
Steven: body.nosrc *[src]:before
11:05:14 [yamx]
Steven: {content: ""}
11:05:26 [yamx]
Steven: *[src]:error
11:06:18 [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
11:06:19 [yamx]
Steven described an error case with src="foo.xdiv" srctype="vide/xdiv"
11:09:19 [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.
11:12:33 [yamx]
Roland: we will talk XML Event 2 after lunch break.
11:12:56 [yamx]
s/Event 2/Events 2/
11:13:54 [oedipus]
when will we resume? how much time are you breaking for lunch?
11:14:45 [Steven]
11:15:32 [Steven]
Gregory, I expect lunch will be an hour
11:16:43 [oedipus]
thanks - now if only i had a left-over canoli (sp?) to eat for breakfast...
11:16:52 [Steven]
Gregory, wrt your content: question
11:17:03 [oedipus]
11:17:10 [Steven]
I didn't put any real content there
11:17:16 [Steven]
in one case it is the embedded image
11:17:40 [Steven]
in the other case, the embedded image is overwritten with 'nothing' (empty string)
11:17:46 [Steven]
the dom remains the same in both cases
11:17:55 [Steven]
(I think)
11:18:18 [Steven]
and the DOM contains the URL of the image, and the alternate content, both of which reside in the DOM without change
11:18:33 [oedipus]
do you think the UAAG2 req unreasonable?
11:18:40 [Steven]
and so is accessible to any software that wants to make use of it
11:18:47 [oedipus]
11:19:14 [Steven]
I have no problem with the UAAG2 requirement
11:19:26 [oedipus]
that's certainly good to hear
11:19:40 [Steven]
In fact it is a pain when you copy a numbered list, and don't get the numbers in the copy buffer
11:19:40 [oedipus]
the tricky bit is wording it correctly
11:19:55 [Steven]
because of the generated content problem
11:20:26 [yamx]
Rich: Guideline for browser for markup?
11:20:30 [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
11:20:45 [yamx]
Shane: we provided default CSS for XHMTL2.
11:20:52 [Steven]
But for instance Gergory, XForms which also generates content, amongst other places via repeats talks of a shadom tree (or DOM)
11:20:58 [Steven]
so you have two DOMs
11:21:17 [oedipus]
that's the tricky bit UAAG is trying to deal with -- multiple DOMs
11:21:18 [yamx]
Shane: Browser people complained "don't constrain browsers".
11:21:20 [Steven]
11:21:55 [oedipus]
browser people are always complaining -- just like their users!!!
11:22:59 [Steven]
11:23:16 [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
11:24:18 [yamx]
Shane: I have an action item to turn OWL into RDFa.
11:24:27 [yamx]
.. at the end of role spec.
11:24:33 [Steven]
ack that Gregory
11:25:23 [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
11:26:03 [yamx]
Steven: at the end of vocab, RDFa is readable for human and machine, everyone happy.
11:26:18 [ShaneM]
Creative Commons stuff in RDFa:
11:26:59 [yamx]
Lunch break.
11:27:37 [Steven]
Pity that they use the wrong DOCTYPE. Otherwise COOL!
11:28:43 [yamx]
(we really go to lunch, now...)
11:28:45 [oedipus]
goda del pranzo, tutto
11:29:07 [ShaneM]
ShaneM has left #xhtml
12:11:49 [oedipus]
oedipus has joined #xhtml
12:21:45 [ShaneM]
ShaneM has joined #xhtml
12:24:22 [OedipusWrecked]
OedipusWrecked has joined #xhtml
12:54:10 [myakura]
myakura has joined #xhtml
13:16:17 [Steven]
back finally
13:16:30 [Steven]
sorry, slow service
13:16:38 [oedipus]
no comment...
13:19:12 [yamx]
yamx has joined #xhtml
13:19:21 [yamx]
(People are back from Lunch)
13:22:46 [Steven]
rrsagent, make minutes
13:22:46 [RRSAgent]
I have made the request to generate Steven
13:22:59 [Steven]
Present+Simone Onofri
13:24:28 [Steven]
13:24:50 [ShaneM]
Mark sent belated regrets for today. I have not yet determined if he might be available tomorrow.
13:25:30 [oedipus]
Shane, thou art the bearer of bad news, but since i took a vow not to shoot the messenger...
13:26:17 [Steven]
RDFa is rather eating up his time
13:27:04 [Steven]
shane, ringing
13:27:05 [oedipus]
but it tastes SO GOOD
13:27:50 [Steven]
shane? ShaneM?
13:28:40 [Steven]
Simone is an IWA member
13:28:49 [Steven]
... and a member of SWD
13:29:21 [Steven]
... and is involved with RDFa
13:29:57 [Steven]
... attends the RDFa calls
13:30:39 [yamx]
Topic: XML Events 2
13:30:53 [oedipus]
q+ to ask question via IRC
13:30:54 [Roland_]
13:31:07 [Steven]
ack oedipus
13:31:09 [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:
13:31:09 [oedipus]
13:31:09 [oedipus]
13:31:09 [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
13:31:38 [Simone]
Simone has joined #xhtml
13:32:43 [ShaneM]
cant we just use "role" for that Gregory?
13:33:12 [oedipus]
13:33:17 [oedipus]
13:33:28 [yamx]
Roland: I have a suggestion, found in a thread...
13:33:33 [Roland_]
I commented on this topic a while ago:
13:33:48 [oedipus]
thanks for pointer - am checking
13:35:01 [oedipus]
roland, i am intrigued by your ideas, and would like to subscribe to your newsletter...
13:35:16 [Steven]
Another two long pages for us to digest Gregory :-)
13:35:23 [oedipus]
seriously, you raise an excellent point
13:35:33 [oedipus]
steven, i guess i speed listen
13:36:08 [yamx]
Shane: Purpose disapeared thanks to "role".
13:36:57 [yamx]
Roland: adding info for human is complementary.
13:37:38 [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)
13:38:09 [oedipus]
it doesn't tell anything human or machine parseable, is what i mean
13:38:40 [ShaneM]
well - @role should be machine parseable. human readable is another, potentially important area
13:39:24 [Rich]
Rich has joined #xhtml
13:39:32 [Steven]
Gregory, how do you see the purpose element being used in accessible software?
13:40:55 [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)
13:41:42 [oedipus]
it is specialized middle-ware that will rely on OWL or RDF, most likely (er, if i had my way)
13:42:13 [Steven]
So if a handler had a label element (for instance), that briefly described the purpose, is that enough?
13:42:21 [oedipus]
13:42:25 [oedipus]
what does rich think?
13:42:37 [Steven]
He just said "That'll work"
13:42:45 [oedipus]
i think so to
13:42:49 [oedipus]
13:43:09 [yamx]
Roland: talked about xForms, hint, label, and role.
13:43:57 [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
13:45:14 [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
13:46:47 [yamx]
Shane:table discussion does not relate to event handler.
13:46:48 [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
13:47:08 [oedipus]
ok, i'll get off my high horse, shane...
13:47:30 [Steven]
(Shane's comment was an explanation, not a complaint)
13:48:04 [oedipus]
should have added a <wink>
13:48:39 [yamx]
Shane: separate module, scope event, qname in DOM3. that leading to this, Roland.
13:49:13 [yamx]
Roland: DOM Level 2 interface, rather than Level 3.
13:49:42 [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
13:51:32 [yamx]
Steven: We originally put script only when it does not support following name spaces.
13:51:53 [yamx]
.. for legacy cases.
13:52:12 [ShaneM]
This might be useful for understanding what is different:
13:52:20 [yamx]
(Steven wrote an example for script element in a flipchart.)
13:52:44 [oedipus]
yam, you are doing an EXCELLENT job of minuting
13:53:16 [yamx]
thank you.
13:53:28 [oedipus]
thank you!
13:53:57 [yamx]
<script src="xhtml.js" type="...." implements="Ns URI" />
13:54:26 [yamx]
Steven: should we put into XHMTL2 or hander spec?
13:55:02 [oedipus]
can i raise both hands?
13:55:09 [Steven]
So I propose adding in XML Events 2 <script src="xforms.js" type="..." implements="... NS URI ..." />
13:55:18 [yamx]
13:55:34 [oedipus]
i think that would work, steven
13:56:03 [Steven]
@implements tells the system that if they have an implementation of that NS, ignore this scrpt
13:57:32 [Steven]
Shane: We can also do that with an @if that checks HASFEATURE
13:57:56 [Steven]
... so @implements is then a shorthand
13:58:25 [gshults]
gshults has joined #xhtml
13:58:47 [Steven]
13:58:54 [oedipus]
that makes sense to me (which should alarm you, steven!)
13:58:55 [gshults]
Good morning
13:59:00 [yamx]
Roland: this XML Events 2 defines two modules (events, handler).
13:59:10 [Steven]
Shane will skype you Gerrie
13:59:15 [Steven]
to save bandwidth at this end
13:59:17 [gshults]
13:59:41 [oedipus]
14:00:16 [Steven]
Yam: I have a minor comment
14:01:25 [yamx]
Yam: new version of HTML in "introduction" is umbiquious now. To XHTML.
14:01:26 [Steven]
... we should s/a new version of HTML/a new version of XHTML/ in the intro
14:02:56 [yamx]
Yam: All XML applications in W3C follows this "XML Event 2"?
14:03:09 [yamx]
Steven: Yes.
14:03:38 [yamx]
14:03:58 [Steven]
Not all XML applications use it, though they all could (if they use DOM Events)
14:04:50 [yamx]
Steven: In the past, some groups mentioned they had some special requirements, but no, they had a same problem.
14:06:34 [yamx]
Roland: Introduction needs updating, covering handerls.
14:06:38 [Steven]
... which was that parts of the DOM tree can be unavailable at times
14:06:43 [yamx]
14:06:48 [ShaneM]
ACTION: Shane to update intro to XML Events to reflect its current scope of Handlers and Events.
14:06:59 [Steven]
... and when the part of the tree is unavailable, they musn't generate events, nor handle them
14:08:22 [yamx]
Steven: XHTML2 says that it uses XML Events 2. XML Events 2 will decide whether DOM2 or DOM3 event.
14:09:30 [yamx]
Roland: fall-back is in XHTML2.
14:10:02 [yamx]
Roland: DOM2 did not have load error.
14:10:18 [Steven]
It sounds like we need DOM3 events since it has the new-style load event, and the error event
14:10:54 [yamx]
Roland: how about just put a note in XHTML2.
14:11:47 [yamx]
Roland: put a note in XML Event 2.
14:12:41 [yamx]
Shane: It says DOM2 and qname in the current spec.
14:13:03 [yamx]
Steven: last week, Form group met.
14:13:15 [yamx]
... hopefully seriously going, now.
14:13:38 [yamx]
Roland: propose to switch for DOM 3 Event.
14:15:00 [yamx]
Roland: let's refer to the last published.
14:15:17 [yamx]
RESOLUTION: XML Event 2 will be based on DOM 3 Event.
14:15:26 [yamx]
14:17:10 [yamx]
Shane: the current DOM 3 spec has how to map qname in DOM2 compatible.
14:18:57 [yamx]
ACTION: Shane to update "Introduction"(HTML->XHTML) and references to DOM3.
14:19:56 [yamx]
Shane: XML Event 1 shortname will result in the same doc..
14:20:42 [yamx]
Roland: no suffix, XML Event shortname.
14:21:46 [yamx]
Roland: green part, chameleon namespace at the end of 2.1 Document Conformance.
14:22:49 [yamx]
Shane: conceptually supercedes any markuplanguage. implementers can magically deal with. That is an issue.
14:23:03 [yamx]
14:23:51 [yamx]
Shane: It is Mark's issue, he is not here.
14:24:09 [yamx]
s/markuplanguage/markup language/
14:26:10 [yamx]
Roland: regardless of markup language, general processor does. built-in does.
14:26:39 [yamx]
Roland: we are not sure about what the implications are for implementors.
14:27:45 [yamx]
Roland: do we have proforma text, highlighting features for asertions?
14:27:52 [yamx]
14:28:40 [yamx]
Roland: machine extracting assertiosn for conformance testing, it is not available now.
14:29:44 [yamx]
Roland: proforma text, it will be dealt separately.
14:29:48 [ShaneM]
new shortname should be xml-events2 whilst we are developing.
14:32:21 [yamx]
Shane: we need xml id in an explicit way? Steven?
14:32:48 [yamx]
Steven: We definitely need it.
14:34:27 [yamx]
Roland: default action, can we stop it? decision in listner?
14:34:50 [yamx]
Shane: we have it in handler section.
14:35:26 [yamx]
Roland: precedence perform and prevent?
14:35:43 [yamx]
s/precedence/precedence issue,/
14:36:29 [Steven]
We recommend this syntax for latest version URIs:
14:36:40 [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.).
14:36:48 [Steven]
14:37:07 [yamx]
Steven: it is XPath 1.
14:39:38 [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.
14:40:42 [yamx]
Shane: 3.1 Listner element, there is Editor's note, which we deferred.
14:41:00 [yamx]
14:41:20 [yamx]
Roland: URI is in the universe, security risk.
14:42:30 [yamx]
Roland: keep id, for compatibility. Introducing URL later.
14:43:38 [yamx]
Roland: Dispatcher element has target child attribute.
14:45:01 [yamx]
Shane: we defined them in global for target.
14:45:07 [yamx]
(Steven just came back)
14:45:56 [yamx]
Shane: observer can be URI. it is an issue.
14:46:06 [yamx]
14:46:59 [yamx]
Roland: I proposed we create observeuri if we need one.
14:47:10 [yamx]
s/uri/uri attribute/
14:47:24 [yamx]
s/one/one, later/
14:47:49 [yamx]
Roland: I propse the current Editor's note.
14:47:56 [yamx]
14:48:09 [yamx]
s/the current/to remove the current/
14:48:22 [yamx]
Roland: I propose the text as it is (with removing Editor's Note).
14:49:06 [yamx]
Roland: while.
14:49:07 [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.
14:49:28 [yamx]
Steven: Original use case is to repeat it until some condition is satisfied, in XForms.
14:50:22 [yamx]
(Steven went to a flipchart to describe an example for Roland.)
14:51:04 [yamx]
(delete all sort of dates, if they exists out of date nodes...)
14:51:47 [yamx]
<trigger ev:event="DOMActivate"
14:51:56 [yamx]
<label< delete all sort of datels </label>
14:52:16 [yamx]
<actionwhile="exists(outdeated)" <delete node>
14:52:21 [yamx]
14:52:32 [yamx]
s/<actionwhile/<acton while/
14:54:12 [yamx]
14:55:08 [yamx]
Roland: Section 4, table there. action elements say..
14:55:51 [yamx]
Roland: why we repeat the global "id" here. trouble to reconcile..
14:56:48 [yamx]
Steven: Action does, script doesn't, wired.
14:57:03 [yamx]
14:57:48 [yamx]
Roland: put if and while on action and script.
14:58:01 [yamx]
Roland: not having it in listener.
14:58:20 [ShaneM]
<div ev:if="condition">
14:58:26 [yamx]
Shane: not in global attributes, which you can attach to anything.
14:59:13 [ShaneM]
ACTION: migrate @if and @while from listener element to the handler elements
14:59:15 [yamx]
Steven: if refers to action only.
14:59:25 [yamx]
14:59:35 [yamx]
14:59:44 [ShaneM]
s/migrate/Shane to migrate/
15:00:51 [ShaneM]
Shane: is the Basic Profile still useful? Section 3.6
15:02:02 [yamx]
Shane: Yam, do we need mobile profile? From Panasonic request a while ago.
15:02:38 [yamx]
Yam: OMA currently has no plan to cutomize Events, with troubles with DOM2 events and DOM3 events, no more fragmentations or burdens to thnk about.
15:03:58 [yamx]
Yam: restrictions will be good, but we need some good guidance, which we don't come up with now.
15:04:09 [yamx]
15:04:25 [Steven]
I asked Kenneth Sklandler who is an implementor of XML Events on mobile devices.
15:04:29 [Steven]
He said:
15:05:02 [Steven]
"no i do not think it is needed. the normal xml events profile is not too complex for mobile"
15:05:48 [yamx]
Shane: MXL Event 1, expressed DOM2, DOMactivate.
15:05:54 [yamx]
15:06:07 [yamx]
s/expressed DOM2/expressed in DOM2/
15:06:35 [yamx]
Steven: we can use DOMactivate, it is illustrative example.
15:07:15 [yamx]
Roland: XForms, we use DOMactivate.
15:07:25 [yamx]
Shane: overflow.
15:07:53 [yamx]
s/overflow./overflow. which we cannot find/
15:08:28 [yamx]
Roland: we have click, activate. which should be DOMactivate.
15:10:14 [yamx]
Steven: capture, bubble, target. strictly speaking, the figure...
15:10:46 [yamx]
.. capture stops at bubbling. Bubble does not start from target.
15:11:09 [yamx]
Roland: include link to introduction.
15:11:41 [yamx]
Steven: discussing arrows in exact defined meanings.
15:12:01 [yamx]
Roland: showing some definitions in DOM3 Events.
15:12:35 [yamx]
s/Events./Events, to Steven./
15:13:31 [yamx]
Roland: in event interface (1.4) DOM 3 Event.
15:13:41 [ShaneM]
15:13:41 [ShaneM]
The current event is in the target phase, i.e. it is being evaluated at the event target.
15:13:41 [ShaneM]
15:13:41 [ShaneM]
The current event phase is the bubbling phase.
15:13:41 [ShaneM]
15:13:42 [ShaneM]
The current event phase is the capture phase.
15:13:44 [ShaneM]
15:13:53 [Roland_]
Event Interface:
15:14:24 [Steven]
15:14:51 [oedipus]
thanks for pointers
15:15:08 [yamx]
Roland: we have to refer to it, not reproducing them.
15:16:29 [yamx]
.. 1.2 Event dispatch and DOM event flow (in DOM 3 Events)
15:16:49 [Steven]
I don't think I have *ever* needed to use the phase attribute
15:16:56 [Steven]
... the defaults are just right
15:17:44 [Steven]
... but I have no problem with adding a phase="target"
15:17:50 [Steven]
... as John Boyer requested
15:18:05 [Steven]
... or phase="attarget"
15:19:13 [yamx]
Roland: three options, if none specified, default (whatever DOM 3 event) applied.
15:19:17 [yamx]
Steven: Bubble includes target.
15:19:28 [yamx]
Steven: Bubble is default.
15:19:54 [ShaneM]
Just to be clear, what I think you are proposing is: phase ("bubble"* | "capture" | "target"),<br />
15:20:04 [yamx]
Roland: all of better descriptions and diagrams, better than we did.
15:20:18 [ShaneM]
ShaneM has left #xhtml
15:20:26 [ShaneM]
ShaneM has joined #xhtml
15:21:22 [yamx]
Roland: @phase has four values (3 phases + default). "default" is for backward-compatibility.
15:21:52 [yamx]
Roland: No specified, default. default is synonim to "bubble".
15:27:10 [Lachy]
Lachy has joined #xhtml
15:27:29 [yamx]
Roland: WML is little bit out of date in illustration.
15:28:28 [yamx]
Roland: propose 3.5 Event Hander.
15:28:40 [yamx]
Steven: we don't need 3.6.
15:28:43 [yamx]
Shane: both gone.
15:32:48 [Lachy]
Lachy has joined #xhtml
15:33:40 [yamx]
Roland: we found section 4 new things.
15:34:16 [yamx]
Roland: Chameleion to be applied to whole spec.
15:34:46 [yamx]
Roland: back to earlier discussion, hint label and help, part of content?
15:35:00 [yamx]
Roland: any consensus?
15:35:20 [yamx]
Roland: Essentially identical, but we have to doublecheck.
15:35:39 [yamx]
s/identical/identical to XForms/
15:35:51 [Steven]
XForms: action Common, Events, Action Common (Action)+
15:36:30 [Steven]
This module also defines the content set "Action", which includes the following elements:
15:36:30 [Steven]
15:36:30 [Steven]
15:38:34 [Steven]
15:40:14 [yamx]
Steven: some discrepancy from XForms, dispatch and dispatchevent.
15:40:39 [Steven]
Here is dispatch in XForms 1.1:
15:40:40 [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]
15:41:16 [yamx]
15:41:24 [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"
15:41:48 [yamx]
Steven: destid.
15:42:26 [yamx]
Shane: a conf call among Shane, Steven, Mark, over a year ago.
15:43:41 [yamx]
Shane: some collision... we identified.
15:44:01 [yamx]
Steven: I am reluctant to go all this again...
15:44:08 [yamx]
.., but..
15:44:29 [Steven]
<action event="foo"
15:44:37 [Steven]
<action ev:event=="foo"
15:44:45 [Steven]
15:44:54 [yamx]
Steven: equivalent way to same things.
15:45:19 [yamx]
Shane: we prohibit putting both in the same time.
15:46:17 [ShaneM]
<dispatchEvent destid="overthere" targetid="otherhandler">
15:47:13 [yamx]
Shane: do in assistive technology.
15:47:53 [yamx]
Steven: not to handler, dispatch event to elemente, handler is maybe listening.
15:48:03 [yamx]
15:48:50 [yamx]
Steven: Document? Document means root element?
15:49:21 [yamx]
... reading dispatchEvent element.
15:50:04 [yamx]
Steven: this is a syntactic bindint to DOM 3 Event. Let's read DOM 3 Events.
15:51:27 [Steven]
In DOM3 it is:
15:51:32 [Steven]
15:52:11 [yamx]
Steven: destid is required attribute, not optional.
15:52:41 [yamx]
Roland: default works.
15:55:34 [yamx]
Steven: in DOM3, it is method, but here, it is not method in Section 4.
15:55:57 [yamx]
Steven: use "action" insted of "method" in Section 4.
15:56:04 [yamx]
Shane: done.
15:57:31 [yamx]
Shane: current words on destid... does it make sense?
15:58:19 [yamx]
Steven: "otherwise, the event is dispatched to "document". ???
15:59:31 [yamx]
Steven: events should be dispatched to "element" , nowhere to go.
15:59:54 [yamx]
Steven: in root, just hit root element. no other places to go.
16:00:09 [yamx]
s/in root/in root element case/
16:00:31 [yamx]
Steven: describing phases in root element.
16:01:07 [yamx]
Shane: whole bunches of handler in head element?
16:01:51 [yamx]
s/handler in/handlers in/
16:01:59 [yamx]
Steven: load event can only in html and body, nowhere else.
16:02:39 [yamx]
Roland: dispatch in XForms and dispatchEvent in XML Event 2 , quite different attributes...
16:02:53 [yamx]
(Steven went to a flipboard...)
16:02:54 [markbirbeck]
markbirbeck has joined #xhtml
16:03:34 [yamx]
(describing "dispatchEvent" example.)
16:04:43 [yamx]
(highlighting differences between XML Event2 and XForms 1.1)
16:06:40 [Roland__]
Roland__ has joined #xhtml
16:07:40 [yamx]
Steven: cancelable="cancelable" , that's the traditional way of boolean.
16:08:56 [yamx]
<dispatchEvent name="load"
16:09:09 [yamx]
16:09:15 [yamx]
16:09:28 [yamx]
16:09:58 [yamx]
s/cancelable"/cancelable" \/>/
16:10:10 [yamx]
<dispatch name="load"
16:10:17 [yamx]
16:10:29 [yamx]
16:10:34 [yamx]
16:10:43 [yamx]
cancelable="true()" />
16:11:35 [Steven]
Steven has joined #xhtml
16:12:05 [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
16:13:23 [yamx]
s/<dispatch/in XForms 1.1 <dispatch/
16:13:30 [Steven]
And yet I pasted a text above that says we don't
16:13:47 [yamx]
s/<dispatchEvent/in XML Events 2 <dispatchEvent/
16:14:10 [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.).
16:15:21 [ShaneM]
IanJ refered me to this document:
16:15:51 [Roland_]
Roland_ has joined #xhtml
16:16:15 [yamx]
Shane: I will manage this shortname issue.
16:17:46 [Steven_]
Steven_ has joined #xhtml
16:17:55 [OedipusWrecked]
OedipusWrecked has joined #xhtml
16:18:06 [yamx]
Steven: says that we dont need Director(domain lead) approval.
16:18:16 [yamx]
16:19:15 [yamx]
Steven: target is global in our spec, it is a problem.
16:19:46 [yamx]
Steven: we can use name(as in XForms 1.1)
16:20:06 [Steven_]
but we have a problem with @target
16:20:11 [oedipus]
oedipus has joined #xhtml
16:20:26 [yamx]
Steven: I have a sneaking feeling that we talked with XForms group...
16:21:02 [yamx]
Steven: how about "targetid" instaed of "destid", closest possible to XForms 1.1.
16:21:13 [yamx]
16:22:05 [yamx]
Shane: targetid is global.
16:22:21 [yamx]
.. as in Section 3.
16:23:20 [Roland_]
dispatchEvent should be changed to dispatch
16:24:12 [Roland_]
the raise attribute should be changed to name
16:24:40 [yamx]
Shane: targetid means something different in Section 3.
16:25:03 [Roland_]
bubbles attribute should be changed to an Xpath expression that evaluates to a boolean
16:25:21 [Roland_]
cancelable attribute should be changed to an Xpath expression that evaluates to a boolean
16:25:35 [markbirbeck_]
markbirbeck_ has joined #xhtml
16:26:37 [yamx]
Steven: both target and targetid are called away.
16:26:56 [yamx]
Steven: how about "to"?
16:27:09 [yamx]
Roland: fine with me.
16:27:16 [Steven_]
<dispathc name="DOMActivate" to="#foo"
16:27:26 [Steven_]
16:27:49 [Steven_]
rrsagent, make minutes
16:27:49 [RRSAgent]
I have made the request to generate Steven_
16:29:10 [yamx]
Steven: OK?
16:29:20 [yamx]
Roland: let's check how much left.
16:29:23 [oedipus]
ok by me
16:29:41 [Steven_]
Regrets: Tina, Mark
16:30:14 [Steven_]
rrsagent, make minutes
16:30:14 [RRSAgent]
I have made the request to generate Steven_
16:30:22 [yamx]
Steven: we did not resolve hint label and help.
16:30:39 [yamx]
.. as a child of action.
16:30:50 [yamx]
Steven: XForms does not do that.
16:30:58 [oedipus]
i gave +1 to your proposal, steven
16:30:58 [yamx]
Steven: but we could.
16:31:52 [yamx]
Steven: role is global attribute.
16:32:12 [yamx]
Roland: rather than xh:role..
16:32:58 [yamx]
Steven: two seperate modules, language designers will combine if necesary.
16:34:58 [yamx]
Steven: event cancelable or not is defined where the event is defined.
16:35:26 [markbirbeck_]
swdwg has just voted that rdfa should go to last call. :)
16:36:01 [Steven_]
16:36:07 [Steven_]
Congrats all round!
16:36:27 [Steven_]
Unfortunately we resolved today that it is not yet ready
16:36:28 [ShaneM]
I will prepare a formal WD for publication. Who is sending the publication request?
16:36:39 [Steven_]
ha ha
16:36:43 [markbirbeck_]
16:37:07 [Steven_]
GOod question. I suppose it needs to be a joint request
16:37:19 [Steven_]
16:37:49 [Rich]
Rich has joined #xhtml
16:37:59 [Roland_]
the destid attribute should be changed to "to"
16:39:40 [yamx]
Roland: addEventListner has four attributes, not described.
16:39:56 [yamx]
16:40:14 [yamx]
Roland: 4.5 removeEventListener has similar problems.
16:40:37 [yamx]
Roland: they are all global, not duplicating.
16:41:26 [yamx]
Roland: just to make it helpful, to describe attributes.
16:41:40 [yamx]
s/Roland: they are/Shane: they are/
16:43:29 [yamx]
Shane: addEventListener uses attributes(global attributes from Listner element).
16:43:42 [yamx]
Shane: but not disagree, add them here.
16:44:48 [ShaneM]
ACTION: Shane to ensure that all listener events are shown on all elements in the Handler module.
16:45:16 [yamx]
Steven: it is done for today.
16:45:26 [yamx]
(because it is Steven's birthday)
16:45:35 [Rich]
Rich has left #xhtml
16:45:46 [oedipus]
buon compleanno, steven -- goda il vostro pranzo!
16:45:59 [Steven_]
16:46:06 [yamx]
Roland: we will discuss some more comments on XML Event 2 tomorrow morning (3 comments).
16:46:15 [Steven_]
16:46:37 [Steven_]
(From JohnB)
16:46:45 [Steven_]
rrsagent, make minutes
16:46:45 [RRSAgent]
I have made the request to generate Steven_
16:46:48 [oedipus]
good night, grazie <wink>
16:47:08 [gshults]
Happy Birthday, Steven. Please survive the night to return and participate tomorrow!
16:47:22 [yamx]
We have to survive.
16:47:22 [Steven_]
If I must
16:47:49 [ShaneM]
publication target date for rdfa-syntax is thursday
16:47:59 [oedipus]
16:48:43 [Steven_]
16:52:18 [Steven_]
Where do the rdfa comments get sent to?
16:52:23 [Steven_]
16:52:35 [ShaneM]
16:52:40 [ShaneM]
err..... I think so
16:52:45 [ShaneM]
Ralph is doing pub request
16:52:54 [Steven_]
Oh, then I will stop doing it
16:52:55 [Steven_]
16:52:57 [Steven_]
16:53:00 [ShaneM]
16:53:17 [Steven_]
does he have the URL of our decision to go to last call?
16:53:29 [ShaneM]
he should.
16:53:51 [ShaneM]
no worries. I can find it if not
16:54:12 [Steven_]
16:54:51 [ShaneM]
ShaneM has left #xhtml
16:55:43 [Steven_]
Topic: XHTML Basic 1.1
16:55:50 [Steven_]
scribe: Steven
16:56:21 [Steven_]
Steven: I have had a message from Steve Bratt that he is OK with our option 1 (to accept a single implementation of inputmode).
16:56:31 [Steven_]
... so we can move to PR quickly
16:56:41 [Steven_]
rrsagent, make minutes
16:56:41 [RRSAgent]
I have made the request to generate Steven_
17:12:36 [markbirbeck]
markbirbeck has joined #xhtml
17:24:31 [oedipus]
oedipus has left #xhtml
19:33:35 [John_M_Boyer]
John_M_Boyer has joined #xhtml
20:30:16 [markbirbeck]
markbirbeck has joined #xhtml
22:36:47 [Lachy]
Lachy has joined #xhtml
22:43:26 [sbuluf]
sbuluf has joined #xhtml