- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Tue, 06 Oct 2009 09:32:27 +0100
- To: www-tag@w3.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Are now available at
http://www.w3.org/2001/tag/2009/10/01-minutes.html
and below.
ht
- ---------------
- DRAFT -
TAG telcon
01 Oct 2009
[2]Agenda
See also: [3]IRC log
Attendees
Present
Noah Mendelsohn, Jonathan Rees, Henry S. Thompson, Larry Masinter,
Dan Connolly, Tim Berners-Lee
Regrets
Ashok Malhotra, John Kemp
Chair
Noah Mendelsohn
Scribe
Henry S. Thompson with help from Noah Mendelsohn and Tim Berners-Lee
Contents
* [4]Topics
1. [5]Admin
2. [6]HTML 5 review
3. [7]Relationship between the DOM and its HTML serializations
_________________________________________________________________
Admin
NM: Next call 2009-10-08, scribe-designate is DC
... We are still waiting on DC for f2f minute cleanup for 23 and JAR for 25
HTML 5 review
<noah> [8]http://www.w3.org/2001/tag/2009/09/HTMLIssuesRevised.pdf
LM: Let's look for things we can conclude
HST: I explored some background wrt this topic
<masinter> it's ok, i hope we eventually get to all
HT: I checked whether it's intended to be the case that there is expected to
be a relationship between document conformance, and processor recovery. The
answer is no.
... In the case of a binary attribute, there is no error condition noticed
or recovered in the case of an unexpected value. Allows for extensibility.
HT: So, not a high priority
<DanC> (huh? for binary, the spec determines a "true" or "false" value for
every case, no?)
<ht> Yes, DC, but there is no error recovery required
<ht> No error is even detected
<jar> because there are no errors in that case?
<DanC> well, returning "true" or "false" is error recovery, no?
<ht> What I mean is there is nothing in the spec of the form "recover by
...." or any indication wrt the processor that anything unusual has happened
at all
<Zakim> masinter, you wanted to say the purpose of a mime type is to tell
the receiver what the sender intended when the sender sent the message with
the mime type label
Relationship between the DOM and its HTML serializations
TBL: This sounds like the fact that the parsing of XML and HTML are
different
... even if you parse the same document in the two different ways you may
get different DOMs
... e.g. the insertion (or not) of a tbody
<noah> Anyone else remember the nuances of what was intended by this one.
<noah> If we can't agreement on what this issue was, and why it's high
priority, I'm going to pick another.
<DanC> (I wonder if the <tbody> thing is in the appendix C guidelines
[9]http://www.w3.org/TR/xhtml1/#guidelines ...)
<DanC> (yes... it is, briefly... "e.g. the tbody element within table")
HT: I think this has to do with "what is the spec about"? Is it the
semantics of the DOM? The serialization. At the moment it's about both.
JAR: And about the APIs?
<ht> scribenick: ht
LM: There were once two documents, HTML and the DOM, but the interactions
were sufficiently complex that they've now been merged
... but the result has sort of lost the definition of the HTM Language
... which leads us back to the desire to separate out the language
definition
LM: I have some sympathy wrt this because browsers are in fact based on the
DOM API
<timbl> Browsers -- code in general which treats HTML or XML should be
written in terms of the DOM, of course, not the serialization.
HT: Yes. The argument that document.write makes it difficult to separate
behavioral and static aspects of the spec is a sound one. Until we find
"allies" and find partial consensus to find version that does not support
document.write, at least in the context of live scripting (at parse
time)....
... Script outside the head.
<Zakim> masinter, you wanted to say 'not possible' is wrong; 'difficult'
perhaps and to point out also about security contexts which don't allow the
things that also give difficulty
LM: I think it is possible to define a language and DOM w/o document.write
... and then add document.write as a feature
... There are also security contexts in which document.write is not allowed
... They would benefit from a clean defn of the language
NM: When?
<DanC> (html mail is an example)
<timbl> Suppose we recognize that document.write() is a dirty level-breaker
and those who enter abandon hope of simplicity or wide interoperability. And
we promote the alternatives -- often document.write is used when a cleaner
alrernative exists, or should be designed.
<noah> Thanks dan, that's what I expected to hear.
LM: Mashups
TBL: document.write is a classic piece of dangerous engineering -- distrust
self-modifying code -- we could divide cases into reasonable and a safer
cleaner alternative provided, and bad cases
... innerHTML=... [??? a better alternative ???]
<DanC> (raman pointed me to a script loading technique that didn't use
document.write(); I think I lost track of it before I managed to study it
closely.)
TBL: In contrast squeezing a new script elt via document.write in order to
get around the lack of dynamic script loading
<DanC> tim said .becomes() is better than .innerHTML =
TBL: We could promote the alternatives
<Zakim> DanC, you wanted to note (a) a streaming subset of HTML that
hsivonen found/implemented that's pretty interesting and (b) remaining open
issues in specifying document.write() and
DC: Separating out document.write has been asserted to be hard, but Henri
Siv. allowed document.write in a one-pass HTML parser -- that could/should
be promoted
... People talk as if the HTML 5 parsing algorithm is done, but it isn't --
when Henri implemented the published algorithm in the Mozilla code carcass,
it doesn't go back and reparse as often as the browsers actually do, and
this causes interop bugs
TBL: Example?
DC: Heuristics for distinguishing actual comments from JS inside comments
... THere is a list of 3 problems from Henri [ref?]
... This is classified as 'needs research' in Hixie's queue
DC: Discussion to date by WHATWG has not reached a good conclusion
<DanC> re fixes re reparsing: "Wow. Please can we stick to just the current
magic escapes and not add even more magic?" -- Ian Hickson
[10]http://lists.w3.org/Archives/Public/public-html/2009Aug/0617.html
<DanC> (re streaming subset... looks like hsivonen doesn't support it as a
feature, but he sketched it in
[11]http://lists.w3.org/Archives/Public/public-html/2009May/0582.html )
NM: I think it's true in principle that documenting a language w/o
document.write would be a good thing
... but in practice it is widely used, and insofar as HTML 5 is about what
browsers actually do
... we have to document the true complexity of the current situation
... So either someone has to demonstrate that layering will achieve this
... because otherwise we will just have to write two documents
NM: And I think the first is unlikely to succeed
... because of asynchrony, for instance
<jar> maybe some macrology... generate multiple docs from single source
NM: So, without a sketch of what a declarative story would look like, I
don't think we can take this forward
<noah> Specifically, I think the challenge is to find someone who can do a
more declarative exposition of all the logic they now have, including
document.write
<noah> Note to Henry: gee, the DOM/document spec split reminds a lot of the
difficulties in writing a convenient specification for XSD at both the
serialization and component level
<Zakim> masinter, you wanted to ask to separate editorial vs. normative
requirements issues
LM: The definition of interop used in the HTML 5 discussion is pretty
different from what we're used to -- its "works the same" rather than "as
specified"
... For example, different chrome and different behaviour of the back button
[scribe is lost, invites LM to write this down]
<noah> [fwiw, I'm finding it hard to follow Larry too]
LM: Roy F.' s argument that many HTML applications don't have a DOM, and
there's no place to put the conformance requirements on those applications
LM: so all you have is a definition of conformant documents, and a
definition of conformant DOM-based consumers, but no definition of
conformant processors which are not DOM-based
TB<
xxx
<jar> The conformance section of HTML5 explicitly acknolwedges non-browser
(and I think non-DOM) consumers
<Zakim> timbl, you wanted to say one could rough out a very conservative
version of the languge, for example which just does't have scripts or
doesn't have document.write(). and to say one
TBL: What about "if in doubt, throw it out" -- that is,
... not looking for biggest language you can define
TBL: I don't use script (or tbody) or document.write, so life is simpler for
me
... And we could document how simple it gets
... Having specs for docs and for behaviour isn't crazy, as long as you can
show they match up and give a coherent protocol
TBL: It would be nice to show that relationship holds mathematically
<noah> I think Tim missed my point, which is that these folks will want to
document how browsers work. I never questioned that smaller languages could
be documented. I questioned whether anyone would invest in maintaining that
spec in duplicate with the full browser spec.
NM: There seems to be a concensus in the community that a documentation of
current browser behaviour is needed
<DanC> masinter, re proxies etc., they can treat "DOM" as "abstract syntax"
or "data model" or "infoset", as sivonen argued in
[12]http://lists.w3.org/Archives/Public/public-html/2009Aug/1322.html
NM: If that's going to be done, and done well, that leaves the simpler
cleaner subsets
TBL: What about a profile?
NM: It's hard to profile the non-declarative form of the current spec.
TBL: But if you just say "look at that spec., don't use document.write, use
tbody, then things are much better"
NM: Maybe, but that wouldn't be the same as a much simpler spec. written
explicitly to define the simpler language
... which defines the two simple trees (doc and DOM) and a clean
non-procedural mapping between them
<DanC> (yes, it does seem to me that the goal of HTML 5, to specify every
case of how scripts work, involves solving the halting problem)
<Zakim> noah, you wanted to ask, with chair hat on, is this discussion on a
path to useful input to the HTML 5 group, or at least articulating our
concerns more clearly and accurately?
NM: How is this feeding into helping the HTML 5 WG?
<Zakim> timbl2, you wanted to say to Larry (a) it is in general correct and
normal to spec the semantics of a language in terms of the abstract model
not the syntax, for XML and RDF for example
<Zakim> masinter, you wanted to point out that the goal has been to
accomplish something that no standard in the history of standards, much less
in the history of computer software
DC: I think if you look at the DOM as abstract syntax, similar to XPath data
model or infoset, then the "agents that are not DOM-based lose" argument
collapses
LM: I'm not sure the consensus is ...
... The group is chartered to produce an incremental update of the HTML
language and the DOM, but not necessarily a browser implementation spec.
<noah> Is Larry's characterization of the HTML WG charter correct? I took it
as implicit, and perhaps explicit, that when WhatWG teamed up with W3C, that
a user agent spec was very much a goal. Am I wrong?
LM: The intent to write a standard which matches exactly and precisely to
what is implemented has no precedent
... Maybe a C language spec.
<noah> Class loaders in Java?
<DanC> a user agent spec isn't explicit in the charter.
([13]http://www.w3.org/2007/03/HTML-WG-charter.html )
<masinter> [14]http://krijnhoetmer.nl/irc-logs/whatwg/20090927#l-459
LM: The desire to specify exactly what browsers do moves you from language
description to algorithms to describe behaviour
... This seems different from any spec. I'm familiar with
HT: Interestingly, the XML grammar simultaneously defines the XML language
both before and after entity replacement. Trying to do something like that
for HTML, in order to make the treatment of load-time scripting and
document.write at least partly declarative, is an interesting challenge.
Then there is Noah/Raman's question: even if we could, would it have impact
on the working group?
HT: We would have to convince them that this would lead to a better way of
achieving their existing goals. Seems unlikely.
<noah> I agree with Dan; that bit of the XML spec is tricky, not a model for
future work.
<timbl> DanC, in what way .. what params or whether a charcstream or byte
stream etc ?
<DanC> char stream, or dictionary of entity_name->char_stream, etc.
<DanC> (noah and timbl are responding to an unminuted comment that I made: I
was never happy with that aspect of the XML spec... it's not at all clear
what the input to an XML parser is )
NM: [15]http://www.w3.org/2007/03/HTML-WG-charter.html
"A language evolved from HTML4 for describing the semantics of documents
and applications on the World Wide Web. This will be a complete
specification, not a delta specification."
NM: The history of all this is unusual
... The WHATWG perceived a gap in what the W3C was doing
... I've always understood that their goal was to document what was required
to build the next Mozilla or Opera or Chrome
... not at the superficial level
... but in terms of how the language and the DOM and CSS combine to do the
right thing
NM: That project attracted support, and we can't ignore that
... saying the world doesn't or shouldn't care about that project is
pointless -- that train has left the station
... Our only possible way forward is to show that an alternative, layered,
approach actually achieves their goals, and has other benefits
LM: I disagree that the train has left the station -- even if this project
goes ahead unchanged, it's still appropriate for the TAG to describe what
should have happened
<noah> I think this spec. will have more direct impact than any other spec
the W3C produces in this period of several years. I want to put a top
priority on helping it, or making it better. Just saying why it's wrong or
could have done better, even if true, strikes me as a much lower priority
for now.
LM: Doing more than just hand-waving is important, to delve into our
concerns
... DC may think that converting DOM-construction specifications into more
declarative ones isn't difficult, but it seems to make backing off of some
aspects much much harder
<DanC> ("difficult" I don't disagree with. The claim [I heard] was "does not
apply to non-DOM-based agents")
<noah> I think the future will be reached by evolving from whateve winds up
in this spec. Maybe or maybe not getting someone to write a clean spec in
parallel will have good influence as well, but the XHTML experience makes me
pessimistic.
NM: So, suppose we agreed with all you said, what should we do?
<Zakim> timbl, you wanted to point out the ffuture is longer than the past
LM: Historically outputs for us include Notes, Findings and WebArch. . .
... advice to members, or to the Team
... we could encourage the production of another spec. with better
properties
TBL: In one sense it's left, but it has a long way to go in the future
... Pointing out that a simpler language has good properties might stimulate
interest
... A book might get written without our help
<masinter> I think the concern is around allowing use of the same spec with
different normative requirements for different applications, for example,
those that don't have DOMs
TBL: There will be vast numbers of books about HTML 5 -- the spec. is not
the last thing that will happen
... and more specs will come
<noah> FWIW, while I appeared to disagree with Tim earlier, I agree
completely with what he's saying here. Pointing out the advantages of
cleaner and/or smaller formulations is a good thing to do.
TBL: I would like to find things to point to which say that BNF is better
than C code
<noah> I don't think it fulfills our responsibility to help the larger spec
be more successful too.
TBL: Prioritize specific feedback requesting changes to the document
... For example, the Data section should be removed
<masinter> looking for "From Roy Fielding Wed 8/26/2009 10:23 AM"
LM: Maybe we should start a document: Summary of TAG issues/discussions wrt
the HTML 5 spec. . .
... Questions/issues/places where we're uneasy/would like further work
... Could even become a companion piece
<masinter> that's what you were asking for, Noah, is "what are we going to
do next"?
NM: Not ready for that kind of structuring question, still aiming for
specific feedback to the HTML WG on specific issues
LM: Are we procedurally blocked, or do we disagree about the technical
issue?
... Is there something which in principle we all agree would be a good
thing?
TBL: Yes, removing the Data section
<DanC> and what position are you asking whether I agree to?
<masinter> DanC: on Issue 11 about the spec being based on the DOM
NM: Back to issue 7
<noah> Still on issue 7 {-)
<masinter> sorry 7, not 11
<noah> Still on issue 7 :-)
TBL: Proposal: we should ask that the spec. specifies a set of constraints
under which one can publish XML to be read as HTML [without loss]
<masinter> I'm concerned about normative requirements for non-DOM-based HTML
consumers
<noah> Larry, we'll get to non-Dom issue in a minute. I heard you say that,
and several others disagree.
TBL: Anyone disagree?
DC: I do
JAR: I would like to know how that would be different from XHTML5
<DanC> TimBL asked whether he thought this would be a useful comment. I
think (a) the spec already allows it and (b) the resulting discussion would
be anything but useful.
TBL: If you mean the XML serialization of HTML5, the problem is that goes
through a different path
<jar> must be quarantined under a different media type
NM: So, one of your constraints would rule out document.write ?
TBL: Typically, yes
<DanC> the technical substance of TimBL's request was achieved when Sam Ruby
convinced Ian Hickson to allow <br />
TBL: One possibility would be don't use scripts
... or, scripts OK, but document.write out
... [another one, scribe missed]
<masinter> I think Roy has the most cogent argument about this, suggest
reading the discussion
<noah> Link?
<masinter>
[16]http://lists.w3.org/Archives/Public/public-html/2009Aug/1298.html
HST: So I heard LM to say that the output of our work need not be entirely,
or even mostly, feedback to the HTML WG -- even if we don't feed back to
them on certain issues, recording our discussions and conclusions would be
valuable in any case
TBL: Feedback to the WG is the most important thing
LM: Understood -- just that we may not feedback on everything we've talked
about
NM: For the future, and for other specs, setting out what we've learned is
valuable even if it doesn't affect the HTML 5 spec.
... but I reiterate that the HTML 5 spec. is going to have a huge impact,
and we need to focus on helping to make it better
... It will be the basis on which the future is built
<masinter> i don't understand why you think I disagree with you
NM: There are times when writing the clean spec. and getting away from the
old cruft is good
... but we can't shirk the responsibility to help make this spec that they
are writing better
... We've asked them to specify what they call an Authoring spec.
... TBL has suggested another request, that they specify another thing, a
clean subset
<masinter> noah: who are you arguing with?
TBL: Could we get the TAG to resolve that there should be a document subset
of HTML that can be serialized as XML?
<masinter> 1+, although I'd like something stronger
Noah: Pleas type in IRC whether you agree with the following proposal: that
there should be a documented subset of HTML that can be serialized as XML
<DanC> -1; it's not clear how this is asking for something that's not
already in the spec
<jar> jar defers to ht. can't fathom the implications
<masinter> although the discussion at F2F on alternate serializations of XML
infoset are interesting
<masinter> and the MS proposal on namespaces in HTML is interesting
<masinter> everyone see that?
TBL: +1
<DanC> (ht is no longer on this call, jar)
<noah> +1 Yes in principle; still on the fence as to whether asking the HTML
WG to do this now is on balance the right way and the right time
<jar> oh foo.
<jar> +0 I'd like to understand better. I'm being dense
<timbl> Jar, there is a statememt like "If you use doctype HTML and you use
tbody and you don't use document.write(), the you can serialize as XML and
label as HTML"
DC: I think this may already be there, in two ways 1) xml serialization is
defined and 2) lots of XML docs match the HTML grammar
<DanC> (yes, that's what I said, though there's not actually a grammar)
NM: Fair enough... the implied grammar :-)
<timbl> 2) no, HTML does not have <xx />
DC: yes it does
TBL: Really?
<masinter>
[17]http://lists.w3.org/Archives/Public/public-html/2009Aug/1184.html
<timbl> So which XML doc s don't match the HTML grammar, dan?
<DanC> the technical substance of TimBL's request was achieved when Sam Ruby
convinced Ian Hickson to allow <br />
DC: Yes
<masinter> "removal of the permission for sending syntactic profiles of XML
as text/html. "
<img />?
<timbl> masinter, is that an issue ?
Time check: 5 mins to go.
<DanC> (well, Ian Hickson's goal.)
masinter: There is an issue in HTML WG to update the registration of
text/html, to remove the permission to serve XML syntax as text/html
TBL: Open, closed or rejected issue?
LM: Closed.
TBL: Dropped?
DC: You sure it's closed?
... Issue 53 is pending review.
<DanC> [18]http://www.w3.org/html/wg/tracker/issues/53 ISSUE-53
<DanC> mediatypereg Need to update media type registrations
<DanC> State: PENDING REVIEW
LM: We can have influence by offering opinions on issues not yet closed in
HTML WG
1 minute
<DanC> (entertaining specific proposals does seem to be productive)
_________________________________________________________________
Minutes formatted by David Booth's [19]scribe.perl version 1.134 ([20]CVS
log)
$Date: 2009/10/05 17:30:14 $
References
1. http://www.w3.org/
2. http://www.w3.org/2001/tag/2009/10/01-agenda.html
3. http://www.w3.org/2009/10/01-tagmem-irc
4. http://www.w3.org/2001/tag/2009/10/01-minutes.html#agenda
5. http://www.w3.org/2001/tag/2009/10/01-minutes.html#item01
6. http://www.w3.org/2001/tag/2009/10/01-minutes.html#item02
7. http://www.w3.org/2001/tag/2009/10/01-minutes.html#item03
8. http://www.w3.org/2001/tag/2009/09/HTMLIssuesRevised.pdf
9. http://www.w3.org/TR/xhtml1/#guidelines
10. http://lists.w3.org/Archives/Public/public-html/2009Aug/0617.html
11. http://lists.w3.org/Archives/Public/public-html/2009May/0582.html
12. http://lists.w3.org/Archives/Public/public-html/2009Aug/1322.html
13. http://www.w3.org/2007/03/HTML-WG-charter.html
14. http://krijnhoetmer.nl/irc-logs/whatwg/20090927#l-459
15. http://www.w3.org/2007/03/HTML-WG-charter.html
16. http://lists.w3.org/Archives/Public/public-html/2009Aug/1298.html
17. http://lists.w3.org/Archives/Public/public-html/2009Aug/1184.html
18. http://www.w3.org/html/wg/tracker/issues/53
19. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
20. http://dev.w3.org/cvsweb/2002/scribe/
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFKywCbkjnJixAXWBoRAlQ7AJ9pkHfRXVv7uFIJV1KOsNImY0A59ACfTGsE
uWNci9ft7cG82KWmgAMjPGs=
=q/mi
-----END PGP SIGNATURE-----
Received on Tuesday, 6 October 2009 08:32:58 UTC