We have only one change proposal on issue 133, and the righ next step is to do a call for consensus
<hober> http://www.w3.org/html/wg/tracker/issues/133
<pimpbot> Title: ISSUE-133: Add a modal attribute to html5 to indicate a modal segment of the DOM (modal dialog) - HTML Weekly Tracker (at www.w3.org)
<hober> the proposal: http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-133
<pimpbot> Title: User:Eoconnor/ISSUE-133 - HTML WG Wiki (at www.w3.org)
<eliot> all issues: http://dev.w3.org/html5/status/issue-status.html
<pimpbot> Title: Change Proposal Status (at dev.w3.org)
RESOLUTION: do a call for consensus on issue 133
JS: earlier this week PF decided to do a small aria.next release on a or short cycle and include aria-describedat in that release.
<dsinger> issue-30?
<trackbot> ISSUE-30 -- Should HTML 5 include a longdesc attribute for images -- open
<trackbot> http://www.w3.org/html/wg/tracker/issues/30
<pimpbot> Title: ISSUE-30: Should HTML 5 include a longdesc attribute for images - HTML Weekly Tracker (at www.w3.org)
JS: accessibility TF has been thinking about asking for longdesc to apply to tables in addition to images
... that would replace @summary, and would allow AT and non-AT users to get the info without it being forced on them
... we're concerned that there is still some misunderstanding withitn the wg about why some of the counter-proposals are not ok with task force
PC: How does aria-describedat impact issue 30?
JS: it doesn't, but is a longer term solution
JF: expanding on all 3 points...
... we sat down and defined the user requirement and looked at possible solutions
... user interaction... for some users providign extra info on complex objects is important
... discoverability is also important, and it needs to be actionable
... that's the interaction in UA for longdesc
... need HTML markup in the altenrative after you navigate to it
... real problem is users agent support
... longdesc has been abused in the past, and is a mess. but it's the best we have right now, and it supports the user needs
... aria-describedby is not discoverable, it just gets read, no way to choose
... only exposed to accessibility APIs, not there for non-AT usres, such as those with cognitive issues
... describedby is flattened to a string, markup is gone in teh accessibility apis, because those apis don't support html markup
... we've talked about introducing aria-describedat that would have a URL, and solve the use case
... longdesc doesn't put a visual encumbrance on the graphical layer, which is an imporant use case for business. we could put it in the chrome, but browsers are trying to have less chrome. suggest a user preference to make longdesc indication visible
... looking ot introduce new attribute in aria, but there is a lot of work before it's working for real users. while we're doing that, we ask that you leave longdesc alone until aria-describedat is ready.
PC: you are not proposing any revisions to longdesc change proposal.
JF: that is correct
PC: you're proposing a parallel aria solution, but don't belive it's germaine to issue 30 right now
JF: important that we understand why aria-descibedby doesn't work for this use case.
PC: are you proposing to get rid of describedby
JF: no, it's a different use case
JS: yes, it is not impactful at this time
PC: third item you wanted to discuss was the counter-arguments to longdesc based on aria-describedby
<JF> http://www.w3.org/wiki/User:Jfoliot/longdescresponse
<pimpbot> Title: A11yTF/longdescresponse - W3C Wiki (at www.w3.org)
JF: aria-describedby lacks discoverability and actionability, and gets flattened in the accessiblity apis
PC: where is the argument you're trying to counter?
JF: Jonas' proposal to keep longdesc non-conforming and chairs decision
PC: your target is the rationale section of Jonas' proposal
<pimpbot> Title: HTML WG f2f -- 03 Nov 2011 (at www.w3.org)
JF: hearing that there is pain with longdesc, we're building a solution in aria, but please leave longdesc alone while we have time to do that right
PC: is there any reason not to push issue 30 forward?
JF: no
<eliot> Jonas proposal: http://www.w3.org/html/wg/wiki/ChangeProposals/DeprecateLongdesc
<pimpbot> Title: ChangeProposals/DeprecateLongdesc - HTML WG Wiki (at www.w3.org)
MC: there is also Matthew's proposal, which also asks to have longdesc non-conforming
<MichaelC> http://www.w3.org/html/wg/wiki/ChangeProposals/DeprecateLongdesc
<pimpbot> Title: ChangeProposals/DeprecateLongdesc - HTML WG Wiki (at www.w3.org)
PC: a survey would come down to whether aria-describedby is adequate
MC: the first longdesc proposal didn't list all the use cases, but this one includes several new use cases. the counter proposal say that use cases can be satisfy the use cases. You are arguing that aria-describedby doesn't meet the use cases
PC: you need to copy all of this into the change proposal
JF: what I just wrote is not a change proposal, it's a rebuttle to another change proposal
PC: we've asked the authors of the counter proposal to list why describedby works. I heard MC asking you to list why it doesn't.
JF: it does
PC: I'm not seeing it in the doc
SF: are the chairs just saying to copy the stuff from wiki to the change proposal?
MC: yes
PC: yes
... when we go to survey, we want a section with responses to counter-proposal
JF: we will make the chagne
<laura> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions
<pimpbot> Title: ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions - HTML WG Wiki (at www.w3.org)
PC: do you see aria-describedat having any impact on any of the change proposals
JS: not at this time
<laura> Suggested Alternatives Are Not Viable Solutions
<laura> aria-describedat reinvents the wheel.
<laura> ARIA should be used to augment the available semantics of HTML as necessary, not to duplicate a basic mechanism that has already previously been created.
<laura> aria-describedat is vaporware. It currently does not provide external reference functionality. longdesc provides it now.
<laura> aria-describedat would be strictly assistive technology oriented. Whereas @longdesc has even been implemented in Opera, iCab etc.
<laura> aria-describedat is not backwards compatible.
<laura> The only pain that there is with longdesc is the pain of having to reinstate it into HTML5.
PC: Actions are: TF to provide the new info in the change proposal, chairs contineu review to get to survey
<laura> The information is already there.
<Stevef> hgroup replace proposal http://www.w3.org/html/wg/wiki/ChangeProposals/hgroup
<pimpbot> Title: ChangeProposals/hgroup - HTML WG Wiki (at www.w3.org)
<Stevef> hgroup remove http://www.w3.org/html/wg/wiki/ChangeProposals/dropHgroup
<pimpbot> Title: ChangeProposals/dropHgroup - HTML WG Wiki (at www.w3.org)
SF: use case of hiding subheadings from TOC is not compelling
<anne> so instead of a new element to address the use case we add a new element?
SF: Lauchland Hunt provided some patterns that hgroup would fit. I found other ways to create that pattern, including 'subline' semantic
PC: 11731 proposes to chagne hgroup to something else, 11828 is to get rid of it.
... editor rejected, but there is no change proposal to leave it as is.
AVK: some people stopped caring about doing the change proposal process
... it's too heavyweight
<anne> i didn't say that cyns
sorry, please correct it to what you said
AVK: I don't get saying that we don't need an element for that use case and then adding a different elements
JF: was offering an additional idea for discussion. maybe there is a reason to have it.
... I suggested it to get feedback. There some patterns where hiding a subline could be useful, but hgroup doesn't do that. It collapses the two headings into a single heading, which is confusing for accessiblity scenarios
SR: you wrote the proposal to get discussion, which didn't happen. If you withdraw it, since you can live with the other proposal, we'll do a call for consensus.
SF: I withdraw the subline proposal.
PC: process point. What happens when we do a survey and people object because they want to keep hgroup?
SR: they can do a change proposal with their survey response.
PC: which will put us back in the state of having two proposals
PC: do we want one issue on time and a separate issue on data?
SR: some people were happy to have both time and data
... revert request asked have everything put back
PC: we need change proposal
... Tantik's proposal will be about time, and may or may not include data
SR: there was a response in the bug
PC: there is further dialog
... there is a call for change proposals closing today, Nov 4.
TOPIC issue-180
PC: av_param
<scribe> ACTION: Paul confirm that chagne proposal for av_param is still active [recorded in http://www.w3.org/2011/11/03-html-wg-minutes.html#action01]
<trackbot> Created ACTION-207 - Confirm that chagne proposal for av_param is still active [on Paul Cotton - due 2011-11-11].
PS: want to figure out a path forward on this issue
... sent out a message last night collating my thoughts.
... there is an IRI working group at the IETF, which is updating the core IRI spec.
... that should be done early next year
<pimpbot> changes: sam: Call for Consensus on 133 <http://lists.w3.org/Archives/Public/public-html-diffs/2011Nov/0019.html>
PS: that is refernced from the HTML spec.
... there is text in html about parsing "urls" and some aspects of that are related to IRIs, and parts of it are pre-processing
... there is little energy for doing this work in IRI workign group. perhaps its better for this to happen here.
karl: would it be ok with the IETF group if there was a link from the IRI spec to the parsing spec?
<pimpbot> Title: How many ways can you slice a URL and name the pieces? - Tantek (at tantek.com)
stpeter: implementors are going to be looking at the html spec, not the iri spec
karl: people doing libraries would have a link directly to the parsing spec
AVK: each client is only using one library
... people in opera implemeting iri spec currently don't need to look at html spc
<eliot> issue 56:
<eliot> http://www.w3.org/html/wg/tracker/issues/56
<pimpbot> Title: ISSUE-56: Bring "URLs" section/definition and IRI specification in alignment. - HTML Weekly Tracker (at www.w3.org)
PC: The chairs decison adopts the change proposal to restore the text
... this can be revisited if there is new info, such as IETF creating a doc. PS said the document is not progressing
<tantek> Julian, example and citation needed - incorrect according to what?
PC: would the html wg have a separate parsing spec, and anyone could refer to it, including IETF?
<Julian> tantek, it doesn't describe what UAs do
<Julian> tantek, it might be describing what *some* do
<tlr> (discussion about preprocessing vs parsing)
<MichaelC> scribe: MichaelC
<tlr> anne: only care about Web context?
<tlr> stpeter: SIP
<tlr> ... other protocols as well
<scribe> scribe: tlr
... liberal parsing of URIs might leak into other applications
... implicit concern that people seem to have had
anne: URLs leak all over the place; seems desirable to parse them all over the place
karl: document might surface or solve those issues
... but that's not what we're looking at right now
... let's find agreement on how to proceed
stpeter: don't have one place that captures everything
... some text in HTML5, delegated to Adam, Adam expanded, ...
... from technical point, we don't have one place where we can talk about this
<pimpbot> bugmail: [Bug 14427] Investigate if click()'s click-in-progress should apply to user and/or script initiated clicks <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Nov/0296.html> ** [Bug 14427] Investigate if click()'s click-in-progress should apply to user and/or script initiated clicks <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Nov/0295.html> ** [Bug 13570] why does input type=color support autocomplete? <
... if more people who implement and care are around here, then perhaps do the work here
<tantek> Julian, sounds like hand waving. Your assertion "restored text is known to be incorrect" is unactionable without providing at a minimum: 1. specific section of said "restored text", 2. either a) according to what other specification (citation needed), or b) example of a URI and an implementation that interprets it differently than the restored text. Please write that up and post it on the web (e.g. HTML WG wiki), otherwise "known to be incorrect" has no basis.
paul: the issue is closed
... what you want to do is to reopen the issue that defines the parsing
... the way you characterized it, you have a man-power problem
... all that we can do is ask whether there's anyone in this WG who can take on the task
<Julian> tantek, it's in the WG's archives, but I currently don't have the energy to research.
... somebody could propose an editor's draft that can sit along the HTML5 spec
Mike5: willing to take that on, and work with Adam
... I will edit the document myself if I have to
stpeter: I will edit the document myself if I have to
... but we're not supposed to have ADs edit documents
<scribe> ScribeNick: cyns
<tantek> Julian - "don't have the energy to research" is a common problem with "[email] archives" (poor searchability), hence my request for you to post a write-up on the HTML WG wiki.
PS: maybe we can get enough people together and get this done
PC: lets assume we have technical agreement on what needs to happen, we still have a clock ticking on last call 1
... let's get the material out into a separate document, then decide if people want to open a separate issue on it.
<Julian> tantek, I realize that you prefer wiki-over-email, but replicating a one-year-old mail thread into a wiki seems like a waste of time to me; I can try to find the relevant mails and will post pointers to the mailing list (where they will be picked up by the Tracker)
AVK: several years ago, we moved this into a separate draft, and IETF asked us to remove it and they would right a new one
<tlr> mike5: we won't nuke the document again
MS: we will not remove this document again if we're asked to.
PS: let's concentrate on the problem moving forward.
action item on Peter and Mike Smith due november 19
<trackbot> Sorry, couldn't find user - item
<Julian> Tantek: http://lists.w3.org/Archives/Public/public-html/2010Jul/0036.html
<pimpbot> Title: Re: Change proposal for ISSUE-56 from Roy T. Fielding on 2010-07-15 (public-html@w3.org from July 2010) (at lists.w3.org)
TO
<MikeSmith> trackbot, status?
PC: Jeff Jaffe will be visiting us at 11:30.
... recessed until 11:30
<MikeSmith> ACTION: Michael[tm] to sync up with Peter St. Andre on URL processing draft and report back in two weeks [recorded in http://www.w3.org/2011/11/03-html-wg-minutes.html#action02]
<trackbot> Created ACTION-208 - Sync up with Peter St. Andre on URL processing draft and report back in two weeks [on Michael[tm] Smith - due 2011-11-11].
<MikeSmith> action-208 due 2011-11-18
<trackbot> ACTION-208 Sync up with Peter St. Andre on URL processing draft and report back in two weeks due date now 2011-11-18
<pimpbot> changes: hixie: Change how nested clicks are prevented to also prevent click() inside a regular onclick=''. (part 2) (whatwg r6818) <http://lists.w3.org/Archives/Public/public-html-diffs/2011Nov/0022.html> ** hixie: Change how nested clicks are prevented to also prevent click() inside a regular onclick=''. (whatwg r6817) <http://lists.w3.org/Archives/Public/public-html-diffs/2011Nov/0021.html> ** sam: Call for consensus on issue 164 <http:/
<pimpbot> bugmail: [Bug 14427] Investigate if click()'s click-in-progress should apply to user and/or script initiated clicks <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Nov/0297.html>
<karl> I think there is an issue :) and a big one indeed
<karl> ArtB, yes it seems
<karl> it should start in a couple of minutes
<karl> oopsie even the irc txt log is gone http://www.w3.org/2011/11/04-html-wg-irc