XHTML2 Working Group Teleconference -- 24 Oct 2008

<inserted> scribenick: oeddie

<trackbot> Date: 24 October 2008

<Steven> Meeting: XHTML2 WG FtF, Day 2

XML Events 2

RM: did you make changes?

SM: did

RM: in draft dated 20th

SM: yes

RM: went through list and made some changes
... eventtarget name of changed attribute
... main piece

<Steven> http://www.w3.org/2008/10/20-forms-minutes#item05

<Steven> Forms discussion on XML Events 2

<inserted> ScribeNick: oedipus_laptop

SM: added @eventtarget

RM: for listeners

SM: in general
... thought 2 attribute names i changed

RM: other in handler section

<Roland_> http://www.w3.org/MarkUp/2008/ED-xml-events-20081020/

<Steven> http://www.w3.org/MarkUp/2008/ED-xml-events-20081020/

<Steven> XML Events 2 Draft

<inserted> ScribeNick: oedipus

SM: issue remaining: when are events registered?

RM: had an action on that
... when document loaded would be registered and loaded into DOM at that point in time

SP: happen before load events?

RM: could be tricky

SM: reason have to be registered before onLoadEvent fires

SP: onLoadEvent may know stuff necessary for document which seems to mean that would have to refire onLoad

RM: or protect those looking to load and trigger that way

SP: script run when found

RM: so could be before

<ShaneM> typically you do something like addEvent("load", functionRef) ;

SP: script would get run before onLoad
... would't the code implementing XML Events 2 need to wait for onLoad itself in order to initialize

SM: no, not if run inline

SP: has to run up and down tree to register all listener events
... onLoad, but things depend upon it
... maybe that is its own bootstrap problem

RM: if go in through javascript and listen with javascript wouldn't be any different
... listener in script for onLoadEvent would have problem after
... no different from anyone running script using ListenerOnLoad from script interface

SM: 2 diff problems: 1) what to say about handlers module and when registered; 2) if implement to work in existing UAs, how would ensure outcome of issue 1 supported
... not sure let decisions about current UAs color the answer
... should say registered prior to onLoadFire

SP: yeah

RM: yeah but how to achieve?

Nick: can do onLoad then trigger all events waiting for onLoad -- order not defined

SP: could use root elements
... script implemented can do capture onLoad, initialize, then reinitialize onLoad

SM: implementation must behave as if...

RM: yes

SP: yes

RM: such that handlers may listen for onLoad event

SM: can't decide where need to say
... in addEventListener description?
... yes

RM: makes sense

SM: reason for confusion is MarkB says that this also wasn't clear from XML Events 1 spec -

SP: not place to do it -- that's an action
... place to talk about it is in the description of handler attribute
... i think should be under handler attribute

RM: defined on listener element - optional attribute?

SP: yes
... (reads from spec)
... could do in separate location: whenever handler attached explicitly with handler attribute or implicitly

RM: problem saying that - what happens when try to add handler after - brining script into DOM
... 2 sides: 1) those that are declared in original document will be done before load

SP: discussed before and said that can't do that

RM: should ignore that situation

SP: little point in changing handler attribute via script - if want that effect, can use script already

RM: if put widget in DIV, need assertion -- can't bring in declarative approach to do that

SM: any DOM mutation event should cause the implementation to reexamine tree to ensure all handlers are registered

SP: are you REALLY sure we want that

SM: alternative is build page using AJAX -- if want to work, has to work there too

SP: not sure -- whole point of this markup was to do declaratively so didn't have to use script; if going to use script, use script's function, not declarative markup

RM: may not know if embedded at start-up time or post load

SM: that's my concern too
... don't disagree with SP, but don't know how to accomodate those creating dynamic pages -- added after onLoadEvent fires

RM: could say or provide function to do it - if do insert after mnode, have to do something to reparse and register these items
... responsibility, not dogma

SM: address in document conformance?
... or just advice
... more than advice -- have to do it

RM: have to cause script to get executed in some way to get activated

SM: popular AJAX libraries do it by setting flag for javascripting process

RM: need something similar here

SM: where in doc?

RM: processing model, isn't it?
... make topic in subsection 3 - subject of how to cause listeners to be registered

SM: 3.6?
... after event scope

RM: yep

SM: don't need to do in real time - will edit and we can revisit

Handlers Module

RM: changed to make eventtarget

SM: other is EventType

RM: other thing that makes sense in this section now -- had scripting module, but also discussion if want handler and a script - this script is a "traditional" script inside handler module

scribeNick+ oeddie

SM: script element that would say "here are my handlers"

RM: script that is only a function
... add script for all reasons have today

SM: reluctant to loose section 5 - no home other than XHTML2 today

RM: keep in there; will review MarkB's issues with Mark - question: define handler or function - function takes to script handler to handler

<alessio> hi all, I don't have Skype here... can I follow you via IRC?

RM: reviewing minutes and email from july

of, course, you are welcome in any way you can participate

<alessio> thx!

RM: shane also included in dialog

<Roland_> http://lists.w3.org/Archives/Public/public-xhtml2/2008Aug/0011.html

SM: handler element included in handler module, right?

RM: yes

SP: where is handler element now?

SM: doesn't exist

RM: trying to move from script

SM: load external things - has @src

SP: handler element versus action element

SM: if action element had @src could fulfil function

RM: leave resources tight

SM: don't want to overload action -- just use handler -- make simpler - doesn't cost anything to have in content model

RM: inside action, put handler
... handler can be child of action

SM: doesn't have to be

RM: but valid cases where one might want to
... other change: option of either specifying want handler to run or function to run; where specify handler and where function?

SM: Roland, do you want @implements on handler element?

