HTML Issue Tracking Teleconference -- 10 Jul 2008

<Lachy> what's on the agenda today?

lachy, if things hold to form, http://www.w3.org/html/wg/tracker/agenda

mikeTMsmith's announcement: http://lists.w3.org/Archives/Public/public-html-wg-announce/2008JulSep/0000.html

<Lachy> if you're talking about web forms stuff, that might be interesting and I can call in.

MikeSmith, are you around - can you answer lachy's query about web forms stuff

Web Forms Features Survey (still open for a few hours) - http://www.w3.org/2002/09/wbs/40318/wfreq/

http://www.w3.org/2002/09/wbs/40318/wfreq/results

35 votes so far

<MikeSmith> trackbot, start meeting

<trackbot> Date: 10 July 2008

mike, do you need a scribe?

<Joshue> Can't make call will be on IRC for a short while, apologies

<Joshue> Hi all BTW

<MikeSmith> Joshue: you going to be available on IRC at least?

<Joshue> Yup

<MikeSmith> OK

<MikeSmith> Joshue, is there somebody else who can talk about action 54 on the call?

<Joshue> give me a second I will try again..

<Joshue> I am in Austria at the moment

<MikeSmith> Scribenick: oedipus

<MikeSmith> Scribe: Gregory

chair? MikeSmith?

zakim ??P2 is Josh_O_Connor

zakim +??P2 is Josh_O_Connor

convene meeting, review agenda

missing-alt ISSUE-31 action-54

<DanC> let's not use opaque numbers for topics, please

JC: status is still in review; Steven Faulkner withdrew from group

<Joshue> We are awaiting response from PF

MC: josh can replace SF on Issue Tracker; will assume responsibility for StevenF's issues

TABLE issues & actions update

<DanC> (new headers issue? different from ISSUE-20 table-headers ? hmm.)

JC: thanks for tracker privileges - @headers issue (issue 66?) done work on wiki - also made formal request of PF on @headers issue
... @summary also under investigation and being documented on wiki

MS: sounds fine

<Joshue> @summary wiki is updated (Action Item 66)

MS: wait for responses until next week on SteveF and Josh's stuff

<Joshue> I will add @headers issue to tracker shortly (Buzilla 5822)

<Joshue> Bye y'all

<Lachy> ok, that's weird

<DanC> Joshue, pls review -- darn

http://esw.w3.org/topic/HTML/TableAccessibility

josh - other URIs from ESW?

Agenda Shaping

<MikeSmith> http://www.w3.org/html/wg/tracker/agenda

MS: any additional agenda items other than what is on tracker?

<smedero> DanC - there's no new @headers issue. ISSUE-20 remains the only collection point on @headers I can see?

JR: TAG going to discuss content type sniffing - maybe need to discuss here

MS: DanC - comments?
... URI for TAG announcement

JR: on TAG meeting agenda for today

<Julian> http://www.w3.org/2001/tag/2008/07/10-agenda

<smedero> ISSUE-20 seems sufficiently broad to cover the discussion going in bug 5822.

MS: specifically about Microsoft's authoritative=true proposal?

DC: what prompted it
... I requested TAG discussion based on the authoritative=true discussion, but it's hard to predict what the TAG will discuss once we get started

MS: pre-discussion for DC to take to TAG?

DC: most discussion in email

MS: email record reflects HTML5 side

DC: reflects where bunch of individuals - summary for WG position would be best

GJR: collect issues on wiki page to summarize issues

MS: only problem is getting someone with cycles

DC: the most interesting thing i got out of the thread was options and patches to browse without content sniffing

MS: Adam Barth (?) compiled version of FF with content-type sniffing off - tried digg.com and united.com

<DanC> I solicited data in a blog item http://www.w3.org/QA/2008/07/life_without_mime_type_sniffin.html

MS: good to have more data like that - content-sniffing/identification off experiences

<robburns> +robburns

