XHTML2 WG Virtual FtF Day 3 -- 19 Jun 2008

<ShaneM> omw

<Steven> http://www.w3.org/2002/09/wbs/32107/xhtml2summer08/

<yamx> Sorry, late. I will call in.

<oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2008Jun/0045.html

HTML5 and XHTML 1.*

<oedipus> associated issue: http://www.w3.org/html/wg/tracker/issues/52

<ShaneM> http://www.w3.org/html/wg/tracker/products/1

<ShaneM> is all the issues

<Steven> http://www.w3.org/2007/03/HTML-WG-charter.html

<oedipus> HTML5 Diff From HTML4 WG Note: http://www.w3.org/html/wg/html5/diff/

<Steven> The word "XHTML" doesn't appear in their charter

<oedipus> "The HTML 5 language has a "custom" HTML syntax that is compatible with HTML 4 and XHTML1 documents published on the Web, but is not compatible with the more esoteric SGML features of HTML 4, such as <em/content/. Documents using this "custom" syntax must be served with the text/html MIME type"

<oedipus> The other syntax that can be used for HTML 5 is XML. This syntax is compatible with XHTML1 documents and implementations. Documents using this syntax need to be served with an XML MIME type and elements need to be put in the http://www.w3.org/1999/xhtml namespace following the rules set forth by the XML specifications. [XML]

<oedipus> Below is an example document that conforms to the XML syntax of HTML 5. Note that XML documents must have an XML MIME type such as application/xhtml+xml or application/xml.

<yamx> I am wondering... hmmm..

<yamx> Their notification is not productive...

<Steven_> "XHTML� 1.1 - Module-based XHTML (REC) - track errata, publish third edition as required"

<oedipus> "This specification is intended to replace XHTML 1.0 as the normative definition of the XML serialisation of the HTML vocabulary. [XHTML10]"

<ShaneM> I believe our charter is clear - we are responsible for maintaining and evolving XHTML 1 and XHTML 2. The HTML Working Group's charter does not mention XHTML at all.

<yamx> I agree with Shane.

<Steven_> Scribe: Steven_

<oedipus> HTML WG charter states: "An extensible, serialized form of such a language, using XML"

<oedipus> "The HTML WG is encouraged to provide a mechanism to permit independently developed vocabularies such as Internationalization Tag Set (ITS), Ruby, and RDFa to be mixed into HTML documents. Whether this occurs through the extensibility mechanism of XML, whether it is also allowed in the classic HTML serialization, and whether it uses the DTD and Schema modularization techniques, is for the HTML WG to determine."

Roland: Our charter mentions work on XHTML, including 1.0
... So if we create a 1.2 that would crystalise the situation

Shane: I agree
... I have it in writing from Chris Lilley that we can do a 1.2

<oedipus> institutional angst is but the tip of the existential iceberg

Roland: We should raise it at the HCG
... it is clearly in the charters

Tina: Regarding 1.2
... quoting above, it says that HTML5 replaces XHTML 1.0
... so what about XHTML2?

<yamx> They cannot replace XHTML2...

Shane: They are trying to orphan XHTML2

<yamx> They will change "Relationship to XHTML 1.x" to "Relationship to XHTML m.n". :-)

Shane: we need to respond forcefully
... By charter we are responsible for the XHTML series, and HTML5 is not chartered to do that

Tina: Is Mike's response a formal one from the WG?

Gregory: We haven't discussed it in the group

Shane: So they made the change without discussion

Tina: We should reply that we are chartered to do that work

<yamx> ... I just cannot understand how they work in HTML5....

Roland: We should keep it short, and not debate the points

<oedipus> root of problem: (from Status of this Document) - "The latest stable version of the editor's draft of this specification is always available on the W3C CVS server and in the WHATWG Subversion repository. The latest editor's working copy (which may contain unfinished text in the process of being prepared) is available on the WHATWG site. "

Shane: We should reply that they should remove all text that gives the impression that they are producing XHTML

<yamx> I agree.

<oedipus> amen

<yamx> I support the resolution.

<ShaneM> Rationale... they are introducing confusion in the marketplace and damaging the brand that is XHTML. This is harmful and misleading.

PROPOSED RESOLUTION: The WG recognises that we are chartered to maintain and develop the XHTML series, and the HTML5 specification should therefore not contain text that makes it appear differently

<yamx> yes.

RESOLUTION: The WG recognises that we are chartered to maintain and develop the XHTML series, and the HTML5 specification should therefore not contain text that makes it appear differently

<oedipus> +1

<Tina> +1

<ShaneM> In particular, HTML5 is NOT empowered to supercede XHTML *anything*

