HTML WG face-to-face meeting — 24 October 2008

See also: IRC log

Progress review/evaluation of stability of sections of HTML5 (round 1)

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 http://dev.w3.org/cvsweb/html5/spec/

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? http://lists.w3.org/Archives/Public/public-html/2008Jun/0264.html

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

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 changed

<Hixie> http://lists.w3.org/Archives/Public/public-xhtml2/2008Jul/0037.html 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 http://lists.w3.org/Archives/Public/public-html/2008Jul/0417.html

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

<Lachy> The other messages from the XHTML2 WG:

<Lachy> http://lists.w3.org/Archives/Public/public-html/2008Jun/0251.html

<Lachy> http://lists.w3.org/Archives/Public/public-html/2008Jun/0253.html

<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 lists.w3.org)

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

<pimpbot> Title: XHTML2 WG Virtual FtF Day 3 -- 19 Jun 2008 (at www.w3.org)

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 http://lists.w3.org/Archives/Public/public-html/2008Jul/0417.html

<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 lists.w3.org)

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

<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 http://lists.w3.org/Archives/Public/public-html/2007Oct/0385.html -- 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 www.w3.org)

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)

<Lachy> http://html5.lachy.id.au/output?data=%3Chtml+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2Fns%2Fnot-xhtml%22%3E%0D%0A%3Ctitle%3ETest%3C%2Ftitle%3E%0D%0A%3Cp%3Etest%3C%2Fp%3E%0D%0A%3C%2Fhtml%3E&type=application%2Fxhtml%2Bxml

<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 misleading/wrong

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

<CWilso> ACTION: ChrisWilson - send email to spark issue-60 [recorded in http://www.w3.org/2008/10/24-html-wg-minutes.html#action02]

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

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

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

<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

<DanC_lap> http://lists.w3.org/Archives/Public/public-html/2007Aug/1187.html

<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 http://lists.w3.org/Archives/Public/public-html/2007Aug/1187.html

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

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

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 www.w3.org)

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

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 respond

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

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

<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 opinion.
... my opinion is based on whether or not there is outstanding feedback

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... http://dev.w3.org/cvsweb/~checkout~/html5/spec/toc-status.html?rev=1.3

<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 "upstairs"

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

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

<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 www.w3.org)

which types need to be sniffed? What are never encountered

<gsnedders> http://crypto.stanford.edu/~abarth/research/html5/content-sniffing/

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

<gsnedders> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016562.html

<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 http://www.w3.org/2008/10/24-html-wg-minutes.html#action03]

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

<gsnedders> http://lists.w3.org/Archives/Public/public-html/2007Aug/0671.html

<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 http://www.w3.org/2008/10/24-html-wg-minutes.html#action04]

<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 http://www.w3.org/2008/10/24-html-wg-minutes.html#action05]

<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 http://www.w3.org/2008/10/24-html-wg-minutes.html#action06]

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

<gsnedders> http://bugs.simplepie.org/repositories/entry/sp1/releases/1.1.1/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 clearer
... 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 <11http://standardssuck.org/benmillard>

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 www.w3.org)

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 implemented

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 specs

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)

ARIA implicit roles

Ian Hickson Ben Millard, Anne van Kesteren, Cynthia Shelly, Michael Cooper, Henri Sivonen, and Marcos Caceres met for a separate “breakout session” to discuss ARIA implicit roles. See the separate minutes for that discussion.

Status report on authoring guide to HTML5

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

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 <11http://standardssuck.org/benmillard>

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

<smedero> In case anyone didn't catch it yet, http://lists.w3.org/Archives/Public/public-html/2008Oct/0089.html

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

Progress review/evaluation of stability of sections of HTML5 (round 2)

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

<dbaron> http://lists.w3.org/Archives/Public/www-style/2006May/0133.html 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: <http://www.ibs.org/bible/verse/index.php?q=Mark+14:64>

<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 www.bluishcoder.co.nz)

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

<pimpbot> Title: Index of /test/moz/video-selection (at hsivonen.iki.fi)

[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 styles
... 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 issues]

<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 krijnhoetmer.nl)

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

<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 http://www.w3.org/2008/10/24-html-wg-minutes.html#action07]

<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 http://commons.wikimedia.org/wiki/Image:Human.svg

<pimpbot> Title: Image:Human.svg - Wikimedia Commons (at commons.wikimedia.org)

<hsivonen> http://lists.w3.org/Archives/Public/public-html/2008Jul/0250.html

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

<shepazu> http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html

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

<shepazu> http://lists.w3.org/Archives/Public/www-svg/2008Aug/0069.html

<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 lists.w3.org)

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

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

<hsivonen> http://lists.w3.org/Archives/Public/public-html/2008Jul/0250.html

<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, made

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

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

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 in

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

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 already

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 problem

Hixie: so we need to look as [what the problem is that we want to solve]
... 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, et.c

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

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 application
... currently, SVG is being produced by [people who are more XML-aware]
... 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, so...

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

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: http://lists.w3.org/Archives/Public/www-svg/2008Aug/0069.html

<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 lists.w3.org)

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

<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 text/html.

[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 text/html.

[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 efficient
... 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 HTML

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

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

<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 vein,

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

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

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 change

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 documents

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

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 constraints]

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

[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 http://www.w3.org/2008/10/24-html-wg-minutes.html#action07]
[NEW] ACTION: ChrisWilson to suggestion text for 1.4.4 [recorded in http://www.w3.org/2008/10/24-html-wg-minutes.html#action01]
[NEW] ACTION: ChrisWilson: Hixie to put content-type sniffing section on list of sections to find an editor for [recorded in http://www.w3.org/2008/10/24-html-wg-minutes.html#action06]
[NEW] ACTION: Hixie to look for other editor for sniffing section [recorded in http://www.w3.org/2008/10/24-html-wg-minutes.html#action03]
[NEW] ACTION: hixie to look for other editor for sniffing section [recorded in http://www.w3.org/2008/10/24-html-wg-minutes.html#action04]
[NEW] ACTION: Hixie to put content-type sniffing section on list of sections to find an editor for [recorded in http://www.w3.org/2008/10/24-html-wg-minutes.html#action05]