GJR: can "see" argument for it, perhaps in case of expert handlers

RM: trying to think of a reason to say no -- seems might confuse things
... depends upon script - script in 2 diff modules - events module, handlers moule, and script module
... just section in XHTML2 -- need script out of events module document altogether

SM: case for retention: XML module, not XHTML module; beyond XHTML; like to expose script element to world beyond XML

RM: agree with that statement; bit we need to work on is what script element says -- XML2 script element different in terms of coding, etc.

SM: not really different - tried to normalize

RM: when i looked were definitely differences between Base and Events
... let's finish of the other piece: option to specify handler (ID) or function

SM: suggesting that be global attribute?

RM: wherever can specify handler, can specify function

SM: yes
... we need to keep in mind that everytime add global attribute, polluting global namespace more

RM: under handler as IDREF?

SM: now a URI

SP: lost use case -- what trying to achieve

RM: either a handler or script library with all functions
... get functions from script

<Steven> <a href=..><action ev:event="DomActivate">foobar()</action>Click here</a>

RM: suggesting that could be name of function
... how if going to attach to handler

SP: action element is a handler
... used default

<Steven> <action id="foo">foobar()</action>

<Steven> <a ev:event="DomActivate" handler="foo" href=...>Click here</a>

<Roland_> < listener event="DOMActivate" observer="button1" handler="#doit" / >

RM: instead of handler, have to create actionable which has to call function - can't refer to handler from function

SM: like elegance of SP's solution, but entire module has no inline CDATA

SP: even action?

SM: even action

SP: replae with script element

s/relae/replace

SM: don't know if will work

<Steven> instead of action above

<Steven> couldn't I say

SP: instead of action above, couldn't i say:

<Steven> <script declare="declare" id="foo">foobar()</script>

SP: question is: how much / often the work that handler does is single function -- this is convenience, not functionality - author convenience to call function

RM: interpretation will be different depending upon culture coming from

TV: what gets loaded and fired; ???? ouldn't hear reast
... data model

RM: earlier example in spec: listener > DOMActivate > doit function in script what put there?
... if have script function called doit, would have to create intermediary - that would be handler?

SP: or script

SM: all done is add layer of abstraction; still can't get to single function

SP: in my script core is that single function

RM: wouldn't execute, though

SP: would handler=#foo content of scrpt gets executed

RM: what would happen today

SP: declare

SM: no such element

<ShaneM> defer [CI] When set, this boolean attribute provides a hint to the user agent that the script is not going to generate any document content (e.g., no "document.write" in javascript) and thus, the user agent can continue parsing and rendering.

SM: is attribute "defer" - hints that not going to do DocumentWrite()
... have @declare on action element

SP: not sure why

TV: no way to tell UA not to execute piece of script;

RM: what led to suggestion of adding function
... still have way of action invoke function
... actionhas function equals -- then no need of another parameter

TV: will some of these things have effect on ????
... 2 - one depends on function that came from ????
... respect to javascript node - if script tag has src that gets loaded - trick to make load is do Document.Create element; do things need to block or can execution/loading of document continue
... all happen after onLoadEvents fire; if have 2 blocks 1 dependent upon quote from first block, have to find these and define behavior carefully

SM: makes perfect sense
... discussing handler element - decided to introduce; then discussed if needed function attribute as part of global attribute set; now keep handler and that handler can invoke function
... separate modules - XML Events does not require XML Handlers

TV: would like to keep separate if possible

GJR: plus 1

SM: +1
... no way to use listener that ties to a function

RM: handler is always a function could be specified in a language

TV: other way to fix - declare one of things in XML Events to be a handler (such as the handler) - handler spec can elaborate on that; XML Events client that doesn't support handler can use module

RM: handler goes to events goes to listener

SM: another option: @handler doesn't get included into global space unless use events as well

TV: handler in handler module

GJR: like way headed

RM: need to work out specifics - still question - handler attribute to invoke a script function

SM: also backwards compat - events 1
... happy to define handler element in context of Event Module

SP: in Events 1 did diliberately to try and get others to adopt XML Events

TV: Charlie, is there a voice group position on this?

SP: other groups think our events are special; almost always turns out that they have relevance or something close to it in XForms terms where events don't fire handlers on parts of tree that are irrelevant

TV: event filtering

SP: interesting; no other spec talks about relavance like that, amybe ought to put into spec; SMIL good example

TV: also gets by argument that need to implement a lot of what i don't need to get what i do need

SP: 2 implements: how do you deal with relavance specially
... how stop events firing on tree where shouldn't

Charlie: handlers decide what to do

SP: switch that contains element bound to something that changes, but switch not told; strictly speaking, events so go to that thing and bubble up tree, but currently doesn't

Uli: in Chiba does

TV: no one should notice bubble on client side
... about 5 years ago had a partial implementation
... event list in XML: can say to handler, fire event under certain criterion -- i am done, don't do anymore
... could could use XML handler to do conditionality -- if x is true through attributes, then relevant, otherwise, not
... target phase, bubble phase or capture phase all should respect conditionality of XML handler

RM: conclusion / agreement

RESOLUTION: take handler out, put into Events Module, ability to invoke script function will be added to handler

GJR: plus 1

<ShaneM> +1

BREAK FOR 30 MINUTES

<alessio> +1

i/Attendees/Previous: http://www.w3.org/2008/10/23-xhtml-minutes.html

i/see also/Previous: http://www.w3.org/2008/10/23-xhtml-minutes.html

<ShaneM> omw

<ShaneM> listener says handler="#foo"

<Roland_> < handler function="whatever" / >

GJR: like function better

SM: trying to understand what means; using examnple above, the symptom is going to do what? load the resource at whatever, find the fragment identified by #someActionElement -- doesn't make sens

