See also: IRC log
<inserted> scribenick: oeddie
<trackbot> Date: 24 October 2008
<Steven> Meeting: XHTML2 WG FtF, Day 2
RM: did you make changes?
RM: in draft dated 20th
RM: went through list and made
... eventtarget name of changed attribute
... main piece
<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
<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
... 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
... 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
... not sure let decisions about current UAs color the answer
... should say registered prior to onLoadFire
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: such that handlers may listen for onLoad event
SM: can't decide where need to
... in addEventListener description?
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
... 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?
... (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
... 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
... or just advice
... more than advice -- have to do it
RM: have to cause script to get executed in some way to get activated
RM: need something similar here
SM: where in doc?
RM: processing model, isn't
... make topic in subsection 3 - subject of how to cause listeners to be registered
... after event scope
SM: don't need to do in real time - will edit and we can revisit
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
SM: script element that would say "here are my handlers"
RM: script that is only a
... 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
RM: shane also included in dialog
SM: handler element included in handler module, right?
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 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
... 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
... how if going to attach to handler
SP: action element is a
... 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
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
... 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
SM: no such element
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
... 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 ????
... 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
... 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 -
... 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
BREAK FOR 30 MINUTES
i/see also/Previous: http://www.w3.org/2008/10/23-xhtml-minutes.html
<ShaneM> listener says handler="#foo"
<ShaneM> <handler src="whatever" />
<ShaneM> <handler src="whatever#someActionElement" />
<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?
SM: guess i'm fine with that -
would be as easy to put function on listener and be done with
... handler module describes action element and way to declaratively define handlers
<ShaneM> <handler id="myhandler" src="#someActionElement" />
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
RM: one is fragment identifier - URI or function name
SM: that would work today, for what it is worth
SP: URI, not CURIE
RM: function: would also be URI
SP: then have to go to IETF
SP: Bjoern Hoehrmann to register schemes widely used and not registered anywhere -- ran out of time or cycles
RM: function name with brackets
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
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
... replace scheme with http still works
SM: within iPhone architecture itself - when install app, can register scheme
SP: as handler you know # defined
... then need to look there to find out if can use fragments
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
<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
... not sure if need handler and function simultaneously
SM: function called when the event reaches observer
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
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
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/
SM: can do now or later
... HTML4.01 script that we care about
<alessio> thx 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
... 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
... 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
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
... 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
SM: think inherited from HTML 4.01
RM: add to XHTML 1.2?
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
... now have: @src, @type, @implements - do we need @defer? think has no semantics and should skip
RM: if have no use for it, leave
... 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
RESOLUTION: keep everything from XHTML 1.0 definition of script
RM: finished topic?
SM: think so
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
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
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
... Basic so new, don't think there is errata for that yet
... www-html-editor where to find errata?
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
SP: isn't myakura our Basic rep -- he is here now, so let's ask him
<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/
<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"
<Roland_> I do not, but my "vanilla" dog didn't really like stamps
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
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
RM: Shane had dialog with commentor
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
RM: this is Note produced by
... talks about XHTML1 versus HTML 4.01
SM: historical data
RM: Introduction: brief summary
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
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
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> 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
... remove about transforming into HTML?
... haven't removed any guidelines, but rules in 1.0 still in document - backwards compatibility there
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
... 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
... 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 -
... 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
... 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
... 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
... 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
... 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?
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
... 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
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
... 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
... 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
... 22 application/xml and the DOM
SM: get rid of it?
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
... 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
... 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
... if scripting is enabled, contents of noscript parsed as CCDATA if script parsed as CDATA
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
... 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
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
... Metadata Attribute Collection
SP: CC message to group or just to ODF inquirer?
<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
... 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
SP: pretty far advanced - things
don't have implementations for in XHTML2 (frames replacement
stuff) and @src and @href everywhere; alessio helping on all
... implementation of features demonstration in good shape
SM: what version of XForms including?
SP: anticipating XForms 1.1
SM: XML Events 2, too?
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?
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
... should make sure we should do that
SM: where 1.2 or 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].
<Steven> thanks ALessio
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/wen/went/ Succeeded: i/Date: 24 October 2008/scribenick: oeddie Succeeded: i/SM: added @eventtarget/ScribeNick: oedipus_laptop Succeeded: i/SM: issue remaining/ScribeNick: oedipus Succeeded: s/""/"/ FAILED: s/relae/replace/ Succeeded: s/if/id/ Succeeded: s/invoke a script/invoke a script function/ Succeeded: s/Shiva/Chiba/ FAILED: i/Attendees/Previous: http://www.w3.org/2008/10/23-xhtml-minutes.html FAILED: i/see also/Previous: http://www.w3.org/2008/10/23-xhtml-minutes.html Succeeded: s/"whatever()"/"whatever"/ Succeeded: s/tried/Bjoern Hoermann/ Succeeded: s/mann/mann tried/ Succeeded: s/Hoer/Hoehr/ Succeeded: s/SP/RM/ Succeeded: s/@/#/ Succeeded: s/Regrets+ alessio// FAILED: s/of nothing/no problem/ Succeeded: s/id/@id/ Succeeded: s/source/src attribute/ Succeeded: s/implement/implements/ Succeeded: s/remove @defer from script element/keep everything from HTML 4.01 definition of script/ Succeeded: s/keep everything from HTML 4.01 definition of script/keep everything from XHTML 1.0 definition of script/ Succeeded: i/RM: topic haven't addressed/Topic: Fallout of M12N 1.1 Succeeded: i/RM: topic haven't/TOPIC: Fallout of M12n Succeeded: s/may/my/ FAILED: s/mayakura/myakura/ Succeeded: s/would e/would be/ Succeeded: s/1.0/1.1/ Succeeded: s/TOPIC: M12n/TOPIC: XHTML Mime/ Succeeded: s/n't// Succeeded: s/n't// Succeeded: s/paragraph/paragraph?/ Succeeded: s/3.4/3.2/ Succeeded: s/trhough/through/ WARNING: Bad s/// command: s/SM: 3.3 'application/xml'/SM: 3.2 application/xhtml+xml Succeeded: s/utf-i/utf-8/ Succeeded: s/B/A.10/ Succeeded: s/37 iframe/27 iframe/ Succeeded: s/planning/XForms is planning/ Found ScribeNick: oeddie Found ScribeNick: oedipus_laptop Found ScribeNick: oedipus Inferring Scribes: oeddie, oedipus_laptop, oedipus Scribes: oeddie, oedipus_laptop, oedipus ScribeNicks: oeddie, oedipus_laptop, oedipus Default Present: ShaneM, Executive_3, oedipus Present: Alessio Charlie Executive_3 Gregory Nick Raman Roland Shane ShaneM Steven Uli oedipus Masataka_Yakura(remote) Gregory_Rosmaita Regrets: MarkB Tina Agenda: http://www.w3.org/MarkUp/xhtml2/wiki/2008-10-FtF-Agenda#Friday:_2008-10-24 Found Date: 24 Oct 2008 Guessing minutes URL: http://www.w3.org/2008/10/24-xhtml-minutes.html People with action items: shane WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]