See also: IRC log
<trackbot> Date: 26 June 2013
<scribe> Scribe: Nick
<scribe> Agenda: http://lists.w3.org/Archives/Public/public-forms/2013Jun/0018.html
http://lists.w3.org/Archives/Public/public-forms/2013Jun/0015.html
nvdbleek: Had anybody time to review it already?
ebruchez: I send in some comments
... 1. The reference to Core Form Controls was in the source but didn't
show. I fixed it.
ebruchez: 2. "the IDREF may not uniquely identify the desired dialog if the
dialog element bearing the matching ID resides in a repeating
construct such as element repeat" however we say the element is a
"top level container form control".
ebruchez: We talk about the ID resolution, but it needs to be a top level element
... So we shouldn't talk about ID resolution
ACTION nvdbleek Remove note about ID resolution in show/hide elements because it is not needed the dialog element is a top level element
<trackbot> Created ACTION-1952 - Remove note about ID resolution in show/hide elements because it is not needed the dialog element is a top level element [on Nick Van Den Bleeken - due 2013-07-03].
ebruchez: 3. Since `xf:dialog` is new, do we want to support `xf:show/xf:dialog`, since we have AVTs?
... We are deprecating child elements, so we shouldn't add xf:dialog child elements for show/hide elements
ACTION nvdbleek remove dialog child element for show/hide element
<trackbot> Created ACTION-1953 - Remove dialog child element for show/hide element [on Nick Van Den Bleeken - due 2013-07-03].
ebruchez: 4. It would be convenient if `xf:dialog/@dialog` was indeed optional, but would resolve, when possible, to the enclosing dialog.
... the attribute is optional because it also supported the dialog child element
... We could make the dialog attribute optional on the hide to hide the parent dialog element
nvdbleek: I'm note sure because it makes no sense on the show action
ebruchez: We don't this for recalculate either
... (to specify the model, the model is mandatory)
nvdbleek: ebruchez would you like to be dialog optional on hide
ebruchez: It would be convenient, but it is not symmetrical
... Let's wait a bit for this one
... I know it is a use case
... I'm rather in favour of making dialog attribute optional on hide
... It is similar to the toggle action
<ebruchez> but the toggle action is more like xf:show, so that's not helping
nvdbleek: I'm not sure, but on the other hand who will omit the dialog attribute on show
ebruchez: 5. Minor edits. [1] I wanted to do more, but some of the funny wording is used by group and switch too. I think readers are familar with the notion of a dialog, so I simplified a bit.
... It is weird, but the wording is used other group controls too
... 6. I had suggested `xforms-dialog-shown` and `xforms-dialog-hidden` as notification event names [3]. Right now, the text has `xforms-dialog-show` and `xforms-dialog-hide` as events dispatched by the action. One issue is: what happens with the dialog's "hide" button when present? There has to be a way to know that the dialog was hidden. Should we say that the button dispatches `xforms-dialog-show`? And/or should we have both show/hide and shown/[CUT]
one being the event for the action, the other one the event dispatched to the dialog when it is effectively opening/closing?
ebruchez: There are two type of events:
... 1) dispatched by the action to open and close dialogs by the action
... 2) Notification events (to know when a dialog is opened or about to be closed)
... With the notification events you can for example copy some data
... I suggested notification elements
... The current events are cancellable so you can't listen for the events to be sure if the dialog is opened/closed
nvdbleek: I think we need the notification events
ebruchez: In our implementation the events aren't cancellable
nvdbleek: Doesn't it makes sense to be able to cancel the hide event (e.g.: prevent the dialog from disappearing till a certain condition is met)
ebruchez: It would be weird if you have a close button on your dialog and hitting it won't close the dialog
... For switch it are notification events
... I'm not convinced we need the actions to perform the action
... The most versatile approach is to have 4 events
nvdbleek: Then xforms-dialog-hide will dispatch xforms-dialog-hidden in its default action
… xforms-dialog-show will dispatch xforms-dialog-shown in its default action
scribe: and xforms-dialog-hidden and xforms-dialog-shown are notification events (not cancellable)
ebruchez: You want the xforms-dialog-hidden event to be called just before it is hidden, otherwise the content won't be relevant
... I will send a message to the group about this
... 7. We had a question of what to do when the dialog becomes non-relevant, but I think that goes away as right now we say the dialog is only a top-level element.
nvdbleek: I'm quite sure there is no binding, we removed this quite some time ago
ebruchez: that's good for the dialog then
http://lists.w3.org/Archives/Public/public-forms/2013Jun/0017.html
nvdbleek: I've reviewed the change, and I think it is OK
ebruchez: I pointed to the W3C version of HTML5 for the explanation of how to handle the accept attribute
alain: It's ok for me
http://lists.w3.org/Archives/Public/public-forms/2013Jun/0010.html
nvdbleek: We discussed this last time
ebruchez: I have a few action items todo
This is scribe.perl Revision: 1.137 of Date: 2012-09-20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/hiden/hidden/ No ScribeNick specified. Guessing ScribeNick: nvdbleek Found Scribe: Nick Default Present: nvdbleek, pfennell, ebruchez, [IPcaller] Present: nvdbleek pfennell ebruchez [IPcaller] Regrets: Steven Uli Agenda: http://lists.w3.org/Archives/Public/public-forms/2013Jun/0018.html Found Date: 26 Jun 2013 People with action items:[End of scribe.perl diagnostic output]