JR: ChrisW needs to give more info about MS plans

<smedero> Did anyone recommend a method to disable content-sniffing in WebKit?

CW: read blog post - not sure what more to say

JR: content-type sniffing end altogether, or just specific sniffing case - if serve image as GIF would content="foo"

MS: believe would turn off all content sniffing - including for images
... Laura, agenda addenda?

<Lachy> image/gif;authoritive=true for a JPEG is unlikely to break because most browsers just pass off the image to the image processor, which then determines its type from the magic numbers

MS: Laura, summary of contact with PF

LC: waiting on PF for review of ALT (action 54) - still in progress
... @headers PF will be discussing

<Lachy> but the real question is whether a <script src="..."> served as text/plain;authoritive=true obeys the content type

MS: looking back at email - has been discussion in PF about 5822 whihch is about headers

<Laura> headers bug 5822

<Laura> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5822

<Laura> PF will be involved

MS: issue of how to access content of "title" popups - waiting for feedback from PFWG on accessibile title exposure (multi-modal, not just expressed as tooltip)
... change due date to next week for action 54
... continue to wait for PFWG on this

GJR: suggests that someone talk with AlG - may be WAI CG issues holding things up

<Laura> We are still waiting for a reply from the PFWG for Action Item 54 regarding several issues:

<Laura> http://tinyurl.com/48uyqv

<Laura> http://tinyurl.com/3v68tn

<Laura> Action 54 is dependent on PF's response. PF is beginning a process to provide guidance.

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

Action Item Review

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

<Laura> No timeline was given in Al's email. Request for an Action Item 54 time extension until there is a response from the PFWG.

<MikeSmith> action-56?

<trackbot> ACTION-56 -- Chris Wilson to chris Wilson to work with MikeSmith and DanC on (re)plan of action for forms coordination with Forms WG -- due 2008-06-26 -- PENDINGREVIEW

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

MS: should not keep ACTION 56 open

