See also: IRC log
<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/
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?
<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
zakim ??P2 is Josh_O_Connor
zakim +??P2 is Josh_O_Connor
<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
<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
josh - other URIs from ESW?
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
<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
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> 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
... 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> Action 54 is dependent on PF's response. PF is beginning a process to provide guidance.
<trackbot> Sorry, couldn't find user - 54
<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.
<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
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
<trackbot> ACTION-69 -- Dan Connolly to produce poll on integrating sections of Webforms 2.0 -- due 2008-07-03 -- PENDINGREVIEW
<DanC> close action-69
<trackbot> ACTION-69 Produce poll on integrating sections of Webforms 2.0 closed
DC: at a loss - chris was supposed to address at PF face2face
... 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..."
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> Examples like the following one needs to be conforming in HTML 5:
<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> 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.
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 <firstname.lastname@example.org>
<DanC> To: Roy T. Fielding <email@example.com>
<DanC> Cc: firstname.lastname@example.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
<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
MS: comment from hixie htat test
cases not written to obtain results, but only to study browser
... 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."
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
... 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
... 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
... Section 2.3 for the record
<trackbot> ACTION-23 -- Gregory Rosmaita to coordinate tests using ARIA -- due 2008-07-10 -- OPEN
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
<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
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:
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
<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?
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
<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
MS: adjourn for week - ChrisW can you chair next week
<MikeSmith> ChrisWilson will chair next week
ChrisW: yes will chair next week
<robburns_> Zakim robburns_ is robburns
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Action Item 54 Update/missing-alt ISSUE-31 action-54/ Succeeded: i/(new headers/TOPIC: TABLE issues & actions update Succeeded: s/missing/sniffing/ Succeeded: s/problems with patches interesting aspect/the most interesting thing i got out of the thread was options and patches to browse without content sniffing/ Succeeded: s/Adam Barr/Adam Barth/ Succeeded: s/dig.com/digg.com/ Succeeded: s/specifically about MS?/specifically about Microsoft's authoritative=true proposal?/ Succeeded: s/TAG discussions wide-ranging/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/ Succeeded: s/not sure to/should not/ Succeeded: s/GJR:/GJR notes/ Succeeded: s/IanH/IanH's findings/ Succeeded: s/straw poll/reminder/ Found ScribeNick: oedipus Found Scribe: Gregory Default Present: Gregory_Rosmaita, ChrisWilson, MikeSmith, Cynthia_Shelly, Julian, DanC, Josh_O_Connor, [Microsoft], Lachy, laura, [IPcaller] Present: ChrisWilson Cynthia_Shelly DanC Gregory_Rosmaita Josh_O_Connor Julian Lachy MikeSmith Rob_Burns laura robburns Regrets: Joshue DaveSinger Agenda: http://www.w3.org/html/wg/tracker/agenda Found Date: 10 Jul 2008 Guessing minutes URL: http://www.w3.org/2008/07/10-html-wg-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]