<Roland_> <handler src="whatever#someActionElement" />

SP: not sure about that

<Roland_> <handler id="foo" src="whatever#someActionElement" />

SM: this is case trying to solve, right?

SP: yes

SM: guess i'm fine with that - would be as easy to put function on listener and be done with it
... handler module describes action element and way to declaratively define handlers

RM: doesn't explain in XML Events 1

SM: has to be embedded?

SP: easy to put function on listener, so what is problem

RM: do we want another global attribute -- wherever a handlers attribute there would be a function

SM: hoping to come up with clever way to overload handler

<ShaneM> handler="javascript:function"

RM: one is fragment identifier - URI or function name

SM: that would work today, for what it is worth

RM: wouldn't have to put javascript, name of function

SP: URI, not CURIE

RM: function: would also be URI

SP: then have to go to IETF

SM: not a formal javascript

SP: convention

<Steven> javascript:alert("foo")

SM: used for href="javascript..."

SP: Bjoern Hoehrmann to register schemes widely used and not registered anywhere -- ran out of time or cycles

RM: function name with brackets

<Roland_> http://tools.ietf.org/html/draft-hoehrmann tried-javascript-scheme-00

RM: why not use

SM: TAG would have heart-attack

RM: get through LC and put in example

SP: Shane, your example is very clever - would never have come up with that

RM: someone might take this scheme trhough for all we know

SM: what happens with such a function: get past event context or part of global javascript feed

RM: as per SP's example

SP: what has TAG against it -- that not registered?

SM: TAG doesn't like registering new schemes - want to use HTTP
... WebAPI group defining widget spec - so could register in DIV - TAG said no; external group (OASIS) tried to register XIT to IETF, failed

<ShaneM> Would this work? foo.js#functionName ?

SP: TAG objects to schemes which are just HTTP in disguise - apple has one, and just use it
... replace scheme with http still works

SM: within iPhone architecture itself - when install app, can register scheme

js#functionName

SP: as handler you know # defined by media type - application/javascript
... then need to look there to find out if can use fragments

<Steven> http://www.ietf.org/rfc/rfc4329.txt

Scripting Media Types

SM: could put function attribute on it and be done with it

RM: go back to what trying to achieve

SM: 99% of today's use cases, @function would satisfy; could put in note that can do with handler at some time in future, but probably want to stay away from that

SP: safest route is another attribute

SM: clearest for constituents

GJR: plus 1

RM: sounds good to me

SM: having said all that, do we still need handler element?

SP: don't think so

SM: MarkB thinks so -- he introduced this thread

SP: would have to ask Mark

SM: does anyone believe that any scripting language used other than javascript?

<ShaneM> Is this adequate? <dt id="attr-listener-function">function</dt>

<ShaneM> <dd>The <code>function</code> attribute identifies an optional

<ShaneM> function name that will be called when the handler is invoked by

<ShaneM> an event listener.</dd>

SP: think that in 15 years time, maybe - wrong to make assumption that will always predominate
... not sure if need handler and function simultaneously

SM: function called when the event reaches observer

SP: yes

SM: think have to say specify either a handler or a function attribute, and if specify both @function takes precedence

RM: sounds good to me

GJR: plus 1

<alessio> for me too... +1

RM: function doesn't require javascript - can use other function libraries/languages

RESOLUTION: specify either a handler or a function attribute; if specify both @function takes precedence

SM: have abstraction built-into spec, don't know if will ever be used

Script Module

RM: same as in XML Events only with @function added

SM: so XML Script Element

RM: why would it not be XHTML 1.1 or 1.2 Script Element + Implements?

SM: modules designed to move cleanly into XHTML2; in XHTML2 have broader understanding of i18n; don't care if do differently in Script Module, but going to have to change when move to XHTML2

<Steven> s/of nothing/no problem/

<ShaneM> http://www.w3.org/TR/html401/interact/scripts.html#edef-SCRIPT

SM: can do now or later
... HTML4.01 script that we care about

<alessio> thx steven

<Steven> :-)

SM: @type in HTML4 is much diff than @type in XHTML2
... didn't put defer in here, but could
... is what we are trying to accomplish is that this script looks like HTML 4.01 script + implements

RM: yes, so can implment in existing browsers

SM: if that is case, we shouldn't have complex def of @type in here
... Steven, XML Events 2 right now uses definitions from XHTML2

SP: XHTML2 has extended version of @type, but if another app going to use XML Events may not want that def of @type
... no objection to XML Events 2 having simpler @type as long as doesn't ruin generic @type in XHTML2
... M12n allows us to extend an attribute, right

SM: sure
... if agree to change, will rip out complex content-type lang and replace with stuff from HTML4.01

RM: @id element?

SM: everything has @id in XHTML

RM: id or xml:id

SM: interesting discussion we should have
... if goal is this is used generically in XML languages, would make sense to remove @id from this spec, which is used in context of other host languages

RM: agree

SP: everyone uses @id -- allow people to use other attributes -- don't want to replicate problem with XFOrms where assumed that host language would define @id, in the end had to put it back in

RM: would be legitimate - don't have to use javascript if have @function
... do we know what we are doing with script

SM: believe so -- trying to find definition of @id

<alessio> @id could be still useful as immediate "pointer" for an element

SM: plan with document?

RM: go through changes, review and take to LC

http://www.w3.org/MarkUp/2007/ED-xhtml2-20071024/mod-core.html#adef_core_id

SM: think inherited from HTML 4.01

RM: add to XHTML 1.2?

SM: no

http://www.w3.org/MarkUp/2007/ED-xhtml2-20071024/mod-core.html#adef_core_id

SP: text def of id is attribute that assigns an identifier to element

