HTML Issue Tracking Teleconference

14 Aug 2008


See also: IRC log


Cynthia_Shelly, DanC, Gregory_Rosmaita, Julian, Laura, Mike, Shepazu, [Microsoft], robburns, smedero




<trackbot> Date: 14 August 2008

<MikeSmith> oedipus: you calling in today?

yes right now

<Julian> Zakin, +49.251.280is me

<DanC> hmm... profile doesn't show up in "Issues discussed over the last week" ... I guess we didn't give any tracker clues in the discussion. or was that last week?

<Julian> profile: I guess it was the week before

<scribe> Scribe: Gregory_Rosmaita

<scribe> ScribeNick: oedipus

Agenda Review

MS: trackbot page - if something not yet entered into tracker but want addressed today, speak up now, please
... no agenda additions - preferences on where to start?

DC: curious about the raised issues

MS: start with raised issues
... go through in reverse chronological order?

<MikeSmith> issue-58?

<trackbot> ISSUE-58 -- Use of "curly brackets" to identify a graphical image by its use or type by inserting a generic identifier / descriptor in curly braces as the @alt value for an IMG, -- RAISED

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


DC: clearly a dupe of missing alt to me

MS: agree, but a bit more precise
... discussions gone on for months about alt -- after reviewing several proposals for handling disputed cases where author can't determine useful alternative text, what should the author do?
... 1 solution offered was curly brace delimited generic type text placeholder to provide information for software to use in intelligent matter -- user choice of what to expose and not

<Laura> Curly braces is but one of many potential solutions have been discussed and are listed at:

<Laura> http://esw.w3.org/topic/HTML/IssueAltAttribute#head-27468e7ee9afd1f9e07186c8d74f0b0168b3975a

<DanC> yes, {photo} is the recent proposal for the missing-alt issue; making a new issue doesn't seem like a useful way to organize the discussion.

<Laura> Advice has been sought, is needed, and is pending from PFWG regarding what an authoring or publishing tool should insert, in a case where no alt has been provided by the author, but the image is known to be "critical content".

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

MS: hixie sent message many months ago to PF, but no response

<Laura> usurping the role of WAI. PF has previously pointed out, "WCAG WG is chartered to set Accessibility guidelines and HTML WG is not".

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

<Laura> The W3C Web Accessibility Initiative (WAI) is the accessibility authority.

MS: recently, hixie made change to spec, and that sparked response

<Laura> Imposing a particular solution and adding it to the draft could be seen as usurping the role of WAI. PF has previously pointed out, "WCAG WG is chartered to set Accessibility guidelines and HTML WG is not".

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

<Laura> The W3C Web Accessibility Initiative (WAI) is the accessibility authority.

<Laura> The curly braces proposal in the editor's draft doesn't appear to be a text equivalent per WCAG. The HTML WG needs to be sure deliverables satisfy accessibility requirements. PF are the go-to-guys for guidance in accessibility matters. PF's counsel is needed BEFORE any particular solution is chosen to be added to the next published draft. The curly braces proposal should not be published outside of an editor's draft without consultation and collaboration

MS: change in discussion since added to spec

GJR: alt for human parseable info, need @role for machine parseable info/hooks

CS: PF talked about this on call yesterday, working on proposal/response

MS: commenting on GJR's comments - HTML WG has as its mandate what @alt is - can change purpose of alt attribute to make provisions to bring up to date with use cases and reqs that are out there; def of @alt is not static and locked-down for ever; not categorically an abuse if redefine @alt to accept something other than textual equivalent

GJR: if @alt is to be used as machine parseable, info - how is @alt equivalent to be expressed?

MS: yet to be determined

<Laura> The Protocols and Formats Working Group (PFWG) has not yet provided guidance with regarding curly braces proposal in the the img section of the editor's draft with respect to conformance with:

<Laura> - Web Content Accessibility Guidelines (WCAG)

<Laura> - Authoring Tool Accessibility Guidelines (ATAG)

<Laura> - User Agent Accessibility Guidelines (UAAG)

MS: can't cut conversation short by citing older recs

GJR: that's the proposal @role that would fulfil this use case without compromising alt for those who care of can add it

<Laura> The curly braces proposal should not be published outside of an editor's draft without consultation and collaboration with PF.

