IRC log of xhtml on 2008-06-18

Timestamps are in UTC.

07:42:14 [RRSAgent]
RRSAgent has joined #xhtml
07:42:14 [RRSAgent]
logging to
07:42:20 [Zakim]
Zakim has joined #xhtml
07:42:27 [Steven_]
zakim, this will be xhtml
07:42:27 [Zakim]
ok, Steven_; I see IA_XHTML2()4:00AM scheduled to start in 18 minutes
07:42:38 [Steven_]
rrsagent, make log public
07:43:13 [Steven]
Meeting: XHTML2 WG Virtual FtF, Day 2
07:43:16 [Steven]
Chair: Roland
07:43:50 [Steven]
Agenda: 04
07:44:03 [Steven]
04rrsagent, make minutes
07:44:40 [Steven]
rrsagent, make minutes
07:44:40 [RRSAgent]
I have made the request to generate Steven
07:48:18 [Steven]
mu irc UA copies colours with cut and paste, and they end up as escape sequences in the log which rrsagent doesn't recognise
07:48:23 [Steven]
07:49:03 [oedipus]
drag... can you disable that?
07:51:20 [Steven]
Not as far as I know
07:52:14 [oedipus]
no substitute for good old command line *nix irc
07:54:02 [Steven]
yep, I guess
07:58:10 [oedipus]
emailed Access Module comment requests to UbiWeb, UAAG and SVG
07:59:03 [Zakim]
IA_XHTML2()4:00AM has now started
07:59:10 [Zakim]
08:00:13 [Steven]
zakim, dial steven-617
08:00:13 [Zakim]
ok, Steven; the call is being made
08:00:18 [yamx]
yamx has joined #xhtml
08:00:18 [Zakim]
08:00:46 [Zakim]
08:03:07 [Zakim]
08:03:39 [yamx]
zakim, ??P2 is yamx
08:03:39 [Zakim]
+yamx; got it
08:04:24 [yamx]
It seems like the microphone with my handsets have some problems. I have to take the handset manually to release hand-free mode to speak...
08:09:43 [ShaneM]
08:12:16 [oedipus]
IFRAME Accessibility Inquiry:
08:14:02 [Zakim]
08:14:11 [Steven]
zakim, who is here?
08:14:11 [Zakim]
On the phone I see Roland, Steven, Gregory_Rosmaita, yamx, ShaneM
08:14:12 [Zakim]
On IRC I see yamx, Zakim, RRSAgent, oedipus, Roland, ShaneM, Lachy, Steven
08:14:58 [oedipus]
poetic justice?
08:15:44 [Steven]
08:16:03 [oedipus]
scribeNick: oedipus
08:16:17 [oedipus]
RM: review of yesterday; new review of CURIE received today
08:16:40 [oedipus]
08:17:31 [Steven]
08:17:39 [oedipus]
RM: model response on that submitted on behalf of XForms?
08:17:43 [Steven]
08:18:22 [oedipus]
RM: personal comment from leigh: "We will clear up the wording to help reduce any potential confusion. We
08:18:22 [oedipus]
will also clarify that host languages are only required to use XMLNS for
08:18:22 [oedipus]
prefix definition if the language supports XML Namespaces. Thanks!
08:18:22 [oedipus]
08:19:29 [oedipus]
SM: saw new comments last night; no DTD because the DTD is in M12n -
08:19:53 [oedipus]
RM: we make it clear that there is a separate pointer to one or the other
08:20:15 [oedipus]
RM: put pointer to say definitive definition is pointed to and provide pointer
08:20:36 [oedipus]
RM: defined in one place - need to reference elsewhere
08:20:40 [oedipus]
SM: ok
08:21:11 [oedipus]
SM: comment continues - confused as to why normative - perhaps whole section should be informative
08:21:31 [oedipus]
RM: normative schema can be found here and the normative DTD can be found here, but section not normative itself
08:21:46 [oedipus]
SP: normative bit is syntax - DTDs and schemas just informative
08:21:50 [oedipus]
RM: mixture in section
08:22:04 [oedipus]
SP: either make DTD and schemas normative both or informative both
08:22:15 [oedipus]
RM: normative reference in M12n
08:22:25 [oedipus]
SM: and point to it from informative section
08:22:46 [oedipus]
SM: in the m12n implementation, but is not in modularization itself
08:23:00 [oedipus]
SM: didn't went m12n have dependency on CURIEs
08:23:37 [oedipus]
SP: think good not to link to m12n - people should be able to use CURIEs regardless of implementation method
08:23:48 [oedipus]
SP: DTD and schema informative is ok
08:23:56 [oedipus]
SM: don't mind relaxNG thing
08:24:21 [oedipus]
RM: more general point on what to do with RelaxNG for future - syntax for constraint, not type definitions
08:24:42 [oedipus]
SP: Relax uses schema datatypes to find datatypes - used for program structure
08:25:03 [oedipus]
RM: avoid RelaxNG now
08:25:21 [oedipus]
SP: XHTML2 spec has RelxNG - future will include, but too late to add now
08:25:43 [oedipus]
RM: informative definition of RelaxNG might enhance readability - very editorial, not real request for RelaxNG
08:26:03 [oedipus]
SM: intend to do work on RelaxNG in future, but want to address in cohesive fashion in very near future
08:26:28 [oedipus]
SM: should i redirect comment into tracking system so is logged as LC comment
08:26:32 [oedipus]
RM & SP: yes
08:27:54 [oedipus]
08:28:14 [oedipus]
RM: draft available; email about new tool from olivier
08:28:26 [Steven]
08:28:38 [oedipus]
SM: how to approach
08:28:44 [oedipus]
RM: work our way through document
08:29:19 [oedipus]
08:29:21 [Roland]
08:30:40 [oedipus]
SM: took old one, put in pub system; made least number of changes possible; added appendix and that's where things stand
08:30:53 [oedipus]
SM: diff marked version from previous
08:30:53 [oedipus]
08:31:01 [oedipus]
SM: will help other people
08:31:13 [oedipus]
SM: should approach as new document today
08:31:23 [oedipus]
RM: start at introduction and work our way forwards
08:31:36 [oedipus]
08:32:47 [oedipus]
SP: see part of our implementation strategy for XHTML2 going via script route; scripts that implement XHTML2 part and runs down tree making necessary changes so works within existing HTML browsers
08:33:04 [oedipus]
SP: in that case, many UAs will have to receive as text/html just to serve, so...
08:33:23 [oedipus]
SP: when we say "use of text/html should be limited to HTML-compatible..." -- wonder if that is too strong
08:34:22 [oedipus]
SP: media type is being used to deliver stuff to UA just to get it in there, then - due to scripting - deliver XForms - UA thinks is HTML, and then script does what is necessary to compile into HTML
08:34:46 [oedipus]
SP: want to deliver documents to UAs as text/html, but want to be very careful about definition of HTML-compatible
08:35:02 [oedipus]
RM: distinction not between documents, but capacities of browser;
08:35:13 [oedipus]
SM: browsers that explicitly accept that mime-type
08:35:41 [oedipus]
RM: focus on document negotiating with browser and serving most appropropriate - if wants text/html, give it
08:36:00 [oedipus]
RM: this is XML and that is what we are
08:36:10 [oedipus]
SM: disconnect by the way Roland & Steven
08:36:40 [oedipus]
RM: UA only meant to parse well formed XML, should deliver xml mime-type - you take XML, we have XML, here it is
08:37:02 [oedipus]
SM: if FF claims to accept XML and XHTML, why serve text/html
08:37:17 [oedipus]
SP: no if UA accepts application/xml give it that
08:37:33 [oedipus]
SP: hiccup is use of text/html should be limited to HTML-compatible family documents
08:37:47 [oedipus]
SM: right -- it does say that
08:37:49 [ShaneM]
the use of 'text/html' SHOULD be limited to HTML-compatible XHTML Family documents intended for delivery to user agents that do not explcitly accept 'application/xhtml+xml'.
08:37:51 [Steven]
"the use of 'text/html' SHOULD be limited to HTML-compatible XHTML Family documents"
08:38:17 [oedipus]
08:38:53 [oedipus]
SM: thought intent was not to irritate constituencies using XHTML1 - transitional thing; has to be HTML-compatible, or target UA may not accept it
08:39:03 [oedipus]
SP: depends on our definition of HTML-compatible
08:39:22 [oedipus]
SM: try to explain in Appendix C of XHTML 1.0 - Appendix A of this document
08:39:46 [oedipus]
RM: if UA asks for page and prefers XML, serve as XML; if UA doesn't support XML only HTML, then serve text/html
08:39:59 [oedipus]
RM: document agnostic - can do either thing and respond based on what UA wants
08:40:16 [oedipus]
RM: not document constraint per se, but browser constraint, which we handle
08:40:52 [oedipus]
SP: explicitly mention cases where people doing stuff - implementing XML based languages via scripting; in that case, acceptable to deliver as text/html just to get to UA
08:41:09 [oedipus]
RM: not sure right justification - doc should state what should be done, not justify
08:41:33 [oedipus]
SP: don't want to get into current situation where people claim not XML because being delivered via text/html
08:41:40 [oedipus]
SP: in past didn't care about media types
08:41:56 [oedipus]
RM: this is where should be strong - not about media types, but whether passes series of constraints
08:42:11 [oedipus]
RM: mandating particular doctypes wrong approach
08:42:22 [oedipus]
SP: doctype only current way to declare restraints
08:42:38 [oedipus]
RM: can make assertion against a document through validation -
08:43:07 [oedipus]
RM: can write a doc where all markup valid against mobile profile, xhtml10 and xhtml11 - why have to pick one
08:43:14 [Tina]
Tina has joined #xhtml
08:43:35 [oedipus]
SM: possible to craft doc that can validate against any of our markup family, but this WG has said "have to have doc type"
08:44:18 [oedipus]
SP: if want to declare doc as mobile OK, document has to have basic DTD in front - if someone else declares as foo, need another DTD even if document satisfies both standards, can't validate as both
08:44:41 [oedipus]
SP: rule about doctype to use constrains authors from authoring once and declaring valid for a number of profiles
08:44:44 [oedipus]
RM: correct
08:45:02 [oedipus]
SM: not clear how relevant to document or what we can do
08:45:44 [oedipus]
RM: perfectly acceptable to deliver as XHTML1.0, XHTML1.1, Mobile Profile, HTML5 -- pipe stream can then use text/html or application/xml
08:45:58 [oedipus]
RM: assertion part of document not metadata
08:46:46 [oedipus]
RM: is byte stream acceptable as text/html in HTML4x browser; same byte stream delivered to valid mobile device, then deliver as application/xml; not implicit to byte stream
08:47:09 [oedipus]
SM: media type tells the consumer how to evaluate document - what internal engine to use
08:47:20 [oedipus]
RM: that's not intrinsic to document, but how bind 2 together
08:47:57 [oedipus]
RM: can take same byte stream into FF and whether served as text/html or application/xml works
08:48:03 [oedipus]
SM: side-effects: changes the DOM
08:48:15 [oedipus]
SM: is there anything in doc that is in conflict with your points
08:48:51 [oedipus]
RM: turn around question - how respond to request from UA, not something intrinsic in document - document can legitimately be multiple form (valid in more than one langauge)
08:49:07 [oedipus]
SM: hope that that behavior is encouraged by this doc
08:49:31 [oedipus]
RM: document-centric approach (what to push to browser) rather than responding to UA requests - push-pull or pull-push
08:49:49 [oedipus]
RM: what UA asks for or is capable of understanding determines how we act
08:49:57 [oedipus]
SM: first paragraph of abstract says that
08:50:19 [alessio]
alessio has joined #xhtml
08:50:46 [oedipus]
RM: if browser asks for application/xml send as that - serve what UA prefers; negotiation in pike
08:51:26 [oedipus]
RM: XML higher fidelity, but if only understands one or other, then that is the constraint, not the document
08:51:50 [oedipus]
RM: response from negotiation with UA; this is what i can accept, give me the highest fidelity
08:52:13 [oedipus]
TH: without a DOCTYPE many tools beome impossible to write, such as accessibility checkers
08:52:22 [Tina]
Without a DOCTYPE many tools becomes impossible to write such that they can deliver trustworthy results. Accessibility checkers is one such example.
08:52:30 [ShaneM]
+1 to Tina's comment
08:53:16 [oedipus]
Yam: as mobile UA manufacturer, don't want to be bound to any mime-type - process what we can; interested in using mime-type to advertise browser capability; media type specification or note?
08:54:23 [Tina]
Wouldn't it be far more useful to continue the work on CC/PP instead of using the mime-type, since the mime-type, looked at pragmatically, doesn't really say anything about capability?
08:55:02 [oedipus]
Yam: if note, emphasize 1.0 or 1.1 - from mobile UA viewpoint, this module will clarify how to handle XHTML Basic as well as other XHTML flavors; 2 editorial points: status of document (have to make sure consistent); second in 3.5 say HTML, should be HTML4 other places HTML-compatible; need to define HTML compatible or explicitly state HTML4-compatible
08:55:10 [oedipus]
tina, yes to CC/PP
08:55:10 [Roland]
My comment was not that DOCTYPE should not be used but that a single document can conform to more than one DOCTYPE.
08:55:23 [oedipus]
Yam: profile
08:55:36 [oedipus]
SM: need strategy for that - came up on RDFa discussion this week
08:56:35 [oedipus]
Yam: mimetype profile should require specification of DTD -- can clarify have to use profile + foo; my assumption is have to use profile parameter and in doing so have to specify DTD
08:57:21 [oedipus]
SM: haven't developed concrete strategy there; markB has other ideas; had other suggestions; reasonable to use mimetype but need to do in rec track document or m12n, otherwise, not normative
08:57:30 [oedipus]
Yam: happy with informative
08:58:07 [oedipus]
SM: issue with HTML-compatible and HTML4 - HTML4-compatible would explicitly exclude HTML5 for better or worse
08:58:22 [oedipus]
GJR +1 to HTML4-compatible
08:58:30 [oedipus]
SP: too early to say HTML5
08:58:43 [oedipus]
Yam: don't know anything about HTML5 compatibility
08:58:47 [oedipus]
SM: absolutely right
08:58:57 [oedipus]
SM: HTML4-compatible ok?
08:58:58 [oedipus]
GJR: yes
08:59:03 [oedipus]
Yam: yes
09:00:06 [Zakim]
09:00:10 [oedipus]
RESOLVED: in mimetype document use HTML4-compatible and HTML4-foo wherever appears in document to remove confusion
09:00:23 [oedipus]
zakim, ??P8 is Alessio
09:00:23 [Zakim]
+Alessio; got it
09:00:23 [Steven]
zakim, ??P8 is Alessio
09:00:24 [Zakim]
I already had ??P8 as Alessio, Steven
09:00:56 [oedipus]
RM: what should abstract say that currently doesn't?
09:01:37 [oedipus]
RM: how to make as easy as possible for authors to develop content so can be delivered in multiple mimetypes
09:02:01 [oedipus]
SM: something about title?
09:02:26 [oedipus]
RM: title itself doesn't get to heart of what trying to do - guide for authors on how to develop content so can be served as multiple media types
09:02:36 [oedipus]
SM: understand, but title already well-know
09:03:07 [oedipus]
RM: title - XML Media Type sub-title: Serving XML in an HTML World
09:03:19 [oedipus]
SP: Serving XHTML in Legacy UAs?
09:03:28 [oedipus]
RM: Serving XHTML to Multiple User Agents
09:04:14 [ShaneM]
Delivering XHTML to XHTML and HTML User Agents
09:04:16 [oedipus]
Serving the Most Appropriate Content to Multiple User Agents from a Single Document Source
09:04:24 [oedipus]
RM: who is expected to read?
09:04:29 [oedipus]
SP: olivier
09:04:51 [Steven]
That was intended as a joke, for the record
09:05:08 [oedipus]
SM: consumers of document: all people who hang out on freenode #web who say don't use XHTML because doesn't work
09:05:40 [oedipus]
SM: if can get them to understand ok to serve XHTML to current UAs, then that is a huge win
09:06:37 [oedipus]
Yam: reason document more implemented on mobile browser is no way to specify XHTML Basic or other/multiple host language support; W3C note will gratify my constituency
09:07:43 [Tina]
I find that hard to agree to. Most authors appear not to know how to use XHTML. It wouldn't do the "XHTML Case" any good to have an even larger amount of invalid documents out there that people believe are "just fine" 'cause they render as HTML.
09:07:56 [oedipus]
RM: that's what we were trying to discuss earlier - what UA is capable or ready to accept - i accept A, B, C, D, and E so give me the best one you have
09:08:33 [oedipus]
RM: capability of browser and then if document fits multiple profiles; basic 1 and basic 1.1 - UA conforms to basic 1.0, takes that
09:09:30 [oedipus]
SM: logical conclusion means need to specify somewhere a syntax for the accept headers profile parameter -- markB has proposal; UA has to say in precise and concise way all of the things it accepts
09:10:00 [oedipus]
SM: tokens specified for implements in XML Events 2 - could be that sort of mechanism
09:10:15 [oedipus]
Yam: no other document specifies that
09:10:31 [oedipus]
SM: agree - might push into update of RFC if part of media spec
09:10:48 [oedipus]
RM: should consult with UbiWeb and CC/PP
09:10:51 [Zakim]
09:11:50 [oedipus]
RM: break off as topic that needs attention - problem about UA advertising capabilities and preferences and serving the appropriate content
09:12:03 [oedipus]
SM: markB should be in on discussion
09:13:11 [oedipus]
SM: how to make abstract get to point RM wants reword "documents intended for delivery to user agents that do not explcitly accept 'application/xhtml+xml'. 'application/xml' and 'text/xml' MAY also be used, but whenever appropriate, 'application/xhtml+xml' or 'text/html' SHOULD be used rather than those generic XML media types."
09:13:42 [oedipus]
RM: question of persepective - how to respond to UA's capabilities and preferences
09:13:45 [ShaneM]
XHTML Family documents intended for delivery to user agents that do not explcitly state in their HTTP-Accept header that they
09:13:45 [ShaneM]
accept 'application/xhtml+xml'
09:14:04 [oedipus]
SM: that what you mean, Roland?
09:14:06 [oedipus]
RM: yes
09:15:15 [oedipus]
Tina: problem with it is that everyone knows that an accept head is often misleading - tend to ignore accept headers and HTTP requests; not a road we should formally go down - should not ignore accept
09:15:45 [oedipus]
Tina: understand pragmatic reasons, but uneasy with exception for HTML-family document; should talk with HTTP people
09:15:54 [oedipus]
SP: don't understand what you think we are ignoring
09:16:17 [oedipus]
Tina: UAs use accept header that says "i'll accpet everything no matter what" - then how to decide what to give it?
09:17:07 [oedipus]
SP: accept header should give list of what can actually accept, but with a terminal star to cache ("Save As.." dialog is an example - not refused, but check accept headers to check if can natively deal with it
09:17:38 [oedipus]
SM: according to HTTP spec, permisible to accept *.* -- we're telling people to ignore that
09:18:04 [oedipus]
Tina: formal point of view would mean we are telling people to ignore part of HTTP spec
09:18:12 [oedipus]
SP: not saying that
09:18:16 [oedipus]
SM: think we are, actually
09:18:53 [oedipus]
SM: term "explicitly state" - unless UA explicitly says it accepts application/xhtml+xml don't give it xhtml - that's inconsistent with spirit of HTTP spec
09:20:02 [oedipus]
SP: by saying *.* how do you get xhtml documents in to browsers and parse them correctly; all UAs accept *.*, which means "don't exclude anything"
09:20:20 [oedipus]
RM: these are things UA might say - if this is X do Y, if this is Q do W
09:20:31 [oedipus]
Tina: need to check on *.* support in UAs
09:20:57 [oedipus]
Tina: usual way of writing accept header parsers haven't come across many that accept anything
09:21:20 [oedipus]
Tina: need to investigate further - can we delay discussion so can dig into it a bit?
09:21:24 [Steven]
Here Tina:
09:21:30 [Lachy]
Lachy has joined #xhtml
09:21:43 [Steven]
Opera sends: Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
09:22:18 [oedipus]
RM: peice that is missing; talk about things in abstract not covered in detail - detail goes into media type uses, but don't say what requests might come form UA; accept headers not mentioned in body, just in abstract
09:22:31 [ShaneM]
in our list of explicit rules.... how about if we say "if an Accept header only contains */*, documents SHOULD be sent using media type text/html if they are HTML4 compatible, or as application/xhtml+xml if they are not" or something.
09:22:40 [Steven]
Safari sends: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
09:22:45 [oedipus]
RM: in media type usage, should say "which is the most appropriate"
09:23:01 [oedipus]
TH: worth noting that ones tested so far send a Qvalue with *.*
09:23:19 [oedipus]
TH: who set up
09:23:47 [oedipus]
yoyo: "Welcome to Yoyo Internet Services. We pride ourselves on consistency of service and quality of workmanship. Founded in 1996 by Matt Saunders and Neil Levine, Yoyo has gone from strength to strength despite its overwhelming vacuousity."
09:23:51 [Steven]
Mozilla: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
09:24:18 [oedipus]
"Our mission is to consistently conjugate through dynamism, surrealism and semanticism in order to further our goals of hysterical servlet hypotenae. This autonomy cultivates our duplicitous mercenary valetism in the eclectic dot org arena."
09:24:21 [Steven]
Amaya: <nobr>
09:24:21 [Steven]
09:24:21 [Steven]
09:24:21 [Steven]
09:24:34 [oedipus]
RM: accept header fallback for browser detect
09:24:38 [oedipus]
Tina: not useable
09:24:42 [oedipus]
GJR: easily forged
09:25:08 [oedipus]
Tina: need to point out that should do that
09:25:23 [ShaneM]
Lets add a section for dealing with content negotiation via accept headers explicitly
09:25:24 [oedipus]
RM: process accept headers to determine which of possible types to send - not addressed in detail
09:25:37 [alessio]
alessio has joined #xhtml
09:25:40 [oedipus]
RM: give accept header and respond
09:26:45 [oedipus]
Yam: OMA specifies that UA should advertise their supported mimetypes - send QValues because of *.* - at end smallest QValue
09:26:53 [oedipus]
RM: please send us a pointer
09:26:59 [Steven]
Lynx sends: Accept: text/html, text/plain, application/x-bittorrent,
09:26:59 [Steven]
application/x-troff-man, message/partial, message/external-body,
09:26:59 [Steven]
application/x-tar, application/x-gtar, application/msword,
09:26:59 [Steven]
text/richtext, text/enriched, application/ms-tnef, text/*,
09:26:59 [Steven]
application/x-debian-package, audio/basic, */*;q=0.01
09:27:07 [oedipus]
SM: i introduced that before OMA was OMA
09:27:26 [Tina]
My local Lynx sends text/html, text/plain, text/css, text/sgml, */*;q=0.01
09:28:03 [Steven]
09:28:14 [Steven]
09:28:24 [oedipus]
i often change my lynx settings in response to browser sniffing so i can get into certain sites
09:28:30 [oedipus]
SP: fifteen minute break?
09:28:42 [oedipus]
=== 15 MINUTE BREAK ===
09:28:49 [oedipus]
rrsagent, draft minutes
09:28:49 [RRSAgent]
I have made the request to generate oedipus
09:28:53 [Zakim]
09:28:55 [Zakim]
09:28:57 [Zakim]
09:28:57 [Zakim]
09:28:59 [Zakim]
09:29:00 [Zakim]
09:31:29 [Steven]
Steven has joined #xhtml
09:33:44 [oedipus]
IFrame Accessibility Query:
09:34:15 [oedipus]
first response (S Schnabel of SAP):
09:34:19 [oedipus]
rrsagent, draft minutes
09:34:19 [RRSAgent]
I have made the request to generate oedipus
09:35:53 [Lachy]
Lachy has joined #xhtml
09:37:37 [alessio]
alessio has joined #xhtml
09:41:20 [Roland]
Roland has left #xhtml
09:46:06 [Roland]
Roland has joined #xhtml
09:47:35 [Steven]
09:47:41 [Steven]
zakim, dial steven-617
09:47:41 [Zakim]
ok, Steven; the call is being made
09:47:42 [Zakim]
09:47:45 [Zakim]
09:47:55 [Zakim]
09:48:41 [Zakim]
09:49:05 [yamx]
I joined, but Zakim said nothing...
09:49:06 [Zakim]
09:49:15 [yamx]
Zakim, ??P8 is yamx
09:49:15 [Zakim]
+yamx; got it
09:49:37 [Zakim]
09:49:44 [alessio]
zakim, ??P12 is Alessio
09:49:44 [Zakim]
+Alessio; got it
09:50:00 [Steven]
rrsagent, make minutes
09:50:00 [RRSAgent]
I have made the request to generate Steven
09:50:16 [ShaneM]
FYI - updated CURIEs as per mail from Leigh and our discussion today.
09:51:09 [oedipus]
RM: appendix on capacity guidelines for authors to deliver documents as valid XHTML or XML
09:52:13 [oedipus]
TH: reread HTTP spec - no provision in 14.4 for accept header - only send if explicitly stated, so withdraw my objection
09:52:33 [Tina]
Section 14.1 on the HTTP specification does not explicitly prohibit sending content to an UA which explicitly mention support for a MIME type
09:52:41 [ShaneM]
09:52:44 [Steven]
09:52:56 [oedipus]
s/provision in 14.4/provision in 14.1
09:54:03 [oedipus]
TH: content negotioation is feasible again - since accept explicitly, like to add - please convert XHTML to HTML when delivering to HTML UA; problem is that those using XHTML are doing so poorly in belief that if use XHTML, UA will alert them if something wrong, and then send as text/html
09:54:26 [oedipus]
RM: how should one write one's content to minimize those problems
09:54:55 [oedipus]
TH: do it on server before sending down the pipe; a lot of authors mis-using XHTML - no idea of concepts behind it
09:55:07 [oedipus]
RM: a lot of content generated directly from databases as XML
09:55:19 [oedipus]
RM: automatically emit XML, not XHTML
09:55:24 [oedipus]
TH: technical limitation
09:55:42 [oedipus]
RM: many database servers only support XML, not XHTML --
09:55:50 [oedipus]
TH: can't send structured data to UA
09:55:53 [oedipus]
RM: you can
09:55:59 [oedipus]
TH: not if won't accept it
09:56:21 [oedipus]
TH: won't be structured data you think it is; if send XHTML to HTML user agent will not be interpreted as XHTML
09:57:00 [oedipus]
TH: won't help people structure data - the "out" is that XHTML will be ok when served as HTML and if something was wrong, something would notify me
09:57:22 [oedipus]
SP: people so used to idea to check document source by loading into UA and seeing if looks "right"
09:57:40 [oedipus]
TH: XHTML is an XML langauage - problem with not with code but delivery mechanism
09:58:14 [oedipus]
SP: trying to say, if UA accepts XML media types, use that - fall back to HTML media type as a recourse of last resort
09:58:22 [oedipus]
TH: if fall back to HTML, please transform it
09:58:28 [oedipus]
SP: what to transform?
09:58:41 [oedipus]
SM: if develop according to compatibility guidelines, no need to transform
09:59:07 [oedipus]
TH: trying to up the ante so get people to send valid XHTML to HTML user agents
09:59:35 [oedipus]
RM: document in general write as XHTML and if valid, XML-based browser will serve it
10:00:14 [oedipus]
SM: if not going to follow guidelines, then ensure that you transform your content before delilvery to HTML browser?
10:00:57 [oedipus]
TH: please transform to language browser supports - can automatically transform XML
10:01:22 [alessio]
old test page with server content negotiation:
10:01:24 [oedipus]
SP: saying that, but not quite in those words; compatability guidelines - if serve as text/html, text should be in this form
10:01:50 [oedipus]
RM: 2 alternatives: write to compatability GL to ensure XHTML can be parsed by HTML UA, if not, then need to transform into HTML
10:01:56 [oedipus]
TH: want it to be VERY explicit
10:02:17 [oedipus]
RM: can make explicit that one can write to GL or transform XHTML to HTML
10:02:38 [oedipus]
TH: matter of finding good tech solution - which exist, so not the major problem
10:02:43 [ShaneM]
ACTION: Shane craft text to about transformation of XHTML to HTML.
10:03:55 [oedipus]
SP: why an Appendix A and then Appendix 2?
10:03:58 [oedipus]
SM: odd...
10:04:23 [oedipus]
SM: first one Processing Instructions should be A1
10:04:45 [oedipus]
s/should be A1/should be a 1
10:05:17 [oedipus]
SM: attempted to take old guidelines, port them here, and clarify style - want to recast as clear instructions as to what should and should not do
10:05:31 [oedipus]
SM: original text still in draft for WG review
10:06:04 [oedipus]
SM: problem with way written previously, not clear what one supposed to do -- explained compatiblity risks and ways to work around them
10:06:20 [oedipus]
SM: don't use processing instructions PERIOD etc.
10:06:36 [oedipus]
SM: questions about approach or my take on problem?
10:07:14 [oedipus]
RM: need good example illustrating all principles - second, when state "do not" include a "do"
10:07:34 [oedipus]
RM: need to be crystral clear about what should do and not do
10:07:43 [oedipus]
SM: not a corresponding "do" for first guideline
10:08:00 [Steven]
10:08:01 [oedipus]
RM: general principle: not leaving to people to infer what one should do and not do
10:08:08 [oedipus]
SM: the "do" should come first
10:08:10 [oedipus]
RM: yes
10:08:19 [oedipus]
SM: objections to GL1?
10:08:44 [oedipus]
SP: no objection - use of word of "legacy" potentially distraction
10:09:28 [oedipus]
"Processing Instructions and the XML Declaration" should be A.1
10:09:57 [oedipus]
RM: break out a warning - stronger than "remember, however..." - pull out and make clearer and stronger
10:10:42 [oedipus]
SM: next one "A.2. Empty Elements" - Roland, you requested i change this
10:10:48 [oedipus]
RM: can't remember what i said
10:10:54 [oedipus]
SM: combined A.2 and A.3
10:11:19 [oedipus]
SP: A.2 about elements that can only be empty and A.3 about elements that normally aren't empty, but can be
10:11:28 [oedipus]
RM: have to know certain elements can only be empty
10:11:44 [oedipus]
RM: about a dozen
10:11:59 [oedipus]
SM: will paste in "live" URL
10:12:24 [oedipus]
FYI: A.3. Element Minimization and Empty Element Content
10:12:47 [oedipus]
Tina: no comments on A.1, and A.2 seems reasonable
10:13:11 [oedipus]
SP: interesting to note that A.2 in "normal" UAs isn't an issue
10:13:26 [oedipus]
Tina: older agents need space
10:13:42 [oedipus]
SP: not advocating deletion, just noting a peculiarity
10:13:51 [ShaneM]
10:14:01 [Steven]
10:14:14 [oedipus]
10:14:48 [oedipus]
SM: A.2 is now entitled: "Elements with no content" and combined with old A.3
10:14:57 [oedipus]
RM: useful to have them there
10:15:07 [oedipus]
SM: will have to update when introduce new elements
10:15:31 [oedipus]
TH: big question: compatability GL for HTML4 and less
10:15:39 [oedipus]
TH: won't be added in HTML5
10:15:59 [oedipus]
SM: if introduce new elements in XHTML2 have to revisit this document
10:16:22 [oedipus]
SM: don't want to discuss today, but need to think about how to serve to "classic" browsers
10:16:36 [oedipus]
TH: probability of sending XHTML2 to legacy agents
10:16:44 [oedipus]
SP: people do that nowadays
10:16:50 [oedipus]
rrsagent, draft minutes
10:16:50 [RRSAgent]
I have made the request to generate oedipus
10:17:11 [oedipus]
SP: XForms scripts convert XForm into HTML, but delivered XForms
10:17:16 [oedipus]
TH: using javascript, i assume
10:17:18 [oedipus]
SP: yes
10:17:28 [oedipus]
TH: accessibility part of it - what to do with javascript
10:17:53 [oedipus]
RM: are people happy with A.2 "Elements with no content"
10:18:16 [oedipus]
SP: personally prefered old form with separation between empty elements and those which can be empty
10:18:45 [oedipus]
TH: A.3 more of a problem - should keep separate;
10:19:19 [oedipus]
SP: liked fact that pointed out that XML allowed <br></br> doesn't mean anything
10:19:27 [oedipus]
RM: can go into rationale - doesn't change rules
10:19:57 [oedipus]
Original A.3 text: "Include a space before the trailing / and > of empty elements, e.g. <br />, <hr /> and <img src="karen.jpg" alt="Karen" />. Also, use the minimized tag syntax for empty elements, e.g. <br />, as the alternative syntax <br></br> allowed by XML gives uncertain results in many existing user agents."
10:20:13 [oedipus]
TH: clearer we are, the better the results when authors write it
10:20:43 [oedipus]
RM: A.2 what should do is <br /> what should not do is <br></br>
10:21:05 [oedipus]
SP: good example is script - if script src= have to have /script
10:21:10 [oedipus]
Alessio: yes
10:21:35 [oedipus]
SP: let's use scripts there - that is poster-child example of why have to do this way
10:21:57 [oedipus]
RM: concrete do this and don't do this in CSS columns
10:21:59 [Tina]
This was spotted "in the wild" last week: <div style="... "/>
10:22:10 [oedipus]
SM: 2 votes for restoring A.3
10:22:29 [oedipus]
RM: don't object, but understand distinction WG members making, but not sure authors care about
10:22:39 [oedipus]
SP: then say "elements that can only be empty"
10:23:00 [oedipus]
RM: some elements can only be empty; list them and what can do with them
10:23:07 [oedipus]
SM: elements that can never have content?
10:23:10 [oedipus]
SP: works for me
10:23:15 [alessio]
10:23:35 [oedipus]
SM: Elements that can never have content versus Elements that may not contain content
10:23:40 [Tina]
10:23:44 [oedipus]
GJR +1
10:24:01 [oedipus]
RM: when do scripting, do certain things (but that topic for later)
10:24:11 [oedipus]
SM: script example in restored A.3?
10:24:28 [oedipus]
SM: trying to capture ideas in draft - will update later
10:24:53 [oedipus]
SM: A.4 "A.4. Embedded Style Sheets and Scripts" say "do" but not "do not"
10:24:58 [oedipus]
RM: needs balance
10:25:35 [oedipus]
TH: why not say use external stylesheets and scripts - XHTML in HTML compatability mode, use external scripts
10:25:49 [oedipus]
SM: unreasonable burden if all one is doing is adding a few localized styles
10:26:01 [oedipus]
RM: override one style with another for single document instance
10:26:38 [oedipus]
RM: example would be helpful - if use pointy brackets have to do like this in order to work, but easier to create and maintain external stylesheets
10:27:27 [oedipus]
SP: problem can arise if content gets fed through XSLT first - protecting documents; what we warn about could happen - authors should be aware
10:28:03 [oedipus]
GJR notes that FireVox cannot process external stylesheets but only embedded or inline CSS3-speech values
10:28:29 [oedipus]
SM: A.5 A.5. Line Breaks within Attribute Values - dont' know why anyone would care
10:28:59 [oedipus]
TH: some probably process new lines specially
10:29:13 [oedipus]
TH: as long as is CDATA should ignore new lines
10:29:24 [oedipus]
SM: so if datatypes IDREFs wouldn't be legal
10:29:34 [oedipus]
SM: fine guideline, but don't know origin -- needs a do
10:29:36 [oedipus]
RM: yes
10:30:26 [oedipus]
RM: has this problem been mitigated over the years?
10:30:44 [oedipus]
RM: perhaps confusion is that problem was limited and long time ago
10:30:57 [oedipus]
SM: not a bad rule, but next rule is candidate for deletion
10:31:10 [oedipus]
SM: A.6. isindex - who uses them?
10:31:18 [oedipus]
GJR: deprecated in HTML4 anyway
10:31:45 [oedipus]
SM: original text wrong - no more than one ISINDEX element is a no brainer
10:31:50 [oedipus]
SM: would remove A.6
10:31:52 [oedipus]
SP: ok
10:31:56 [oedipus]
Alessio: ok
10:31:59 [oedipus]
GJR: ok
10:32:27 [oedipus]
SM: kept these consistent with Appendix C - even down to fragment IDs
10:32:35 [oedipus]
RM: can log changed
10:32:43 [oedipus]
SM: change number?
10:33:04 [oedipus]
TH: use DEL to show A.6 no longer applicable
10:33:16 [oedipus]
SM: renumber
10:33:18 [oedipus]
SP: good
10:33:35 [oedipus]
SM: A.7. The lang and xml:lang Attributes - may be controversial
10:34:10 [oedipus]
TH: tool looks at doctype then tries to figure out lang attribute
10:34:19 [Zakim]
10:34:56 [Steven]
I have no problem with the lang and xml:lang
10:35:11 [Steven]
scribe: Steven
10:35:35 [Steven]
TH: I'm worried that tools that see it's HTML: will go looking for @lang
10:35:38 [oedipus]
dropped the phone - must have disconnected
10:36:06 [oedipus]
ATs key off of lang - if try just xml:lang, won't switch natural langauges - can log as bug with GNOME's Orca
10:36:14 [Steven]
Yam: I'm not sure about this issue
10:36:35 [Zakim]
10:36:37 [Steven]
... we are thinking about removing @lang
10:36:47 [Steven]
... but CSS selectors may use it (for instance)
10:36:54 [Steven]
... we have no strong position though
10:37:14 [Steven]
scribe: oedipus
10:37:59 [oedipus]
need to find CSS selector example that uses aria live regions to change language of text
10:38:09 [oedipus]
SM: need portable way to indicated language change
10:38:36 [oedipus]
Yam: existing UA implementations use @lang for CSS selectors - we discourage use of that for XHTML family of languages consistency of use
10:39:07 [oedipus]
RM: people using lang specifically, can't write XHTML 1.1 or 1.2 document with @lang
10:39:23 [oedipus]
SM: want to ensure rule works before ship XHTML2
10:39:30 [oedipus]
SM: could reintroduce lang
10:39:34 [oedipus]
RM: perhaps target
10:39:59 [oedipus]
GJR: AT problem is DOM calls and limitations AT-side on what it relies upon to key natural language switches
10:40:28 [oedipus]
SP: if need compatability GLs to serve as HTML need lang, but in XHTML lang means nothing and is just there for convenience
10:40:52 [oedipus]
SM: normatively state allow @lang but if doc served as XHTML @lang must be ignored?
10:41:17 [oedipus]
SP: yes, no meaning in XHTML - only there for convenience of being able to serve XHTML documents to legacy browsers
10:41:21 [oedipus]
RM: synonyms?
10:41:30 [oedipus]
SP: then people might stop using xml:lang
10:41:37 [oedipus]
RM: rammifications?
10:42:32 [oedipus]
SM: CSS selectors based on lang when have both lang and xml:lang - XHTML 1.1 document, for example, serving document in either media type, how to craft css selectors to make everything in latin pink and italic given i'm using lang and xml:lang
10:43:07 [oedipus]
SP: no, use coma as delimeter -- CSS doesn't select on attribute - in HTML uses lang, in XHTML uses xml:lang, so only one rule in CSS
10:43:17 [oedipus]
TH: could use CSS rule to key on @lang specifically
10:44:21 [oedipus]
SP: CSS has knowledge of language text is in due to selector - language comes from parent element of current element; if current element is in latin, do this - only way to do in CSS anyway
10:44:56 [oedipus]
SP: no selector that says if parent of current element has @blah ...
10:45:58 [oedipus]
TH: selecing on lang attribute correct thing to do according to CSS
10:46:07 [oedipus]
SP: can have select on lang and xml:lang
10:46:27 [oedipus]
TH: people today select on lang - problem is HTML compatibility GLs
10:46:38 [oedipus]
SP: why i'm suggesting we add lang back into the languages
10:46:48 [oedipus]
GJR plus 1 to readding @lang
10:46:57 [ShaneM]
q+ about how we support @lang via M12N
10:47:22 [oedipus]
TH: if people transformed to HTML would be easier
10:47:38 [oedipus]
TH: if transform from xml:lang to lang
10:47:50 [oedipus]
SP: what is easier
10:48:01 [oedipus]
TH: don't need to put lang into XHTML Base
10:48:42 [oedipus]
SM: 2 sets of constituents to serve: one of them is "the great unwashed" - just have a simple site who want simple solutions; then there are sites such as amazon, which have FAR more resources can bring to bear
10:48:56 [oedipus]
SP: but don't want to transform everytime serve page
10:49:07 [oedipus]
SM: cache it
10:49:21 [oedipus]
RM: can i? if getting weather updated every 5 seconds, may never be cached
10:49:27 [ShaneM]
q+ to discuss how we support @lang via M12N
10:49:28 [oedipus]
SM: cached for 5 seconds
10:49:48 [oedipus]
RM: a lot of transformation for 5 seconds
10:50:30 [oedipus]
SM: if permit lang along lines SP discussed - technically, how do we do that?
10:50:44 [oedipus]
SM: or introduce new lang module?
10:51:10 [oedipus]
SP: yeah, or may need other attributes, in which case a "compatability module" would be the answer
10:51:20 [oedipus]
Yam: have legacy module, right?
10:51:29 [oedipus]
SP: don't want to allow BLINK along with @lang
10:51:42 [Zakim]
10:51:59 [oedipus]
SM: lang not in legacy module now, so wouldn't be conflict if introduced elsewhere
10:52:23 [oedipus]
SM: could introduce an HTML compatibility module as update to 1.1
10:52:24 [Zakim]
10:52:34 [yamx]
i killed line by mistake
10:52:37 [oedipus]
zakim, ??P4 is Yam
10:52:37 [Zakim]
+Yam; got it
10:52:38 [yamx]
Zakim, ??P4 is yamx
10:52:39 [Zakim]
I already had ??P4 as Yam, yamx
10:52:50 [yamx]
OK, zakim, thanks.
10:52:53 [oedipus]
SM: compatibility GLs wouldn't be useful for 1.1
10:53:03 [oedipus]
SP: better off using 1.2 anyway
10:53:08 [oedipus]
RM: definitely
10:53:44 [oedipus]
SM: for this GL, "do use lang" - or "do use both" - realize can't if doing 1.1, Basic, +RDFa, etc
10:54:04 [oedipus]
TH: need to put responsibility on author - use both
10:54:13 [oedipus]
GJR: same thing authors do with name and id
10:54:52 [oedipus]
SM: will update appropriately and then need to figure out how to help languages support both of these, but that is independent discusssion
10:55:08 [oedipus]
SM: "A.8. Fragment Identifiers" - not controversial
10:55:10 [oedipus]
TH: no
10:55:40 [oedipus]
SP: when wrote A.8 there were UAs that didn't recognize ID, but that has changed
10:55:44 [oedipus]
SM: and i changed the doc
10:56:09 [oedipus]
SM: "A.9. Character Encoding"
10:56:14 [oedipus]
SM: interesting problem
10:56:26 [oedipus]
Yam: Japanese example would be useful
10:56:29 [oedipus]
SM: true
10:56:56 [oedipus]
SP: including mediatype and encoding in same metadata bad choice made way back when
10:57:22 [oedipus]
RM: there is a default - if satisfied with default, don't need to do this
10:58:06 [oedipus]
TH: back to HTTP spec - not possible - HTTP content type can be set as much as you want, but often receive US ASCII from server
10:58:25 [oedipus]
SM: if accessing document in filesystem not possible
10:58:34 [oedipus]
TH: author can't change content type served by server
10:59:20 [Steven]
And some protocol;s don't support encodings, eg ftp, file:
10:59:28 [Steven]
10:59:28 [oedipus]
TH: can't change content type set by server; practical problem; really ought to set on server - should stress
10:59:43 [Steven]
11:00:05 [oedipus]
SM: if doc coming from server, character encoding is specified in response, so is authoritative, and may even override XML declaration
11:00:07 [oedipus]
TH: yes
11:00:17 [oedipus]
SM: telling people not to use XML declaratoin
11:00:33 [oedipus]
TH: bigger problem if send as XHTML and don't have control over encoding and content type
11:01:35 [oedipus]
SM: serious problem - compatability GLs and content negotiation only relevant when have access to server and ability to control headers otherwise nothing we say matters
11:01:52 [oedipus]
TH: some think HTTP-EQUIV panacea; still sending as text/html
11:02:02 [alessio]
really true
11:02:28 [oedipus]
SP: HTML4 spec says that server should look at HTTP-EQUIV and send appropriate, but never implemented
11:02:51 [oedipus]
SP: GL should be "when serving a document, putting anything in the document that is unlikely to help because server always has priority"
11:02:58 [oedipus]
TH: also not to expect something else
11:03:08 [oedipus]
SP: META unlikely to help you at all
11:03:12 [oedipus]
SM: maybe not mention
11:03:17 [oedipus]
SP: should to make explicit
11:03:29 [oedipus]
RM: first item similar
11:04:00 [oedipus]
SM: suggestion: could we have 2 rules: when document being sent from server, do this
11:04:12 [oedipus]
SM: when document being accessed directly do this
11:04:31 [Steven]
Default for XML is UTF-8, right?
11:04:41 [oedipus]
TH: even when served by HTTP daemon, even if proper content type served, save as HTML
11:04:55 [alessio]
yes, steven
11:05:32 [oedipus]
TH: legacy issue; if not serving direct from server, use HTTP-EQUIV as per spec, but if set content type and char encoding on server
11:05:39 [oedipus]
RM: not an isolated issue
11:06:00 [oedipus]
SM: why don't we just say - ifyou want to be compatible encode as UTF-8 or UTF-16
11:06:03 [oedipus]
RM: agree
11:06:13 [oedipus]
SP: and state ensure that server serves it as UTF-8
11:06:14 [alessio]
11:06:19 [oedipus]
plus 1
11:06:43 [oedipus]
RM: happy with that solution
11:06:58 [oedipus]
SM: if want docs to be protable, encode in UTF-8 or UTF-16
11:07:21 [oedipus]
11:07:40 [oedipus]
SP: people should use UTF-8 everywhere ideally
11:08:23 [oedipus]
TH: make sure server announces correctly needs to be in GL
11:09:10 [oedipus]
11:09:34 [oedipus]
HTML5: "If the document contains a meta element with a charset attribute or a meta element in the Encoding declaration state, then the character encoding used must be an ASCII-compatible character encoding. "
11:10:09 [oedipus]
SM: HTML5 talking about default when no server - we say use META HTTP-EQUIV
11:10:24 [oedipus]
HTML5: "If the document does not start with a BOM, and if its encoding is not explicitly given by Content-Type metadata, then the character encoding used must be an ASCII-compatible character encoding, and, in addition, if that encoding isn't US-ASCII itself, then the encoding must be specified using a meta element with a charset attribute or a meta element in the Encoding declaration state. "
11:10:46 [oedipus]
SP: anyone actually look at HTTP-EQUIV
11:10:51 [oedipus]
SM: browsers do
11:11:00 [oedipus]
TH: most commonly used browsers do
11:11:27 [oedipus]
TH: issue is what is use they make of it - some ignore content type based on extension
11:11:45 [oedipus]
Yam: use META HTTP-EQUIV to ensure japanese encoding
11:12:04 [oedipus]
Yam: all Japanese encoding should be in meta http-equiv
11:12:11 [oedipus]
SM: that overrides HTTP headers?
11:12:32 [oedipus]
Yam: not sure; easier for carrier to serve
11:12:59 [oedipus]
SM: A.10. Boolean Attributes
11:13:04 [oedipus]
SM: controversy?
11:13:10 [oedipus]
RM: looks good
11:13:29 [oedipus]
SM: A.11. Document Object Model and XHTML
11:13:49 [oedipus]
Alessio: can get to HTML DOM as well
11:14:05 [oedipus]
SM: will remove "if is really true" editorial note
11:14:18 [oedipus]
TH: as long as works with HTML4 UAs don;t have problem
11:14:33 [oedipus]
SM: A.12. Using Ampersands
11:14:57 [oedipus]
fine with GJR
11:15:14 [oedipus]
SP: sentence difficult to read - AND in all caps
11:15:24 [oedipus]
SP: change AND to lower case
11:15:30 [oedipus]
TH: possibly STRONG?
11:15:49 [oedipus]
TH: if possible, use semi-colon instead of ampersands in URIs
11:16:35 [oedipus]
SM: made change to case of "and"
11:17:16 [deane]
deane has joined #xhtml
11:17:20 [oedipus]
GJR: plus an abbr expansion for & <abbr title="ampersand">&</abbr>
11:17:52 [oedipus]
SM: when using ampersand in URI use its escaped form
11:17:53 [oedipus]
SM: A.13. Cascading Style Sheets (CSS) and XHTML
11:18:01 [oedipus]
SM: may have over-simplified
11:18:10 [oedipus]
RM: may want to make comment on lang here
11:18:23 [oedipus]
SP: CSS selector on xml:lang rather than lang
11:18:45 [oedipus]
SM: do nots needed?
11:18:50 [oedipus]
RM: inverse fairly obvious
11:19:09 [oedipus]
SM: added thing about style HTML element
11:19:30 [oedipus]
SM: in HTML style on body becomes style for entire viewport; in XML does not
11:19:45 [oedipus]
TH: change Do rule - if need to set, then...
11:20:46 [oedipus]
SP: special rule in CSS is because early versions of IE didn't have style for HTML element, so CSS states, style BODY element
11:20:52 [oedipus]
SM: do style HTML element?
11:21:06 [oedipus]
SP: no, for compatability reasons, style BODY rather than HTML element
11:21:28 [oedipus]
SM: style applies only to block not whole window
11:22:04 [oedipus]
SP: if you want to remove styling put on HTML, have to define style for HTML, but this might be the ocassion to say "this is an old rule"
11:22:26 [oedipus]
SP: when wrote, were browsers that didn't support HTML
11:22:30 [oedipus]
SM: just added this
11:22:54 [oedipus]
RM: implications - example of consequences - we need to make clear what consequences are
11:23:44 [oedipus]
SM: good point, Roland; maybe not even necessary to say this; authors put style on BODY, not HEAD; and when served as HTML style on BODY apply to entire window
11:24:00 [oedipus]
SP: what CSS spec says, but not reality; 2px margin around HTML element
11:24:37 [oedipus]
SP: why can't i get rid of margin around my HTML document - reason: have to explicitly state padding:0;margin:0
11:24:42 [oedipus]
SM: do we need this rule?
11:24:44 [oedipus]
SP: no
11:25:06 [oedipus]
TH: need rule to point this out
11:25:28 [oedipus]
RM: rationale needs more work - particularly important for this appendix a section
11:25:36 [oedipus]
SM: will try to update so can revisit later
11:26:14 [oedipus]
SM: had been telling people to use xml style declarations, and i think we should tell people not to use them for compatibility
11:26:37 [oedipus]
SM: A.15. White Space Characters in HTML vs. XML
11:26:57 [oedipus]
SM: should change name from "white space"
11:27:00 [oedipus]
SP: agreee
11:27:08 [oedipus]
SM: A.16. The Named Character Reference &apos;
11:27:36 [oedipus]
TH: typographcally, is right single quote - no problem with A.16, but shouldn't get into typography side of it
11:27:37 [oedipus]
SM: ok
11:28:14 [oedipus]
===== ADJOURN FOR LUNCH - RETURN in 77 Minutes (quarter to next hour ======
11:28:19 [oedipus]
rrsagent, make minutes
11:28:19 [RRSAgent]
I have made the request to generate oedipus
11:28:19 [Zakim]
11:28:20 [Zakim]
11:28:24 [Zakim]
11:28:25 [Zakim]
11:28:26 [Zakim]
11:28:26 [Zakim]
11:28:28 [Zakim]
11:28:30 [Zakim]
IA_XHTML2()4:00AM has ended
11:28:32 [Zakim]
Attendees were Roland, Steven, Gregory_Rosmaita, yamx, ShaneM, Alessio, Tina, Yam
11:39:17 [oedipus_laptop]
oedipus_laptop has joined #xhtml
12:20:26 [alessio]
alessio has joined #xhtml
12:30:40 [ShaneM]
ShaneM has joined #xhtml
12:44:07 [Zakim]
IA_XHTML2()4:00AM has now started
12:44:14 [Zakim]
12:44:42 [Zakim]
12:45:12 [yamx]
OK, I will join, too.
12:45:34 [Steven]
zakim, dial steven-617
12:45:34 [Zakim]
ok, Steven; the call is being made
12:45:36 [Zakim]
12:45:49 [Zakim]
12:45:53 [Zakim]
12:46:06 [oedipus]
zakim, ??P8 is Yam
12:46:06 [Zakim]
+Yam; got it
12:46:17 [yamx]
12:46:18 [Zakim]
12:46:22 [alessio]
zakim, ??P9
12:46:22 [Zakim]
I don't understand '??P9', alessio
12:46:22 [oedipus]
my pleasure
12:46:26 [alessio]
zakim, ??P9 is Alessio
12:46:26 [Zakim]
+Alessio; got it
12:46:35 [Zakim]
12:47:21 [oedipus]
SP: complete discussion of media types?
12:47:28 [oedipus]
SM: enough to create a new draft
12:47:42 [oedipus]
RM: one other thing: validator thing olivier brought up
12:47:49 [ShaneM]
Olivier says: Good. How about:
12:47:49 [ShaneM]
- [now] updating the tool to match the draft guidelines in the ED of xhtmlmime
12:47:49 [ShaneM]
- [soon] including the checks into the validator, mark them as [experimental], informative, whatever. That will provide us with better and more feedback than just a WD.
12:47:56 [oedipus]
SM: his proposal to me this morning appears above
12:48:29 [oedipus]
RM: something we'd like to see, isn't it?
12:49:05 [oedipus]
RM: do we believe running through validator to get info if suitable to be served?
12:49:24 [oedipus]
GJR thinks would promote awareness
12:49:29 [alessio]
12:50:29 [oedipus]
SM: concern is "validator as holy writ" -- good or bad, depending upon whether it works; would be more comfortable if could provide WG resources to work on that
12:50:47 [oedipus]
(that being validator and control over changes)
12:51:08 [oedipus]
SP: depends on how they present information -- warnings versus errors
12:51:16 [oedipus]
RM: that is what they did
12:51:55 [oedipus]
SM: get document updated to reflect discussion today; respond to olivier that WG ok with warnings
12:52:20 [oedipus]
GJR would like a STRICT mode where errors are reported as errors
12:52:39 [oedipus]
SM: open source tool
12:52:57 [oedipus]
RM: anyone can hack anytime want to; what is in w3c validator he takes care of
12:53:37 [ShaneM]
ACTION: Shane to finish the updating the XHTMLMIME draft then respond to Olivier's proposal.
12:53:45 [oedipus]
RM: anything anyone wants to mention in closing on mime doc?
12:54:06 [oedipus]
TOPIC: XHTML 1.n (Follow on to 1.1)
12:54:46 [oedipus]
RM: have 1.1 spec waiting for modularization; proposed change adding target attribute back in, which is considered not in scope of what should do in new edition
12:54:51 [oedipus]
RM: what do we do next?
12:54:59 [oedipus]
RM: drop from second edition?
12:55:11 [oedipus]
RM: release XHTML 1.n and if so what would be in it?
12:55:49 [oedipus]
SP: adding @target to 1.1 is that Basic needs -- 1.1 should be considered full Basic with all facets of Basic
12:56:13 [oedipus]
TH: @target to open frame or new window?
12:56:22 [oedipus]
TH: no reason to put into declarative markup language
12:56:28 [oedipus]
SM: why is target not useful
12:56:37 [oedipus]
TH: authors shouldn't force new windows
12:56:45 [oedipus]
TH: if in XFrames, ok, but not in Basic
12:57:08 [oedipus]
GJR notes that handling of @target is user agent control issue being addressed in UAAG2.0
12:57:23 [oedipus]
TH: opening windows outside scope of declarative language
12:57:49 [oedipus]
Yam: against using target, but made compromise with CDF or another WG who demanded it be restored; don't think we need it
12:57:55 [oedipus]
12:58:02 [oedipus]
SP: doesn't SVG need it in some way?
12:58:24 [oedipus]
RM: compatability guide question -- html mime --- inhibiter for those trying to move from HTML to XML
12:58:32 [oedipus]
SP: reasonalbe use cases for @target
12:58:54 [oedipus]
SP: list of search results - click on a search result to get result without changing underlying doc
12:58:59 [oedipus]
TH: UA has built in
12:59:11 [oedipus]
TH: those that can spawn new windows have that feature
12:59:18 [oedipus]
12:59:31 [oedipus]
GJR author proposes, user disposes
12:59:50 [oedipus]
SM: @target has different semantics in SVG?
13:00:35 [oedipus]
Yam: against @target in 1.2 -- agree that natural that have in 1.1, but from practical POV it is a mess -- HTML5, XHTML2, etc.
13:00:50 [oedipus]
SP: talking about 1.1 -- issue 1.1 as proper superset of basic
13:01:09 [oedipus]
SM: if don't add anything to 1.1 can release as PER
13:01:12 [oedipus]
with schema
13:01:21 [oedipus]
SM: would not be superset of Basic
13:01:23 [oedipus]
SP: why not
13:01:30 [oedipus]
SM: not including @target
13:01:46 [oedipus]
SM: those who care about input mode and @target will be affected - who are they?
13:02:02 [oedipus]
Yam: don't care if 1.1 is superset or not
13:02:33 [oedipus]
SM: very good point: explanation of XHTML family would be fine to support 1.1 second edition or first edition -- basic 1.1 document
13:02:59 [oedipus]
SM: @target is single-most requested feature in our public wish list
13:03:21 [oedipus]
TH: any UA used today that allows user not to open @target-ed windows
13:03:43 [oedipus]
RM: a lot of users don't know that can click on link and open new window
13:04:55 [oedipus]
TH: @target specifies UA behavior in practice
13:05:02 [oedipus]
SP: a "hook" for use by
13:05:02 [alessio]
you're right, gregory
13:05:20 [oedipus]
GJR: render unto User Agent what is user agent...
13:05:41 [oedipus]
TH: going to be used to open new windows - removed to prevent that so shouldn't go back in
13:06:07 [oedipus]
SP: didn't remove - never in STRICT and 1.1 is a revised version of STRICT, but didn't revise version of transitional DTD b/c nothing to revise
13:06:21 [oedipus]
SP: one thing people have asked for is to use @target in 1.1
13:06:43 [oedipus]
SP: not clear why we should say people shouldn't do that - perhaps should give arguments for people not opening windows
13:06:48 [oedipus]
TH: why put back?
13:06:52 [oedipus]
SP: popular demand
13:07:01 [oedipus]
TH: what purpose does @target fill in XHTML?
13:07:34 [alessio]
people reintroduces it with dom injection...
13:07:38 [oedipus]
TH: know complaints, but purpose aren't for frames mostly but for forcing open new windows
13:07:49 [oedipus]
SP: XFrames - target a document onto a frame
13:08:13 [oedipus]
SP: XFrames does NOT need @target - that's why need in HTML - if environment that needs this, here are the hooks you use
13:08:45 [oedipus]
Alessio: @target should not be in 1.1 -- regard @target as action
13:08:58 [oedipus]
SP: SVG uses @target, i believe -- trying to locate
13:09:41 [oedipus]
Alessio: 2 diff roles for target - 1. to open new window; 2. to point at a frame in a frameset or multimedia concept
13:10:02 [oedipus]
RM: if we don't have @target, what is effect? going to write scripts to force open scripts
13:10:19 [oedipus]
RM: inhibitor to go to 1.1 or will just write script
13:10:36 [oedipus]
TH: include despite bad practice because people going to do it anyway
13:11:01 [oedipus]
GJR notes that BLOCKQUOTE deprecated for layout purposes in HTML4x but you can find it used for layout on W3C site
13:11:42 [oedipus]
TH: why @target in HTML? to open new windows - compromise: use to target fragments that already exist - not to open new windows because that is not role of markup langauge
13:11:53 [oedipus]
TH: say "is NOT to be used to open new windows"
13:11:59 [Steven]
"The target attribute is designed to be a general hook for binding to an external environment"
13:12:04 [ShaneM]
see for explanation of Target Module
13:12:24 [alessio]
another use of "target" attribute:
13:12:50 [oedipus]
@target itself could be repurposed to a new tab, a sidebar by user agent
13:13:08 [oedipus]
TH: user agent problem that persists - @target simply opens new window/browser instance
13:13:18 [oedipus]
TH: why cave in to an illegitimate request?
13:13:30 [oedipus]
SP: what is wrong with clicking on things to open windows
13:13:36 [oedipus]
SM: explicit user action
13:13:43 [oedipus]
GJR: that is point of UAAG1 and UAAG2
13:13:48 [alessio]
target in SMIL: "This attribute defines either the existing display environment in which the link should be opened (e.g., a SMIL region, an HTML frame or another named window), or triggers the creation of a new display environment with the given name. Its value is the identifier of the display environment. If no currently active display environment has this identifier, a new display environment is opened and assigned the identifier of the target."
13:13:55 [oedipus]
TH: open in same window or another window
13:14:01 [oedipus]
SP: programming problem with browser
13:14:09 [oedipus]
TH: support a11y by suppressing @target
13:14:27 [oedipus]
TH: take stand that every problem due to poor user agents
13:14:35 [oedipus]
TH: opens unpleasant can of worms
13:14:48 [oedipus]
SP: agree with removing features that have no raison d'etre
13:14:57 [oedipus]
SP: open windows all day long by clicking on things
13:15:09 [oedipus]
GJR: @target should be treated as an option, not an absolute
13:15:38 [oedipus]
TH: if going to say has good uses, have to also note problems
13:15:58 [oedipus]
SP: both cases UA problem
13:16:06 [oedipus]
TH: in one case SHOULD in other SHOULD NOT
13:16:41 [yamx]
I don't think this argument is productive... If we don't like target (I am not a fan of target), we should discuss in XHTML Basic 1.1., not in XHTML 1.n 2nd edition...
13:17:21 [oedipus]
@target should be treated as an option by UAs until explicit user action determines what to do
13:17:30 [yamx]
Whatever it is. XHTML 1.n 2nd ed should be a super set of XHTML Basic 1.1., which is the starting point of this discussion.
13:17:50 [oedipus]
RM: applications in windows environment still open windows that are accessible
13:17:56 [oedipus]
TH: don't agree
13:18:13 [oedipus]
TH: far larger probability if opens in new window won't know
13:18:15 [oedipus]
13:18:27 [ShaneM]
13:18:39 [oedipus]
TH: authors shouldn't make assumptions
13:18:46 [oedipus]
GJR: author proposes, user disposes
13:19:01 [oedipus]
SP: opposite is never open another link in another window - non sequitor
13:19:03 [alessio]
maybe the UA could help, alerting when a new window is prospected
13:19:50 [oedipus]
TH: problem include link and target to open in new window, have no idea what happens when link gets to user - author wants to open new window, user will be surprised by uncertainty and unexpected behavior
13:20:33 [oedipus]
SP: filling in long form, don't understand something, click on help link, tells me what to do, but hasn't destroyed context of form and other helps open in same popup window
13:20:45 [oedipus]
TH: if 800% magnification, where does window open?
13:20:58 [yamx]
target has an interoperability problem in mobile domain, certainly, but we have to accept @target for compromising SVG group...
13:21:13 [oedipus]
there is a queue
13:21:39 [oedipus]
AT should alert the user that new window being opened or new pane / tab being opened
13:21:52 [oedipus]
TH: shou ld be user's choice, not authors
13:22:17 [ShaneM]
13:23:26 [oedipus]
13:24:15 [oedipus]
TH: screen magnifiers - simply blow up what is on screen - too dumb an app
13:24:32 [oedipus]
GJR: if no @target will end up with raw javascripted links which are a WCAG violation
13:24:34 [Zakim]
13:25:08 [oedipus]
RM: not language purity - from author and/or user -- what do constituents want: authors creating material, and users interacting with that
13:25:37 [oedipus]
RM: if in there could treat @target as an option - if have javascript won't have single standard hook
13:25:46 [oedipus]
TH: to this point no UA has implemented that
13:26:16 [oedipus]
TH: user agents include options to open new windows and tabs from context menues; not bothered to use @target to give users an option
13:26:25 [Zakim]
13:26:27 [oedipus]
RM: will just use javascript to do anyway
13:26:31 [alessio]
zakim, ??P0 is Alessio
13:26:31 [Zakim]
+Alessio; got it
13:26:56 [Steven]
13:27:14 [ShaneM]
13:27:15 [oedipus]
The more things are forbidden, the more popular they become. -- Mark Twain
13:27:25 [oedipus]
TH: why not restore MARQUEE
13:27:30 [Steven]
We have had no requests to put marquee back in
13:27:30 [oedipus]
TH: same rationale
13:27:52 [Steven]
there is a queue
13:27:55 [oedipus]
GJR: put @target in with strict limitations -- that is an option that should be a programmatic flag
13:28:05 [ShaneM]
13:28:11 [alessio]
13:28:13 [Steven]
13:28:17 [oedipus]
RM: if target has characteristics, what hooks can we provide what options are available
13:29:00 [oedipus]
SP: hear TH's problems with @target, also hear a lot of complaints that @target not in 1.1 so use 1.0
13:29:15 [oedipus]
SP: thing i like about target is gives us control - can put conditions on its use
13:29:42 [oedipus]
SP: can say, if use it user agent should do this and that -- XHTML Basic accepts but ignores it which is perfectly acceptable behavior
13:30:15 [oedipus]
SP: serious and valuable use cases for @target - if in markup, is under control - if don't have it, people will use javascript to do it with all the rammifications of that
13:30:22 [oedipus]
13:30:28 [oedipus]
ack Steven
13:30:32 [oedipus]
ack ShaneM
13:32:05 [oedipus]
SM: UAAG exist - to extent they exist, don't know if UA devs pay any attention to or authors pay attention to or anyone pays attention to - no control over those guidelines, but do have control over our own spec; proposal in IRC to put limitations on target - need to define; value in doing that independent of decision vis a vis 1.1.; regardless of what we do with @target, poeplewil want to create new windows
13:32:27 [oedipus]
SM: need to give authors a consistent way to do it, and provide documentation for UA devs
13:32:45 [oedipus]
SM: people always going to be generating new windows - should put conditions on it
13:33:28 [oedipus]
TH: keeping it out is a signal as much as putting it back in - shouldn't be allowing authors to engage in improper behavior under cover of standards
13:33:36 [oedipus]
SP: for people to use "as they see fit"
13:33:56 [oedipus]
TH: try other way around - put @target back in but say DO NOT use to open new windows
13:34:29 [oedipus]
SP: can point to UAAG and WCAG
13:34:58 [oedipus]
GJR: win win - WCAG also against raw javascripted links and stripping chrome
13:35:13 [oedipus]
13:35:46 [oedipus]
RM: EU reference WCAG directly
13:36:07 [oedipus]
RM: procurment in most european countries and will become EU wide
13:36:24 [oedipus]
Yam: if prohibit use of @target to open new window, then ok to include
13:36:56 [oedipus]
Alessio: some government sites forced to use XHTML 1.0 Strict so cannot open new windows declaratively
13:37:08 [oedipus]
AC: people will use javascript to work around that though
13:37:12 [alessio]
yes, the stanca act
13:37:22 [oedipus]
RM: conclusions?
13:37:57 [oedipus]
RM: looked at target but where to be reintroduced and how?
13:38:33 [oedipus]
AC: @target for support of SVG elements - think need to point out how NOT to use @target
13:38:58 [oedipus]
AC: need to know interoperability with UAs; what do UAs need to do to warn user?
13:39:07 [oedipus]
13:39:23 [oedipus]
also a requirements document at
13:39:40 [alessio]
yes, thanks gregory
13:39:50 [oedipus]
SM: Yam, you felt 1.1 could be superset of Basic 1.1
13:39:58 [oedipus]
Yam: starting point of discussion, i think
13:40:06 [oedipus]
Yam: do we need second edition?
13:40:20 [oedipus]
SM: need to republish to add schema implementation - no extension,
13:40:29 [oedipus]
Yam: ambivalent
13:40:31 [Zakim]
13:40:43 [yamx]
Oh, I kill the line by mistake, too.
13:40:56 [oedipus]
SP: don't care very much - 1.2 more interesting bit
13:41:19 [oedipus]
SP: if issue as PER, people would rationalize that @target and input mode should be in 1.0 as well
13:41:31 [Zakim]
13:41:33 [oedipus]
SP: only counter argument is that XHTML2 coming to fix these things
13:41:34 [yamx]
I am back.
13:41:40 [yamx]
Zakim, ??P1 is yamx
13:41:40 [Zakim]
+yamx; got it
13:42:06 [oedipus]
SP: similar with Print - family of MLs trhat arent' constrained to each other either way
13:42:52 [oedipus]
RM: second edition just add schema - or add schema and a couple of attributes?
13:43:07 [oedipus]
SM: couldn't do in second edition
13:43:19 [oedipus]
RM: 1.1 second edition that adds schema is only thing to do
13:43:25 [oedipus]
SM: agree -- if want to reissue 1.1
13:43:38 [oedipus]
SM: low-impact, so can do it logistically
13:44:01 [oedipus]
SP: unchanged 1.1 a better approach; 1.2 where expend energy on combining existing specifications
13:44:26 [oedipus]
SM: Yam not to interested in 1.2 - should go directly to XHTML2 - need to have discussion on that
13:44:42 [oedipus]
RM: 1.1 take to second edition that simply adds schema and errata
13:44:46 [yamx]
13:45:02 [oedipus]
SM: same thing with Print at same time
13:45:03 [yamx]
no objection.
13:45:08 [Steven]
13:45:08 [oedipus]
RM: objections?
13:45:10 [alessio]
13:45:13 [oedipus]
GJR no objection
13:45:19 [Steven]
my +1 was to the 1.1 suggestion
13:45:38 [oedipus]
RESOLVED: take XHTML 1.1 to Second Edition by simply adding Schema and Errata
13:45:39 [yamx]
13:45:46 [oedipus]
rrsagent, make minutes
13:45:46 [RRSAgent]
I have made the request to generate oedipus
13:46:07 [oedipus]
RM: can we/should we do a 1.2 and if so why and what would be in it?
13:46:33 [oedipus]
SP: created something people using not backed up by spec XHTML1.1+RDFa
13:46:39 [oedipus]
SM: references DTD
13:46:50 [oedipus]
SP: oh - then it's not as bad as i thought
13:47:15 [oedipus]
SP: option 1 is take all specs being produced seperately as part of m12n
13:47:18 [oedipus]
13:47:20 [oedipus]
RM: yes
13:47:30 [ShaneM]
XHTML+RDFa is defined at
13:47:48 [oedipus]
SP: wrap all those up into a language called XHTML 1.2 so people can refer to markup language that uses these things
13:47:57 [oedipus]
SP: another reason, makes step to XHTML2 that much smaller
13:48:22 [oedipus]
SP: community needs to be led step-by-step to XHTML2 rather than just being presented with it - get used to concepts
13:48:45 [oedipus]
RM: XML Events and ????
13:49:06 [oedipus]
SP: step to XHTML2 is XForms, HREF everywhere and SRC everywhere
13:49:35 [oedipus]
SP: on the other hand, people out there already using XHTML11+ without doctype - not backed up by single spec, but rather widely used
13:49:47 [oedipus]
SP: another option - do it all at one go
13:50:04 [ShaneM]
I think stepping directly to XForms for xhtml 1.2 would be too far.
13:51:04 [oedipus]
RM: how to introduce Access, ARIA, Role as first class citizen and validatable -- small step but huge gain - point release rationale is to add a11y features -- good advertising
13:51:07 [oedipus]
plus 1
13:51:51 [oedipus]
SM: anything put into XHTML 1.2 should work in browsers today
13:51:58 [oedipus]
RM: agree with that
13:52:07 [alessio]
13:52:09 [oedipus]
SP: wou ld mean not including Access
13:52:15 [oedipus]
RM: right
13:52:20 [oedipus]
SM: yep
13:52:44 [oedipus]
SP: so 2 options there: 1. only bit remaining to be implemented
13:52:58 [ShaneM]
XHTML2 also has meta and link everywhere
13:53:02 [oedipus]
SP: could make effor to do implementation of Access in javascript
13:53:07 [oedipus]
SM: started a few weeks ago
13:53:18 [oedipus]
GJR: PF needs to submit support for Access to HTML5
13:53:24 [oedipus]
GJR: was in initial request to HTML5
13:53:36 [alessio]
I'd done last year a test for Access
13:53:51 [oedipus]
RM: XML Events - adding @implements on SCRIPT
13:53:58 [oedipus]
SP: no problem because works already
13:54:00 [oedipus]
SM: yes
13:54:04 [oedipus]
GJR: huge plus 1
13:54:14 [oedipus]
SM: not all XML Events
13:54:23 [oedipus]
RM: no, just to enable @implements feature
13:55:21 [oedipus]
RM: proposal for release and its content
13:55:33 [oedipus]
SM: yes, and a timetable - dependencies on things not yet completed
13:56:35 [oedipus]
RM: agree in principle to create proposal for XHTML 1.2 including @implements
13:57:00 [oedipus]
Yam: don't object, but W3C may - agree under condition to make transition market for XML short, not long
13:57:03 [Steven]
oedipus, alessio, please add agreemetns like that to the record!
13:57:05 [oedipus]
RM: most definitely
13:57:17 [oedipus]
GJR: @implements is going to be VERY useful
13:57:20 [Steven]
13:57:38 [yamx]
13:58:03 [oedipus]
RESOLVED: Proposal for XHTML 1.2 - Content and Timescale as outlined here
13:58:22 [oedipus]
ACTION: Steven - draft proposal for XHTML 1.2 - Content and Timescale
13:58:29 [oedipus]
rrsagent, make minutes
13:58:29 [RRSAgent]
I have made the request to generate oedipus
13:58:45 [yamx]
It is 23:00 in Japan.
13:58:49 [oedipus]
RM: good discussion- made progress
13:59:12 [yamx]
13:59:14 [oedipus]
RM: XML Events 2 and Features after break?
13:59:18 [Zakim]
13:59:19 [yamx]
see you later.
13:59:21 [Zakim]
13:59:22 [oedipus]
===== 15 MINUTE BREAK ======
13:59:23 [Zakim]
13:59:25 [Zakim]
13:59:26 [Zakim]
13:59:39 [Zakim]
14:15:04 [Zakim]
14:15:49 [Zakim]
14:16:11 [yamx]
zakim, ??p6 is yamx
14:16:11 [Zakim]
+yamx; got it
14:16:27 [oedipus]
zakim, mute Gregory_Rosmaita
14:16:27 [Zakim]
Gregory_Rosmaita should now be muted
14:17:03 [Zakim]
14:18:48 [Zakim]
14:18:54 [alessio]
zakim, IPcaller is Alessio
14:18:54 [Zakim]
+Alessio; got it
14:19:01 [oedipus]
TOPIC: XML Events 2
14:19:03 [oedipus]
14:19:04 [Zakim]
14:19:46 [oedipus]
zakim, unmute me
14:19:46 [Zakim]
sorry, oedipus, I do not know which phone connection belongs to you
14:19:52 [oedipus]
zakim, unmute Gregory_Rosmaita
14:19:52 [Zakim]
Gregory_Rosmaita should no longer be muted
14:21:09 [oedipus]
zakim, mute Gregory_Rosmaita
14:21:09 [Zakim]
Gregory_Rosmaita should now be muted
14:21:33 [Steven]
zakim, dial steven-617
14:21:33 [Zakim]
ok, Steven; the call is being made
14:21:35 [Zakim]
14:21:49 [oedipus]
RM: XML Events 2 -
14:22:05 [oedipus]
14:22:23 [oedipus]
RM: number of updates since last face2face - would like to get to LC - what needs to be done?
14:22:47 [oedipus]
RM: did see some comments in XForms group, but don't know what happened to them - their status
14:23:02 [oedipus]
RM: comments sent to XForms group, but not XHTML2 list(s)
14:23:08 [oedipus]
SP: researches the matter
14:23:23 [Steven]
14:23:29 [oedipus]
RM: felt XML Events doc should be more self contained
14:23:46 [oedipus]
RM: people shouldn't have to go to DOM3 spec, for instance charlie commented
14:24:03 [oedipus]
SP: long discussion but no action item; most comments editorial, spec overall good
14:24:16 [oedipus]
SP: will ping him to send comments to us
14:24:24 [oedipus]
RM: editorial things not too much of a problem
14:24:45 [oedipus]
RM: start with abstract
14:25:11 [oedipus]
14:25:29 [oedipus]
RM: differences from DOM3 and @target
14:25:47 [oedipus]
14:25:54 [oedipus]
RM: conformance - not much change at all
14:26:12 [oedipus]
RM: addition was to allow chameleon version should ML allow
14:26:37 [oedipus]
SM: what does this mean given our new understanding of "null namespace"?
14:26:48 [oedipus]
SM: bring in Events Module?
14:26:57 [oedipus]
SP: not sure have new understanding of "null namespace"
14:27:12 [oedipus]
SP: terminology used in certain circles not backed by any spec
14:27:24 [oedipus]
SM: lets call it "no namespace"
14:27:49 [oedipus]
SM: are we suggesting ok to bring XML Events into a language and use XML Event attributes in "no namespace"
14:28:06 [oedipus]
RM: unless someone uses chameleon, including events
14:28:37 [oedipus]
SP: not syntaxically the same, but semantically the same
14:28:48 [oedipus]
SM: don't access from DOM in same way
14:29:57 [oedipus]
SM: in a Compound Document, HTML uses Events in chameleon form - bring into HTML elements with no qualifiers, but SVG does not - in a Compound Document, do we expect the action attribute or event attribute will have same semantic on HTML p element as ???
14:30:32 [Steven]
We will write <a href="..."><action event="DOMActivate"...>
14:30:43 [Steven]
instead of
14:31:19 [Steven]
this <a href="..."><action ev:event="DOMActivate"...>
14:31:37 [oedipus]
14:31:38 [Steven]
but the meaning will be the same
14:31:50 [oedipus]
rrsagent, make minutes
14:31:50 [RRSAgent]
I have made the request to generate oedipus
14:32:42 [Steven]
We should coordiante with Forms WG on this
14:32:55 [Steven]
14:32:56 [oedipus]
RM: been discussed at forms WG meetings i believe
14:33:08 [oedipus]
RM: namespaces discussed in Forms f2f last week?
14:33:22 [oedipus]
SP: consults minutes from Forms f2f
14:34:30 [oedipus]
SP: not in detail
14:34:44 [oedipus]
RM: specifics of what is in XML Events Module
14:34:51 [oedipus]
RM: listener element
14:35:10 [oedipus]
14:35:21 [oedipus]
14:35:25 [oedipus]
14:35:34 [oedipus]
RM: diff with DOM3 is QNames?
14:35:38 [oedipus]
SM: essential difference
14:35:47 [oedipus]
RM: observer element
14:35:56 [oedipus]
RM: handler element
14:36:11 [oedipus]
14:36:17 [oedipus]
RM: default is target
14:36:34 [oedipus]
RM: event propogates or continues - default should be performed or not
14:36:47 [oedipus]
RM: not too diff from XML Events 1 - same principle
14:37:09 [oedipus]
14:37:20 [oedipus]
attributes for observer
14:37:39 [oedipus]
RM: can add attribute to handler itself -
14:37:55 [oedipus]
RM: not much different from XML Events 1 - comments?
14:38:05 [alessio]
14:38:08 [oedipus]
14:38:14 [oedipus]
RM: XML Handlers
14:38:21 [oedipus]
action element:
14:38:49 [oedipus]
RM: similar to XForms, can use as container for potential actions
14:39:10 [oedipus]
RM: condition - only true if XPath expression true
14:39:20 [oedipus]
RM: can finally have xml:id
14:39:22 [Steven]
action 4=
14:39:56 [oedipus]
RM: script element -
14:40:09 [oedipus]
RM: refined SCRIPT - important diff is @implements
14:40:41 [oedipus]
RM: will discuss @implements in detail later
14:40:52 [oedipus]
the dispatch element:
14:41:17 [oedipus]
14:41:31 [oedipus]
RM: very similar - can register eventListener
14:41:42 [oedipus]
RM: can stop bubbling
14:41:50 [oedipus]
RM: can prevent default defined for event
14:41:54 [oedipus]
RM: straightforward
14:42:02 [oedipus]
14:42:08 [oedipus]
14:42:12 [oedipus]
14:42:20 [oedipus]
14:42:30 [oedipus]
RM: XPath Expressions:
14:42:37 [oedipus]
14:42:50 [oedipus]
RM: XPath to describe context information (XPath context)
14:43:01 [oedipus]
14:43:14 [oedipus]
RM: @implements
14:43:30 [oedipus]
RM: optional - this script should only be loaded if UA doesn't have implementation of feature
14:43:43 [oedipus]
RM: key thing is how to describe features
14:44:06 [oedipus]
RM: safe URI or safe CURIE ok, but how to define features
14:44:25 [oedipus] - names event and where dispatched to
14:44:44 [oedipus]
RM: events predefined by DOM3, can create own events and dispatch those
14:44:54 [oedipus]
RM: XPath Expressions ahs extra note
14:45:18 [oedipus]
RM: not setting particular context mode
14:45:48 [oedipus]
RM :what necessary to define context - what would someone find useful - don't currently have idea of context
14:46:08 [oedipus]
RM: 6.1.1.XPath event Function
14:46:24 [oedipus]
RM: "Function event returns the value of a property of the current event object, as determined by the string argument. "
14:46:49 [oedipus]
RM: identify feature for @implements - URI but represents what?
14:47:03 [oedipus]
RM: comments? observations? questions?
14:47:16 [oedipus]
SP: anticipate fight over XPath
14:47:29 [oedipus]
SP: last version didn't have XPath, now it is required
14:47:59 [oedipus]
SP: XBL2 fight over XPath or CSS - in end hixie said "do CSS or i take spec to whatwg and do it there"
14:48:39 [oedipus]
SM: some way to do that doesn't require XPath?
14:48:50 [oedipus]
SM: conditionals without way of referencing?
14:48:57 [oedipus]
RM: could do in script
14:49:16 [oedipus]
RM: definition of what conditionals are
14:49:30 [oedipus]
SP: conditionals need to be in some langauge
14:49:43 [oedipus]
SP: maybe call section 6 "Expressions"
14:49:56 [oedipus]
SP: expressions that happen to be the ones in XPath
14:50:16 [oedipus]
SP: not asking to implement XPath, but syntax derived from XPath - serious difference
14:50:30 [oedipus]
RM: what is the core we need? what subset of XPath
14:50:40 [oedipus]
RM: not a big dependency on XPath
14:51:17 [oedipus]
SM: 2 modules - XML Events and XML Handlers - do we envision world where one can have handlers without events
14:51:27 [oedipus]
SP: people write scripts today without XML Events
14:51:47 [oedipus]
SM: XML Handler Module needs all of what is defined in XML Events
14:51:57 [oedipus]
RM: except for SCRIPT element
14:51:59 [oedipus]
SM: true
14:52:37 [oedipus]
SM: might be useful to have SCRIPT and @implements independent of XML Events - applies to Handlers as well
14:52:52 [Steven]
14:52:59 [alessio]
14:53:01 [oedipus]
SM: wonder if shouldn't have a module in specificiation - XML Events, Handler Element, Script ELement
14:53:07 [oedipus]
plus 1
14:53:16 [oedipus]
RM: agree
14:53:38 [oedipus]
RM: a convenience that in one document, but they are separate --
14:53:58 [oedipus]
SM: imagin e there is a Script Module without dependency on other 2 modules
14:54:02 [oedipus]
RM: does not appear so
14:54:15 [oedipus]
SM: new Handler module without new Events module doesn't make sense
14:54:31 [oedipus]
RM: some actions could be useful without events
14:54:54 [oedipus]
SM: if anything has dependency on events, then depenency on events module
14:54:56 [oedipus]
RM: yes
14:55:08 [oedipus]
RM: only exception is script - no dependence on other 2
14:55:14 [oedipus]
SM: then separate it out
14:55:30 [oedipus]
SM: make sense to have XML Events Module without XML Handlers Module?
14:55:51 [oedipus]
RM: XML Events 1 are used today and there are no handlers, so must have some value without handlers
14:56:20 [oedipus]
SP: didn't define handlers because wanted people to use handlers already had on XML Events
14:56:41 [oedipus]
SM: require people to use XML Events Module AND XML Handlers Modlue?
14:56:43 [oedipus]
SP: no
14:56:47 [oedipus]
SM: good
14:57:29 [oedipus]
RM: proposal: split into 3 modules - XML Events, XML Handlers, and Script plus change in wording about use of XPath
14:57:36 [oedipus]
SM: minor editorial stuff too
14:58:27 [oedipus]
RESOLVED: will break into 3 Modules: XML Events Module, XML Handlers Module, and Script Module
14:58:43 [oedipus]
rrsagent, make minutes
14:58:43 [RRSAgent]
I have made the request to generate oedipus
14:58:57 [oedipus]
SM: accept Yam's proposal
14:59:15 [oedipus]
Yam: change attribution/acknowledgement
14:59:27 [oedipus]
RM: needs to describe who we are today and who is doing the work today
15:00:14 [oedipus]
TOPIC: Features of XML Events
15:00:59 [oedipus]
RM: namespaces - should be dealing with someting more fine grained in namespace
15:01:17 [oedipus]
RM: there is another namespace option
15:01:17 [Zakim]
15:01:20 [Steven]
s/Features/Feature identification in/
15:01:31 [Steven]
scribe: Steven
15:01:57 [Steven]
RM: So a namespace is rather too coarse grain to define the features that will be implemented
15:02:24 [Steven]
SM: The spec says CURIEs are used for identification
15:02:37 [Steven]
... the CURIE spec allows for reserved values
15:03:07 [Steven]
... but doesn't allow for multiple default prefixes
15:03:25 [Zakim]
15:04:19 [Steven]
... so if we are to define a separate vocab document, it *can't* be another default vocab
15:04:35 [Steven]
15:04:59 [Steven]
SM: So you may as well just use the URI
15:05:03 [oedipus]
thought was supposed to be able to use URI
15:05:29 [Steven]
RM: You're only going to write this once, so it isn't a major problem having to write it
15:05:36 [ShaneM]
15:05:48 [Steven]
15:06:02 [Steven]
SM: That was what I had in mind
15:06:05 [Steven]
RM: Me too
15:06:42 [Steven]
10 01
15:07:04 [Steven]
RM: So if I implemented XML Events 2, what would it say?
15:07:28 [ShaneM]
15:07:41 [oedipus]
implements="m12n:events m12n:handlers" ?
15:07:50 [Steven]
SM: Right, so we mneed to define the term for each module
15:08:14 [Steven]
15:08:32 [Steven]
RM: Can we agregate features?
15:08:42 [Steven]
Steven: I hope so; eg XForms
15:08:48 [Steven]
... or even XHTML2
15:08:52 [oedipus]
me too
15:10:21 [oedipus]
RM: core - first features XML Events
15:10:35 [oedipus]
RM: XML Events not in xmlns
15:10:43 [Steven]
scribe: oedipus
15:10:47 [oedipus]
RM: URI probablly different
15:10:58 [oedipus]
SM: keep conflating namespaces and vocabulary spaces
15:10:58 [ShaneM]
15:11:18 [Zakim]
15:11:20 [oedipus]
RM: would break linkage to NS
15:11:45 [oedipus]
RM: using namespace name suggest something that isn't true - or a linkage that isn't there
15:12:02 [oedipus]
SM: in feature space can put anywhere we want, but makes sense to coollect in single place
15:12:10 [Zakim]
15:12:15 [alessio]
zakim, ??P2 is Alessio
15:12:15 [Zakim]
+Alessio; got it
15:12:25 [oedipus]
SM: is XForms in this document or will they incorporate?
15:12:35 [oedipus]
RM: can go anywhere URI can point to
15:13:16 [ShaneM]
ACTION: Shane create an initial features document that includes the features from XML Events 2.
15:13:32 [oedipus]
GJR: point about conflating namespaces and vocab spaces very pertinent (for building expert handlers)
15:13:45 [oedipus]
SM: should point to XML Events - so good BP in document
15:14:06 [oedipus]
RM: in script element, could show how to point to other parts of document -- could in fact, implement itself
15:14:11 [oedipus]
RM: could be bootstrapped in
15:14:30 [oedipus]
SM: could.... but not sure for first version
15:14:38 [oedipus]
RM: showing how implments handler events
15:14:58 [oedipus]
RM: any other thoughts on this topic?
15:15:12 [oedipus]
SP: action shane has is list names of features and module feature represents, right?
15:15:27 [oedipus]
RM: assign names to features and make clear that named features are modules in question
15:15:46 [oedipus]
SM: have a vision of it - linked together and back to base spec
15:16:05 [oedipus]
SM: want meaningful triples - should have best practices
15:16:16 [oedipus]
RM: not just in spec, but in position to develop solution that does it
15:16:19 [oedipus]
SM: definitely
15:16:31 [oedipus]
RM: other comments?
15:16:34 [yamx]
no from me.
15:16:52 [oedipus]
RM: conclude this topic - anything else to go back over from earlier today?
15:17:09 [oedipus]
RM: have some catch-up time tomorrow morning
15:18:06 [oedipus]
Yam: yesterday mark mentioned HTML5 group have security issues - relevant for any ML - if devise good mechansim for wwindow shouold be seperate spec
15:18:34 [oedipus]
Yam: interesting info, but dont' think was captgured in minutes
15:19:38 [oedipus]
15:19:58 [Roland]
15:20:00 [oedipus]
RM: action number 2 - immediately after mark's comments
15:20:01 [oedipus]
15:21:08 [oedipus]
RM: idea was MarkB go back on items and our reply should be consistent with / coordinate with XForms response on this
15:21:41 [oedipus]
SP: moved comments up into section where topic discussed
15:22:04 [oedipus]
RM: Yam correct, do want to ensure coordinated response
15:22:21 [oedipus]
Yam: don't agree with justifications
15:23:46 [oedipus]
========= ADJOURN ============
15:23:54 [Zakim]
15:23:57 [Zakim]
15:23:59 [Zakim]
15:24:05 [Zakim]
15:24:07 [Zakim]
15:24:07 [Zakim]
15:24:09 [Zakim]
15:24:10 [Zakim]
IA_XHTML2()4:00AM has ended
15:24:11 [Zakim]
Attendees were Roland, ShaneM, Steven, Gregory_Rosmaita, Yam, Alessio, Tina, yamx
15:24:18 [oedipus]
rrsagent, make minutes
15:24:18 [RRSAgent]
I have made the request to generate oedipus
15:24:41 [Lachy]
Lachy has joined #xhtml
15:25:00 [oedipus]
rrsagent, please part
15:25:00 [RRSAgent]
I see 5 open action items saved in :
15:25:00 [RRSAgent]
ACTION: Shane craft text to about transformation of XHTML to HTML. [1]
15:25:00 [RRSAgent]
recorded in
15:25:00 [RRSAgent]
ACTION: Shane to finish the updating the XHTMLMIME draft then respond to Olivier's proposal. [2]
15:25:00 [RRSAgent]
recorded in
15:25:00 [RRSAgent]
ACTION: Steven - draft proposal for XHTML 1.2 - Content and Timescale [3]
15:25:00 [RRSAgent]
recorded in
15:25:00 [RRSAgent]
15:25:00 [RRSAgent]
recorded in
15:25:00 [RRSAgent]
ACTION: Shane create an initial features document that includes the features from XML Events 2. [5]
15:25:00 [RRSAgent]
recorded in