SM: taking high-level details

<ShaneM> <dd>The optional id attribute assigns an identifier to an element. The value of this attribute must be unique within a document. This attribute MUST NOT be specified on an element in conjunction with the xml:id attribute.</dd>

SM: makes sens to mention xml:id here in regards scripting
... coding versus charset - what do we want to do?

RM: XHTML 1.0 says what?

SM: changed for XHTML2 in response to comment from i18n

SP: could leave in encoding
... encoding only for the src attribute

SM: wants to map cleanly to script in HTML 4.01

SP: 2 options: leave; include both to allow for future developments; or just add in XHTML2

RM: add in XHTML2 and deprecate old one

SM: put in note: "in future version of module expect to change base encoding..."

RM: don't know what value that adds other than to melt minds

SM: ok
... now have: @src, @type, @implements - do we need @defer? think has no semantics and should skip

RM: if have no use for it, leave it out
... is in XHTML 1.0?

SP: everything in 1.0

RM: XHTML 1.1?

<alessio> @SM I agree

SM: in 1.1

RM: same as 1.1 with addition of @implements - XHTML2 script element

http://www.w3.org/TR/html401/interact/scripts.html#adef-defer

RESOLUTION: keep everything from XHTML 1.0 definition of script

RM: finished topic?

SM: think so

Fallout of M12N 1.1

Fallout of M12n

RM: topic haven't addressed: now that have M12n as Rec need to update other specs - can we discuss after lunch -- fallout from getting M12n to Rec

SM: pretty sure in all in mail

<Roland_> Now that XHTML M12N 1.1 is a REC, we need to update our other specs.

<Roland_> There are new versions in shape for PER that include the schema

<Roland_> implementations. They include XHTML 1.1, XHTML Basic 1.1, XHTML Print

<Roland_> 1.0, and RDFa Syntax 1.0. We should decide a strategy for moving these

<Roland_> forward.

SP: Basic, Print, and RDFa

RM: 1.1 Second Edition

SM: will all be second edition

RM: 1.1 SE has been waiting for M12n for quite a while
... strategy?

SP: add reference and shove out there

SM: updated all drafts as SE and are all ready to go

SP: way to go Shane!

SM: think these are PERs per W3C process

SP: that's right

SM: can't imagine any real contention or difficulty in moving forward;
... check errata to ensure all addressed;
... RDFa synax odd man out; asked melinda to ask XHTML Print comminity for errata; Print, Basic and XHTML 1.1 we can submit as single submission: same style of change, etc.

RM: seems reasonable: M12n is underpinning
... Basic so new, don't think there is errata for that yet
... www-html-editor where to find errata?

SM: yep

RM: fun for the whole family...

SM: RDFa Syntax unusual - produced in conjunction with another group in Task Force - up to TF to decide to take to PER?
... my guess is ben will want to do a stability check on it first
... W3C process questions for SP: Basic, Print, and XHTML 1.1

SP: if errata, work in, add schemas and then submit

SM: submit all in one transition call

SP: best approach

SM: concerned about tracking errata -- need to do a sweep of www-html-editor for the last 5 years

SP: can garuntee that when producing agenda that everytime something new on html-editor, i put on agenda, so i think only need to do a year's trawling/trolling

SM: never added anything to an errata docmument ever
... troll agenda to find issues identified; just need to ensure resulted in decision
... according to melinda 2 typos which i fixed
... print went to rec in September 2006

SP: comment on fieldset sub-elements; Shane and Melinda replied
... fieldset asked and disposed - no other comments on Print

RM: looking for mentions of XHTML 1.1 in html-editor
... flattened DTD
... talking about second edition flattened DTD so that's ok
... most recent one - replied

SM: if any stuff need to update, should do it; technically, if stuff in errata doc, should be reflected, but errata docs empty
... all indications are that there aren't any dangling erratas

<Steven> Mayakura?

SP: isn't myakura our Basic rep -- he is here now, so let's ask him

<Steven> Myakura?

s/mayakura/myakura

<myakura> yes?

<ShaneM> are you aware of any errata or comments against XHTML Basic 1.1 as of yet?

<myakura> ShaneM: not really.

RM: need to work through these items - when to submit

SP: shouldn't be too much process work

<myakura> doesn't think i'm the rep for Basic though...

SM: want to verify schema implementation works (by someone other than me)

RM: worth talking with validator guys

SM: if had schema validation, would be

myakura just told me he is unaware of any errors

<ShaneM> XML Events 2 updated at http://www.w3.org/MarkUp/2008/ED-xml-events-20081024/

<Steven> http://www.w3.org/2001/03/webdata/xsv

<ShaneM> myakura: oh - sorry. Someone indicated you might know about it. We will ping Yam. Thanks!

<myakura> no probs :)

SM: not obvious how to use XSV

SP: bad user interface

SM: was able to use to validate schema along with oxygen and other tools
... reasonably confident, but until use schema in anger, won't know if work

SP: could provide interface -- validate your doc against any of these schemas - XHTML validator

SM: not a bad idea
... need to resolve to move to PER as soon as possible

RESOLUTION: take Basic 1.1, Print 1.1, XHTML 1.1 to PER as soon as errata check finished

SP: will email RDFa task force about monvement on that front

<ShaneM> updated draft with schema of RDFa Syntax is at http://www.w3.org/MarkUp/2008/ED-rdfa-syntax-20081018/

ADJOURN FOR LUNCH: RETURN IN 60 MINUTES

[fyi] Using ARIA Live Regions to Make Twitter Tweet: http://www.paciellogroup.com/blog/index.php?s=twitter

aloha, alessio -- i have a question for you (and possibly diego and roberto) about iframe - i haven't finished the emessage yet, but i think i did point you to http://esw.w3.org/topic/PF/XTech/IFrame