<Laura> It seems as if the curly braces proposal is meant for meta data and would fit better in a separate img attribute. In any event it isn't a text equivalent per WCAG. Not only do reserved characters pollute the possible values available for an attribute whose data type is string, but also it is meta data about the image - not an equivalent. They are two different things.

GJR: what will happen when author wants to add alt text as equiv and machine parseable info for app processing?

<Laura> What if someone actually has an image of {} or {captcha} etc - text shouldn't be in graphics, but what if this is needed where say someone is showing how text appears in a new font they are designing?

<DanC> (this discussion is hard to follow; some are arguing positions in the design space, some are pointing out the scope of the HTML WG, and some are arguing that one issue is a dup of another.)

MS: case where author not able to put useable text equiv into value of @alt
... no agreement on @alt - even disagreement over use cases
... if don't address requirement, then result is that authors just going to dump use of content into @alt - spirit of change was to address use case/req for those who cannot add @alt

GJR: ability to auto-add machine-parseable info should NOT compromise the author's ability to provide a textual equivalent
... reason @role was suggested was to satisfy the original use case that led to the curly braces verbiage

CS: agree that use case exists, but don't think curly braces best -- like GJR's solution, but some reservations, need to think through; would be useful to have both categorization and equivalent info

<Zakim> DanC, you wanted to get back to the raised issue and suggest again that ISSUE-58 curly alt be closed as a dup of ISSUE-31 missing-alt

DanC: curly alt discussion is same as missing alt - wouldn't make seperate decisions

MS: DanC's wants to close new issue - same design space

GJR: moves issue forward by proposing @role