<scribe> ACTION: Roland to reply to HTML5 WG to communicate our resolution on XHTML naming [recorded in http://www.w3.org/2008/06/19-xhtml-minutes.html#action01]

<Steven> Scribe: Steven

<ShaneM> Proposal: Re-issue XHTML 1.0 removing appendix C and pointing to XHTMLMIME.

<oedipus> that will be VERY helpful

Shane: Would that be a good idea?

Gregory: Yes

Steven: We are chartered to do it

RDFa

Roland: What do we have to do?

<ShaneM> Proposed CR end date for RDFa is 18 July

Steven: There are lots of implementations
... so the CR period will be short
... we have XHTML 1.1+RDFa
... and we can merge that with @role and so on, and create 1.2

Roland: Is the media type issue resolved?

Shane: Maybe not

Steven: Not clear. TimBL has sent a new message; not clear if that reopens the issue

Shane: He has an issue about how you ask the server for the RDF involved with a document
... but I think the media type issue is solved
... the peripheral issue is about 'announcement'; how an author says that a document contains RDF
... Ralph in his recent message

<oedipus> "If saying SHOULD for *any* of the 3 document conformance options 4, 5, or 6 leaves the reader with the impression that NOT doing any of the three means the author has NOT intended to state these triples then I would agree with your concern. However, these SHOULDs are there for 3 different reasons."

Shane: http://lists.w3.org/Archives/Public/public-xhtml2/2008Jun/0056.html
... suggests that authors MAY add version information
... any opinions?
... I've never used MAY in this context

Steven: I have trouble understanding what Tim really wants

<oedipus> RFC2119 def of MAY: This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with red

Shane: I mean more generally, what does it mean to say MAY for the author

<ShaneM> http://www.w3.org/MarkUp/2008/ED-rdfa-syntax-20080616/#docconf

<oedipus> GJR thinks SHOULD should remain SHOULD

Steven: Ralph seems to want to be able to extract RDF from a doc without a DOCTYPE, or a version, or a profile

Shane: Yes, and he thinks Tim does too

<yamx> I agree with Steven on putting "MAY" for author conformance... But maybe it is because usually we avoid any document conformance....

<oedipus> http://lists.w3.org/Archives/Public/public-xhtml2/2008Jun/0054.html

Shane: But I don't agree that that is what Tim wants
... he seems to be a big supporter of GRDDL

<oedipus> "You could say, (2) "All servers MUST put the namespace GRDDL, and clients MAY use namespace GRDDL, or may use inherent knowledge of the spec." That would work in all cases." [...] "So I suspect you want go with (2). To define RDFa conformance. Obviously, people might want to make documents in the short term which work equally well by conforming to the GRDDL spec (document profile method) and by RDFa but that is a distraction."

Steven: GRDDL is not harmful to RDFa

Shane: CR may be held up by Tim's comment
... we may be asked to quickly decide on changes to the conformance clause to fix this objection

<yamx> see you later.

Shane: the TF has been told verbally that the changes they had made would satisfy Tim's objection.

==== 2 min break ===

=== bacl at xx:25 ===

<oedipus> if i don't use a speaker phone, i often inadvertantly cover the mouthpiece so it is easier for others if i use speakerphone

<yamx> alessio, p3!

<yamx> Thanks.

rrsgent, make minutes

<oedipus> FYI: open accessibility (open a11y) uses XHTML 1.0 strict but is migrating to 1.1+RDFa for specifications and documents

<scribe> ACTION: Steven to start an implementation page on the wiki [recorded in http://www.w3.org/2008/06/19-xhtml-minutes.html#action02]

<oedipus> FYI: http://xml.house.gov/drafting.htm

<alessio> gregory, as IWA/HWG we are present in that WG with three people :)

<oedipus> hooray!

XHTML2

<Roland> Venice: http://www.w3.org/2008/02/18-xhtml-minutes.html#item06

http://www.w3.org/MarkUp/2007/ED-xhtml2-20071024/

<oedipus> GJR would like to make some specific suggestions (e.g. use global @src on Q for URI/IDREF and redefine @cite to contain human parseable info of the type of info encased in CITE element )

Roland: We still need to do some work

Steven: RDFa has been the main gating factor
... since we reference RDFa normatively, we have to follow it one step behind

<oedipus> scribe: oedipus

SM: haven't put out PWD in 2 years
... everytime propose new PWD, get objections -- need to get a snapshot up
... updates from 2 years ago need to be effected

RESOLUTION: Issue a new XHTML2 Public Working Draft

<yamx> no objection from me.

RM: next steps after publication?

<Steven> +1

<alessio> +1

<Tina> +1

RM: do we want XHTML2 to be all-encompasing or refer to modules

SP: refer to modules - actually, depends on what you mean

<Steven> Yes, modules

<Steven> + refer to XForms 1.1

RM: XML Events on spec track, Access on spec track, etc. -- don't want to have to go through last call again - XHTML2 should incorporate modules externally defined

<Steven> RDFa

SP: include RDFa and XForms 1.1

<Steven> + access + role

<Steven> + XML Events

SM: had rule that XHTML author should be able to use XHTML2 spec to get enough info to write documents; should be able to find content model and syntax in XHTML2 - misguided - people write books to do that - can point to other specs to help keep in sync

<Steven> I can live with that if there are good enough links to definitions of elements and attributes elsewhere

RM: Events, Handlers and Script modules (new XML Events in 3 Modules)

<ShaneM> http://www.w3.org/MarkUp/2007/ED-xhtml2-20071024/xhtml2-doctype.html#s_doctype

SM: if want to change philosophy of what ought to be in spec, should do consciously
... need to update section cited above and remove some other chapters - should be sufficient

RM: minimal work to publish new PWD that refers to latest state of things been driving forward

<scribe> ACTION: ShaneM - incorporate Access, Role, XML Events (in 3 modules: Events, Handlers, Script), and RDFa modules through external reference to XHTML2? [recorded in http://www.w3.org/2008/06/19-xhtml-minutes.html#action03]

RM: how long will that take, shane?

SM: can have by monday

RM: new PWD by end of june

SM: perfect

<Zakim> oedipus, you wanted to ask what is most efficacious feedback stream for XHTML2?

SP: send to WG as email with suggestions and examples
... one implementation strategy is to try and create set of javascripts that implement XHTML2 - XHTML2 with script to work in existing browsers
... half of that is on the way with IBM's ubiquity -- XForms, but the heart of it - a lot can be done with CSS in XHTML2 that authors are familiar with, remaining hard bits are HREF and SRC everywhere
... good place to start working is to create bit of script or script library that supports HREF and SRC everywhere

Alessio: i will try to write one
... Access module support in XBL - can transfer solution

SM: XML Events 2 another challanging bit

SP: XForms does XML Events, so ubiquity will move to XML Events 2

SM: uses Events, not Handlers

SP: Handlers derived from XForms
... conditionals from XForms 1.1
... should be referencing XForms 1.1 rather than XForms 1.0
... XML Events is difficult, but ubiquity will help us

RM: implementation of SCRIPT tag through javascript?

SP: danger is UA gets to SCRIPT tag before XHTML2 script does

Alessio: interesting point

SP: may be ok - proof will be in the proverbial pudding

SM: things in scripts don't do inline functions - should declare, not execute

RM: move it all into a single namespace?
... make author's life as easy as can make it

SM: what would that encompass "all"?

RM: XML Events, XML Handlers - take as chameleon to XHTML namespace

<Steven> http://groups.google.com/group/ubiquity-xforms

SP: let's do it and see what reaction is

RM: ARIA Module - should be in here

SM: absolutely think should include ARIA (as aria- ) in XHTML2

Alessio: agree

GJR: agree

<Steven> http://code.google.com/p/ubiquity-xforms/

RM: our view is that we will do aria-

SM: wrt XHTML2, ARIA spec will be rolled in - should add reference to XHTML2.0 doctype chapter

http://www.w3.org/WAI/PF/aria

http://www.w3.org/WAI/PF/aria-roadmap

http://www.w3.org/WAI/PF/aria-primer

http://www.w3.org/WAI/PF/aria-practices

latest drafts 18 june 2008

<ShaneM> Let's offer to help ARIA create a DTD and Schema for their spec that conforms to M12N 1.1

yes, shane - i will work with you on that if you like

RM: discussion aroiund Alessio's work - viewports in source as well as from elsewhere - fact of life need to talk out how to address
... what to do with certain types of elements - XHTML2 include H1 - H6 - should be using H for headings and H1 to H6 in another place

SP: legacy module

SM: agree

Alessio: yes

Yam; yes

GJR: yes

SM: can migrate things to legacy module; rather not craft new module for next week

<yamx> Yam; yes? yes :-)

RM: agree - this is future work - raising bar and dealing with structural and clean authoring - adapting to needs of a11y, ubiquitous, etc

Yam: any enumerated list of issues to resolve for LC of XHTML2?

SP: interesting questoin: have a list of issues that have been raised about XHTML2

Yam: make sub-set of issues we have to clear - work on both sets of issues

SP: shane can provide a URI to tthe database of issues
... strictly speaking, we are a different WG than those addressed to us prior to split of MarkUp

Yam: still need to attend to them

RM: we should start to work through old issues during next hour

SM: 82 issues in incoming bucket that have never been filed
... trying to get URI that includes old and newer issues

<ShaneM> http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues?user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: not marked "implemented" - means hasn't been fixed
... suggest we do in alphabetic order

RM: ok

<Steven> http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/AttribColls?id=7661;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: constrain attribute groups together - could extend syntax to show that was my response, but seems an abstract issue (4 year old comment - 7661)

SP: issue for M12n, not XHTML2 per se

SM: M12n 2 is direct product of work on XHTML2

RM: explainations in prose to schema - might have to switch to RelaxNG

SP: not necessarily -

RM: if want to put in as implementation, need to use RelaxNG - will become issue in LC

SM: marked as "suspended"

SP: add note to say think is good thing for M12n 2

SM: ok
... issue 7783 - already improved - need to add text to @src to clarify when dir applies to source

SP: believe specificied dir only in regard CSS properties
... that would answer question

SM: does it?

SP: if say @dir defined this way and reference CSS - only affects content of element

SM: misconception may arise from @src treated as object
... use of @src to provide inline text
... @src doesn't say thing brought in is in its own context - there is a resolution somewhere, but change yet to be effected to draft

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/Conventions?user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SP: feature request to sysreq - use ID for resolutions in perl script that generates minutes
... will send in issue request now

<ShaneM> http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/Conventions?id=7799;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

<ShaneM> http://www.w3.org/MarkUp/2007/ED-xhtml2-20071024/mod-embedding.html#adef_embedding_src

SM: ISSUE 7799 Jim Ley points out that not clear how deal with quality values in regards source - "Please clarify the section to explain how document quality values, and user agent quality values combine."
... comment reflects on @srctype - clarify in text what we mean by intersection

SP: explanation: in HTML4, one could say type="foo" to specify type of thing pointing at -- doesn't do anything, just a hint - no garuntee that it is true - comment more than anything; made more useful to merge type into HTTP-REQUEST sent for resource; allows one to specify the RDF version of a document - gives control over content negotiation
... haven't specified for quality values
... no answer off top of my head

RM: @src and @srctype - example of a handler element

SM: used to
... good catch -will fix now

SP: needs some brainwork

SM: started to address in XHTMLMIME doc last night in regards requests in general and use of profile parameter as media selector - all dovetail

<scribe> ACTION: Steven - devote brain cycles to solving quality values question [recorded in http://www.w3.org/2008/06/19-xhtml-minutes.html#action04]

SM: ISSUE 7799 is "open" then
... next issue in same section also from Jim Ley

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/Conventions?id=7800;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: "intersection of mime-types" - what does asterisk mean when creating intersections

SP: similar issue - answer fairly obvious - will combine with previous action item

<scribe> ACTION: Steven - combine answer to ISSUE 7800 with answer to ISSUE 7799 [recorded in http://www.w3.org/2008/06/19-xhtml-minutes.html#action05]

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/CoreAttrs?id=7872;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: "attributes without values"
... from issue: "class attribute is defined as NMTOKENS, which in turn is defined as one or more whitespace separated NMTOKEN... but I think it is always legal to specify an attribute with no value. Isn't it? We should make that clear."
... thought this was closed
... marked "The working group intended this be NMTOKENS, and that an empty value be not

permitted.

SM: WG did not want use for class

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/EmbeddingAttrs?user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

RM: need to start devoting significant time and effort on this

SM: biggest criticism WG has had is non-responsiveness to public issues

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/EmbeddingAttrs?id=7730;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: one of family of comments from Jim Ley - please specify something when something goes bad

ISSUE 7730: "If the user aborts downloading whilst the chicken.xhtml resource is only partially downloaded, is the chicken.xhtml resource successful or not? And what should be rendered, the parts of chicken.xhtml that had been downloaded and rendered so far, or should the fallback content be rendered instead? Is the behaviour any different if instead of a user initiated abort, there's an abort caused by the network?"

TH: similar to conversation yesterday

<Steven> (Feature request for id on RESOLUTIONS sent)

TH: if download document that is perfectly valid, document shouldn't be rendered by UA
... if embed fragment, and collection is lost - what then?

SM: diff by the way separate documents (OBJECT or IFRAME) and embedded documents

SP: good question - gut feeling is that any failure should be counted as a failure

SM: what does it mean when fails -- falls back?

SP: if loading of resource fails, fallback content should be used - that's what @src states - if network fails during download, fallback to fallback content

<alessio> +1

<Tina> +1

RM: unpredictable - did or didn't - if succeed, get it, if fails, don't get it and get fallback (which is what it is there for)

SP: need to state explicitly

SM: same argument applies to ISSUE 7731

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/EmbeddingAttrs?id=7731;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

RM: marking as closed?

SM: marking as go

RM: don't want to have to revisit in a few months

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/EmbeddingAttrs?id=7732;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: 7731 same as 7730

SP: different - when talking about @src - if have PDF as target of @src, but if PDF not available/supported should not be an error; errors in @src should ONLY refer to network errors in retrieving source

TH: agree that if you link embedded PDF and is handed off to third-party app, not a failure, but in jimL's example, compromise entire document
... XHTML fragment with host document suddenly becomes invalid host document; processing directive "this has been embedded with @src shouldn't text that for validity"

SP: when process top-level XHTML2 document, and XHTML2 processor not aware/agnostic of mediatype - goes and gets resource; if retrieving resource successful, hands off to plug-in; if not delivered (failure to load remote resource)

RM: not clear from reading def of @src what DOM looks like after it has succeded
... what happens?

TH: embedding mechanism @src doesn't care about content-type or resource?

SP: in loading it, doesn't do anything special for diff mediatypes

TH: separate processor - if resource in form of XML, does XML become part of host document

SM: answer is no

SP: like IMG @src now

TH: can't access that segment via the DOM

RM: that is what is unclear in @src def

SM: intent - anything included by @src works as OBJECT element should - separate entity in displayed document (has own security context, DOM, etc.)

<Steven> Yes, it is a shortcut for object, good description

RM: syntaxic shortcut for OBJECT element? need to make that clear

<alessio> true

SM: if that is what it is, not entirely sure is useful

RM: still going to write HTTP-REQUESTs

SP: reason good is that solves problem with LONGDESC - moving longdesc into document
... keeping separate docs up to date with LONGDESC model very difficult; in this way, keep longdesc in document itself and have best of both worlds

SM: agree that very difficult to maintain LONGDESC, but if only use case, very heavy handed solution

SP: not only use case, but a REALLY good solution for LONGDESC

RM: if want @src to appear in DOM, don't use this - need to clarify
... to have in DOM and manipulate, use HTTP-REQUEST

SP: XForms

SM: no XHR or server-side includes

<alessio> +1 for an embedded LONGDESC

SP: XHR is derived from XForms

+1 for embedded LONGDESC (on user configuration)

RM: don't think so
... restrictions and restraints lacking

SP: should discuss, but XForms instance gives us what we want

SM: if that is the case, it is a non-obvious solution to this problem

RM: if XForms 1.1 isolates network module for getting and putting resources will be easier than XForms today

SP: why? load some resource then use part of them

RM: no, load resource inline in DOM no referencing - just there

SM: mash-up use case -

SP: XForms addresses that in my opinion

SM: text doesn't make it clear and needs clarification - who owns section?

SP: suspect it is me

RM: known issues

SM: @src content embedded, so needs own styling

TH: needs to be stressed as well

SM: SP owns section

PRPOSED ACTION: Steven - add text to make clear that item not in DOM and clarify styling implications

SM: strong argument, RM for other sort of include - proposal would be good

<ShaneM> http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/EmbeddingAttrs?id=7732;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

<scribe> ACTION: Steven add text to @src section to make clear that item not in DOM and clarify styling implications [recorded in http://www.w3.org/2008/06/19-xhtml-minutes.html#action06]

SM: ISSUE 7732 - clarify intersection of what author is asking for and what UA can handle

"Please remove this constraint.

TH: Needs clarification

SM: clarified somewhere - discussed multiple times

TH: if what JimL quotes is correct, then "OUCH!"

SP: trouble is thing is being embedded, so the surrounding XHTML2 processor not going to be displaying it; what XHTML2 processor can display non-issue - encoding matters to what is used to process that doctype

RM: does same issue apply to OBJECT?

SM: don't think is same

<ShaneM> http://www.w3.org/MarkUp/2007/ED-xhtml2-20071024/mod-embedding.html#adef_embedding_encoding

<markbirbeck> Apologies again guys...can't join today. Sorry. :(

<markbirbeck> Will stay on IRC for as long as I can.

TH: seems like matter of semantics - intent of section is to say author may suggest what to request, but UA chooses what can understand

<Steven> http://www.w3.org/TR/html401/struct/links.html#adef-charset

SP: charset attribute used on A, LINK, SCRIPT in HTML4 - renamed at request of i18n
... HTML4 says "this attribute specifies character encoding specified by link" so HTML4 has same problem

TH: fundamental difference - in HTML4 resource specified by link; objection is to "user agent must use this list to indicate what accepts"

SP: HTML4 to XHTML2 - HTML4 @charset specifies character encoding of source specified by link; what if UA doesn't know encoding; no prose about refusing if UA cannot accept - just says "that's the encoding"

TH: problem with any link

SP: XHTML2 adds to accept headers - asks for specific resource and sent off in request headers
... shoujld we use encoding in request, or in accordance with what UA says it accepts
... if answer is yes, combine with what UA can accept, means excluding resources not natively supported by UA (PDF example)
... not issue of UA can handle UTF-8, but if PDF parser can handle UTF-8

TH: still back to semantics - need to sort out -
... not clear to me or authors - doesn't solve problem of what happens if host UA is rendering what it serves

<Steven> So, there is nothing wrong with <img src="foo.pdf" srctype="app/pdf" encoding="utf-8"/>

SP: no business of UA whether can handle UTF-8

TH: that's what needs to be clarified

"The user agent must use this list as the field value of the accept-charset request header when requesting the resource using HTTP"

RM: what is use case of putting source of PDF in there?

SP: just an example

RM: what is the "real" motivating use case for this

SM: just think OBJECT - think about it in that context

RM: so applies to OBJECT

SM: yes

SP: and attribute is used by OBJECT

SM: meant in HTML4

SP: ah

SM: if specified on OBJECT element currently, UA would constrain request

SP: not in HTML4
... design error in definition of @srctype and @encoding in HTML4 - useless comments from which nothing is gained

<alessio> yes

TH: sort out JimL's issue by clarifying his misunderstanding -
... need to sort issues out -

<Steven> http://www.w3.org/MarkUp/2007/ED-xhtml2-20071024/mod-embedding.html#s_embeddingmodule

SP: i don't think there is very much of use case for @encoding attribute - most people don't and won't use it; purely a comment in HTML4; XHTML2 tightening it up for a use, but barely a reason why one would want to use

TH: if use on OBJECT in HTML4, can provided basis for content negotiation

SP: how does UA know what thing which is doing embedding can accept?
... when use OBJECT for a video, not UA that does video, hands off to plug-in

SM: and no way for UA to tell not supported so give me fallback

TH: UA doesn't know what plugin can handle

<ShaneM> How about saying "The encoding applies to retrieving a specific version of a resource to hand off to a resource processor for an embedded attribute. It has nothing to do, per se, with the capabilities of the user agent. We will make it clear in the text that this is the case."

TH: make 18.1 explicit that this is what processor can handle, not User Agent

<Steven> tina breaking up

GJR plus 1 to shaneM suggestion

<Tina> If we can clear up 18.1 to make it explicit that it is the processor that handles the embedded content which use this encoding, and NOT the embedding UA, then we can close the issue.

SM: information that a UA would give to the plugin - handler for associated mediatype - plugin should know to retreive resource or accept resource using this encoding

RM: still have problem figuring out why useful - embedding attribute module

SM: larger question - even if atts only expressed in relation to OBJECT would still have same issues

RM: trouble understanding value of putting this everywhere

SM: issue 7733 - http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/EmbeddingAttrs?id=7733;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1
... response is "embedded content is not in the stream"

Steven: +1

GJR +1

<yamx> Yam: +1 (quite natural)

RESOLUTION: Issue 7733 closed by responding "embedded content is not in the stream"

<alessio> +1

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/EmbeddingAttrs?id=7734;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: also from Jim Ley - visited previously but still open - how to know if a "successful failure" - don't think should say anthing about http

SP: agree

<ShaneM> This specification should not specify anything about how the underlying protocols associated with a URI scheme report success or failure.

SP: http spec already says what is and isn't failure - what begins with a 4 is failure, what begins with 2 or 3 is success

TH: leave to separate protocols to determine what is successful and what is failure

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/EmbeddingAttrs?id=7736;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: 7735 closed
... ISSUE 7736 - what happens when an HREF and an SRC

TH: would embedded content be linkable

SM: content from HREF replaces SRC

SP: no - if a P remains a P

TH: so embedded content linkable - don't see problem

<Steven> I think that <a id="donkey" href="donkey.html" src="chicken.xhtml>chickens</a>

TH: embedded content used as the link, which seems reasonable; some styles to apply to embedded images (A with IMG)
... replace content with CSS

<Steven> is equiv to the present <a id="donkey" href="donkey.html"><img src="chicken.xhtml" alt="chickens"/></a>

SM: anything brought in by @src in own dom tree not in doc tree, but styleable itself, not covered by host document's styling

TH: authors going to assume can still style image used as a link

SM: styling box in which image is contained - effectively defining border

TH: border is part of image element, because img doing the embedding
... not sure going to be clear to authors

SM: counterintuative

TH: issue raises another thing: if embedded content not in DOM and not styled by host, can it be linked?

<ShaneM> Content brought in via the src attribute is placed *within* the surrounding element, so any annotation on the surrounding element would apply to that element. In this case, the href attribute would make the surrounding element (the a) linkable.

TH: use an A element and @src to embed content - what happens to the link?

<Steven> see above example

sounds reasonable

TH: like shane's example

SM: capture that for edit

TH: not eager to explain to author when tries to style inline elements in an A that content is actually embedded

RM: share that concern - need to return to as BIG ISSUE

SM: ISSUE http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/EmbeddingAttrs?id=7737;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1
... ISSUE 7737 - if iframe has link and click on it, what is replaced

SP: not a new problem

TH: IFRAMEs separate content

SP: content of IFRAME gets place

TH: what happens to OBJECT?

<alessio> yes

SM: would need OBJECT to work correctly

RM: Alessio has contribution/suggestions that help

<alessio> my example had a fallback

SP: link will only be activated in context of embedding

SM: agree

TH: then embedded content works as OBJECT?

SM: how OBJECT should work

RM: should container be able to determine where action taken

SM: today UAs don't permit embedded actions in embedded content

SP: browser doesn't get events

SM: go to PDF document with FF and try closing window

SP: same with embedded YouTube clips

TH: need to clarify this

<alessio> true

RM: irritating implementation bug

SP: don't have control over communication mechanism between plugin and browser

<ShaneM> Embedded content is in an independent context, so any links within that content would replace the embedded content, and not effect the surrounding document.

Alessio: why HTML5 created VIDEO and AUDIO elements -- mediatype specific

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/EmbeddingAttrs?id=7738;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: still need to finish 7737 - "both behavior desireable - please suggest to author what happens when executed"
... would like to leave open while discuss what @src does and how to provide both functionalities

TH: author choice and consistency - implemented easier if one handling model

<ShaneM> Embedded content is in an independent context, so any links within that content would replace the embedded content, and not effect the surrounding document. We will examine providing functionality to embed content inline in a specification separately.

SP: agree that there are 2 use cases, but disagree that same mechanism should do both - server side includes, XML includes - do they solve use case or not - one reason why haven't made equivalency - if tech is defined elseshere then don't duplicate

<Steven> http://www.w3.org/TR/2004/PR-xinclude-20040930/

<yamx> thanks.

<Steven> http://www.w3.org/TR/xinclude/

SM: 7738 editorial request - think should just do it

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/EmbeddingAttrs?id=7738;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SP: example chosen to show can do for any source of element type
... styling problem - CSS has no selector to tell you if something replaced or not
... would be good for image - when resource fails, style thusly; when resource embedded, style in this manner

TH: can't style embedded content anyway

SP: if an image has been replaaced want a thick border around it; one that has replaced want @alt value in bold
... how image element to be displayed when there and when not there

SM: how would you do that? if provide fallback and want styled differently, wouldn't i put styling on embedded atttribute?
... object to JimL's example?

SP: he's right, but that's not point of example - example just shows can do on TABLE if want

TH: remind JimL this is an example

SP: only there to illustrate an option
... probably had genesis in response to question "can i do this with TABLE?"

TH: what happens if embed image - doesn't replace TABLE, but fills TABLE with image, but TABLE can't directly embed an image
... how is embedding UA to deal with this in content model - an empty table?
... embedding happens through DOM, won't get to content of TABLE

SM: all the necessary stuff to is in DOM; DOM created before @src processed

TH: first child node of TABLE node what do you get?

SM: TR or CAPTION

SP: replaced elements in CSS-terms -- CSS talks about replaced elements
... content in DOM not replaced -content in presentation changed

RM: complicated, styling implications need to be clarified, as well as what is in the DOM at any point in time

TH: not directly related to issue, but need to investigate - people use javascript to change appearance after DOM loaded

SP: if you change a piece of DOM that isn't displayed, still isn't displayed; if change parent to cause content to be displayed will be displayed

SM: one way to look at this is that we haven't specified how one can tell a @src is successful via the DOM

SP: problem with image already as argued before

TH: can't get to it thorugh DOM - people are going to be confused - will take DIV and first child element TABLE and change, but can't get to TABLE

SP: if they do that will discover what embedding really is
... why spending so much time worrying about @src for HTML @src for anything at all

RM: really only for opaque blocks - not what i exected

SP: should discuss cases of embedding bits of XML and see if XMLInclude solves use case - tool for embedding fragments

<alessio> +1

RM: also DISELECT which is intended to run client side and takes expressions so can change at runtime

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/EmbeddingAttrs?id=7739;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: embedded resources styled with CSS - "If the embedded resource is an XHTML 2 document that is styled with CSS, such that content is positioned at top:-100px;left:-100px, must this content be rendered by a CSS supporting user agent, or is it implementation dependant:"
... embedded resource in its block and everything related to that

RM: high-grade with own anchor

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/EmbeddingAttrs?id=7774;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SP: new WG inherited these issues

SM: tabled pending resolution of other stuff, but now back on this
... ISSUE 7734 - motivation for embedding attributes

RM: most convincing (and perhaps only) case is LONGDESC

SM: should say we can provide addditinoal examples and use cases

SP: 2 examples are equivalent, but that isn't a problem

<p>

An image of us on holiday

</img>

</p>

equivalent to:

<table>

<caption> Average monthly temperature over the last 20

years</caption>

</tr>

7</td><td>

9</td><td>13</td><td>16</td>

7</td><td> 4</td>

</tr>

</table>

</img>

SM: comments abour @srclang

SP: for consistency, @src and @href should be aligned
... @hreflang equiv: @srclang

TH: add to Core?

SP: embedding applies to everything

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/EmbeddingAttrs?id=7892;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

<yamx> 66 minutes?

===== BREAK FOR 66 MINUTES FOR LUNCH ======

<yamx> see you later.

RM: start at quarter to hour

<yamx> yah

it's 8:54 AM local time

<ShaneM> omw

<Steven> good plan

RM: afternoon session start continuing with XHTML2 review

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/I18NAttrs?user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: completed looking at embedding buckets

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/I18NAttrs?id=7883;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SP: no, special markup for that called ITS and people should use that if want to

SM: references ITS
... so what are we missing?

SP: use case - google translates pages automatically, some terms need to be handled specially

SM: that's what ITS is for
... if knows about ITS, then what need for TRANSLATE

SP: became ITS rec in 2007

RM: comment 15 months before that

SM: include ITS in XHTML2?
... don't see why not - wouldn't roll into namespace - can point to ITS with namespace independence
... already created schema and implementation for it

SP: is there a translate attribute in ITS - yes, they do
... in own namespace

<yamx> if you do, no objection.

RESOLUTION: Incorporate ITS (International Tag Set) into XHTML2 Doctype Section

SP: won't delay CR

<ShaneM> ACTION: Shane to add ITS into the XHTML 2 Doctype section [recorded in http://www.w3.org/2008/06/19-xhtml-minutes.html#action07]

<alessio> +1

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/Img?id=7887;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: Issue 7887 -

SP: thought: within XForms, have label, help, hint, and alert - MarkB oft proposed allowing everywhere in XHTML2 as well as XForms

RM: think made that proposal at last f2f

SP: <img label="blah blah blah">

SM: doesn't solve internationalization problem

<Steven> It is <label>Foobar</label>

SP: it is an element

SM: doesn't make sense

GJR like LABEL for FORM in HTML4?

RM: if use title everywhere,

GJR isn't @title for tooltip-type hints and alt for labelling in HTML4?

RM: write same in ALT and TITLE because no garuntee of what will happen

<Steven> Roland meant <title>My picture</title>

RM: html doc has TITLE element
... how displayed is separate question

<Steven> that is <img src="..."><title>My house</title></img>

SP: reason for not using title - confusion between @title and TITLE

RM: why XForms has the 4 different elements

<alessio> agree

SP: 1 meant to be rendered, 1 available for reuse, 1 meant to be rendered on user action, visible when error ocurs

SM: what is our plan

<alessio> misunderstanding with alt and title started with IE

RM: opened out - slightly broader - if do here, where else?

<alessio> and the alt showed as a tooltip

SP: within XForms answer is: it is used everywhere - could say is allowed anywhere text content is allowed

RM: the "it" in the circumstance are the 4 elements
... do we need/want all 4 elements everywhere - have an H for purpose

SM: disagree - don't think H is purpose

RM: 1 of 4 will always be rendered - what if have H and LABEL

Explicit Association Pattern Collisions need to be straightened out - cascade or politeness order

http://esw.w3.org/topic/HTML/ExplicitAssociationPatterns

SM: lost thread

RM: what to do with this - open up for 4 state solution

<Tina> Zakim: mute Tina

RM: what are ramifications? what is resolution?

SM: should open up - will mark issue as "suspended" while we deal with it

RM: should we introduce the 4 from XForms into XHTML2
... resolution of that will effect resolution of this issue

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/Intro?user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/Intro?id=7759;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: suspended until LC
... style attribute

SP: personally, don't think style attribute should be in XHTML

Alessio: agree totally

<yamx> it is ok to remove @style attr.

GJR: forms-based web needs inline styles - <span style="speak:spell-out">USA</span>

SP: widely used by spammers to hide stuff

RM: want ability to control some things inline

TH: reminds me of yesterday's discussion of @target

RM: just because one can misuse, shouldn't preclude valid use

SP: requirement from GJR is that can markup but doesn't need @style
... style and presentation should be separate

GJR: agree, but need to use tools we have

SP: better to say want to specify things can be spoken - don't require CSS

RM: we don't but a given author might have CSS around
... example: assembly of fragments - need to specify by STYLE to define a fragment so has style definition and content
... need ability to associate style is a use case, but not necessarily for @style
... through SCRIPT want to define my script in my block and STYLE (element) inline
... not case in older MLs - can't put outside of HEAD
... use STYLE element so can make relevant to discrete blocks of content

PROPOSED RESOLUTION?: @style is deprecated/eliminated; STYLE element can be used outside HEAD

<alessio> +1

<ShaneM> +1

<Steven> I can live with that

RESOLUTION: @style is deprecated/eliminated; STYLE element can be used outside HEAD

<yamx> fine.

TH: users will have use cases for it - this attribute (@style) will continue to be used - what do we do about that

RM: is it in draft?

SP: yes

RM: to be resolved?

SP: always in that state - in, out, in, out, then marked "this is an issue"

SM: marked as issue in draft right now

<ShaneM> http://www.w3.org/MarkUp/2007/ED-xhtml2-20071024/mod-styleAttribute.html#adef_styleAttribute_style

TH: support resolution, but should be consistent in how we deal with controversial attributes (such as @target) - why not give authors option of having it there
... consistent if we can

SM: same argument put forward at f2f 4 years ago at TP -
... deprecated in XHTML1.1

<yamx> if it is already deprecated, we can eliminate it.

s/RESOLVED: @style is deprecated/eliminated/RESOLVED: @style is eliminated

RM: does that satisfy you, tina?

<yamx> "deprecate" is a fair warning for future elimination.

TH: taking out some controversial things and leaving in others

RM: for what has been taken out, have done so because needs been addressed otherwise
... not just style for individual element, but grouping of elements

SM: agree a separate issue - but don't want to return to today

TH: need policy, not adress ad hoc

SM: do have policy about when things are deprecated or removed - remove when suitable replacement that can be recommended

(scribe's note - consult Yam's comment above, as well)

SP: if can show use case can be solved in better way

SM: when features deprecated only done when other things to point to -- good statement to make

<scribe> ACTION: ShaneM - Draft policy statement on migration and evolution [recorded in http://www.w3.org/2008/06/19-xhtml-minutes.html#action08]

<yamx> done deal..

SM: next comment is "please leave @style in"

SP: bimodal issue

RM: here we have is what we believe is an alternative

GJR: example BLOCKQUOTE for formatting in HTML4

SM: 2 options for specifying styles (link)
... recording resolutions in tracking system

tables bucket: http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/Tables?user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/Tables?id=7828;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: never understood this comment (issue 7828)

question: "Why no nested colgroup or rowgroup?"

Alessio: don't understand either

Yam: cannot shed light on it either

SM: reason not to?

TH: semantic reason why?

SP: implementation?

SM: colgroup and rowgroup not supported now

TH: use case described says common use, but sounds like manipulation of data, not valid markup

RM: need to be able to have aggregation of set of columns

TH: can you do with col today?

RM: dojo tables include sorting of rows

GJR notes that this affects @scope (scope="colgroup")

RM: why not just reject

SM: rationale?

SP: don't understand how the markup would help your use case

TH: can do what want to do today with col and id - don't see why would want to nest THEAD and TFOOT

SM: not semantically sensible

RM: suggestion doesn't solve use case - tell us problem, not your idea of solution - what are requirements

SM: ok
... leave in state of feedback - send and await answer

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/Tables?id=7878;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: question is "what is the scope of a header" -- note that we need a better explanation - think this is in wrong bucket - move to structural
... person responsible for TABLE chapter hasn't been active for a few years - would like to reassign - volunteer?

TH: i volunteer, but swamped with work - cannot garuntee complete attention

<yamx> Victim..

SP: if no one else wants it i will take it

RM: list of open sections?

SM: master list in control system
... only see if admin

<scribe> ACTION: ShaneM - create and maintain ownership of wiki page listing who owns what bucket [recorded in http://www.w3.org/2008/06/19-xhtml-minutes.html#action09]

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/Tables?id=7879;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: Issue 7881 related to 7828

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/Tables?id=7881;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: already asked for more info and a description
... follow-ups to public discussion list, so other people chime in
... claims can put in multiple TBODY elements and magic ocurs
... will examine more
... text bucket http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/Text?user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1
... Issue 7876 agreed but marked as open

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/Text?id=7876;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/Text?id=7882;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: requested example of L versus BR from submiter
... many requests to have BR reinstated

SP: thought agreed to do it

SM: ok

(Shane experiences technical difficulties)

TH: use case for 7882 doesn't make sense

SM: agree
... example spurious, but number of people including DanC and TBL who want it back in, so don't really have choice

SP: did agree to restore a while ago

RM: should be implementable in existing browsers

TH: other use cases for BR - so don't mind having back

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/Text?id=7885;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: 7885 - DFN

TH: nothing to do with italics and i and typography - has specific semantic interpretation
... argument is "traditional typographers"

SP: means don't want just I

RM: agree to put DFN in?

SP: don't remember removing it?
... why would we have?

GJR: think still there

SP: think just missed it - don't think we ever took it out

RM: be happy

SP: which module?

<alessio> agree, dfn has a scope

SM: text
... probably inline - PCDATA or text
... can't have DFN that is a DIV

<yamx> I have access to w3c.

SM: 7899 already agreed

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/XForms?user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: section on XForms
... http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/XForms?id=7826;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1
... states: "they are presentational and shouldn't be in structural langauge"

SP: misunderstanding of XForms

SM: not permitted to sub-set XForms, and if didn't have, would compromise XForms

RM: bring up with XForms group

SM: reject request - go tell Forms
... autocomplete attribute

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/XForms?id=7838;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SP: not our issue, please consult Forms WG

RM: already replied that
... you added question - what would they do?
... not in our scope

SM: agree and marked as such

<alessio> +1

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/XHTML-2.0?user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/XHTML-2.0?id=674;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: Issue 674 suspended - decided to use parameter on mediatype
... have to do something about it

SP: if want to do that, have to update RFC, so is our responsibility

SM: ok

RM: who can work IETF process

<scribe> ACTION: ShaneM - write up how WG believes parameters should work on media type and talk with Mark Baker about how to get RFC updated [recorded in http://www.w3.org/2008/06/19-xhtml-minutes.html#action10]

SP: RFC 3236 -
... application+xml has optional profile parameter - section 8 says "this parameter solves short-term problem of ... used only in content negotiation"

SM: XHTML Basic doesn't use it

SP: thought it did

<yamx> we use profile in OMA.

SP: XHTML Basic usage in OMA has different specifications

<yamx> yes.

<yamx> in XHTML Mobile Profile.

SP: looks to me like don't have to update 3236 - can use profile and say "this is the value of profile"

SM: put in language specs?
... if want this, use profile X
... M12n - which families of XHTML you support
... want to address 7726

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/XHTML-2.0?id=7726;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: Issue 7726 - Add XInclude module
... requestor wants XInclude
... think he is wrong - won't replace FRAME or IFRAME

SP: bit complicated, but would solve what TH and i discussed earlier

http://www.w3.org/TR/2004/REC-xinclude-20041220/

http://www.w3.org/TR/xinclude/

<ShaneM> The working group is considering this in the context of the larger issue of embedding resources in documents.

SM: proposed comment
... when have answer, return to issue

RM: reasonable

(no objections logged)

<scribe> ACTION: Roland - investigate what would be involved by adding XInclude [recorded in http://www.w3.org/2008/06/19-xhtml-minutes.html#action11]

SM: next issue: MediaDesc with CSS3

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/XHTML-2.0?id=7729;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: CSS3 not going to be ready soon

SP: been in CR since june 2007

http://www.w3.org/TR/2002/CR-css3-mediaqueries-20020708

SP: not against this, but not rec so can't quote yet

SM: why labelled as open
... notes for Issues 7659 and 7656 need to be broken into individual issues

TH: nothing need to do until broken down

SM: we need to do the breaking down

<scribe> ACTION: ShaneM - break Issues 7659 and 7656 into individual issues so can be addressed [recorded in http://www.w3.org/2008/06/19-xhtml-minutes.html#action12]

SM: handful of items in XML Events

RM: this is what you do now

SM: should put in spec, right?

RM: in new Script Module

SP: 8018 - NOSCRIPT is there because of Document.Write - if can't do document.write, don't need NOSCRIPT - insert NOSCRIPT into document and let SCRIPT get rid of it

RM: what i used to do, what i do now, what i can expect when serve to legacy UA

SM: requirement for NOSCRIPT

SP: replied to guy and he thinks he understands it

SM: i'll find it

SP: explained and said this issue can be closed by mutual agreement
... reply to him, WG and wg-issues

lists.w3.org/archives/public/public-xhtml2

SM: not in issue tracking sytem - will close issue

<Steven_> http://lists.w3.org/Archives/Public/public-xhtml2/2007Aug/0018.html

<Steven_> http://lists.w3.org/Archives/Public/public-xhtml2/2007Aug/0019.html

SM: John Boyer submitted a couple of issues

8029 - Issue with phase attribute in XML Events 2

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/XMLEvents?id=8029;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: additional @target

SP: done that

RM: yes

Issue 8029 closed

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/XMLEvents?id=8030;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: if and while attributes - evaluation context not defined - we have done with XPath section
... context is there is no context

Issue 8031 - XML Events with repeated content

http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues/XMLEvents?id=8031;user=guest;statetype=-3;upostype=-1;changetype=-1;restype=-1

SM: thought Forms WG discussed, but don't know how to fix

"Now, we would like to be able to say that the item element is the target of the xforms-hint event so that one can provide item-specific events. Yet"

RM: done a lot of updates to XML Events 2 covering this, so should suggest they take another look

SP: think his problem is that markup doesn't match DOM tree
... due to repeats expanding DOM tree
... think this is XForms'' problem
... XForms has to define triggering - element repeats causes DOM tree to expand, need to find out what happens with Events - do handlers get duplicated for every repeated sub-tree

SM: should ask to look at document again

RM: DOM tree events are choices they made

SM: assigning XML Events bucket to you

SP: end?

SM: save for the massive "incoming" bucket

RM: 15 minute break then go through other agenda items (update requests) and if time and energy can attack incoming

SM: data point: RDFa group meeting in 3 minutes time - someone from this WG needs to be there

SP: i have to leave at 5

======== FIFTEEN MINUTE BREAK =============

<yamx> ok, see you later.

<ShaneM> CURIE further update: http://htmlwg.mn.aptest.com/htmlwg/curie/

<yamx> This is the first time to make any intensive XHTML2 issue discussion in my 2-year XHTML2 experinece.

<alessio> :)

<yamx> :-)

CURIEs Update

SM: new update in response to latest comments

<ShaneM> http://htmlwg.mn.aptest.com/htmlwg/curie/curie-diff.html

http://htmlwg.mn.aptest.com/htmlwg/curie/

SM: incorporated all changes discussed on tuesday; brief discussion wednesday morning, and updated appendix a to be informative, pointed to normative datatype module, and

<Steven> Are people talking? I hear nothing

SM: not sure what to do about declaring normative

RM: inferred? do we want to define a normative def

SM: M12n doesn't know about CURIEs yet
... think we should just go for it
... suggestion is change this so those are normative definitions?

GJR, ok with me

<alessio> +1

<yamx> PR, no objection.

SM: can we move forward to PR transition based on this draft?

<yamx> CR, no objection.

RESOLUTION: transition CURIEs to CR

RM: good - one down

<Steven> ACTION: Steven to organise CURIEs CR [recorded in http://www.w3.org/2008/06/19-xhtml-minutes.html#action13]

XHTML Access

SM: decided to postpone access

XHTML Role

<ShaneM> http://www.w3.org/MarkUp/2008/ED-xhtml-role-20080617/

SM: update based on f2f discussions - prepared for CR
... incorporate all changes we discussed except links to examples from ARIA - wasn't comfortable putting in at top of Section 3
... tried to remember what we were trying to demonstrate

RM: bad practice <div role="paragraph">

i can get a better example

<Tina> Where was the best-practice bit added?

tina, top of sectoin 3

http://www.w3.org/MarkUp/2008/ED-xhtml-role-20080617/#s_role_module_attributes

<Tina> I'm fine with the wording

SM: example in here now role="navigation sitemap" -- should fix - don't define navigation sitemap

'SM: other examples?

GJR: a real list versus a bunch of lines separated by <br /> or using div /div instead of l /l

<alessio> what about role="video" or role="presentation" ?

RM: appropriate and then inappropriate example

<scribe> ACTION: ShaneM - provide appropriate and then inappropriate example for Section 3 [recorded in http://www.w3.org/2008/06/19-xhtml-minutes.html#action14]

GJR will help ShaneM - there are better examples i can provide

RM: Shane, leaving for RDFa call?

SM: if i can be spared

RM: scheduling

<alessio> and I'll help shane + gregory ;)

RM: how long to take to get thorugh CR transitions?

SP: which ones - depends on how long have to wait for implementations

RM: CURIEs

SP: RDFa providing implementations

RM: roadmap POV - get to CR before july
... CURIEs and Role into CR in July 2008

SP: yes

SM: works for me

RM: new draft of XHTML2 by end of next week or end of month

SM: sure

RM: other significant roadmapping items?

<Steven> Future meetings?

RM: 2 gone to PR - Basic and M12n

SM: 30 day period

SP: out of our hands - happens or doesn'

RM: Role Module to CR timeframe?
... July 2008?

SP: take CURIEs and Role at same call

RM: Access Module holdup?
... waiting for feedback
... XML Events 2
... Last Call for XML Events 2 in July

SP: sounds good if we can
... away first 3 weeks of july

RM: anything else to discuss? will update roadmap this week

<Steven> future meetings

RM: schedule block of time on next few calls to go through rest of XHTML2 issues

SP: future meetings

RM: next scheduled one is at TPAC in south of france (october 2008)

SM: are we meeting next wednesday?

RM: yes

SM: would prefer we do

SP: adjournment?
... great meeting

RM: thanks everybody
... lets keep the momentum -- until next week...

========= ADJOURN ==========

<Steven> thanks Gregory for minuting today

<Tina> oedipus: thank you :)

you are welcome

it's a pleasure to be in a WG that actually lives up to its name!

s/@style is deprecated/eliminated/@style is eliminated

s/@style is deprecated/eliminated/@style is eliminated/

s/RESOLVED: @style is deprecated/eliminated/RESOLVED: @style is eliminated

is ]] the escape for sed?

trying to change s/RESOLVED: @style is eliminated/eliminated to RESOLVED: @style is eliminated

- DRAFT -

XHTML2 WG Virtual FtF Day 3

19 Jun 2008

Attendees

Contents

HTML5 and XHTML 1.*

RDFa

XHTML2

CURIEs Update

XHTML Access

XHTML Role

Summary of Action Items

Scribe.perl diagnostic output