problem is, there aren't any com ports anymore for hardware TTS, and the newer screen readers don't support hardware TTS, which is why i'm trying to work with the RNIB on a sourceforge project for hardware speech support for stuff like NVDA

<ShaneM> in your copious free time?

something like that -- it's just that if NVDA wants to get ANY market penetration into the mainstream it HAS to support older tech, as hardware synths were VERY expensive

i'm looking for other to do the coding - i'm just simon legree

trying to harvest graduate students

which is always a dangerous thing

<ShaneM> can be rewarding but yeah - takes a lot off effort

you said it -- that's why even the "mainstream" ATs are moving towards software everything

but 70% of the target population is unemployed

statistics that are similar throughout the "developed" world

<ShaneM> thats a shockingly high number. sometime you will have to explain to me how that 70% eats

which is why i've been trying to get WAI to set up proxy servers for 12 years -- see if the concept/fix works and if it does, implement it, but leave the proxy up ther for those whose hardware is "frozen in time"

food stamps

<Roland_> I do not, but my "vanilla" dog didn't really like stamps

<Roland_> 06postma01n

those are the numbers according to AFB (in USA) RNIB (in UK) and australia & NZ

that's one postman who won't ring twice

<ShaneM> are we getting ready to restart?

to see what most blind people are dealing with, check http://www.braillewithoutborders.org/ENGLISH/index.html

1 hour, 10 minutes & 56 seconds according to my stopwatch since we broke

i have a stopwatch on my talking watch

<ShaneM> zakim left us

steven dismissed him

<Steven> Di not

<Steven> did not

they have to connect first

oh, then maybe it was roland

RESOLUTION: take handler out, put into Events Module, ability to invoke script function will be added to handler
... specify either a handler or a function attribute; if specify both @function takes precedence
... keep everything from XHTML 1.1 definition of script

XHTML Mime

RM: Shane had dialog with commentor

http://www.w3.org/MarkUp/2008/ED-xhtmlmime-20081022/

We recommend that XHTML be delivered as HTML, but that means it is not valid HTML. Do we care?

(above from agenda)

SM: high level: applied most of simon's edits; not much from others;
... asked for clarification on few issues and he did that
... in this document - original Note and updating - original Note did thurough job of looking at all media types might deliver XML/XHTML document
... does it make sense to talk about DTDs and discourage their use
... Section 3.3 - application/xml

SP: reads document
... worth pointing out that can do it, but may not always be processed as XHTML

RM: while may work, recommend you don't do this
... shouldn't we recommend one over other

SP: allow both, not champion one over other - ok to serve HTML to XML processor

RM: application/xml and application+xml that have to say diff things about them
... what it is that we recommend should or should not do them
... you MAY or you SHOULD?
... who is meant to read document?

SM: document authors

RM: shouldn't we then be more explicit about XHTML family and modularization?

SM: don't know how to answer that question

RM: less technically correct - this applies to XHTML 1.0, XHTML 1.1 or XHTML Basic 1.1

SM: doesn't just apply to those

RM: XHTML 1.1 Basic adoption by author application of XHTML Modularization
... can we put it that way -- if it begins with X, then it is XHTML and an author application of modularizatino

SM: if this doc talks about M12n anywhere is a mistake
... mentions rec

RM: reads from abstract
... is that really the case?
... that's why there are XHTML Media Types - only read this doc if want to write XHTML and how to best get processed by User Agent

SM: ok

RM: this is Note produced by us
... Introduction
... talks about XHTML1 versus HTML 4.01

SM: historical data

RM: Introduction: brief summary

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

RM: some stuff we don't want - they chose language, so will get what they get - language designer, not m12n that made that decision
... too much for people to say "do i have to worry about all this? i'll just use HTML 4.01"

SM: ok - strike first paragraph?

RM: actually last paragraph

"Note that, because of the lack of explicit support for XHTML (and XML in general) in some user agents, only very careful construction of documents can ensure their portability (see Appendix A). If you do not require the advanced features of XHTML Family markup languages (e.g., XML DOM, XML Validation, extensibility via XHTML Modularization, semantic markup via XHTML+RDFa, Assistive Technology access via the XHTML Role and XHTML Access modules, etc.), you may w

SM: happy to reword, but last paragraph addresses objection tina had (we really should tell people use HTML4 unless need XHTML) - reasonable - don't jump through hoops if don't have to

RM: terms and definitions

XHTML Family Document Type: "A document type which belongs to the family of XHTML document types. Such document types include [XHTML1], and XHTML Host Language document types such as XHTML 1.1 [XHTML11] and XHTML Basic [XHTMLBasic]. Elements and attributes in those document types belong to the XHTML namespace (except those from the XML namespace, such as xml:lang), but an XHTML Family document type may also include elements and attributes from other namespaces,

RM: support XHTML, but "host language document type" matter to reader of doc?

SM: defined because term is used in previous definition - you are right - more academic approach than needed

RM: Section 3.2

http://www.w3.org/MarkUp/2008/ED-xhtmlmime-20081022/#application-xhtml-xml

SM: only docs that adhere to our structural reqs can use this media type

<alessio> agree with roland

RM: that's why concentrating on reading from author's PoV
... same with application type - obscure terms versus critical terms
... if i am a document author, don't need to understand a lot of what is explained

GJR: agree -- type of thing that makes people say "it's all geek to me"

<alessio> yeah, that's true gregory

RM: just tell me what to do, save theory for another document

SM: originally not intended for document authors as it was to explain to XHTML2 what works and what doesn't in real world

RM: significance check of terms - integration document set; host language document type

SM: in previous term define XHTML family; would define XHTML Family by turning def around