<DanC> (hmm... I didn't see anything about @role in the curly alt issue)

MS: want to avoid proliferation of core issues - personally agree with dan, good to discuss on call, but not sure a seperate issue
... can append or change description but same issue

<Julian> Either close 58 *and* update 31, or close 31 and update 58.

GJR: ability to perceive visual image a use case that is not changed since web began - this is an attempt to rectify

MS: not going to fall through cracks - bigger issue is sole place to track discussion about this part of the problem

<DanC> what's a better title, indeed?

CS: re-write title of other issue - categorization of objects and not just "missing alt"

<DanC> "Should img without alt ever be conforming"

<MikeSmith> issue-31?

<trackbot> ISSUE-31 -- Should img without alt ever be conforming -- OPEN

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

CS: handling cases where alt is unknown?

<DanC> "handling cases where alt is unknown" works for me

GJR: machine-parseable versus human-parseable values for @alt

MS: replacement?

CS: yes, but first draft

<smedero> I'd also suggest changing the short title from `missing-alt` to just `@alt` or something equally general...

<DanC> I think that's too far, smedero

<smedero> ahh, ok.

<DanC> I can see "machine-parseable versus human-parseable values" as a separate issue. I didn't get it from the initial text of issue 58

<MikeSmith> PROPOSED RESOLUTION: issue 31 title: Should img without alt ever be conforming; machine-parseable versus human-parseable values for @alt

GJR: thinks conflating issues

<DanC> blech.

GJR: minus 1

<DanC> I like "handling cases where alt is unknown" much better.

GJR: retract minus 1 to plus 1

CS: current issue name is inflammatory
... more about how to figure out what to do when good alt not available
... one an implementation detail one a spec detail

<MikeSmith> PROPOSED RESOLUTION: issue 31 title: Should img without alt ever be conforming; what to do when good alt not available

DanC: handling cases where alt is unknown doesn't work for GJR?

<Julian> I like the proposal

<MikeSmith> PROPOSED RESOLUTION: issue 31 title: Should img without alt ever be conforming; what to do when a reasonable alt cannot be determined

CS: handling cases where a useful or reasonable @alt is not available

GJR: that to me is an authoring tool implementation problem, not a declarative language problem

<DanC> (tweaking based on what I hear... "handling cases where reasonable alt is unknown/unavailable")

CS: is and isn't - can be author tool issue - when doing mash-ups, can't know what object is - having way of saying what kind of image or where came from is needed - role might satisfy that

<Laura> The original issue was Omitting alt Attribute for "Critical Content"

<MikeSmith> PROPOSED RESOLUTION: issue 31 title: Should img without alt ever be conforming; what to do when a reasonable alt is unknown/unavailable

<Laura> http://lists.w3.org/Archives/Public/wai-xtech/2007Oct/0044.html

<DanC> "what to do when reasonable alt is unknown/unavailable" works for me

GJR: decide first on @alt and @role - @role would be easily machine-extractable and insertable

<MikeSmith> PROPOSED RESOLUTION: issue 31 title: What to do when a reasonable alt is unknown/unavailable?

CS: what to do when a text a textual equivalent is not available

MS: like term "text" better

<MikeSmith> PROPOSED RESOLUTION: issue 31 title: What to do when a reasonable text equivalent is unknown/unavailable?

GJR: can live with that

<DanC> (this doesn't seem like a technical decision, so we can make this "decision" in a telcon)

<smedero> I've got ISSUE-31 in front of me, so I can make that title change....

<DanC> (i.e. this is just issue tracking admin)

<DanC> I have ISSUE-31 open in edit mode too, fyi

<MikeSmith> smedero: hang on just for a minute

<smedero> ahh, nevermind

<smedero> :)

CS: spend time in PF looking at use case from author and user POV;

MS: good idea

<MikeSmith> RESOLUTION: change issue 31 title to: "What to do when a reasonable text equivalent is unknown/unavailable?"

<MikeSmith> smedero, please change title and also add a note, specically about @role

GJR: concerned about those who want to do the right thing and provide meaningful textual equiv through @alt and machine-parseable info through @role - valid use case - want to provide meaningful equivalent and a machine-parseable hook

MS: can we expect to hear back from PF on use of @role?

CS: soon is a relative term

GJR: is on PF's radar and on PF's agenda

<smedero> DanC: did you have some changes to 31 that you wanted to make or were in the middle of?

<DanC> no

MS: good - laura's earlier point on PF's position - editor's draft is one thing, going past is another is well taken - not going to get to LC without agreement on this - try to do now or later, better to do now

<MikeSmith> smedero, please also close out issue 58 with a note

GJR: trying to provide requirements and comprehensive use cases

MS: coming to a mutual understanding of what reqs are

<smedero> 31's title is updated, going back to add the bits about @rol

<smedero> erm @role.

MS: by charter, not chartered to make binding decisions in telecon time, but can make decisions about issue tracking; main topic covered in this call
... those who call in to telecons, are more likely to shape issue tracking (nudge, nudge)

Raised Issues of Recent Vintage

MS: last one quotation marks for Q element - not useful to discuss

DanC: clarification from MS

MS: problem - everytime close issue, there will be an objection; reluctant to close anything out because don't want to generate an email storm; should start closing issues out

DanC: stright up close or keep

MS: proposals for closure?
... can go through 1 by 1 in 20 minutes left to decide to close
... not good to keep too much open at one time
... walk through rest of issues?
... based on past experience, closing issues, raises an email firestorm, but that should affect efficiency of tracker

<robburns> the issue on curie's could be closed since it was added only for one person and completely misunderstands curie's HTML5 or both

DanC: raised until someone takes an action item to do something

MS: 20-odd issues we haven't touched
... try to pick the low-hanging fruit today's discussion

robburns, what is issue number?

<Zakim> DanC, you wanted to ask about a few more raised issues

DS: quick question: with PF one needs to have them come to HTML WG with use cases and reqs, is it also useful if come with proposed wording?

DanC: hixie doesn't welcome suggested text, but helps me

<robburns> aria-curie is issue 51

<robburns> http://www.w3.org/html/wg/tracker/issues/51

GJR: PF is working on specific verbiage and requirements

DS: is it reasonable to put forth proposed wording or not?

MS: yes, don't listen to what hixie says -- proposed text CAN state req more clearly than stating req in abstract terms
... more helpful to propose text - no harm

DS: good tactic to state reqs, use cases, take proposed text and correlate which part of text goes with which req
... how HTML WG accepts input is my query

MS: for group as whole -- editor does have control over final wording - to propose to working group as a whole as discussion, is in my opinion FAR more helpful than dealing with abstracts

<Laura> Tracker definitions seem to have been followed for the curly brace issue. "RAISED = Issue tracker staff suggests this is worth a WG discussion and potentially a decision."

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

MS: when new info available, should be brought to group

Tracker Agenda Review, continued

MS: raised issues - lot are stale
... can continue to review issues - nothing super-recent (end-of july or pending review for end-of july august)

<MikeSmith> action-73?

<trackbot> ACTION-73 -- Dan Connolly to follow up on WAI-ARIA markup thread, emphasizing the conformance point -- due 2008-07-31 -- PENDINGREVIEW

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

MS: top of agenda, action 73

Action 73

DanC: think is done

MS: objections, otherwise close out

<MikeSmith> close action-73

MS: hearing no objections, will close - action, not issue

<trackbot> ACTION-73 Follow up on WAI-ARIA markup thread, emphasizing the conformance point closed

Issues In Red

MS: Lachy and authoring guide - past due, but not on call - know working on it

<MikeSmith> action-72?

<trackbot> ACTION-72 -- Joshue O Connor to rewrite spec to reinstate id/headers AND their functionality by specifically stating that headers are allowed to reference a td. Reword the current definition of the headers attribute so that each of the space separated tokens must have the value of the ID value of a th or td element. -- due 2008-08-14 -- OPEN

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

MS: action 72 - on Josh;

<Laura> Deliverable for Action 72:

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

Luara: working on it - please consult the above URI

MS: not finished yet, so reset due date until next week

<Laura> Request that the definition of the headers attribute in the spec be extended to allow it to reference a td. This would make it possible for complex data tables to be marked up accessibly.

MS: changed date to 2008-08-20

<Laura> The headers/id markup is functional and works today. Results of some recent testing:

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

<Laura> It needs to be grandfathered into the spec.

<Laura> This issue's history from May 2007 to present:

<DanC> (trackbot wish: "continue action-72" would push the date to 1 week from now)

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

MS: anything else on tracker anyone burning to discuss?

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

MS: if not, can end early
... clear we do need to do something about headers if going to keep in spec; isn't well specified in HTML4.01 - not fixing problem intended to solve
... anything else anyone wants to talk about or adjourn early?

move to adjourn

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

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

MS: surprised - lot of discussion on list -- thought there would be more to discuss; huge threads developing

<DanC> (the discussion of distributed extensibility and GRDDL was kinda interesting, but I'm not sure what to talk about)

JR: set of issues that have been open for a long time, seems that all arguments about issues have been exchanged on mailing list - what to do with them? suggest pick very simple one, and test process - put to vote if can't achieve consensus

MS: simple issue - current XSLT engines not being able to produce conformant HTML5 output a candidate

JR: yes

MS: agree should close out

DanC: thought were going to close discussion

MS: on XSLT, pick issues that are hanging where hixie has explicitly said won't make further changes to text but still bone of contention -- how to dispose of them? perhaps contacting the person who raised the issue to explain

<Julian> http://www.w3.org/html/wg/tracker/issues/54

DanC: issues where discussion done, or ...

MS: not an issue with decision - cannot currently use XSLT engines to produce HTML5

GJR: what does it mean to produce valid HTML5?

MS: conformant with current state of spec - specifically in regards XSLT the issue is the fact that HTML5 says should have a doctype html without system or public identifier, so have to use ugly hack to get an XSLT to generate that; HenriS has pointed out that is least amongst issues with HTML5 and XSLT, for HTML intended to be used by authors and valid

GJR: public working draft or current editors' draft in terms of conformance

JR: public one

GJR: wanted to ensure is PWD not editor's draft that is being "conformed-to"

<DanC> (w.r.t. ISSUE-54 html5-from-xslt , I'm content with XSLT engines adding a new output mode)

MS: will raise this as issue on list - have a disagreement about resolution - editor decided not to make change in spec, but still have problem; agree with hixie in regards this isn't an HTML5 spec problem but limitations of XSLT - cannot limit to legacy output of XSLT - trying to move lang forward; either constrain language to conform to XSLT HTML output, or expect that XSLT will be updated to something that is conformant with current HTML5 spec
... DougS referred to discussions on list -- anything actionable on those?
... could take up a lot of time (and already has)

<Julian> wrt xslt: the underlying question is: should HTML 5 stay compatible with existing HTML generators *if* it's easy to achieve?

DanC: suggest not a critical mass in favor - like to know mozilla's position on some of these issues - what are their positions, what are their reqs?

<Julian> what's the alternative? Re-open XSLT 1.0?

MS: decentralized extensibility - browser vendors shown little interest in that -- I'm oversimplifying the email thread quite a bit, but not a critical mass for us to address this, especially since have a long schedule of meeting implementation reqs and testing

<robburns> Julian: could you point to a specific place in the XSLT rec that prohibits a doctype with no system and public identifiers? I'm having trouble finding it.

MS: don't want to prematurely end decentralized extensibility issue, but don't want it constantly hanging over our heads

JR: decentralized extensibility crossed by thread on profile attribute - would be ok with statement that "we are not chartered to enhance abilities of HTML with regards to decentralized extensibility" -- concern about hixie removing what he doesn't like -- precludes any existing method of using extensibility, and if that is the case,then i'm not comfortable with that -- should keep existing hooks, rather than remove and drop discussion

DanC: expect anything of more discussion?

JR: sometimes new things come up, but no, I don't expect so in this case

MS: everything been said; hixie been quite candid on his position that mechanism for adding arbitrary extensions to core vocab not a good thing
... others think quite differently, and a lot in between
... any individual who wants to write something as separate spec and take to group for decision and to rec; distributed extendibility mechanism is orthogonal to core description vocab; no reason technically why could not be produced as separate spec - affects handling of HTML4/legacy content in text/html
... not exclusive to dealing with new HTML5 content; for a lot of reasons, probably should be developed as separate spec - could be created outside of HTML WG

DS: interesting proposal that it be separate spec; right that not a lot of new info, but not going to get that info if don't explain details of how to do it; since hixie said "not in my spec" is it feasible to expect another W3C WG to pick it up and develop?

MS: pragmattically speaking has to be in separate spec - sam and david might develop spec on how to do and how to integrate into HTML5 and HTML4

DS: hixie working at cross-purposes to that even if separate?

<DanC> (things like profile don't require anything from browsers; authoring tools are perhaps the more relevant party; but I haven't heard from any authoring tool makers about profile either. sigh.)

<robburns> just answering my own question on Issue-54, http://www.w3.org/TR/xslt#section-HTML-Output-Method indicates that the word PUBLIC would be included in HTML output method even if the author indicated a null value for the public identifier.

MS: hixie been very clear that don't want addition of arbitrary custom vocab into HTML5 and expecting UAs to do something with it
... without a clear undestanding of proposition and its value, won't be considered
... use case for which there are not users -- hard thing to tell browser vendors: "add app to add any type of tag they want and expect UA to do somthing useful with arbitrary vocabs"

DS: over-simplification

MS: stating most emphatic opposition

DS: generic mechanism for known or formal vocabs

MS: that is your perspective, but not sam's perspective; don't think that's what Dave Orchard wants either

DS: for ANY language in the future - keep in mind if you want your language integrated into HTML you need to do x,y, and z

MS: good point -- note to say "if you define custom vocab, here is what we strongly suggest you do"

DS: agree generally, but personally don't think other ML has to be changed to use processing model of HTML5

DanC: over-time by 10 minutes

MS: hear from JR then close

JR: 1) have some hooks for distributed extensibility in HTML4 that were removed from HTML5 (profile, scheme); 2) additional attributes, such as RDFa - introducing way to add new elements to language hard to do, but have other points of extensibility -- RDFa -- in charter to work on that - need to start discussion on how to achieve that goal - doesn't require new attributes, but restoring those that worked and are needed

MS: good point, JR
... very unclear if good reason to remove @profile -- mass of opinion against removal
... move to adjourn


<Julian> cu

<robburns> mass of opinion also for distributed extensibility

MS: thanks to all for calling in -- talk to you all next week

<MikeSmith> oedipus: we did reach resolution on that

<MikeSmith> with no objections

<MikeSmith> thanks

RESOLUTION: change issue 31 title to: "What to do when a reasonable text equivalent is unknown/unavailable?"

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/08/14 17:18:08 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/issue/issues/
Succeeded: s/on PF's radar/on PF's agenda/
Succeeded: s/cannot hurt/sometimes new things come up, but no, I don't expect so in this case/
Succeeded: s/oversimplified in discussion/I'm oversimplifying the email thread quite a bit/
Found Scribe: Gregory_Rosmaita
Found ScribeNick: oedipus
Default Present: Mike, DanC, +1.218.349.aaaa, Cynthia_Shelly, Gregory_Rosmaita, +49.251.280.aabb, Julian, Laura, Shepazu, smedero, [Microsoft]
Present: Cynthia_Shelly DanC Gregory_Rosmaita Julian Laura Mike Shepazu [Microsoft] robburns smedero
Regrets: Joshue
Agenda: http://www.w3.org/html/wg/tracker/agenda
Found Date: 14 Aug 2008
Guessing minutes URL: http://www.w3.org/2008/08/14-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]