- From: Michael[tm] Smith <mike@w3.org>
- Date: Sat, 5 Nov 2011 05:55:58 +0900
- To: public-html-wg-announce@w3.org
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