TAG meeting during Santa Clara TPAC, part 1 (Monday AM) -- 02 Nov 2009

Convene, review records and agenda

<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

RESOLUTION: minutes from 23-25 Sep F2F approved
... minutes of october 8 approved
... minutes of October 22 approved

see agenda for references to minutes

privacy policy (Device APIs)

action-318?

<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> http://www.w3.org/2001/tag/group/track/actions/318

action-321?

<trackbot> ACTION-321 -- Noah Mendelsohn to bug Larry about his input to ACTION-318 -- due 2009-10-29 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/321

action-321 was reassigned to lmm

<DanC> action-321?

<trackbot> ACTION-321 -- Larry Masinter to lightly edit TAG input to DAP WG per 8 Oct and tell Noah -- due 2009-10-29 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/321

<DanC> (lmm, actions/321 has a link to the note to edit in the comments)

coordination with Webapps on CORS: preparation

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> CORS: email from Henry Thompson re "CORS still not getting to closure"

<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

coordination with Webapps on CORS: joint session

<DanC> CORS item in Web Applications Working Group 2 Nov minutes

<DanC> WebApps WG 'confused deputy problem' issue

Discussion topics with HTML WG on Thursday: text/html

<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 specs. [roughly]
... 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 type registration?
... 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."

<masinter> http://www.ietf.org/rfc/rfc2854.txt

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

[missed exchange]

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 "switch"...
... 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_> let authors choose text/html or application/xhtml+xml (detailed review of section 1. Introduction)

<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 XXX as text/html (I.e. because it happens to be well formed XML)

[scribing lightly until we get closer to a conclusion...]

propose we endorse http://lists.w3.org/Archives/Public/public-html/2007Aug/1188.html

(http://dev.w3.org/html5/spec/infrastructure.html#conformance-requirements )

<ht> http://www.whatwg.org/specs/web-apps/current-work/#conformance-requirements

"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 XXXXX as text/html

yes

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 compatibility stuff...
... but perhaps we can follow that up in a different vendue

Discussion topics with HTML WG on Thursday: data

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> the separate Microdata draft (it's 3 months old)

<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

<ht> HTML WG Microdata/RDFa issue

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

<ht> bug 7542 "Remove Section 5. Microdata"

Discussion topics with HTML WG on Thursday: authoring 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

<noahm> http://dev.w3.org/html5/spec-author-view/spec.html

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

.
.

Disucssion with HTML WG chairs

+PaulC

+SamR

[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?)

<ht> http://www.w3.org/html/wg/tracker/issues/76

[missed some...]

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]

<ht> yes

[discussion of DOMs with namespaces that can only be created from scripts, not from markup]

TAG meeting during Santa Clara TPAC, part 1 (Monday AM)

02 Nov 2009

Attendees

Contents