See also: IRC log
<yamx> The inputmode resolution is OK for me.
<Steven> Scribe: Rich
Steven: we decided to cancel the face to face
because not enough people were coming
... we had only 2 people that signed up.
... we will have our face to face at the Technical Plenary in Cambridge
<oedipus> XHTML2 f2f at Plenary are at same time as HTML WG sessions at plenary
Steven: I want to cover 2 things today for starters
Steven: the forms group agreed the modifiers
can apply to the default script
... it is possible to have the default mode to digits
... the modifiers apply to that default script
... We do not have to change the test suite to match as the test suite
assumes this already
Steven: We did raise the last call to HCG and it was agreed to have a short last call
<scribe> ACTION: Steven move the role document to last call. [recorded in http://www.w3.org/2007/08/29-xhtml-minutes.html#action01]
Steven: the HTCG agreed to a 3 week last call period.
http://lists.w3.org/Archives/Public/public-xhtml2/2007Jul/0037.html
Steven: we agreed to deprecate the profile
attribute. It used to be on the head
... You will find the wording for html 4 is strange. It refers to a single
URI but that user agents can support multiple URIS by having space separated
URIs
... It is better to have the profiles on links
... <link rel=profile .. and then the uri
... What is being asked is that the profile attribute be kept
... It is not clear that he understand that the profile attribute has been
moved but not removed
... I don't know if Hal Halpin understands that.
<myakura> He understood that (when i joined #grddl-wg and talked a bit about that)
Steven: Masataka clarified what we have done in a note but he did not appear to reply.
<Steven> Ah! OK thanks
<myakura> yet he seemed to want xhtml2 to be not compartible w/ the current grddl implementation (i.e. @profile)
Steven: Should we require grddl to only look at
the profile attribute?
... Profile is so obviously better in link. It is much more explicit.
... it benefits him with the entire semantics storing mechanism.
<oedipus> +1 for future-looking profile rather than legacy link & its vagueness
<oedipus> Rich: cleaner with link - in line with whatever else is going on
Steven: Some people believe we should be backward compatible and old markup should still work.
Mark: The thing is for Hal - can you support
both?
... they are processing the document outside the browser
Steven: we should leave it as it is now with
the link rel vehicle until we see a message from Hal
... I will send him a message and see if he responds.
http://lists.w3.org/Archives/Public/www-html-editor/2007JulSep/0011
http://lists.w3.org/Archives/Public/www-html-editor/2007JulSep/0012
http://lists.w3.org/Archives/Public/www-html-editor/2007JulSep/0013
<Steven> Issues with phase attribute in XML Events 2
Steven: discuss this first: http://lists.w3.org/Archives/Public/www-html-editor/2007JulSep/0011
... The comment from John: It is odd that you can handle an event in the
capture phase and you can
handle it in the target+bubble phase, but that you cannot say you only
want to handle the event if it is the target phase only. Note that the
term "target phase" actually does appear
Steven: John is saying we are specifying a syntax that already exists
Mark: We have added things to support DOM 3 events
Steven: John's comment: Moreover, I would like to express the point of view that the proper
default *should* be "target".
Steven: That is not possible either
Mark: Why does he think the output outside a
label gets a value chnage event?
... The output will not get a value change event
Steven: You're right
Mark: I see. When the node change the event bubbles to the root and back down again
Steven: we could look at this in more
detail.
... we could change attributes and things like that but we can't change DOM 2
events.
Mark: We need to look at this.
RESOLUTION: We shall research further
Steven: next 1
... you can't specify the bubble face
... not sure you would.
Mark: I see what he is getting at. Not sure
John is quite right.
... capture goes down just above the target.
<Steven> http://lists.w3.org/Archives/Public/www-html-editor/2007JulSep/0012
RESOLUTION: We reject 1 and 3 and will investigate 2 in more detail on 0011
Steven: If and While are xpath expressions
Mark: Yes
Steven: So it is right that you have to specify how those xpath expressions get eval'd and in what context.
Mark: We did it that way
... Xpath says that part of the function library.
... Not sure this comment is right
<Steven> http://www.w3.org/TR/xml-events/
Steven: This is clearly marked, in red, in the
document
... the comment is wrong and he has missed something
Mark: I think so
... the exact point of section 6 is to do what he is asking for
<scribe> ACTION: Mark to respond to John's comments [recorded in http://www.w3.org/2007/08/29-xhtml-minutes.html#action02]
<Steven> http://lists.w3.org/Archives/Public/www-html-editor/2007JulSep/0013
Steven: This is like shadow trees
Mark: this came up on a call once where John
was asserting that the event registration process should happen very early on
- prior to the unrolling of the template
... there is nothing in the event spec. that says this.
... John says you will get these extra events attached.
Steven: This is his problem and not ours as we
are mapping to DOM events. XForms has an unusual relationship between the
markup and the DOM
... XForms needs to define what happens when they use handlers
Mark: The key thing here:
... in John's comment: Based on having an XML events processor that is
distinct from the XForms
processor, I think we get both, which is unfortunate.
Mark: There is still a bit of a hole. Say it
was an instance element. XForms would define the instance element to prohibit
further processing
... XForms should sayt the content model of this element is just straight
stuff
... We should doing the same thing for repeat and itemset
... There is a problem but it resides with XForms being clearer on
templates
Shane: agree
Steven: agree
Mark: They need to supress the processing until
the right time.
... Our AJAX version would also have this problem
... Each element processes itself ... I am an input so ...
RESOLUTION: This is the Forms group's problem and not something XML Events 2 can cope with
Mark: We need to have itemset and repeat be an instance.
<Steven> http://www.w3.org/2007/08/22-xhtml-minutes#item06
Shane: I thought we were going to put it in and deprecate it?
Steven: we have a distinct request from Dan Connelly to keep HR
Mark: How do we do that?
Steven: We can say we will keep it, keep/deprecate it, or drop it
<oedipus> re: HR - deprecate, deprecate, deprecate; i've asked HTML WG to adopt LS (logical seperator) similar to XHTML2's selector, but was told that is the realm of XHTML2, not HTML
Shane: We should not remove the legacy module. We keep it in legacy
Steven: We could put profile in legacy as
well
... like in xhtml 1.0, we created 2.0 and then a 2.1 that dumped things we
did not want
... this seems to upset Dan and Tim
Gregory: We should have a logical separator.
Shane: I reserve the right to craft the text for the HR section
<oedipus> +1 to put HR in legacy module
RESOLUTION: Keep HR in the legacy module and make HR deprecated
http://lists.w3.org/Archives/Public/www-html-editor/2007JulSep/0015
From the link: At
http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_bdomodule
, the attribute listed as Core mistakenly links to "Common". Also, "bdo"
should allow "xml:lang" per the DTD.
Steven: bdo should have common and not core
Shane: agreed
From the link: Also, while XHTML does have facilities already for expressing xml:base
and xml:id, would these be reasonable to include in the Core attribute
collection? (I wouldn't use them myself, nor would anybody need them,
but since they are general purpose for XML...).
<oedipus> FYI: URI of my proposal to deprecate HR in HTML5 that resulted in being told to take issue to XHTML2 WG: http://lists.w3.org/Archives/Public/public-html/2007Apr/0099.html
Shane: no
http://lists.w3.org/Archives/Public/www-html-editor/2007JulSep/0017
From the link: Under the Legacy module 'notes', next to 'table', 'tr', 'th', and 'td',
it should, I believe, refer to "Basic Tables", not just "Tables"
(especially since the 'notes' related to 'forms' do distinguish between
the basic and full module.
Shane: if you happen to turn on legacy you would work
Steven: on input align gets placed on basic and
not forms
... legacy is only allowed on the tables module but not on the basic tables
module
Shane: we meant that
<Steven> http://lists.w3.org/Archives/Public/public-xhtml2/2007Aug/0009
Steven: This person wants to add stuff to the
legacy module
... We can't do that at this time.
Shane: agreed
... It may just work but this is not the object of 1.1
<Steven> http://lists.w3.org/Archives/Public/www-html-editor/2007JulSep/0009
Steven: this is cruft in the dtd and we should
not worry about it
... This is on HTML 4
Shane: This is not our problem
RESOLUTION: This is not our problem
<yamx> I will send a regret for next week, I will be on the road from Regensburg to Munich, somewhere in Germany.
<Steven> ok
This is scribe.perl Revision: 1.128 of Date: 2007/02/23 21:38:13 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Holpin/Halpin/ Succeeded: s/repeate/repeat/ Found Scribe: Rich Inferring ScribeNick: Rich Default Present: Gregory_Rosmaita, Steven, yamx, markbirbeck, [IBM], Rich, McCarron Present: Gregory_Rosmaita Steven yamx markbirbeck [IBM] Rich McCarron Regrets: Alessio Masataka_Yakura Roland_Merrick Agenda: http://lists.w3.org/Archives/Public/public-xhtml2/2007Aug/0029 WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 29 Aug 2007 Guessing minutes URL: http://www.w3.org/2007/08/29-xhtml-minutes.html People with action items: mark steven WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]