See also: IRC log
<ht> scribe: Larry Masinter
<ht> scribenick: masinter
nm: invited HTML-WG chairs at 3:30
TVR: at-risk for Fri
... regrets 12th Nov
nm: the rest of TAG who haven't
should review status of open issues that they are shepherd for
by 10th Nov, please.
... future F2F meetings review (see agenda)
... TAG call for nominations posted
from 23-25 Sep F2F approved
... minutes of october 8 approved
... minutes of October 22 approved
see agenda for references to minutes
<trackbot> ACTION-318 -- Noah Mendelsohn to send note to Device APIs and Policy (DAP) Working Group on behalf of the TAG -- due 2009-10-25 -- OPEN
<trackbot> ACTION-321 -- Noah Mendelsohn to bug Larry about his input to ACTION-318 -- due 2009-10-29 -- OPEN
action-321 was reassigned to lmm
<trackbot> ACTION-321 -- Larry Masinter to lightly edit TAG input to DAP WG per 8 Oct and tell Noah -- due 2009-10-29 -- OPEN
<DanC> (lmm, actions/321 has a link to the note to edit in the comments)
Art Barstow invited TAG to come down to talk to WebApps, discussing whether we want to have that meeting
<jar> blast. wish I could
<DanC> HT relayed the TAG's request for an issue; the chair, Barstow, forwarded it to the group; the folks with concern about confused deputy don't seem to be stepping forward to say "yes, we want an issue"
ht: My email asked them to open an issue. But my reading of the thread that followed didn't pile in and say 'yes'
<jar> Mark M is away from email for a couple of weeks
<jar> I don't know about Tyler, and I haven't weighed in because I don't know what to add (and I'm not on the WG)
<jar> MM said on the list that he'd be gone and that he looks forward to a discussion when he returns
<noahm> LM: There's the technical issue, but also process issue as to whether WebApps is the right place to settle this security design.
<noahm> LM: Also, Thomas Roessler is organizing a lunch on Thursday to discuss web security
<jar> the last message on the thread basically said unguessable tokens was best practice, and should be used in *addition* to cors. I contemplated a response saying why do you need Origin: if you're using unguessable tokens, but haven't figured out how to say this in a constructive way
<jar> it's hard to participate given limited time
<masinter_> Poll: Security get-together at TPAC
Thursday lunch meeting on web security
<DanC> scribe: DanC
on text/html... and "XHTML" served as...
TBL: proposed requirement: XHTML served as text/html should work
DanC: that's not feasible
TBL: I'm doing it; it works
NM: clarify, please?. "Works" means is interpreted as it would be as application/xhtml+xml?
DanC: you're not doing it in the general case; you stated the requirement in the general case
HT: what doesn't work?
DanC: <blockquote />
HT: There's a well-documented set of constraints
NM: So, Dan, when you say it's infeasible, you're saying "browsers already interpret text/html in a way that conflicts with being compatible with application/xhtml+xml"
DC: Yes, see example of <BLOCKQUOTE /> above
LMM: I come back to the point
that IETF requires that old content not be invalidated by new
... currently, the spec goes against that.
<masinter> One possible requirement for re-registering a media type is that a new update should not make previously valid content invalid.
<masinter> Previously valid content included XHTML to be served as text/html, as well as consistent versions.
<noahm> FWIW, I would like to converge ASAP on: "Here's what the TAG wants to achieve on this during our Thurs. discussion:
TBL: that's not the HTML WG change policy; their change policy for changes is "we'll consider the costs/impact", not 100% backward compat
LMM: but you can't redefine the media type
DC: I think the WG has accepted that. Old stuff that broke that is now viewed as bugs.
LMM: they've accepted it to some degree, but it doesn't give a coherent view of HTML 2, for example. [something like that]
<Zakim> DanC, you wanted to visit "well-documented set of constraints" and to speak to the new/old invalid
DC: Henry, you said there is a well doc'd set of constraints. There isn't, but that would be a good goal.
HT: What's in the spec isn't good enough.
DC: Not cited by HTML 5, disputed.
HT: Works for me.
DC: Me too.
HT: Is it in the current media
... there's the architectural/versioning aspect of this that LMM is speaking to...
<masinter> "The text/html media type is now defined by W3C Recommendations;
<masinter> the latest published version is [HTML401]. In addition, [XHTML1]
<masinter> defines a profile of use of XHTML which is compatible with HTML
<masinter> 4.01 and which may also be labeled as text/html."
NM: Do we know what to ask for?
DC: Maybe, recruit a writer to write up ...????
HT: what I want is: in the case where the content starts with an XML declaration, parse it with an XML parser
(poll for support around that)
(discussion of label conforming ....)
<Zakim> masinter, you wanted to ask for something else
LMM: I don't think conformance requirements stated in terms of how it's processed is [good]
NM: I meant it as a shorthand
LMM: the "appendix C" was an
intersection... until XHTML is well-deployed
... the question is whether anything in HTML5 [breaks] this
TBL: I don't want a
... I want people to be able to incrementally tidy things up
<masinter> in HTML4 there was a set of documents in the intersection of HTML4 and XHTML such that documents in the intersection could be interpreted EITHER as XML *OR* as HTML, and that it wouldn't matter how it was processed.
<masinter> We are asking for HTML5 to retain that there is a useful subset in the intersection of HTML5 and XHTML
<ht> The above URI http://hixie.ch/advocacy/xhtml is Hixie's old, but somewhat updated, argument against _serving_ XHTML as text/html
<ht> I think it's actually mostly irrelevant as an argument against 'sniffing' and then _parsing_ some text/html as XHTML
<DanC_> ^^ that comment is still pending:
(discussion of W3C web site that have .htaccess depending on browser sniffing to serve the same documents in appendix C subset as text/html or application/xhtml+xml)
<noahm> Am I confused, I thought that question was whether it is legal to send <p>XXX</p> as text/html (I.e. because it happens to be well formed XML)
[scribing lightly until we get closer to a conclusion...]
<noahm> Why can't this be text html? <p>xxxx</p><video>...</video>
<noahm> <html><body> <p>xxxx<video>...</video></body></html>
propose we endorse http://lists.w3.org/Archives/Public/public-html/2007Aug/1188.html
"XML documents that use elements or attributes from the HTML namespace and that are served over the wire (e.g. by HTTP) must be sent using an XML MIME type such as application/xml or application/xhtml+xml and must not be served as text/html. [RFC3023]"
<noahm> Doesn't that rule out <p>XXXXX</p> as text/html
PROPSED: take out ^^^
RESOLUTION: to request that "XML documents that use elements or attributes from the HTML namespace and that are served over the wire (e.g. by HTTP) must be sent using an XML MIME type such as application/xml or application/xhtml+xml and must not be served as text/html. [RFC3023]" be removed
LMM: there's also the overall
... but perhaps we can follow that up in a different vendue
TBL: PROPOSED: that the microdata [data?] section be removed
HT: I gather the microdata stuff is specified separately, while it's still in the spec
<masinter> there is something else we might also want to say about text/html, even if we aren't ready to say
TBL: PROPOSED: that the microdata
section be moved to a separate spec
... PROPOSED2: that the data-* section be moved to a separate spec
LMM: no... they should be
removed, not just moved; they're out of scope of the WG
... the proponents are free to propose it, and to ask that the WG charter be extended...
TVR: given that the WHATWG has declared last call and that they've published an aggregate spec, it seems likely that if they remove it from the W3C spec, they'd keep it in the WHATWG spec
TBL: yes, that won't surprise me...
LMM: vendors often implement and
specify non-standard stuff
... a rats-nest of overly interdependent stuff stifles innovation
NM: I wonder which version of the spec would get pointed to from the media type registration
<masinter> The requirement for the charter of HTML WG is that it should have extensibility mechanisms that would allow it
<ht> Not clear what status it has -- it's _not_ at WhatWG. . .
timbl: we should not be distracted by what WhatWG may or may not do
yes, we just took a position on issue 76 (microdata)
RESOLUTION: to request that the microdata section be removed from the HTML 5 spec
RESOLUTION: to request that the data-* section be removed from the HTML 5 spec
NM: about the idea of an
"authoring spec" for HTML 5...
... we talked about that in Maneliue [sp?]
... IH said he could produce that as a view of the text he wrote
... I had some misgivings that this would work, but he has since done it...
... I tried to grab it and read it on the plane but found that I only got the TOC document
author view of HTML 5 spec - static copy (2nd try) Dan Connolly (Wednesday, 26 August) http://lists.w3.org/Archives/Public/public-html/2009Aug/1296.html
scribe: I'm interested to take a closer look in the next couple days... can anybody tell me how the WG treats it?
DanC: I did some scripting with
it a while back...
... what I like most about it is that it clarifies discussion with the editor; you can ask "is this about browsers or about documents" and see the outcome clearly in the spec
LMM: I don't think many of the API invariants are document [clearly?] [?]
TVR: I don't find this "view of the big spec" approach appealling. It doesn't tell producers the minimum they need to do to conform [?]
NM: LMM, there is a lot about DOM APIs in the authoring version of the spec
LMM: I spent a lot of energy on one example: downloading images, width and "available" and "not available"
<timbl> TVR: The original spec was said to be necessarily non-machine readable, and this new auhtoring spec is said to be a CSS-filtere version of the original, and theefore a spec which is also not machine-readable, and therefore -- as I beleive a language should be specs in a machne-readble way -- not a suitable spec. (?)
<ht> Where did that link _come_ from??????
TVR: so how is this image width analysis relevant to the authoring spec?
LMM: it's specified as a
normative algorithm. what it tells authors is that if width is
available, height is available. [er... I thought he was going
to point out a problem but I didn't hear him give one; did he
get cut off?]
... my point, and it applies to other API specs as well, is that the HTML 5 spec doesn't give a reasonable [... SCRIBE BRAIN EXPLODING]
NM: my point is that this "view of the main spec" won't produce something good for authors
HT: whether a spec should be for implementors or end-users is a very interesting question with lots of history in W3C, but it's editorial, and not architectural
LMM: a language spec serves not only authors and browser implementors but lots of other sorts of agents that consume/produce HTML.
<ht> Lachlan Hunt's "A Web Developer’s Guide to HTML 5" has sometimes been referred to as an authoring guide: http://dev.w3.org/html5/html-author/
<ht> THis is the WG's issue on this topic: http://www.w3.org/html/wg/tracker/issues/59
<ht> Here's Mike Smith's document: http://dev.w3.org/html5/markup/
<ht> Here's an interesting survey of the authoring spec. space: http://edward.oconnor.cx/2009/09/normativity
[discussion of logistics for Thu... 1pm start time suggested.]
NM: tell us about last call... where are you?
SR: we're trying to get issues raised ASAP, rather than having the community treat last call as a time to start raising issues
PC: we're setting up a last call process
NM: we just noted/discussed the bug/tracker-issue escalation stuff
PC: we've been testing the last
call process in the WG
... the accessibility issues look like a long pole get over
SR: e.g. there's an accessibility
issue where a _proposal_ is due 17 Dec
... we're setting expectation that lacking a propsal, we'll time-out issues
NM: are these internal issues? do you check with issue raisers?
SR: it's such an open WG, but
yes, in some sense they're all internal so far
... [..missed some...] "canvas isn't accessible" is both hard and [wrong?].
HT: can you clarify... are issues closed simply for lack of a proposal?
PC: we close _without prejudice_, so they can be re-opened at a later stage if required, and we explicitly call for consensus
[discussion of polyglot documents...]
[discussion of text/html media type registration... whether it should go in the html 5 spec or not... to what extent the html 5 spec re-writes history]
(ht which is that issue again?)
PC: advocates of microdata/RDFa haven't said they think they should be developed independently of the HTML WG.
HT: it's people outside the WG that express this opinion
LMM: yes, the W3C membership explicitly considers these modularity issues, as they relate to which experts/engineers to send to which groups
SR: hmm... not sure I'd heard concerns around data-* before
PC: right; don't expect the WG to be familiar with that.
TBL: data-* competes with URI-based designs such as RDFa
SR: odd... data-* is local to a page... i.e. to be consumed by js on the page, not by crawlers
TBL: but once there's lots of useful data-* data somewhere, crawlers will want to crawl
SR: hmm... yes, I can see the inevitability of that. hmm.
[... discussion of various lists of things in various stages of discussion]
NM: we didn't get to distributed extensibility this AM
SR: there are 2 things: (1) do we want people to be able to make up their own elements? (2) XML namespaces as is. Don't lead with (1) if your requirement is actually (2)
NM projects quote from HTML 5 spec on #other-applicable-specification
[discussion of the CSS moz- technique in comparison to URI-based techniques]
[discussion of DOMs with namespaces that can only be created from scripts, not from markup]