W3C home > Mailing lists > Public > www-tag@w3.org > October 2009

Draft minutes for TAG telcon 2009-10-01

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Tue, 06 Oct 2009 09:32:27 +0100
To: www-tag@w3.org
Message-ID: <f5bfx9wq5wk.fsf@hildegard.inf.ed.ac.uk>
Hash: SHA1

Are now available at


and below.

- ---------------
                                   - DRAFT -

                                  TAG telcon

                                  01 Oct 2009


   See also: [3]IRC log


          Noah Mendelsohn, Jonathan Rees, Henry S. Thompson, Larry Masinter,
          Dan Connolly, Tim Berners-Lee

          Ashok Malhotra, John Kemp

          Noah Mendelsohn

          Henry S. Thompson with help from Noah Mendelsohn and Tim Berners-Lee


     * [4]Topics
         1. [5]Admin
         2. [6]HTML 5 review
         3. [7]Relationship between the DOM and its HTML serializations


   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
   ... 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

   LM: I have some sympathy wrt this because browsers are in fact based on the

   <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
   ... 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

   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

   <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

   <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
   ... 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



   <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
   ... 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

   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

   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
   ... 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

   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

   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
   ... 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
   ... Is there something which in principle we all agree would be a good

   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

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


   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

   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?


   <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

   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
    $Date: 2009/10/05 17:30:14 $


   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]
Version: GnuPG v1.2.6 (GNU/Linux)

Received on Tuesday, 6 October 2009 08:32:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:03 UTC