Section 3: 3. Recommended Media Type Usage

RM: looks clear to me

@@@@Issue: Do we believe that XHTML documents that adhere to the guidelines are "valid" HTML? Should that be a goal?@@@@

SM: Simon objects to this; i may be being obtuse

SP: what is objection

SM: thinks we are defining content-negotiation and are doing it ppoorly
... shouldn't be redefining rules of content negotiations in doc
... hadn't considered that problem; thinking had been if UA prefers text/html, give in xhtml because that is what it is

RM: if accept header that states application/xhtml+xml ...

<ShaneM> if the Accept header explicitly contains <code>application/xhtml+xml</code>

<ShaneM> and prefers it over other types

<ShaneM> deliver the document using that media type.

<Steven> then deliver as xhtml because that is what it is

SP: what is our aim? deliver XHTML - so deliver as xhtml, and problem over

SM: exactly

SP: trying to say if doesn't accept xhtml, have to do something else

SM: if that is case - what WG wants to say - not defining content negotiation, but telling author if explicitly containx xhtml (with no Qvalue) deliver using that media type
... point 2: if explicitly contains xhtml ... (missed)
... point 3: if */*, then deliver what can

RM: if text/html and xhtml, regardless of priorities, serve xhtml
... if can handle xhtml, always parse the xhtml

SM: anything beyond point 4 is gilding the lilly

RM: doesn't recommend xhtml text/html or */* - have to know what media types DOM is capable of - no recommendation

GJR: makes sense, can only tell authors what to do, can't control parsing

SP: want to say right up front that not redefining content negotiation

RM: yes, need to make very clear

<ShaneM> This section summarizes which Internet media type should

<ShaneM> be used for which XHTML Family document for which purpose.

<ShaneM> Note that while some suggestions are made in this section with

<ShaneM> regard to content delivery, this section is by no means

<ShaneM> a comprehensive discussion of content negotiation techniques.

plus 1 to general gist

RM: state intended readership up front?

SM: yes, definitely

<ShaneM> abstract: Many people want to use XHTML to author their web pages, but are confused

<ShaneM> about the best ways to deliver those pages in such a way that they will be

<ShaneM> processed correctly by various user agents. This Note contains

<ShaneM> suggestions

<ShaneM> about how to format XHTML to ensure it is maximally portable, and how to deliver

<ShaneM> XHTML to various user agents - even those that do not yet support XHTML natively.

<ShaneM> This document is intended to be used by document authors who want to use

<ShaneM> XHTML today, but want to be confident that their XHTML content is going to

<ShaneM> work in the greatest number of environments.

<alessio> it has "pratical" sense...

<Steven> Looks good to me

<alessio> yes, me too

SM: Section 3 - what to do when XML doc does not adhere to guidelines
... if doesn't adhere, don't send as text/html - needs transformation, not false declaration
... Simon pointed out should deliver html documents because not valid

SP: should be saying "getting XHTML into browser"

RM: if you do these things, it will be sufficient to get effect you want in most UAs

SM: Steven, strike entire paragraph?

RM: maybe should say nothing

SM: it is about document performance, not UA limitatinos

RM: use at own risk - will evolve -- suggestions to improve chances

SM: up to us to keep document up to date - fix, and update periodically
... strike entire paragraph?

<ShaneM> Steve suggested: When an XHTML document does NOT adhere to the guidelines, it should only be delivered as media type <code>application/xhtml+xml</code>.

RM: strike it and see

SM: added at specific request

RM: pragmatic, not purist, document

SM: removed all RFC2119 words
... remove about transforming into HTML?
... haven't removed any guidelines, but rules in 1.0 still in document - backwards compatibility there

GJR: right

SM: Simon said "why still asserting this - no longer relevant" - no longer relevant to opera 9, but where does that get the world?

"Note: It is possible that in the future XHTML Modularization will define rules for indicating which specific XHTML Family members are supported by a requestor (e.g., via the profile parameter of the media type in the Accept header). Such rules, when used in conjunction with the "q" parameter of the media type could help a server determine which of several versions of a document to deliver - thereby allowing server-side customization of content for specific cla

SP: XHTML Basic gets delivered with profile
... OMA spec includes something along those lines

RM: what would make me do something different in raction to note?

SM: none - remove

RM: should be as short as we can make it and no shorter

SM: section 3.2 should be 3.1

RM: seemed out of order to me
... when conforms to guidelines in this document "carefully constrcuted" means what?

SM: will fix
... character encoding

RM: trying to figure out how to express why matters to me as author

SM: don't need to give all background; just tell them what to do
... doesn't tell what to do anyway
... GL9 in Appendix A.9

DO encode your document in UTF-8 or UTF-16. When delivering the document from a server, DO set the character encoding for a document via the charset parameter of the HTTP Content-Type header. When not delivering the document from a server, DO set the encoding via a "meta http-equiv" statement in the document (e.g., <meta http-equiv="Content-Type" content="text/html; charset=EUC-JP" />). However, note that doing so will explicitly bind the document to an a singl

Rationale: Since these guidelines already recommend that documents NOT contain the XML declaration, setting the encoding via the HTTP header is the only reliable mechanism compatible with HTML and XML user agents. When that mechanism is not available, the only portable fallback is the "meta http-equiv" statement.

SM: Simon said example silly (change to japanese at end)

RM: beware of character encoding issues, in particular GL/A.9
... why reiterate?
... if have guidelines, point to them, don't reiterate them

SM: if content in here i care about, will push down to guidelines
... 3.3. 'application/xml'

RM: all is honky-dory - procede - no problem
... run through validator; if valid, procede
... bit of overkill

SM: put in because validator people trying to enforce validity guidelines

