See also: IRC log
<yamx> Sorry, late. I will call in.
<oedipus> associated issue: http://www.w3.org/html/wg/tracker/issues/52
<ShaneM> is all the issues
<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
... 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
... 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.
<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
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
<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?
Steven: We are chartered to do it
Roland: What do we have to do?
<ShaneM> Proposed CR end date for RDFa is 18 July
Steven: There are lots of
... 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."
... 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
<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....
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
... 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!
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 :)
<Roland> Venice: http://www.w3.org/2008/02/18-xhtml-minutes.html#item06
<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
... since we reference RDFa normatively, we have to follow it one step behind
<oedipus> scribe: oedipus
SM: haven't put out PWD in 2
... 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?
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
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)
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
<Zakim> oedipus, you wanted to ask what is most efficacious feedback stream for XHTML2?
SP: send to WG as email with
suggestions and examples
... 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
... 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
... 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
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
... 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
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
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
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: 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
SM: not marked "implemented" -
means hasn't been fixed
... suggest we do in alphabetic order
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
... 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
SP: feature request to sysreq -
use ID for resolutions in perl script that generates
... will send in issue request now
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
... 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"
... next issue in same section also from Jim Ley
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]
SM: "attributes without
... 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
SM: WG did not want use for class
RM: need to start devoting significant time and effort on this
SM: biggest criticism WG has had is non-responsiveness to public issues
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
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
RM: marking as closed?
SM: marking as go
RM: don't want to have to revisit in a few months
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
... 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
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
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
<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
<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
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
... 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
SP: and attribute is used by OBJECT
SM: meant in HTML4
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
TH: sort out JimL's issue by
clarifying his misunderstanding -
... need to sort issues out -
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 -
... response is "embedded content is not in the stream"
<yamx> Yam: +1 (quite natural)
RESOLUTION: Issue 7733 closed by responding "embedded content is not in the stream"
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
<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
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
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
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
... 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?
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
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
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
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
SM: 7738 editorial request - think should just do it
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
... 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
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
RM: also DISELECT which is intended to run client side and takes expressions so can change at runtime
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
... embedded resource in its block and everything related to that
RM: high-grade with own anchor
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
<img src="holiday" srctype="image/png, image/gif;q=0.5">
An image of us on holiday
<img src="temperature-graph.png" srctype="image/png">
<caption> Average monthly temperature over the last 20
<tr> <td> 4</td><td> 2</td><td>
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
<yamx> 66 minutes?
===== BREAK FOR 66 MINUTES FOR LUNCH ======
<yamx> see you later.
RM: start at quarter to hour
it's 8:54 AM local time
<Steven> good plan
RM: afternoon session start continuing with XHTML2 review
SM: completed looking at embedding buckets
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]
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?
<img alt="blah" src="blach.png"><label>Blah</label></img>
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
... 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
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
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
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
<Steven> I can live with that
RESOLUTION: @style is deprecated/eliminated; STYLE element can be used outside HEAD
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?
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
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
... recording resolutions in tracking system
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?
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
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
... leave in state of feedback - send and await answer
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
SP: if no one else wants it i will take it
RM: list of open sections?
SM: master list in control
... 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]
SM: Issue 7881 related to 7828
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
SM: requested example of L versus
BR from submiter
... many requests to have BR reinstated
SP: thought agreed to do it
(Shane experiences technical difficulties)
TH: use case for 7882 doesn't make sense
... 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
SM: 7885 - DFN
TH: nothing to do with italics
and i and typography - has specific semantic
... argument is "traditional typographers"
SP: means don't want just I
RM: agree to put DFN in?
SP: don't remember removing
... 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
... probably inline - PCDATA or text
... can't have DFN that is a DIV
<yamx> I have access to w3c.
SM: 7899 already agreed
SM: section on XForms
... 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
... autocomplete attribute
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
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
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> 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
SM: Issue 7726 - Add XInclude
... 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
<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
(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
SM: CSS3 not going to be ready soon
SP: been in CR since june 2007
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
SM: not in issue tracking sytem - will close issue
SM: John Boyer submitted a couple of issues
8029 - Issue with phase attribute in XML Events 2
SM: additional @target
SP: done that
Issue 8029 closed
SM: if and while attributes -
evaluation context not defined - we have done with XPath
... context is there is no context
Issue 8031 - XML Events with repeated content
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
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.
SM: new update in response to latest comments
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
... think we should just go for it
... suggestion is change this so those are normative definitions?
GJR, ok with me
<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]
SM: decided to postpone access
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
<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
<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
SP: RDFa providing implementations
RM: roadmap POV - get to CR
... CURIEs and Role into CR in July 2008
SM: works for me
RM: new draft of XHTML2 by end of next week or end of month
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
... 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?
SM: would prefer we do
... 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
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/inb/in/ Succeeded: s/ a / the / Succeeded: s/Scribe: Steven/Scribe: Steven_/ Succeeded: s/FY:/FYI:/ Succeeded: s/form/from/ Succeeded: s/to XML/to XHTML/ Succeeded: s/@sourcetype/@srctype/ Succeeded: s/prt/rt/ Succeeded: s/prlbem/problem/ Succeeded: s/8.1/18.1/ Succeeded: s/ahve/have/ Succeeded: s/with 3/with 2 or 3/ Succeeded: s/windo/window/ Succeeded: s/mech/mechanism/ Succeeded: s/into XHTML2/into XHTML2 Doctype Section/ Succeeded: s/RM: 1/SP: 1/ Succeeded: s/need style/need @style/ WARNING: Bad s/// command: s/RESOLVED: @style is deprecated/eliminated/RESOLVED: @style is eliminated Succeeded: s/XHTML1/XHTML1.1/ Succeeded: s/= note/-- note/ Succeeded: s/evaluation/evaluation context/ Succeeded: s/XForms/XForms'' problem/ WARNING: Bad s/// command: s/@style is deprecated/eliminated/@style is eliminated WARNING: Bad s/// command: s/@style is deprecated/eliminated/@style is eliminated/ WARNING: Bad s/// command: s/RESOLVED: @style is deprecated/eliminated/RESOLVED: @style is eliminated Succeeded: s/RESOLVED: @style is deprecated/RESOLVED: @style is eliminated/ Found Scribe: Steven_ Inferring ScribeNick: Steven_ Found Scribe: Steven Inferring ScribeNick: Steven Found Scribe: oedipus Inferring ScribeNick: oedipus Scribes: Steven_, Steven, oedipus ScribeNicks: Steven_, Steven, oedipus WARNING: Replacing list of attendees. Old list: Roland Steven Gregory_Rosmaita Tina ShaneM yamx Alessio Yam New list: Roland Gregory_Rosmaita yamx Alessio Steven ShaneM Tina Default Present: Roland, Gregory_Rosmaita, yamx, Alessio, Steven, ShaneM, Tina Present: Roland Steven Tina Gregory_Rosmaita Alessio Yam ShaneM Agenda: http://www.w3.org/MarkUp/xhtml2/wiki/2008-06-FtF-Agenda0401 Got date from IRC log name: 19 Jun 2008 Guessing minutes URL: http://www.w3.org/2008/06/19-xhtml-minutes.html People with action items: - add answer brain combine cycles devote roland shane shanem steven text[End of scribe.perl diagnostic output]