W3C home > Mailing lists > Public > public-html-wg-announce@w3.org > October to December 2011

minutes for HTML WG f2f, 2011-11-04, part 1

From: Michael[tm] Smith <mike@w3.org>
Date: Sat, 5 Nov 2011 05:55:58 +0900
To: public-html-wg-announce@w3.org
Message-ID: <20111104205558.GA22192@sideshowbarker>
http://www.w3.org/2011/11/04-html-wg-minutes-part1.html

HTML WG f2f,  04 Nov 2011 -- part 1

     * Topics
         1. Issue 133 Dialog
         2. Issue 30 Longdesc
         3. issue-164 hgroup
         4. short update on the status of the time element
         5. issue-179
         6. URI/IRI
     * Summary of Action Items
     _________________________________________________________

Issue 133 Dialog

   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

      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

      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

      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

Issue 30 Longdesc

   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

      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

      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

      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

      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/A
   lternativesAreNotViableSolutions

      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

issue-164 hgroup

   <laura> The information is already there.

   <Stevef> hgroup replace proposal
   http://www.w3.org/html/wg/wiki/ChangeProposals/hgroup

      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

      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

short update on the status of the time element

   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

issue-179

   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]

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

URI/IRI

   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/0
   019.html>

      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

      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/2011No
   v/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/2011No
   v/0295.html> ** [Bug 13570] why does input type=color support
   autocomplete? <

      http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Nov/0296.html>
      http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Nov/0295.html>

   񏫤̏ 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.htm
   l

      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]

      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/0
   022.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/0
   021.html> ** sam: Call for consensus on issue 164 <http:/

      http://lists.w3.org/Archives/Public/public-html-diffs/2011Nov/0022.html>
      http://lists.w3.org/Archives/Public/public-html-diffs/2011Nov/0021.html>

   <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/2011No
   v/0297.html>

      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

      http://www.w3.org/2011/11/04-html-wg-irc

Summary of Action Items

   [NEW] 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]
   [NEW] 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]

-- 
Michael[tm] Smith
http://people.w3.org/mike/+
Received on Friday, 4 November 2011 20:58:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:08:41 UTC