s/SM: 3.3 'application/xml'/SM: 3.2 application/xhtml+xml

SM: XML stylesheet processing instructions? keep?

SP: idea that this is XML so should use XML features where possible; when XML and HTML feaature, XML feature should get priority

SM: not XSLT, but sytlesheet PI
... will just remove paragraph
... final paragraph - character encoding issues

RM: thought was all utf-8

SM: if serving as text/html can serve as whatever you want

RM: recommendations? HTML4 as well as XHTML

SM: if that is the case shouldn't be telling people to ignore guidelines
... if message is you care about portability, follow the guidelines

RM: content-encoding
... circular reference

SM: doesn't depend on RFC
... documented in 3.3 - says same thing we already believe it wants
... will be document processing agents, not user agents - search engines, and trawling tools

RM: 3rd paragraph - "generic user agent"
... user agent give what it asks for, don't worry about it

SM: suggest leave 3.3 and 3.4 - remove references to other media types from this document

RM: reference 3.3 to 3.2

SM: think can remove summary section

RM: refer to it early on
... looks too complicated
... althought will be a lot smaller

SM: we've said what preference rules are and why should use; at beginning of section 3, should expand on it - already did
... in section on application/xhml+xml - if document uses other namespaces MUST use this mime type

RM: reverse and put in other section
... Appendix A looks better with DO NOTs and DOs
... Appendix A
... Appendix A.1 - sounds good

SM: made all changes SimonP wanted, so should be satisfied - when done with whinnowing process, we should go back and add more examples

RM: A.2, A.3 fine to me

SM: added extras to A.4

RM: A.4 actually works?

SM: yes

RM: will be using

SM: A.5 because is allowed
... A.6 missing - deleted rule - reluctant to renumber other rules because map to XHTML 1.0

SP: could say A.6 Deleted

RM: or superseded by events

GJR: thanks for A.7

SM: need to complete second "DO NOT"

RM: should not use one or the other

SM: rationale says why
... reinforces why need to reintroduce into XHTML2
... A.8 Fragment Identifiers

SP: very good

GJR: 2 thumbs up (guess where)

SM: meta stuff addressed in A.9

"DO encode your document in UTF-8 or UTF-16. When delivering the document from a server, DO set the character encoding for a document via the charset parameter of the HTTP Content-Type header. When not delivering the document from a server, DO set the encoding via a "meta http-equiv" statement in the document (e.g., <meta http-equiv="Content-Type" content="text/html; charset=EUC-JP" />). However, note that doing so will explicitly bind the document to an a sing

"Rationale: Since these guidelines already recommend that documents NOT contain the XML declaration, setting the encoding via the HTTP header is the only reliable mechanism compatible with HTML and XML user agents. When that mechanism is not available, the only portable fallback is the "meta http-equiv" statement."

SM: covered here
... changed EUC-JP to utf-8

RM: Move on to Appendix A.10

SM: not sure got this right
... can rely on html DOM methods; overlap with XHTML DOM; but XHTML DOM not going to return elements and attributes in upper case
... think portable is: rely upon the DOM

SP: all need to say

SM: bit about element and attribute names meaningful - uppercase versus lowercase

RM: if want to be case insensitive, use lower, otherwise will have to use camelcase
... be sensitive to case

SM: DO ensure element and attribute names are case insensitive in your scripts.

RM: A.12 seems fine
... just needs examples

<alessio> yes

RM: A.14 - ok
... A.15 formfeed character

SP: fixed in later XML

RM: no harm in doing this
... A.16 - ok
... A.17 The XML DTD Internal Subset

SM: A.18 perhaps too strong

"DO NOT use the XML CDATA mechanism."

SM: contradict with A.4 - bring into harmony

RM: A.19 - just tbody?

SM: thought were ignored, not inferred?
... don't think are in DOM
... Steven, might be right that there is another inferred element

SP: context of stylesheets, think just tbody

RM: DO use the base element if you need to establish an alternate base URI for your document. should be in same block as ""DO NOT use the xml:base element.
... document.write - do not use

SM: wondering if rationale is right

SP: parsing models for XML doesn't require halving on fly; document.write only works with streaming parsers, so shouldn't use it; might do reader some good explaining how to do so modifies DOM directly

SM: a "do" clause?

RM: if this is what you ar etrying to achieve, use DOM manipulation to achieve same effect
... 22 application/xml and the DOM

SM: get rid of it?

SP: yes,

SM: 23 put in over tina's objection "updating document using innerHTML"

SP: is this difference between HTML and XHTML rule

SM: simon said ensure content is well formed and here is GL if going to

RM: reasonable caveat

SM: took one step further

RM: example, such as that needed for document.write - show how to do properly if need to do it
... 24 scripts and missing tbody elemtns

SP: still don't understand why 23 in here?

SM: have to ensure that conforms to GL if going to insert it

SP: link should be in rationale
... 25 says too much and too little

"Rationale: In HTML 4, these properties were often specified on the body element. CSS specifies that in XHTML they need to be specified on the html element in order to apply to the entire viewport."

SM: and CSS spec says works that way

SP: insisted spec say that because couldn't do any other way - compromise
... ensure any CSS properties on HTML element are also specified on BODY element
... warning is: if serve XHTML as xhtml, garuntee that CSS will work - if serve as html will work in some browsers and not in others

SM: diff problem - CSS on body element, syles bounding box of body, not viewport
... very different effects

SP: standard thing to do is switch everything off HTML and onto BODY
... On some user agents, put initial sytling on HTML some on BODY, so have to code CSS to take that to into account

SM: ensure properties on HTML also on BODY is fine

SP: rationale is some UAs recognize in BODY or HTML

