W3C home > Mailing lists > Public > public-html@w3.org > November 2008

{minutes} 2008-10-24 f2f meeting (day two)

From: Michael(tm) Smith <mike@w3.org>
Date: Fri, 7 Nov 2008 14:39:42 +0900
To: public-html@w3.org
Message-ID: <20081107053942.GC12526@toro.w3.mag.keio.ac.jp>


 * Topics

     1. Progress review/evaluation of stability of sections of
        HTML5 spec
     2. SVG in text/html

 * Summary of Action Items

Progress review/evaluation of stability of sections of HTML5

   ChrisWilson: The goal this morning is to go through the spec with an
   eye towards building a test suite

   MikeSmith: We talked about when the TAG was here, having a rational
   discussion about what parts of the spec can be split out
   ... Assess work effort for possible sections

   Hixie: I can take a action item to do that

   MikeSmith: We should focus now on the status part
   ... I can take on updating the annotations

   Hixie: What info do we want for a section?

   <DanC_lap> ah... found the annotations hacking I did; it's in


   MikeSmith: There is one section we should talk about right now

   <pimpbot> Title: html5/spec/ (at dev.w3.org)

   MikeSmith: 1.4.3 Relationship to XHTML 1.x

   Hixie: We are waiting from feedback from the XHTML2 WG

   Lachy: What were their complaints?

   Hixie: They didn't like it

   DanC_lap: We should find the email addressing their complaints

   <DanC> this one from Roland?


   <pimpbot> Title: Re: changes in HTML5 draft regarding XHTML1 from
   Roland Merrick on 2008-06-20 (public-html@w3.org from June 2008) (at

   MikeSmith: The initial objections were communicated privately to me

   <DanC_lap> in that 20 jun msg, he accepts the ball "I will put the
   subject on the agenda for our WG telecon.

   <DanC_lap> "

   MikeSmith: Originally they objected to language that has since been

   ml is the latest i could find


   <pimpbot> Title: Re: changes in HTML5 draft regarding XHTML1 from
   Roland Merrick on 2008-07-31 (public-xhtml2@w3.org from July 2008)
   (at lists.w3.org)

   <DanC_lap> "we will get back to you" -- Merrick 31 July


   <pimpbot> Title: Re: changes in HTML5 draft regarding XHTML1 from
   Roland Merrick on 2008-07-31 (public-html@w3.org from July 2008) (at

   <Lachy> The other messages from the XHTML2 WG:





   <Lachy> http://www.w3.org/2008/06/19-xhtml-minutes#item01


   <pimpbot> Title: Re: changes in HTML5 draft regarding XHTML1 from
   Roland Merrick on 2008-06-19 (public-html@w3.org from June 2008) (at

   <pimpbot> Title: Re: changes in HTML5 draft regarding XHTML1 from
   Roland Merrick on 2008-06-19 (public-html@w3.org from June 2008) (at

   <pimpbot> Title: XHTML2 WG Virtual FtF Day 3 -- 19 Jun 2008 (at

   MikeSmith: Hixie, we need another status category in your annotation
   tool for sections.

   <scribe> .... "pending feedback"

   Hixie: I would like to add something like "controversial feedback"

   <DanC_lap> issue-52: "we will get back to you" -- Merrick 31 July


   <trackbot> ISSUE-52 Resolve XHTML2 WG objections to language in
   HTML5 draft regarding XHTML1 notes added

   <pimpbot> Title: Re: changes in HTML5 draft regarding XHTML1 from
   Roland Merrick on 2008-07-31 (public-html@w3.org from July 2008) (at

   <DanC_lap> html5 is listed in http://www.w3.org/1999/xhtml too


   <pimpbot> Title: XHTML namespace (at www.w3.org)

   DanC: ISSUE-52 contains pointers XHMTL 2 WG's concern with the spec

   <CWilso> ACTION: ChrisWilson to suggestion text for 1.4.4 [recorded
   in http://www.w3.org/2008/10/24-html-wg-minutes.html#action01]

   <trackbot> Created ACTION-78 - Suggestion text for 1.4.4 [on Chris
   Wilson - due 2008-10-31].

   MikeSmith: Everytime I go somewhere to speak I am asked "how does
   XHTML 5 relate to XHTML 1 or 2"?

   <DanC_lap> action-62?

   <trackbot> ACTION-62 -- Michael(tm) Smith to ensure HTML WG response
   to XHTML 2 WG re name of XML serialization
   l -- due 2008-10-02 -- OPEN


   <trackbot> http://www.w3.org/html/wg/tracker/actions/62


   <pimpbot> Title: Re: The only name for the xml serialisation of
   html5 from Dan Connolly on 2007-10-31 (public-html@w3.org from
   October 2007) (at lists.w3.org)

   <pimpbot> Title: ACTION-62 - HTML Issue Tracking Tracker (at

   MikeSmith: I can talk to Roland this week and see where we are at

   CW: 1.5 is controversial because of the name "XHTML5"

   rsagent, make minutes public

   Lachy: I'm trying to find an older email where concerns were
   expressed about the namespace

   Murray_Maloney: I object to the namespace

   CW: Explain why we can't use something else

   Hixie: The browsers already use this namespace (in section 2.1.1)



   <pimpbot> Title: Test (at html5.lachy.id.au)

   MM: I understand that may be your goal, the namespace belongs to the
   W3C and XHTML
   ... You're applying a different meaning

   <CWilso> issue: Reuse of 1998 XHTML namespace is potentially

   <trackbot> Created ISSUE-60 - Reuse of 1999 XHTML namespace is
   potentially misleading/wrong ; please complete additional details at
   http://www.w3.org/html/wg/tracker/issues/60/edit .


   Lachy: In Firefox you get a DOM tree

   MM: Yesterday we had a talk with TAG about having a contract. There
   is an expectation with other user-agents and you're violating that

   <CWilso> ACTION: ChrisWilson - send email to spark issue-60
   [recorded in

   <trackbot> Created ACTION-79 - - send email to spark issue-60 [on
   Chris Wilson - due 2008-10-31].

   CW: We have evidence then that this section (2.1.1) is controversial

   MikeSmith: It might be nice to have a freeform comment field in your
   annotation tool

   Hixie: We do, it is the mailing list

   CW: It might be nice though to have these comments inline with the

   <DanC_lap> Lachy, is the namespace name observable from tests
   without using the application/xhtml-xml mime type?

   <Lachy> yes

   <zcorpan> alert(document.body.namespaceURI)

   <DanC_lap> ok. whew. thought I was confused.

   <Lachy> if we were to use a different namespace for the HTML
   serialisation from the XHTML serialisation, then that would create

   <Lachy> and we cannot get away with using a different namespace for

   <DanC_lap> seems worthwhile, to me, to capture that constraint in a
   test case. here's hoping.

   <zcorpan> switching namespace is as much of a non-starter as
   switching all the tag names. in fact it's basically the same thing

   MikeSmith: Moving on to review section 2.2

   Hixie: Conformance requirements is pretty stable

   DanC: I'm very much unhappy about the conformance section
   ... It is not objective, the conformance requirements depend on the
   mood of the author

   CW: I understand what you are saying, I might put it a different way

   <zcorpan> at least if you switch all the tag names you still keep
   the HTMLElement interface (so class and style etc still work). if
   you switch the namespace it's just Element (only xml:lang etc works)

   CW: you should raise the issue if you like

   DanC: I've raised it in an email before

   CW: You should make a recommendation with alternative language



   <pimpbot> Title: keep conformance objective (detailed review of
   section 1. Introduction) from Dan Connolly on 2007-08-30
   (public-html@w3.org from August 2007) (at lists.w3.org)

   <DanC_lap> issue: conformance depends on author's intent

   <trackbot> Created ISSUE-61 - Conformance depends on author's intent
   ; please complete additional details at
   http://www.w3.org/html/wg/tracker/issues/61/edit .


   <DanC_lap> issue-61: originates in


   <trackbot> ISSUE-61 Conformance depends on author's intent notes

   <pimpbot> Title: keep conformance objective (detailed review of
   section 1. Introduction) from Dan Connolly on 2007-08-30
   (public-html@w3.org from August 2007) (at lists.w3.org)

   MikeSmith: What about section 2.2.2? "this section will be removed
   at some point"

   Hixie: I want to replace it with a pointer to DOM3CORE

   MikeSmith: What is are the asterisks on the spec?

   Hixie: Whenever you see those there is a red box in that section

   CW: In section 2.3 is that really what IE does for string

   Hixie: Yes

   CW: We'll need to go through and double-check

   Hixie: Feedback on this section would be very welcome

   <DanC_lap> (this string compare stuff seems straightforward to test
   too. but ok... I guess I'm OK to focus more on status/requirements
   than test-suite-building)

   DanC: The annotation system allows for links to test, right?

   Hixie: Yes

   MikeSmith: Who has tests for section 2.4.1?

   <CWilso> [in section 2.3 - the issue is that IE does caseless string
   compares in some situations where other browsers might do ASCII
   case-insensitive compares. we will need to review each compare to
   ensure we're making the right decision.]

   Geoffery Sneddon: I had test for section 2.4.3 and I've just updated
   the annotation

   scribe: I think my tests may be out of date

   DanC: Someone can try to reproduce your results though

   MM: Can we have pointers in the spec to open issues?

   Hixie: It would be hard to keep them up-to-date

   <DanC_lap> (thousands of issues? I count 59.
   http://www.w3.org/html/wg/tracker/issues )


   <pimpbot> Title: Issues - HTML Issue Tracking Tracker (at

   GS: Could we have something like when a section was last edited?

   MM: What mechanism do we have to know there are no complaints?

   MikeSmith: We use the w3c tracker system and the w3c bugzilla system
   for different groups

   MM: I'm not interested in the systems, what is the process used
   within the working group to determine stability of the spec

   <DanC_lap> hmm... my annotations-munging code seems horked.

   MM: how can different groups tracking the stability of individual
   sections? the descriptions of the editing states aren't all that
   ... I'm used to working with a little more clarity with status
   levels on a document going through an editorial process. it should
   be more visible to members of other working groups and the public.

   BM: What is the process you are used to?

   MM: That there is a metric to measure stability or clear definition
   of what the process is

   CW: I share your concerns but we need something flexible

   MikeSmith: Having some kinda of mechanism for when the status
   changes, would be great
   ... maybe we can have something like an RSS feed or something

   CW: We need some way to define what a controversial section means

   <DanC_lap> aha... I was matching on match="h:ul[@class='toc']" and
   it's now an <ol>

   Hixie: The issues that have been marked controversial so far, have
   all been marked just today so I don't have anything other than what
   is in the minutes for today.

   <CWilso> we are now using the queue

   Karl Dubost: My impression of the process was that everything is a
   working draft until there are enough implementations to make a
   section stable

   Cynthia: I want to describe some of the process we had on WCAG.
   ... we would send out surveys to our members
   ... and we would discuss the survey feedback on telecons
   ... once consensus was reached we didn't reopen sections

   Julian: I am confused about the term "last call" on a section
   ... I'm not sure if it means I only have a certain time left to

   CW: It is not like "Last Call", in the capital L and C sense

   Hixie: Right now there are 2500 outstanding emails
   ... we are not reopening a section when the feedback has been
   ... but often feedback comes in afterward that necessitates
   reopening a section (for example, security issues)
   ... once something is implemented interoperably we don't have much
   room to change
   ... once you have implementations and people are using them we can't
   change them

   MM: There are places for the status of implementations for browsers.
   Shouldn't one of the status be "not applicable"?
   ... the technical part might be stable but the text part might need
   work still
   ... it seems to me it would be useful to distinguish between the
   editor's view and the working group's view
   ... we should leverage the semantic web resources at the w3c because
   it seems like this spec is a good example of an awesome semantic web

   <DanC_lap> (our system admin channel bot quips "sounds like a
   semantic web project" when asked to do something unfamiliar)

   <DanC_lap> [10:32] <DanC_lap> infobot, what about a better tracking

   <DanC_lap> [10:32] <infobot> danc_lap: sounds like a good semantic
   web project

   Cynthia: How do you know when something is done and how do you
   decide when to reopen?

   CW: We do have a process for that. The decision making process is
   that editor makes a recommendation in text and we use a number of
   mechanisms to review that.
   ... we try to have significant discussion about an issue to gauge
   consensus before we go to polling the working group.

   <DanC_lap> fixed my code...

   Hixie: I want to clarify a comment that Murray made between the
   difference on my opinion of a section and the working group's
   ... my opinion is based on whether or not there is outstanding

   MM: There doesn't seem to be an audit trail for feedback.

   CW: We do have that, there is the mailing list and issue tracking.

   <CWilso> issue tracking in particular is the answer to the "audit
   trail" question

   Hixie: The reason that implementations are already an issue is
   because the implementors are writing code quickly
   ... when there is one implementation we can talk to implementor and
   make changes but once there are two or three implementations it
   becomes much harder

   <DanC_lap> there...


   <DanC_lap> (which also serves as a copy of (some of the) annotation
   data on w3.org)

   <CWilso> s/wants/needs

   <Lachy> http://www.whatwg.org/issues/


   <pimpbot> Title: WHATWG Issues List (at www.whatwg.org)

   <pimpbot> Title: HTML WG -- 24 Oct 2008 (at www.w3.org)

   <anne> did he go out with chaals?

   <anne> ;)

   anyone else want to scribe? because uh, while this last session went
   on i've got some issue tracking work I need to catch up

   <gsnedders> +present Michael Smith

   <gsnedders> RRSAgent: draft minutes

   <pimpbot> Title: HTML WG -- 24 Oct 2008 (at www.w3.org)

   <gsnedders> someone needs to do that

   <gsnedders> I can't recall everyone's name offhand

   <gsnedders> bonjour, mes amis

   <gsnedders> hsivonen: ping

   <gsnedders> Are at 2.5?

   scribe volunteers?

   <MikeSmith> scribenick: cshelly

   <MikeSmith> scribe: CynthiaShelley

   <CWilso> scribe: CynthiaShelly

   <DanC_lap> i.e. URL sections

   <DanC_lap> would be great for somebody to pick up testing and report
   interop results for base uris

   content type is controversial, but what parts are stable?

   <CWilso> chair: ChrisWilson

   <smedero> hsivonen, I believe it is going to be in exec4, which is

   <smedero> (you have to go up a another flight of stairs from the

   hsivonen, we'll meet in the WG room, and then go up to exec 4

   <hsivonen> smedero, cshelly, thanks

   <DanC_lap> issue-28?

   <trackbot> ISSUE-28 -- Content type rules in HTML 5 overlaps with
   the HTTP specification? -- CLOSED

   <trackbot> http://www.w3.org/html/wg/tracker/issues/28


   <pimpbot> Title: ISSUE-28 - HTML Issue Tracking Tracker (at

   which types need to be sniffed? What are never encountered



   <pimpbot> Title: Content Sniffing Data (as of September 26, 2008)
   (at crypto.stanford.edu)



   <pimpbot> Title: [whatwg] Mime sniffing data (at lists.whatwg.org)

   <DanC_lap> GS: a problem with writing tests on this is that it
   doesn't define [missed]

   <DanC_lap> ... I sent mail...

   <Lachy> implementation of that content sniffing algorithm in
   javascript http://html5.lachy.id.au/content-sniffing/


   <pimpbot> Title: text/html Content Sniffing (at html5.lachy.id.au)

   <scribe> ACTION: Hixie to look for other editor for sniffing section
   [recorded in

   <trackbot> Sorry, couldn't find user - Hixie



   <pimpbot> Title: Step 10 of Feed/HTML sniffing (part of detailed
   review of "Determining the type of a new resource in a browsing
   context") from Geoffrey Sneddon on 2007-08-17 (public-html@w3.org
   from August 2007) (at lists.w3.org)

   <gsnedders> That's the email I sent

   <scribe> ACTION: hixie to look for other editor for sniffing section
   [recorded in

   <trackbot> Sorry, couldn't find user - hixie

   <CWilso> ACTION: Hixie to put content-type sniffing section on list
   of sections to find an editor for [recorded in

   <trackbot> Sorry, couldn't find user - Hixie

   <CWilso> ACTION: ChrisWilson: Hixie to put content-type sniffing
   section on list of sections to find an editor for [recorded in

   <trackbot> Created ACTION-81 - Hixie to put content-type sniffing
   section on list of sections to find an editor for [on Chris Wilson -
   due 2008-10-31].

   hixie: methods starting with xxx are temporary

   <Hixie> DanC_lap: section 3 (of 11)

   simplepie.inc#L11840 — out of date version of the content-type
   sniffing algorithm, but shipping


   <pimpbot> Title: SimplePie 1.x - /releases/1.1.1/simplepie.inc -
   SimplePie (at bugs.simplepie.org)

   <DanC_lap> (what happened with 2.8?)

   Mike: do we actually need section 3.1, intro to semantic structure?
   ... sections 3 and 4 are core definitions of markup language.

   <DanC_lap> (I'd like to see the security stuff written up in
   "extended abstract" form or something.)

   <DanC_lap> Hixie: a lot of this stuff [3.2.3 Resource metadata
   management] is DOM level 0. [ i.e. unstandardized ]

   <DanC_lap> Hixie: there's feedback pending on this... e.g. cookies

   Mike: web apps dependencies on HTML 5

   Marcos: none on resource metadata management

   Dan: work the interface name into the section title, might make it
   ... are global attributes interoperably implemented?

   Hixie: no

   <DanC_lap> Hixie: e.g. draggable has maybe 1 implementation

   Julian: data attributes are sometimes used for extensibility, but
   not designed to do that

   <DanC_lap> looking at 3.7 Dynamic markup insertion

   <pimpbot> planet: Ben on contributing to the W3C HTML WG


   Dan: why is innerHTML bad?

   Hixie: it's not typed. not checking

   <DanC_lap> (innerHTML sounds a little like eval. pointy instrument,
   but sometimes useful.)

   Timbl: perhaps put in the spec that you should only use innerHTML
   for balanced stuff and compile time check it?

   <DanC_lap> +timbl

   Hixie: agree in principal, may be hard in javascript

   <DanC_lap> (noodling on a QA/TAG/HTML blog item on innerHTML and
   document.write() ... )

   timbl: document.write is much worse, not adding to the DOM
   ... spec that whatever you put in there should correspond to a piece
   of DOM

   hixie: timbl means something that is well formed and wouldn't throw
   a parse error

   <pimpbot> Title: ISSUE-1 - XHTML2 Working Group Tracker (at

   Murray: preamble: 2 years ago I was here and the problem was social:
   tension between XML and HTML communities. GRDDL bridges the gap.
   ... in this meeting I see that there is a big social problem between
   HTML WG and the rest of the world

   here is an opportunity for Semantic Web community to help HTML WG.

   problem is visibility to what is happening, how to track, etc.

   other big problem is lack of resources for editing, providing
   technical assistance, etc.

   Semantic Web part of w3c all about how to relate data and such

   other social problem is that w3c has spent lots of resources on
   semantic web but there aren't real world uses that have been

   can't wrap my brain around why Tim is having problems with HTML, and
   why HTML 5 is having problems with XML

   quite a few members of HTML 5 WG have deep knowledge of XML and
   understand problems it has for the things people and browsers want
   to do with HTML

   quite a few XML people willing to accept that feedback

   technologies should work together

   want to put out there the idea of having the rest of w3c community
   help the HTML WG work in a way that helps the process and visibility
   work without interfering with how HTML WG does its job

   tim you have all these resources on Semantic Web, can we improve the
   status annotation on the HTML 5 draft? Hixie has defined some
   things, but could be expanded. Would be really useful in all w3c

   we're having process problems in this group, and in all groups.

   Marcos: its not the tools, its the people
   ... could be doing it on paper

   Murray: lots of resources applied to semantic web, seems that w3c
   applying semantic web resources to creating some tools...

   Timbl: in semantic web area, people are developing specs. don't have
   grad students looking for work.
   ... I can understand an argument for moving resources from Semantic
   Web to HTML.
   ... another adjustment you could talk about is to have a concerted
   tools effort instead of human cycles
   ... expanding this tool might be useful
   ... neither semantic web nor tools is magic. people still need to do
   the work.
   ... allowing people to extend this so people can mark what's
   implementation, what's authoring, allowing crowdsourcing

   Dan: I asked for these tools when the WG was set up

   chris wilson suggests hosting a table at lunch to discuss

   time to break

   <karl> reconvening at 12:45

   <pimpbot> Title: HTML WG -- 24 Oct 2008 (at www.w3.org)

   <karl> Meeting: HTML WG - 24 October 2008 - Technical Plenary

   <pimpbot> Title: HTML WG -- 24 Oct 2008 (at www.w3.org)

   <smedero> Chair: ChrisWilson

   <pimpbot> Title: HTML WG -- 24 Oct 2008 (at www.w3.org)

   <CWilso> MS: Summary of where we are with Authoring Guide.

   <gsnedders> Can we have a link in IRC?

   <smedero> http://dev.w3.org/html5/html-author/


   <pimpbot> Title: The Web Developer’s Guide to HTML 5 (at dev.w3.org)

   <CWilso> thanks smedero.

   <MikeSmith> scribenick: MikeSmith

   <gsnedders> The document doesn't comply with ISO 2145 — Numbering of
   divisions and subdivisions in written documents.

   Lachy is giving and overview of the Editor's Draft of an authoring
   guide that he has been working on.

   <Hixie> (subgroup is meeting in #role)

   <karl> I have a better CSS.

   Lachy: text/html examples are shown in gray, XML examples in yellow

   <Zakim> karl, you wanted to talk about resources constraints on this
   document and deadlines

   Lachy: recently been working on the attributes section
   ... purpose, syntax, quoted/unquoted, examples
   ... types of content (e.g., phrasing, etc.)
   ... elements section is still sketchy

   karl: I asked Lachy what the resource constraints would be
   ... I'm willing to spend time after the end of November on helping
   with this.

   Lachy: yeah, I've asked for people to help me with this, but so far
   nobody did

   karl: what about a deadline?

   Lachy: after I get CSS Selectors API to LC, then I have more time

   karl: I can't start working on it before the end of November
   ... could work full time on it for December

   Lachy: I want to get a lot of the common elements documented

   MikeSmith: maybe a first step would be for you guys to get together
   and talk about high-level organization of the spec

   <Zakim> gsnedders, you wanted to ask some questions about problems I
   see with it

   <smedero> (apparently)

   gsnedders: [pointing out concerns about the Introduction]
   ... the current draft seems to require too much background knowledge
   on the part of readers
   ... it needs to make clear what's expected of the person reading it

   Lachy: it does provide that information

   karl: so who do you think should read the document?

   gsnedders: I think it should be something you could learn HTML from,
   without having [too much] prior knowledge.

   karl: I think we should not focus too much on the Introduction.. I
   think we share the same goals, but we need to get to the meat first.

   Lachy: gsnedders, how about you take a shot at rewriting the

   gsnedders: yes

   CWilso: so it seems like we don't have anything blocking this.. just
   that it's clear more work needs to be done

   [lunch break]

   <pimpbot> planet: Ben Millard on contributing to the W3C HTML WG


   <pimpbot> Title: HTML WG -- 24 Oct 2008 (at www.w3.org)

   <smedero> In case anyone didn't catch it yet,


   <pimpbot> Title: notes from "implicit role" breakout session from
   Anne van Kesteren on 2008-10-24 (public-html@w3.org from October
   2008) (at lists.w3.org)

   [Going through sections of the HTML5 specification marking up
   stability of sections. Currently at section 4.]

   Jonas: section 4 does not define parsing right?

   Hixie: yes

   Jonas: (<title> section) does it say that it is live?

   Hixie: yes, different section though; should say that, if it
   doesn't, e-mail
   ... <base> section has issues

   Jonas: specification doesn't define what we do?

   Hixie: it says what IE7 changed to do
   ... I did a study on this; didn't matter much; vast majority of the
   pages were spam pages or autogenerated index pages

   Jonas: I'd love to remove the code

   [<link> section marked as "last call"]

   [<style> section]

   Henri_Sivonen: I thought scoped was controversial, dhyatt commented
   on it
   ... I think if dhyatt is not ok with it it counts as controversial

   David_Baron: there was discussion in the CSSWG whether it should be
   matched against the root of the whole tree or the subtree

   Lachlan: I think it should be the whole tree, like in Selectors API

   Jonas: perf implications?


   [some stuff about the CSSOM and its editor]

   Hixie: <eventsource> is probably "last call" because we get
   ... <script> probably not because <script async> is new

   Jonas: we're implementing <eventsource>, not sure what the status is

   Henri_Sivonen: are we considering header level implementation part
   of the <section> section?

   IH, MS: different section, so no

   AnneVK: headings and sections is not really desirable to implement
   because styling is not addressed

   David_Baron: CSS also needs changes for CSS counters and user agent
   style sheets will need changes for sizes

   Henri_Sivonen: has the CSS WG looked into that?

   David_Baron: no, but I have sort of a mental action item to look
   into that

   Lachlan: it would be nice if the CSS WG defined selectors for this
   so you can easily select all second level headings

   Hixie: for the <q> section we need to figure out quoting, so
   "working draft"

   Jonas: so is that a break from HTML4?

   Hixie: yes
   ... we're screwed either way

   David_Baron: Firefox does it but gets complaints from different
   locales because people do not agree on quotation rules

   CW: sigh, we did it the HTML4 way in IE8

   <gsnedders> q:lang(en)::before { content: '"'; } — anyone agree with
   that? :P

   <myakura> Lachy, ::before is css3, so probably not

   [missed bits]

   David_Baron: so maybe we should drop support for it before IE8 does

   <karl> gsnedders, you meant q:lang(en)::before { content: '“'; }

   Henri_Sivonen: one option would be to obsolete quote and require
   ugly quotation marks in the rendering section

   David_Baron: people don't agree what the quotation rules for English
   are at the third nested level

   <gsnedders> karl, I did deliberately do " :)

   David_Baron: the Bible has five levels deep and is widely
   translated, and different locales disagree on the quotation rules

   Henri_Sivonen: I would like to add that the Bible is a bad use case
   for tree based markup as it has overlapping ranges

   <gsnedders> karl, doesn't it make no difference for non-scribes?

   <hsivonen> gsnedders, a verse can span a paragraph break, IIRC

   <gsnedders> hsivonen, Yeah. Often does.

   for 5-nesting of quotes


   <pimpbot> Title: Re: Deep nesting of quotes from Simon Montagu on
   2006-05-16 (www-style@w3.org from May 2006) (at lists.w3.org)

   [text-level semantics]

   Hixie: outstanding feedback on all of them

   MS: what about footnotes

   Hixie: they are conventions that people should use for footnotes

   <gsnedders> Example of overlapping range:


   <pimpbot> Title: Mark 14:64 :: Bible Search (at www.ibs.org)

   <gsnedders> Lachy: The verse cannot be marked up as a single element
   because it continues beyond the paragraph break

   Hixie: the <legend> element is reused and it's not clear whether
   that is actually possible due to legacy

   <hsivonen> Lachy, consider both paras and verses as containers

   Jonas: was this fixed in Firefox 3?

   Hixie: I think it was one of the things it wasn't
   ... in Mozilla <legend> implies a <fieldset>
   ... other browsers just drop it on the ground
   ... nobody relies on this one way or another

   <Lachy> hsivonen, ok, it makes sense if I look at it in context, and
   see how the passage numbers are used

   Hixie: I would like not to add yet another way to mark up a heading

   Henri_Sivonen: I think the legacy parsing will scare away authors so
   I would prefer a new name

   Hixie: it will hamper transition, but delaying it another couple of
   years is fine with me given the cost it would add to the language

   [<img> section]

   Hixie: the red box regarding longdesc is a lie, I have considered
   that feedback

   David_Baron: what about image maps?

   Hixie: separate section


   Henri_Sivonen: does it work for e.g. chrome to have a separate
   process for the nested browsing context

   Hixie: that has been taken into consideration

   [object and embed]

   [how classid maps to a plugin per platform etc.]



   <pimpbot> Title: Bluish Coder: HTML 5 Video Element Examples (at

   <hsivonen> http://hsivonen.iki.fi/test/moz/video-selection/


   <pimpbot> Title: Index of /test/moz/video-selection (at

   [going through the media element section]

   Jonas: smaug was saying loadend was not relevant

   Hixie: we have load, error and abort, so loadend does make sense

   CW: what "Implemented and widely deployed" mean beyond "last call"

   Hixie: yeah

   [discussion whether there should be annotations for sections that
   could be moved out of the spec]

   Hixie: it's typically not a concrete section, but rather several
   sections that have to be taken out together

   Henri_Sivonen: for the <map> element, should we annotate it with
   browser support regarding HTML and XML

   MS: we can't do that level of detail

   <Lachy> scribenick: Lachy

   <scribe> scribe: Lachlan Hunt

   MS: We could probably skip the forms section today
   ... also Tables

   Hixie: Forms has a lot of feedback pending.
   ... Most feedback on tables is about headers

   [added a few annotations to the forms and table sections]

   Hixie: I'm hoping we'll get at least one implemented working on the
   datagrid section and provide feedback.
   ... No-one has said it's bad

   MS: Is the name of the <bb> element stable?

   Hixie: No

   <anne> heh, the interface name is actually BrowserButton

   Hixie: It was added in response to Apple's feedback, wanting to
   provide an in page way of triggering application functionality

   Jonas: Why not use a JS API?

   Hixie: It's to prevent annoying abuses that are possible with JS

   CW: I'm not sure this is better than an API though

   Henri_Sivonen: How much of the rendering section will be different
   from the CSS appendix?

   Hixie: Rendering is a misnomer. It contains more than just basic
   ... There's 2 big issues: The obsolete APIs and elements, and how to
   map that to CSS

   Henri_Sivonen: My spec scraper works better when each element is
   defined in only one place

   Hixie: [points out other problems that still don't solve Henri's

   <Hixie> dbaron, wfm in ff trunk

   <smedero> Philip, did you ever file this bug properly with the IE
   folks? http://krijnhoetmer.nl/irc-logs/whatwg/20081008#l-563


   <pimpbot> Title: IRC logs: freenode / #whatwg / 20081008 (at

   <Philip> smedero, no - I started trying to write some proper tests
   for all the localStorage stuff rather than reporting bugs randomly,
   but then I kind of got bored/lazy/distracted/busy and didn't get

   <Philip> (Firefox had strange bugs with funny characters in
   globalStorage too)

   <smedero> ahh, ok. I can help out a bit if you want to (and it makes
   sense to) split up that work.

   <CWilso> ACTION: ChrisWilson to come up with a 16x16 image icon for
   IE for implementation chart [recorded in

   <trackbot> Created ACTION-83 - Come up with a 16x16 image icon for
   IE for implementation chart [on Chris Wilson - due 2008-10-31].

   <Philip> smedero, I started doing something based on my canvas test
   framework with all the canvas-specific bits ripped out, with the
   intention of adding storage-specific bits (like the ability to run
   each test on a separate domain to get independent storage areas), so
   I probably should try to finish that stuff, and then the actual
   tests should be fairly straightforward to write :-)

   <pimpbot> Title: HTML WG -- 24 Oct 2008 (at www.w3.org)

   <MikeSmith> [afternoon break until 4pm CET]

   <Philip> CWilso, you could print out some SVG people from


   <pimpbot> Title: Image:Human.svg - Wikimedia Commons (at



   <pimpbot> Title: Re: SVG in HTML proposal from Henri Sivonen on
   2008-07-21 (public-html@w3.org from July 2008) (at lists.w3.org)

SVG in text/html

   <MikeSmith> scribenick: MikeSmith

   CWilso: so... SVG in text/html

   <Hixie> -_-



   <pimpbot> Title: SVG and HTML (at dev.w3.org)



   <pimpbot> Title: Feedback on SVGWG's SVG-in-text/html proposal from
   Ian Hickson on 2008-08-28 (www-svg@w3.org from August 2008) (at

   shepazu: we did incorporate some feedback we got on our proposal
   ... nothing is set in stone, we can make further refinements to the

   ChrisL: I assume it's a goal that developers should not have to
   rewrite scripts and such

   Robin_Berjon: yeah, issue is just about the syntax

   Shepazu: all comes down to the syntax
   ... we have disagreements about the syntax, but is there anything



   <pimpbot> Title: Re: SVG in HTML proposal from Henri Sivonen on
   2008-07-21 (public-html@w3.org from July 2008) (at lists.w3.org)

   hsivonen: in July, I sent a message about the proposal but did not
   get a reply...

   shepazu: we made some changes because of comments you, hsivonen,

   hsivonen: I was objecting to the whole premise of how the
   integration would be done [in your proposal]
   ... about which tokenizer is used
   ... I've implemented the proposal that was commented out
   ... I estimated what work it would take to implement it in Gecko and
   in Java SE
   ... and my assessment is that it's much easier in both cases to
   implement the commented-out proposal [from Hixie]
   ... I sent comments about why the SVG WG is not implementable
   ... I fundamentally disagree with having an XML parser inside the
   HTML parser

   ChrisL: I disagree. You've not shown that it's massively

   hsivonen: I don't think I need to implement it [in order to prove

   Hixie: a question that came out is a question of goals

   <Hixie> Is it a goal that anything that is functional in text/html
   be functional when copied and pasted into image/svg+xml

   shepazu: Hixie, do you mean anything?

   Hixie: anything *SVG*

   ChrisL: to the extent possible
   ... hsivonen makes a good point... e.g., Illustrator puts entities

   <Zakim> chaals, you wanted to talk about implementation and propose
   an answer to hixie

   ChrisL: so losing that would be fine

   chaals: we have not thoroughly implemented either system ...

   <ChrisL> but i want most SVG to be usable. Some bits with entities
   may need modification, thats fine

   chaals: but in our assessment, in practical terms, the two proposals
   will work [equally well] -- after looking at the costs .. based on a
   "desk check"
   ... I think it is a goal that where it is feasible, you should be
   able to take SVG content out of text/html content, and stick it
   into, e.g., and editor
   ... we don't want to break the use case of cut-and-paste in that

   ed: to me it's not a goal to allow something to be very different
   from the syntax we have now
   ... important to stay as close as possible to what is out there

   hsivonen: I agree about the importance of the copy-and-paste from
   browser into editor
   ... but following the line of thought, it leads to breaking the
   fundamental permissive nature of text/html (the "host" format)
   ... you can get around this without making fundamental changes to
   HTML parsing ...
   ... some browsers allows you to [output a well-formed serialized
   output of the DOM]

   shepazu: we can't count on that functionality being available
   always, and don't want to spec it as a requirement
   ... problem case is of some of this funky [not-well-formed] SVG
   getting propagated

   <karl> There is a *virtuous* circle to keep good markup or even
   improve it in an ecosystem.

   shepazu: somebody thinks it should work, but it won't
   ... so your scenario [serialized DOM output] does not solve the

   Hixie: so we need to look as [what the problem is that we want to
   ... if we think that it's a goal that anything that is functional in
   HTML should always be functional when pasted into XML, then the
   SVGWG does not satisfy that requirement

   shepazu: I think you do not require attribute quoting?

   Hixie: correct
   ... another example is omitting the SVG end tag

   sicking: I think we [may have] incompatible goals

   ChrisL: being able to draw something in a drawing tool and paste it
   into an HTML document, yeah, of course that should work

   sicking: other goals are that the way that HTML authoring is done
   should also be OK for SVG
   ... but that is an incompatible goal ... string concatenation...
   people generating invalid markup ... writing HTML docs in Notepad,

   ChrisL: people do already generate SVG in those ways [using PHP,

   sicking: we need goals
   ... if we talk about requirements first, then we can work together
   toward a solution

   <Zakim> Robin_Berjon, you wanted to reflect on tools

   Robin_Berjon: about the goals thing ...
   ... everyone agrees that we want to have SVG in HTML
   ... the editor vendors will make it happen ...
   ... it will be cheap to add an HTML5 parser to an editing
   ... currently, SVG is being produced by [people who are more
   ... but once SVG gets very widely used, [the "funky" instances of
   it] will increase, and we will have to deal with them

   hsivonen: I think our goal should be that browsers will have the UI
   [for outputting a serialized DOM]
   ... browsers already have a different parser for text/html and XML,

   <anne> hsivonen, I think the point from Chris Lilley is that nobody
   has implemented the proposal from the SVG WG yet so in theory it is
   unclear which one is simpler; though you did point out you thought
   it was sort of "doomed" the way it is currently written

   hsivonen: suggesting that they wouldn't do so seems weird because
   they are already doing it

   Hixie: I think it is possible to avoid allowing "tag soup" parsing
   support for SVG ...
   ... but we don't have agreement about that being a reasonable goal

   <Zakim> chaals, you wanted to suggest that we drop the hand-raising
   protocol and force people to simply remember their rebuttals and
   wait their turn and to suggest that we drop the

   <Lachy> Just in regards to the UI suggestion from Henri, I just want
   to point out that there are several alternatives besides providing a
   way to get the DOM source, such as simply using "Save Image As..."
   to export a well-formed, re-serialised copy of the image to an SVG

   chaals: our experience is that by-and-large, the quality of SVG has
   improved over time ...
   ... due to it being a goal that we enforce quality requirements
   ... majority case is drawing tools, yeah ...
   ... but they are also generating using PHP, whatever ...
   ... and they do go back and fix their code [if it turns out it's not
   producing well-formed SVG]
   ... we do see it as a goal to keep SVG parsing strict ...
   ... tools for SVG have remained high-quality ...
   ... we don't see it as a goal to make the [SVG content] crappier
   than it already is ...
   ... an area where that's important is mobile
   ... whilst that world is also changing ...
   ... proper browsers being deployed ...
   ... but to blow that off -- to allow [become more tolerant of]
   crappy SVG code

   <Zakim> CWilso, you wanted to suggest that we walk through the goals
   and straw-poll each

   chaals: [we don't want to do that]

   CWilso: so can we look at the set of goals?

   [we have only 10 minutes left]

   <Hixie> goals:


   <pimpbot> Title: Feedback on SVGWG's SVG-in-text/html proposal from
   Ian Hickson on 2008-08-28 (www-svg@w3.org from August 2008) (at

   sicking: concerned about having a requirement about strict parsing

   <Hixie> Robin_Berjon: eh, i start all mine by saying "i, er, i
   think, there is, hm, if we, hm, ..." ;-)

   <shepazu> me that's because I usually go on for half an hour :)

   sicking: is [the problem of unstable equilibrium which we have
   learned] that there is a risk it will just not happen that way in
   the long run

   ChrisL: is it a goal to stop people from putting in well-formed

   <CWilso> * It should be possible to drop an SVG file from a graphic
   editor into an

   <CWilso> HTML5 document sent as text/html and usually have it
   validate and work.

   <CWilso> * The DOM aspect of this should be very similar to using
   SVG in XHTML, so

   <CWilso> that there is no work required beyond parser changes for

   [agreement within rough consensus?]

   <ChrisL> (whether it validates or not is irrelevant to me, but it
   should render as expected)

   <CWilso> * The DOM aspect of this should be very similar to using
   SVG in XHTML, so

   <ChrisL> I'm glad that penalising WF is not a goal

   <CWilso> that there is no work required beyond parser changes for

   [agreement from all]

   <CWilso> * Changes to the parser should be relatively small and
   localised. For

   <CWilso> example, it should not double the number of states in the
   tokeniser, or add

   <CWilso> half a dozen tree construction insertion modes.

   <CWilso> * The parsing model should be very light-weight. It
   shouldn't require,

   <CWilso> for example, extra buffering, or parsing text twice.

   shepazu: I don't strongly oppose this goal.

   chaals: the underlying goal is that the processing is reasonably
   ... the stated goal has more implementation detail in it than needed

   [no broad consensus on this goal]

   <CWilso> * The markup should be as easy to edit by hand as regular
   HTML, modulo

   <CWilso> complications due to the vocabulary itself.

   ChrisL: it over-constrains implementations

   CWilso: "as small as an elephant"

   <hsivonen> I agree with the goal

   [broad consensus]

   <CWilso> * The syntax shouldn't introduce two different syntaxes for

   <CWilso> elements in text/html. For example, it should be possible
   to take a big

   <CWilso> blob of existing HTML, and wrap it in a <foreignObject> and
   have it

   <CWilso> just work, without having to fix up missing end tags or

   <CWilso> declarations or whatever.


   <CWilso> * If possible, the same mechanism should work for both
   MathML and SVG,

   <CWilso> and it should make it relatively easy to introduce other

   <CWilso> in future, at least for vocabularies designed with this
   mechanism in

   <CWilso> mind.

   ChrisL: problematic

   <CWilso> * Markup seen on real pages today, and errors of a similar

   <CWilso> shouldn't result in dramatically different renderings in
   browsers that

   <CWilso> support this feature.

   Hixie: this is the "don't break legacy pages" requirement

   ed: the question is "At what cost?"

   <ChrisL> depends on which broken pages you want to preserve.

   shepazu: some of your pages that you [Hixie] gave as examples are
   [totally broken]

   [discussion about whether it's feasible to do educate/evangelize to
   get people to fix their broken content

   Hixie: this a the single most important requirement from the POV of
   the Chrome team

   ChrisL: SVG pages which currently work -- which produce some useful
   output -- should continue working

   <Hixie> http://puysl.com/view.htm


   <pimpbot> Title: New Page 1 (at puysl.com)

   <Hixie> ^ that one

   hsivonen: [describes a cargo-cult copy-and-paste scenario

   <CWilso> We must not require users to declare namespace prefixes

   sicking: I want to find out how common [the case is that we
   currently are discussing]

   ChrisL: I would like this clarified.

   CWilso: so you can have an svg element and all its children without
   the namespace

   <CWilso> * If possible, we shouldn't expose users to namespace
   syntax at all,

   <CWilso> though the DOM still needs to expose the namespaces.

   CWilso: that should be allowed ...

   ChrisL: but it should not disallow the namespaces

   hsivonen: one issue is, should it render as SVG if you have a
   namespace, but it's the wrong namespace?

   <CWilso> Hixie: we should definitely allow the xmlns case.

   sicking: seems like the third issue [wrong namespace] is the only
   one we don't have agreement on
   ... do we want it to be possible to use an off-the-shelf XML parser?
   ... are we OK to restricting ourselves to non-off-the-shelf XML

   hsivonen: the problem is, that presupposes part of the solution?

   sicking: if I as an implementor am not OK with writing my own XML
   parser, than that excludes [some implementors]

   Hixie: writing your own XML parser is not a small and localized

   CWilso: I think we are narrowing down to get an idea of where the
   disagreements about goals are.

   <shepazu> * It is not a goal that any valid SVG file must be
   embeddable in

   <shepazu> text/html. (Only the syntax that is actually widely used
   need be

   <shepazu> supported.)

   shepazu: this is not talking about whitelisting?

   Hixie: this is about SVG that uses namespace prefixes or that use an
   DTD internal subset

   ChrisL: only place I see people using prefixes in SVG is in compound

   shepazu: OK, I don't think this is controversial

   [strong consensus that this is a non-goal]

   <shepazu> * It is not a goal that anything that is valid text/html
   be valid

   <shepazu> image/svg+xml. In particular, whether to use
   case-sensitive or case-

   <shepazu> insensitive tag and attribute names at the syntax level
   should be

   <shepazu> driven from implementation performance choices, not

   shepazu: case sensitivity...
   ... related to error-correction

   ChrisL: if you're allowed to doing the stuff that the SVG spec says,
   or corrects it to conform to the SVG spec, then fine

   <Zakim> hsivonen, you wanted to talk about mobile

   hsivonen: the performance issue here is very important

   anne: we've had no implementations of the SVGWG proposal, [so we
   don't have any data]

   <karl> the debate on performance should be really put aside before
   having real data on the table for the two options

   shepazu: how about if the spec says it's strongly recommended or
   "SHOULD" that authors should try to [follow XML well-formedness

   sicking: requiring the SVG parts to be totally XML-compliant is
   fine... but authors are going to do whatever ends up working in

   [discussion about the fact that quotes are in fact needed even in
   some cases in text/html]

   ChrisL: "quotes are not required except when they are"

   hsivonen: I'm not fine with requiring that a parser used for a
   validator be different from the parser used by browsers.

   Murray: are there levels of conformance?

   karl: people will always choose the more liberal choice

   CWilso: they will choose random levels

   sicking: majority of people test it in a browser, if it works, OK

   <pimpbot> Title: HTML WG -- 24 Oct 2008 (at www.w3.org)

   <sicking> last post!

   <gsnedders> last + 1 post!

   <anne> o_O

   [adjourned in the company of members of the SVG WG]

Summary of Action Items

   [NEW] ACTION: ChrisWilson - send email to spark issue-60 [recorded
   in http://www.w3.org/2008/10/24-html-wg-minutes.html#action02]
   [NEW] ACTION: ChrisWilson to come up with a 16x16 image icon for IE
   for implementation chart [recorded in
   [NEW] ACTION: ChrisWilson to suggestion text for 1.4.4 [recorded in
   [NEW] ACTION: ChrisWilson: Hixie to put content-type sniffing
   section on list of sections to find an editor for [recorded in
   [NEW] ACTION: Hixie to look for other editor for sniffing section
   [recorded in
   [NEW] ACTION: hixie to look for other editor for sniffing section
   [recorded in
   [NEW] ACTION: Hixie to put content-type sniffing section on list of
   sections to find an editor for [recorded in

Michael(tm) Smith
Received on Friday, 7 November 2008 05:41:03 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:39 UTC