<DanC> (GJR didn't actually voice his "suggests that...")

GJR notes survey on forms ends today

DC: throw out overdue today, and tell others they hjave a week

<DanC> (56? hmm...)

MS: Action 56 and related survey will be closed today; should be on agenda for next week

<DanC> action-69?

<trackbot> ACTION-69 -- Dan Connolly to produce poll on integrating sections of Webforms 2.0 -- due 2008-07-03 -- PENDINGREVIEW

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

<DanC> close action-69

<trackbot> ACTION-69 Produce poll on integrating sections of Webforms 2.0 closed

AGTION 67

DC: at a loss - chris was supposed to address at PF face2face

MS: followup?

CW: headers/id?
... didn't talk about it

LC: ties in with bug 5822

<Laura> headers bug 5822

<DanC> (full URI for 5822?)

<Laura> The specification states that each token in the headers attribute should have the value of an id of a th element. It says:

<Laura> "The headers attribute, if specified, must contain a string consisting

<Laura> of an unordered set of unique space-separated tokens, each of which

<Laura> must have the value of an ID of a th element..."

<Laura> http://www.w3.org/html/wg/html5/#headers

<Julian> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5822

CS: some discussion of table headers, but dont' remember details

<Laura> This is currently implemented in such a way that complex tables cannot be created using the headers attribute. It essentially makes the headers attribute that has been included on tds pointless. The headers attribute needs to be able to reference the id of a td.

<Laura> As hierarchical headers are not allowed in HTML5, this means that

<Laura> conceptual headers (cells that contain data and have their own header,

<Laura> but act as a header for other cells in the table) must be marked up as

<Laura> a td. As these cells are conceptually headings, the headers attribute

<Laura> should be able to reference the id attribute of these cells.

<Laura> In June 2007 in response to my inquiry, PF said, "There is a disability constituency that currently uses and depends on this feature: anyone offering to remove it should be expected to demonstrate that the replacement works better and is in service..."

MS: eliminate multiple actions for same thing - josh following up on this; without objection will close this action

<Laura> http://lists.w3.org/Archives/Public/public-html/2007Jun/0145.html

<Laura> Examples like the following one needs to be conforming in HTML 5:

<Laura> http://juicystudio.com/wcag/tables/complexdatatable.html

<DanC> (yeah... would like to see: ACTION: Josh to follow up on bug 5822 re table headers )

<Laura> A case-in-point is detailed in Bug 5822.

<Laura> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5822

<Laura> The way headers are specied only allows the simplest of data tables to be defined accessibly, which defeats the purpose of getting the headers attribute into the specification at all, because it can't do anything that most ATs don't already do by default.

GJR: PF discussion more of process and liaisoning and collaboration than details

<Laura> Currently, the implementation is such that complex tables cannot be created using the headers attribute. The language in the current spec is attempting to pacify PFWG.

MS: more to do on this? think should reassign to josh
... add note "consider reassigning to josh"

<Laura> The spec complies with PFs advice by paying lip service to headers while dissenting in functional requirements. It is an attempt to circumvent the issue not solve it.

<Laura> he headers attribute in the current specification is of little use, as it can only reference a th, and the th cannot be a hierarchical th. Without being able to associate header cells to data cells, screen reader users will either have great difficulty, or find it impossible, to orientate themselves in complex data tables.

Action Item 68

urls-webarch

<DanC> Taylor http://lists.w3.org/Archives/Public/public-html/2008Jun/0353.html

DC: haven't finished expected results for all cases, but most useful thing was philip taylor's suggestion that for test cases, best thing to do is walk through the text and id test cases
... philip and i walked the text multiple times
... layering on top of UI standard - was going to write python code to match HTML5 and compare results with previous spec, but is pretty difficult
... my investigation concurs with IanH's findings - don't know what else can / should be done

<DanC> From: Ian Hickson <ian@hixie.ch>

<DanC> To: Roy T. Fielding <fielding@gbiv.com>

<DanC> Cc: public-html@w3.org

<DanC> Subject: Re: heads-up about "new" URLs section in HTML5 editor's draft

<DanC> Date: Mon, 30 Jun 2008 05:25:42 +0000 (UTC) (00:25 CDT

<DanC> "How is that different from what the spec does now?"

DC: technical substance of it: 2 questions

<robburns> The spec actually says it uses a different definition of URL than the related RFCs. If that's not he case, then that note should be removed.

DC: what about non-ASCII chars? 2 cases: query part of URL from form - may be insurmmountable legacy that necessitates code in document
... another case: what to do with ASCII chars in accomodating non-ASCII chars? FF has runtime switch to serve all as UTF-8
... still digging through details

MS: status of action? PendingReview or later date?

DC: just reviewed so just keep open for now

MS: nothing to add - DC can change as appropriate

<DanC> action-68?

<trackbot> ACTION-68 -- Dan Connolly to work with Hixie to confirm what expected results are for http://hixie.ch/tests/adhoc/uri/encoding/ tests -- due 2008-07-17 -- OPEN

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

MS: comment from hixie htat test cases not written to obtain results, but only to study browser behavior
... need to evaluate results
... need to state what expected results will be

DC: hixie responded positively to my suggestion

JR: UTF-8 is everywhere - not change between FF2 and FF3 - in hixie's tests find interoperability for that everywhere; coding for non-ASCII characters otherwise varied - not part of URI where UTF-8 is currently used;

<robburns> "The term "URL" in this specification is used in a manner distinct from the precise technical meaning it is given in RFC 3986. Readers familiar with that RFC will find it easier to read this specification if they pretend the term "URL" as used herein is really called something else altogether."

<robburns> http://www.whatwg.org/specs/web-apps/current-work/#terminology0

JR: current text in HTML5 and email about it, given URI and IRI defs need to be fixed; IETF wants to know what is broken and what needs to be fixed?

<DanC> (hmm... maybe I'll use a wiki to aggregate these test results for a while...)

JR: need to define error

<Lachy> All specs need to define error handling. Without error handling, specs are unimplementable and result in interop issues

<Lachy> the whole debate about whether or not to define error handling is silly, cause implementations need to implement error handling anyway

JR: other point of disagreement - HTML5 modified grammar of IRI or URI spec to accomodate special cases; would be much simpler to define mechanism in HTML5 to cite IRI and let IRI spec do defining

DC: unless have test case, that's an editorial matter

JR: agree it is editorial

<Zakim> MikeSmith, you wanted to say that Roy was really objecting to redefining the term "URL"

MS: Roy objected to redefining term URL
... Roy in last post said spec would not get thgrough LC review
... seems accurate - a number of things in HTML5 need resoluition otherwise won't get through last call
... if don't deal with now, will have to deal with in last call

DC: anyone complaining about HTML5 spec, the URL specs are the ones people deem a nightmare

<Zakim> MikeSmith, you wanted to say that error handling needs to be documented somewhere and wonders if people are objecting to it being documented at all

DC: redefining URL in HTML5 spec, there are worse things to do, but what is clearly better?

MS: Roy suggested qualifying it - HTMLURL was one suggestion

<Lachy> the HTML5 spec redefines "URL" to more realistically match how the term is used in practice

MS: don't think that is practical

<hober> clearly better would be for the URI/IRI specs to be updated to match what browsers do

MS: spec is attempting to specify error handling because needs to be documented so UA implementations interoperable
... URI spec - no active work on revising; only have URI mailing list - good for discussion but not path to resolution
... not going to address error handling HTML5 must because we need for interoperability

<DanC> (handling errors is one of our documented design principles. http://www.w3.org/TR/html-design-principles/#handle-errors )

MS: JR serious objections to documenting error handling?

<jmb> hober: browsers aren't the only things that use URI/IRIs

JR: no, what is being said is if HTML docs contain HREF attributes containing whitespace, good idea to define how to handle; fine to do that, but problem is to say this is why URL spec is broken; discussion about how the specific text in HTML5 spec is phrased

<hober> jmb: agreed. As an author of non-browser tools that work with URLs, what I want is for my language's URL library to do what browsers do.

MS: HREF and HTMLURL seem like dead-ends

<Lachy> The URI spec is not broken because it doesn't allow whitespace, it's broken because it doesn't define how to handle it when the URL processor encounters it

MS: understand urge to redefine terms, but thay aren't calling them HREFs but simply URLs - documenting what we mean by URL is essential - think that's what hixie's extant text reflects; browser behavior around HTML and HTML APIs and related specs used by UAs to handle HTML content

JR: any doc that contains a non-embeded IRI ??? - mapping HREF to something else is error handling for malformed documents

MS: not trying to define new performance criteria, but assist authoring
... what everyone should be doing from authoring POV; need to define what happens when author dosn't follow rules

JR: alogrithm phrasing for translation to URI - perhaps need to draft proposal for hixie's consideration

<takkaria> people seem to be getting annoyed at the phrasing of the text, not what it actually accomplishes

<DanC> (yeah... I thought about an alternate proposal, but in doing so, I satisfied myself with what's there.)

MS: concrete proposals always better then vague suggestions
... agree with takkaria's comment - just a problem with wording, not concept
... further resolution to take?
... try to get better phrasing in spec

PROPOSED RESOLUTION: Clarify phrasing of text in section x.x.x ??

<robburns_> it is robburns, but I have a bad onnection so I wil just listen

PROPOSED RESOLUTION: Clarify phrasing of text in section x.x.x ??

MS: no resolution - just informal decision
... Section 2.3 for the record

Action Items Due Next Week

<MikeSmith> action-23?

<trackbot> ACTION-23 -- Gregory Rosmaita to coordinate tests using ARIA -- due 2008-07-10 -- OPEN

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

MS: GJR coordinate tests using aria

<MikeSmith> oedipus: discussed at PFWG 2 weeks ago, different people working on other implementations, waiting for follow-up from PFWG

GJR: PF would prefer to wait until last call

<DanC> "pending review" means "I want to talk about this with the WG". I suggest marking it open and setting the date to ... say... a month from now

DanC, due date is dependent on code-freeze

<DanC> action-66?

<trackbot> ACTION-66 -- Joshue O Connor to joshue to collate information on what spec status is with respect to table@summary, research background on rationale for retaining table@summary as a valid attribute -- due 2008-07-10 -- OPEN

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

for ARIA last call

MS: run through issues
... headers algorithms - not sure whether been much discussion lately
... table summary attribute related issue

<Laura> headers issue's history is detailed at:

<Laura> http://esw.w3.org/topic/HTML/IssueTableHeaders

MS: issue of being able to generate conformant HTML5 content using XSLT; can't have conformant HTML5 with document prologue that lacks proper system id - can't generate from XSLT; HenriS cited as problem with XHTML serialization/modularization
... don't see what progress can make today
... suggest that we stop looking through raised issues; reviewed - pending review issues at bottom of agenda
... discussed for all except HEAD profile issue
... Julian, status? keep open?

JR: opened because discussed 2 or 3 weeks ago, but didn't get into tracker; affects other specs; no new info about it

MS: reminder issue
... wonder what we need to do with these - a state where don't need to be revisted every week

DC: put issue to WG to get consensus

JR: pending review

DC: means editor written whatever he deems answers issue

MS: class of issues like this

DC: owe people chance to object -

MS: get objections on record and close items

<Zakim> robburns, you wanted to say that the problem is that the draft says it redefines it and yet Ian and DanC's test indicate it has not been redefined (so why create confusion for the

<robburns_> yes

<DanC> (Mike said we've been over all the "RAISED" issues... I'm a little confused... why are they still in RAISED state, then? I guess I'll find out in due course.)

<robburns_> I can hear you, but I don't have a good connection to talk

<robburns_> background noise it is too loud here

<DanC> ok, I suppose we've moved on from the URI stuff anyway, Rob

<robburns_> yeah, I entered that point anyway

<robburns_> no, that's all

<MikeSmith> robburns_: OK

DanC, the raised state means "we are conscious of it and will adress when time appropriate

<Zakim> oedipus, you wanted to ask wouldn't julian's issue be "RAISED" - shouldn't that suffice for now?

DC: been addressed

<DanC> (it's sort of a clerical error that the @profile issue wasn't in the tracker when it was discussed, but I don't recommend trying to discuss it more)

MS: need to do what DanC suggested and get questions out to group to get decisions on record

<Laura> Are these definitions of tracker issues accurate?

<Laura> http://esw.w3.org/topic/HTML#line-10

Any other business?

MS: Laura wrote up some very good accurate descriptions

<MikeSmith> DanC says we should encouage people to register for the TPAC

GJR notes that she also did a bang-up job on the email info page, too

<DanC> re "If after due consideration of different opinions, consensus is not achieved," the only way to tell if consensus has been reached is to put a question

MS: discuss on next week's call to ensure WG agreement on http://esw.w3.org/topic/HTML#line-10

<Laura> http://esw.w3.org/topic/HTML/EmailLists

<DanC> the chair can *estimate* the level of consensus, but the only way to be sure is to put a question

MS: need to put up reminder for attendence at TPAC

<MikeSmith> DanC: move to adjourn

second

<MikeSmith> [adjourned]

MS: adjourn for week - ChrisW can you chair next week

<MikeSmith> ChrisWilson will chair next week

<Laura> bye

ChrisW: yes will chair next week

<robburns_> bye

<robburns_> Zakim robburns_ is robburns

- DRAFT -

HTML Issue Tracking Teleconference

10 Jul 2008

Attendees

Contents