SM: 26 - didn't realize problem with noscript
... if scripting is enabled, contents of noscript parsed as CCDATA if script parsed as CDATA

http://esw.w3.org/topic/PF/XTech/IFrame

SM: 27 iframe Element

SP: noscript needed because of document.write

SM: thought no script was for alternative to script

SP: if do all with DOM mutations, initial version of document can contain script that deletes the element
... functionality is there if use script - if use document.write version to change then do need noscript to catch that

SM: 37 iframe Element

SP: need explanation

SM: simon says content is parsed differently - in HTML parsed as CDATA when scripting enabled, or PCDATA when scripting disabled, but in XML alwasy parsed as CDATA - same problem as noscript
... don't know if compatibility issue

SP: not only if evaluated as HTML or XHTML but whether scripting enabled or not

SM: need to copy bit from noscript one

http://esw.w3.org/topic/PF/XTech/IFrame

1. What is the current state of accessibility of IFRAME?

2. What are the outstanding accessibility problems inherit to IFRAME, or have they been mitigated?

1. if, for example, one has a document embedded in an IFRAME which has access keys defined for it, will the embedded document's UI controls take precedence when the focus is in the IFRAME? what about conflicts between embedded UI controls and UI controls in host documents? what if a tabindex value has been defined for the IFRAME, and the document in the IFRAME has its own tabindex order?

The basic question is: How do the 2 documents interact and what can be done to standardize this interaction? Is it possible to harmonize W3C's efforts on IFRAME reform, which include IFRAME in XHTML2 (a subject currently being revisited after having been dropped), the XHTML IFRAME Module and the XHTML Legacy Module versus IFRAME in HTML5) with OpenAjax's support for iFrames?

RM: good if have demonstrative positive example will benefit intended reader base

<alessio> we could investigate possible interactions between IFRAME and wai-aria

SP: ODF wants to use RDFa in documents, and wanted to use xml:broccoli - allowed according to namespacing rules

@alessio -- yes, definitely

SM: RDFa - does it define an attribute collection?
... Metadata Attribute Collection

<ShaneM> http://www.w3.org/TR/rdfa-syntax/#col_Metainformation

SP: CC message to group or just to ODF inquirer?

XHTML2 Roadmap

<Steven> I just messaged the guy

<Steven> since he sent it to me only

SP: all our ducks are in a row

SM: at last f2f we agreed that i was to rip out all sections duplicating content of other specs, then refer to them and then be done
... then thought bad idead beacuse refer to attributes that aren't defined in spec
... have to include placeholders in spec
... told me to rip that all out

SP: if go to Forms section, tells me what i need to know

SM: thought i was supposed to take that out

RM: pointer saying there is this module and the module is elsewhere; summary in XHTML2 or statement "here is module, here is pointer"

SM: like that tact

<ShaneM> XHTMLMIME is updated http://www.w3.org/MarkUp/2008/ED-xhtmlmime-20081024/

RM: a module such as XML Events and XML Handlers are for incorporation into 1.3 if wanted and XHTML2 if wanted -- is that true?
... like to think it is true, but may never be true statement depending on what happens with XHTML2
... developing XML Events 2 reusable in both existing m12n scheme and XHTML2

SP: yes, for both, XForms is planning on importing events 2

RM: nothing more in XHTML2 than incorporates XML Events 2 and XHML Handlers 2
... Access, Role, etc. only in XHTML2 by reference

SM: ok
... dependent on modules - long pole in tent Access or Events 2

RM: implementations for XHTML2 will be needed, too
... Script module in there, too - pull that into XHTML2 and add @implements

SP: issue new WD next month?

RM: before christmas moritorium

SP: relationship to referenced documents

RM: in LC

SP: early next year for LC would be good target

Next Face2Face

SP: when

RM: february

SP: pretty far advanced - things don't have implementations for in XHTML2 (frames replacement stuff) and @src and @href everywhere; alessio helping on all those fronts
... implementation of features demonstration in good shape

SM: what version of XForms including?

SP: anticipating XForms 1.1

SM: XML Events 2, too?

SP: yes

SM: can't imagine get too far without test suite

<alessio> surely gregory

SP: once go to LC, major work will be producing test suite

SM: had one of my guys take existing XHTML test suite and start readying for change to XHTML2 - should i have him continue?

SP: yes

SM: if can take advantage of that work will help us along

SP: anything else?

RM: talked about docs individually - resolved to go to CR and PER on docs;
... XHTML2 separate into separate specs at later date?

MOVE TO ADJOURN

RM: bangs gavel - MEETING ADJOURNED

SM: meet next wednesday?

SP: call starts while still at airport

GJR: US Daylight savings time ends this weekend

SM: if have any cycles to work on transition requests for PERs i probably have the time

SP: long ago, we said to anne van kestren that we would change IDREF on imagemaps when re-issued 1.1
... should make sure we should do that

SM: where 1.2 or 2?

RM: 1.2

SM: override def of module for m12n - not update m12n because then break all other languages

<ShaneM> ACTION: Shane add the IDREF change for imagemap to XHTML 1.2 [recorded in http://www.w3.org/2008/10/24-xhtml-minutes.html#action01]

<trackbot> Created ACTION-16 - Add the IDREF change for imagemap to XHTML 1.2 [on Shane McCarron - due 2008-10-31].

ADJOURNED

<Steven> thanks ALessio

pressent- oedipus

- DRAFT -

XHTML2 Working Group Teleconference

24 Oct 2008

Attendees

Contents

XML Events 2

Handlers Module

Script Module

Fallout of M12N 1.1

Fallout of M12n

XHTML Mime

XHTML2 Roadmap

Next Face2Face

Summary of Action Items

Scribe.perl diagnostic output