<paulc> http://www.w3.org/html/wg/wiki/May2012Agenda
<tantek> good morning
<MikeSmith> ArtB, yeah
<MikeSmith> hey tantek, we are starting in a couple minutes, so you guys will have to catch up once you get here
<ArtB> Title: HTML WG F2F Meeting
<Clarke> Will there be a phone connection?
<MikeSmith> Clarke, yeah
<tantek> thanks MikeSmith
<MikeSmith> Clarke, +1.617.761.6200, code 4865
<MikeSmith> trackbot, start meeting
<trackbot> Date: 03 May 2012
<MikeSmith> Meeting: HTML WG F2F Meeting
<tantek> we can't hear anything on the phone btw
<tantek> is the room dialed into the phone?
<plh> not yet
<MikeSmith> tantek, we are dialing in now
<krisk> scribe: krisk
<paulc> http://www.w3.org/html/wg/wiki/May2012Agenda
paulc: choosing topics for
F2F
... Potential Topics...
time/date OR how/when we add semantic elements to HTML
Issue 183
media extensions/Encrypted media
HTMLG WG charter
If people have specific timeslots for an agenda then we will accommodate
<eliot> needs to drop off the call for a bit. Will return later.
#1 Time/Date
#2 Media Extensions +Task Force
#3 HTML Charter (V.NEXT)
#4 Test Suite
#5 Issue 199
#6 Issue 201 (canvas hit testing)
paulc: Let's collect some other
topics?
... If you have outstanding issue, please speak up
anne: what is the charter (#3) about
plh: we can dive into any of these or scope
anne: We should talk about the
items that occured last week...
... CG, editors...
paulc: This is the stabilization of the spec
<ArtB> Draft HTML5 Stabilization Plan
#7 Stabilization and FAQ
<MikeSmith> issue-194?
<trackbot> ISSUE-194 -- Provide a mechanism for associating a full transcript with an audio or video element. -- open
<trackbot> http://www.w3.org/html/wg/tracker/issues/194
#8 Issue 194
<MikeSmith> http://dev.w3.org/html5/status/issue-status.html#ISSUE-194
<MikeSmith> 21 open issues
#9 Other Issues (21 total), discussion about any of these
<rubys> http://dev.w3.org/html5/status/issue-status.html
<MikeSmith> (Mark Watson arrives)
paulc: we can talk about feedback for proposal, questions, etc...
<MikeSmith> issue-199?
<trackbot> ISSUE-199 -- Define complete processing requirements for ARIA attributes -- open
<trackbot> http://www.w3.org/html/wg/tracker/issues/199
<mjs> hober: are you here yet?
paulc: do we have a rough time estimate for issue 199?
mikesmith: should be about 45 minutes
paulc: Issue 201 will need about
90 minutes
... Media extensions, are people ready to discuss this?
... given the threads, it should take a long time (120
minutes)
anne: can we split the two...
Should we do one of the media ones first?
scribe: no agreement...
paulc: let's do stabilization first?
<MikeSmith> issue-183?
<trackbot> ISSUE-183 -- Enhance and simplify the time element -- open
<trackbot> http://www.w3.org/html/wg/tracker/issues/183
<MikeSmith> issue-184?
<trackbot> ISSUE-184 -- Add a data element -- open
<trackbot> http://www.w3.org/html/wg/tracker/issues/184
paulc..here is the rough schedule
9->10:30 today == Stabilization
10: 45: -> noon Issue-199
1->3pm Issue 201
3: 15 -> 5pm Issue 194, <time> & <date>, 183, 184
paulc: please object if this doesn't work for you
Friday 9->10:30 Media (both parts)
10: 45 -> noon Charter
1-> 5pm Test suite/Open Issues
paulc: Let's move into the stabilization topic
<paulc> http://lists.w3.org/Archives/Public/public-html/2012Apr/0204.html
<anne> is there an updated agenda?
<paulc> See also http://lists.w3.org/Archives/Public/public-html/2012Apr/0205.html
<anne> http://www.w3.org/html/wg/wiki/May2012Agenda looks updated, sorry
<paulc> FAQ (Draft HTML5 Stabilization Plan)
paulc: see both links
... starting with the WG Changes
<MikeSmith> Tantek, Ted have arrived
paulc: Editor changes
<MikeSmith> Cynthia Shelly has arrived
paulc: any questions?
... stabilization plan is the second part
... Q6 in the FAQ has decision policy changes
... many of these bugs are very strong, so if you are not
familiar please read
... for example you can only comment on from LC1
anne: is this allowed by the process?
mjs: it's happend before in WGs
paulc: we do want the decision policy in place before starting LC2
mjs: two questions...
... is this allowed
... Do people think this works for the WG, regardless of it
being allow or not
anne: this seems to discourage comments
glenn: we could have new bugs become exceptions
plh: the process allows you to comment
<glenn> i.e., if a new bug is commented that wasn't previously commented, the WG may choose to process instead of ruling out of scope due to lack of prior LC1 comment
plh: it's just that response to the comment will be 'too late'
anne: I don't like this..
paulc: it could be move to HTML.Next
mjs: see bug #16676
... later in the spec development cycle adding new features
doesn't work
rubys: let's look at the proposed diff
mjs: The key part of the diff
is..
... The chairs agree we do need an exception
... For second and subsequent last calls, only comments related
to changes made since the start of the previous last call will
be accepted.
This is to ensure we do not get into an infinite regress of new feedback; only new changes will get re-reviewed.
<Zakim> tantek, you wanted to say that implementation experience (browsers, web sites) is a good source of commentary for anything in LC.
paulc: can we hear from the room?
tantek: Getting feedback from
vendors, authors will be tough (since spec is very large)
... when browser vendors start to impl features, the find
issues that have not changed.
mjs: how did the CSS2.1 spec go?
tantek: Issues were found and the spec went last call -> CR -> last call -> CR-> lastcall...
paulc: we want to get to CR
mjs: the w3c process, states that if you have made major changes then you need to go back to last call
adrianb: the goal of overtime
narrowing comments, is a good goal
... we should impl these changes and if they don't work then we
can revisit
artb: Q6 seems reasonable, though I could see a issue coming up for the first time
tantek: This is fixing the wrong
problem..
... I'd rather see the WG push for CR and then handle
objections
anne: most of the bugs are OK, except the limiting the scope of issues
paulc: I'd like to hear from the
rest of the room
... Bug 16676
<anne> Also, in general, I think we should aim for less process, not more...
paulc: let's do a vote...
... room seems evenly split...
<mjs> Here's the part of the W3C Process that theoretically requires a new LC after substantive changes: http://www.w3.org/2005/10/Process-20051014/tr.html#return-to-wg
paulc: can anyone not live with
the change?
... seems like if the co-chairs push forward we won't get
strong pushback
mjs: please see the link I pasted in..
<odinho> RRSAgent: make minutes
paulc: giving notice..after next
last call we will be going to CR
... bug 16841 is the feature freeze, basically no new features
by default
paulc bug 16674
paulc: we are trying to not have
changes just appearing in the spec by the editor
... rather changes should come from bugs
... bug 13306 is about getting editors to do work in a finite
amount of time
anne: woud like to talk about this in general
paulc: co-chairs have not processed the applications for editors, but will do so in the next few weeks
anne: the main issue is that we
have too much process already and now we are adding
more..
... the amount of process is driving people away from the
WG
mjs: do you have any specific
ways or thoughts on how this could be changed?
... my point of view the weight of the process can impact the
group...
... unlike in the webapps WG, the wg was not able to get people
to agree and threads never closed out
<chaals> [what maciej said. If there are concrete proposals to change the process and make it nicer, that would be great, but otherwise let's not have a process discussion]
<Zakim> tantek, you wanted to say that current process (and proposed changes) appear(s) to favor spending time on process rather than technical discussion. and to also say flamewars need
tantek: the group has gotten to
the point that people don't want to even help improve the
process
... we are doing more process rather than technical
discussions
... microdata+RDFa discussion is a good example of discussion
just ending..
... chairs should just say in the list this is a perma
thread..
<JF> +1 to what Cynthia is saying
cythia: we at the point in 'shipping' that adding new stuff will be painful
cynthia: it's better now than in the past
anne: thinks the group is worse
<MikeSmith> to be fair, much of the technical discussion takes place in bugzilla and so it's natural that we have less technical discussion on the list than other groups do
mjs: for one reason or not the
HTML spec has been a nexus of issues
... I would like alot less process, but in html after years the
wg could not agree and move on
... for the next version I would not like to see this process
used
... just like in software the start it's a free for all..then
overtime features/changes get more scoped
paulc: the chairs didn't come
with just a stabilzation plan, it was also came with a place
for technical discussions to occur on new features
... we want to do both at the same time..
<Zakim> MikeSmith, you wanted to mention CORS
mikesmith: not all webapps stuff
is perfect
... in the WG we have people that are fundementally
oposed
... I don't know of a process that can fix this problem
plh: in CSS they struggled with CSS3 vs CSS2.1..
<rubys> mikesmith cited hybi and cors as examples
<chaals> [face to face time is helpful for webapps. There are a lot of people who have had a lot of time to talk to each other inside and outside the working group, and that is a key to such success as we have]
<janina> +1 to Chaas as a general rule
<Zakim> anne, you wanted to say this is not about new vs old
<tantek> mikesmith - hybi was hijacked by a single individual who has a known history of trolling in w3c lists.
plh: the chairs could push back to have people work together more than raising issues
<MikeSmith> tantek, that individual did not end up editing the spec
<tantek> anne: "the way things are being worked on are toxic in my opinion"
paulc: do we think we need more time on the topic?
mjs: we didn't discuss the community group
<JF> [I would like to add that "the other way" was and is seen by some groups as toxic as well]
paulc: ok we will discuss this after the coffee break
<tantek> MikeSmith - but he did make discussion on the list nearly impossible
paulc: we will meet again at
11am
... we are about 15 minutes behind the schedule overall..
<eliot> is getting a message that "the conference is restricted at this time."
<eliot> same thing. thanks for trying
<eliot> ahhhhhh
<eliot> when does break end?
<eliot> ;)
<Clarke> OK
<chaals> scribe: chaals
<eliot> thanks, MichaelC!
<MikeSmith> issue-199?
<trackbot> ISSUE-199 -- Define complete processing requirements for ARIA attributes -- open
<trackbot> ISSUE-199 -- Define complete processing requirements for ARIA attributes
mjs: This is about hooking things up to ARIA - what is required...
<MikeSmith> http://dev.w3.org/html5/status/issue-status.html#ISSUE-199
mjs: there are two proposals for this issue. Maybe we can get closer to consensus through discussion - they seem to be in the same spirit but different in technical details
michaelc: Two proposals - I submitted one, Ted submitted one. And there is a critique that Hixie submitted.
<MikeSmith> Michael Cooper's ARIA Processing proposal
michaelc: gone through them. I
think we only have a couple of technical disagreements and want
to focus on those. The rest is formality abou how we express
things in the spec rather than technical difference - it is
stil important to ensure we all nderstand the same from what
the spec says.
... First issue: should role be a single token, or a list of
tokens. In my proposal it is a list, primarily for forward
compatibility when new roles are introduced you can still use a
fallback role.
... user agent would process first value it recognises
Ted: Is this a difference?
michaelC: technical disagreement is whether there is value in setting up a list of tokens rather than a single value.
mjs: can we enumerate the issues, then go through them?
<MikeSmith> Ted O'Connor's ARIA Processing proposal
michaelC: second issue is how we
clarify the forward-compatibility model.
... think my proposal was unclear but I am not sure what would
make it more clear.
... Third: How to make it clear that the first-recognised token
gets processed. Ian had "first token", which isn't what I
meant.
... Fourth: allowing properties to be restricted where they are
not appropriate, or allow processing to determine whether they
are recognised when encoutnered.
... Fifth: Should ARIA stuff be defined in HTML, or in
ARIA.
... Sixth: What processing should be defined in HTML, what
should be defined by ARIA UA implementation guide.
Ted: nothing to add.
<richardschwerdtfe> aria ua implementation guide
rich: If you look at user agent
implementation guide...
... says how to handle mapping between aria and native
platform.
... says where aria roles override host semantics, DOM doesn't
change. UA must still map the aria roles in the accessibility
interfaces.
Ted: Which issue is this?
Rich: Did you use what was here when you defined role mapping?
Ted: in my proposal WAI ARIA role is the first non-abstract role found - think that is the same.
Rich: Reason we don't just point to the role-mapping table in the guide?
Avk: the text there is less specific.
Rich: If we put this in HTML5
spec, then change ARIA in v2, will that create a problem down
the road?
... e.g. changingthe processing rules to deal with custom
roles
AvK: Will the change be compatible
Rich: Not clear. How would we handle sub-roles available in the mac platform?
Cyns: Haven't started discussion on that
AvK: If changes are made, we change the specs.
Ted: If HTML.next changes to be less restrictive than HTML5 I don't see a problem. If you make an incompatible change, that can be a problem.
Rich: Don't think there is an issue today. But changing HTML5 is harder.
AvK: Presumably implementation
guide needs to be stable to be referenced.
... if change is incompatible you might have an adoption
problem because it would break usage.
... if user agents will change anyway, the spec can be updated
too. We have done that with eg DOM specs...
<MikeSmith> scribe: MikeSmith
chaals: key question is, some
specs are easier and faster to update than others
... HTML has shown itself to be relatively slow to update
... and to be honest ARIA has been slow also
... but ARIA will likely be updated sooner than HTML - on the
other hand, more people might read HTML...
<chaals> scribe: chaals
mjs: might make sense for role to
be in ARIA rather than host, but ARIA chose not to do that -
doesn't give a sufficeint definition of how role works. That
option has previously not been taken.
... not sure which issue we are discussing. Let's try getting
through the 6 issues listed here and add new questions.
<MikeSmith> (some context for the record) "My Formal Objection to WAI-ARIA"
rich: want to make people aware
that aria will be used in other host languages like SVG. If we
define the processing differently in different host languages
that could be problematic - might be easier to fix the issues
with definition of processing in the aria implementation
guide
... no issue with ted's text, worried about looking
forward.
mjs: First issue - should role be single token or list of tokens? Ted isn't sure we disagree.
Ted: It's a list in both proposals.
Cyns: Was Hixie's critique listing a single one?
Ted: That isn't on the table, so we don't need to discuss further
<tantek> I'd prefer it was defined similar to other tokenlists, like 'class' and 'rel' attributes.
RESOLUTION: we have lists of tokens
<tantek> we don't need a new type of tenlist
mjs: second - clarifying forward compatibility.
<tantek> btw, how can things be different in SVG? Isn't SVG just part of HTML now?
MC: Fprward compat model. You can provide multiple roles - newer better one first, followed by old one that is beter known. UA takes the first role it recognises.
<shepazu> tantek, what does that mean, functionally?
MC: think that was not clear enough in the change proposal that led ot people raising questions. Do we agree with that model, and how can we clarify?
<anne> fwiw, using RESOLUTION seems wrong, as we can't resolve anything at a F2F
Ted: Both proposals on the table are saying the same thing.
<tantek> regarding the what if 'role' was defined differently in HTML and SVG - I don't see how that's possible.
[anne, I know. But recording that at least the people at the meeting agreed on something seems helpful for finding out what happened when reading two days of minutes.]
Ted: non-abstract roles get skipped in my change proposal... otherwise I think we agree.
<shepazu> (tantek, I agree that that doesn't seem like the right way to frame it, but there are likely to be different role values for SVG than HTML)
mjs: Do you agree with ted's
characterization that we have the same model?
... (modulo clarifying that abstract roles don't get picked
up)?
<tantek> shepazu - I think it's best for web authors if the 'role' attribute in SVG works just like it does in HTML. similar to 'class' etc.
MC: Yes. This issue answer Ian's critique.
AvK: Are implementations doing processing this way?
<shepazu> (tantek, the processing and such, yes, but a graphics language needs different roles than a text language)
Rich: believe they take the first recognised non-abstract role.
mjs: So answer seems to be ",
implementations do this".
... So second issue seems to have agreement in intent. Anyone
disagree with that model?
<tantek> shepazu, I can see adding more roles - but that's up to the ARIA spec IMHO, not SVG. The abstract definition of the 'role' attribute as a holder of such values should be the same in SVG as it is in HTML.
RESOLUTION: Processing is to take the first recognised non-abstract role.
<tantek> "first"? so it's not a list not a set?
mjs: Third issue sounds like a restatement of the issue we just discussed.
<tantek> er, is 'role' a list not a set then?
<shepazu> (tantek, I agree that role should work just as in HTML)
MC: I think the first three issues I raised are addressed now.
<tantek> so 'role' is unlike 'class' and 'rel' then, which are *unordered* sets of values.
mjs: Fourth - disallowing properties where they are not appropriate, or make processing model ignore them where they are not relevant.
MC: Easier to say "all properties can be used, but they are not recognised if irrelevant". Would be a big task to take the alternative and document where they cannot be used.
Ted: There is a distinction between processing and author-conformance requirements. Would prefer leaving author confromance to aria spec to define.
mjs: Do the proposals defer this point as written?
Ted: MC proposal has text where each properties is defined and text saying where they an be used.
rich: I think HTML5 spec is clear
on where you can apply roles or not. Tried in user agent impl
guide not to do the error correct - leave it to authoring to
deal with that.
... ie if checkbox is not allowed on scrollbars, it is flagged
as non-conforming, and test tools should flag those as errors.
UA should not try to repair them.
mjs: Think this is different to
what we are discussing.
... do you mean if a role is specified that doesn't fit, and
ted/MC were discussing what happens when state/properties are
applied in cases they should not be relevant.
rich: don't want the browser to have to solve the problem where things are added in the wrong place.
ted: We are reflecting what the author wrote. It would be weird to have markup that did not get to the DOM.
CMN: THink we need to define in the processing model that erro correction does get done in the browser - and then make it clear which things get corrected where.
mjs: Not sure what the specific difference is between the proposals
Ted: nor am I
<Zakim> MichaelC, you wanted to say the reason I raise this is the HTML spec currently documents that role can't be used on certain elements, or can only be used with certain values; while
MC: Do we want to document the intersection and specify it, or point to the two sets of rules and tell implementors to figure it out?
mjs: Is there a part of the proposal that addresses this question?
MC: My proposal doesn't address that question. I think failure to address it led to concern - don't know if they wanted more or less...
mjs: MC is suggesting we may want to define something that neither proposal does. That isn't a point of difference, it is a separate question to be decided.
Ted: sure
[general agreement that we aren't facing a disagreement to resolve]
mjs: Should aria 'stuff' be defined in HTML or in ARIA specs?
MC: In my proposal I defined all
state and property attributes. Concern was that redefining
these in HTML leadas to duplication -> error. This is
auto-generated so should be possible to keep in synch. Agree
that duplication is potentially problematic.
... Did it because I think HTML needs to be clear what is
happening. Countr-proposal was where math/svg in HTML just
defers to those specs.
... difference is that ARIA doesn't have a root element to
anchor the definition from. But that might not matter - should
it be removed?
Ted: Think the ARIA documents
define what the properties mean and how to use them.
duplicating that is a potential source of synchronisation error
later - and at minimum introduces a maintenance cost that I
don't thnk we need to incur.
... you already have to read the referenced specs to implenent
HTML so not sure what is different here.
<mjs> ach richardschwerdtfe
rich: THink the ARIA spec should
define values for role, state, property. We also have to
address other host languages. So I agree with Ted.
... anything we do needs to be coordinated anyway with other
hosts.
<tantek> shouldn't defining 'role' be similar to the definition for the 'style' attribute between HTML and the CSS 'style' attribute spec?
rich: HTML should define restrictions it makes specifically to HTML, if necessary.
<tantek> http://www.w3.org/TR/css-style-attr/
<tantek> Thanks chaals - I was hoping we were saying similar things but I wasn't sure.
<tantek> and I wanted to provide a concrete existing example (perhaps to mimic)
shepazu: What do people think would be different between svg and html in hosting aria. SVG does not want to redefine processing or rules from ARIA if we can get away with it. There are different roles required, but don't think there would be a difference in processing.
<Zakim> MichaelC, you wanted to say I was also concerned about impacts of the two technologies evolving on different timelines; that was discussed earlier today but couldn't follow well
rich: Think we are in violent agreement.
MC: Not sure what it means for HTML5 conformance if ARIA evolves on a different timeline. Whatever direction we go seems OK though.
mjs: Seems general sense of the room is to delegate the definitions to ARIA by reference, rather than copy them in.
<tantek> for the HTML5 definition of the 'style' attribute see: http://www.w3.org/TR/html5/global-attributes.html#the-style-attribute which links to http://www.w3.org/TR/css-style-attr/ for what goes into the attribute (complete syntax of it).
RESOLUTION: leave the definitions in the ARIA spec and reference them from HTML
<tantek> perhaps entire syntax of 'role' attribute must be defined in the ARIA spec, and have it defined by reference in HTML5.
mjs: What processing should be defined in HTML, what should be defined by ARIA?
<anne> tantek: as long as they use the same definition of space characters
<tantek> anne - agreed
MC: Intended to provide informative explanation of what is define in user agent guide, but reference that for normative requirement. I think that was confusing.
<tantek> anne - is there any such issue of space characters in CSS style attr?
MC: how much should be included even if only in an informative manner (if any).
<anne> tantek: no because that takes CSS
Ted: Proposal defines processing for role, because it wasn't available directly from ARIA. For same reason as before, I would rather have this defined in ARIA spec.
[no further comment]
<tantek> anne, if ARIA normatively references HTML for definition of space characters, would that be sufficient?
mjs: If proposals are aligned,
except where ted did it different consensus follows ted, it
sounds like you guys could align a single proposal.
... MC, Ted, can you do that?
Ted: Sure...
<anne> tantek: it's fine if they copy it
<scribe> ACTION: Ted to outline a timeline for producing an aligned change proposal to address ISSUEE-199. Due in 2 weeks [recorded in http://www.w3.org/2012/05/03-html-wg-minutes.html#action01]
<trackbot> Sorry, couldn't find user - Ted
<tantek> ok - I just figure by reference would have less chance of drift over time.
<anne> tantek: but I guess you really want to reuse the definition of space-separated attribute values (forgot the name of that)
[adjourned for lunch: 1 hour]
<tantek> also by reference avoids temptation to tweak the definition for "editorial" reasons which end up being functional.
<tantek> anne - right
trackbot, who is hober?
<trackbot> Sorry, chaals, I don't understand 'trackbot, who is hober?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
<Clarke> If I drop the phone, will I be able to reconnect after lunch?
<plh> yes, you should be
<eliot> what are you doing?
<eliot> lunch?
<plh> yes
<eliot> ok
trackbot, status?
<odinho> s/yes, you should be//
<odinho> s/what are you doing?//
<odinho> s/lunch?//
<timeless> Scribe: Josh_Soref
<timeless> scribenick: timeless
frankolivier: we have two
proposals
... very close
... if we combine the two
... i think we'll have something that solves one of the
accessibility proposals for <canvas>
... in both proposals, there's something about defining a
path
... in one it's an element in the canvas
... in the other, it could be in the DOM, or a lightweight
object
... the other spec text
... that's been proposed for <canvas>
... don't solve accessibility issues
... i'd like to address them later
hober: it's true that the spec
changes in my proposal cover more UCs than just accessibility
needs
... in this case
... that's a good thing
... the accessibility requirements can be addressed with
requirements that can be used for other things as well
richardschwerdtfe: hober, can you walk us through the proposed changes?
hober: sure, let me pull up the diffs
<anne> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035239.html
s|http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035239.html|-> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035239.html Canvas v5 API additions|
hober: the proposed changes
... allow drawing elipses
... paths
... text alignment paths
... and define a cursor
... for each accessible region
<scribe> ... new text metrics
UNKNOWN_SPEAKER: Hixie's email covers more changes than in my proposal
richardschwerdtfe: there was this
measure-text piece
... how does that fit in?
hober: you are using this for
canvas control
... for some complex effect
... and have something corresponding to a label
... being able to make the area around that text
clickable
... easily requires metrics access
richardschwerdtfe: so it's for the purpose of calculating the text region
frankolivier: are there two
separate issues
... 1. UI controls
... 2. defining text
anne: with text metrics, there's
already api
... these are additions
... for graphics applications, since you don't always know
which font is going to be used
... some things will need that information
richardschwerdtfe: so this is more than just hit-testing
anne: Hixie looked at
<canvas> feedback over the last 3 years
... and added all the things that people were requesting with
good use cases
richardschwerdtfe: when we add
hit region
... there's additional parameters that were added
... tied to lightweight JSON objects
... for accessibility
... if you have these things, i need to have a test tool
... analyzing for accessibility find this
... and it needs to be mappable to the api
hober: for accessibility
... you'd listen for the API call
richardschwerdtfe: these are
browser plugins that do this
... how do you overload this?
anne: in JS you can overload
anything
... and a browser extension can do this
richardschwerdtfe: these things
are lightweight
... and they might belong to the DOM?
hober: there are two things
... elements themselves
... or a description of a javascript object
... in terms of wiring up to the Accessibility Tree
... that could be done by the UA
... if one hit region is contained in another
... that could get complicated
richardschwerdtfe: how do you make those elements keyboard navigable?
anne: the browser does that
... hit regions would be added to focus order
richardschwerdtfe: it's not just fully defined then?
hober: i'm sure the editor would like to hear
richardschwerdtfe: these elements
are not in the DOM?
... they can't take properties
... like Role/Label
hober: not if they need aria-properties
cyns: can you help me understand the value of these?
hober: it's difficult to
discretely identify
... suppose you have a <canvas>
... emulating a Pitri dish
... clicking on the Canvas drops a complex reagent
... there might not a be a point on the canvas corresponding to
a discrete object
... you might want hit regions
... but it would be difficult to describe in a dom tree
... saying "that's a div'ish thing"
... "now there's two blobs"
... the reason we use it, is because there isn't a better
option
cyns: let's treat div as a
rectangle
... it seems like you could have divs that transcribe the
areas
... why are these JSON objects better?
hober: they're much smaller
... let's say you had a 2000x2000 canvas
... using 2000 * 2000 div elements
... would be bad
... it isn't reasonable to ask them to use the dom
... why use the canvas?
cyns: most people seem to be using it because it's trendy
hober: frankolivier had a great
example
... using a distinct canvas object per word in a string of
text
... our answer should be "don't do that"
frankolivier: tying every
accessible object onto the dom is going to be very
expensive
... is that the more common or the less common?
hober: fortunately, this proposal
addresses both
... i don't know, let's find out
anne: if you have an element based thing, you should use svg
frankolivier: tying those
elements to a dot is a bit much
... but there will be more examples of tying to a checkbox
hober: i'm not particularly interested in counting
mjs: there's another purpose to
lightweight hit regions
... you could associate multiple hit regions to a single
element and distinguish between them
... similar to a ComboBox
... this is supported by AddHitRegion
... but not supported by the other proposal
frankolivier: i think we agree on
needing to solve this problem
... i don't think we see a big problem to lightweight
elements
... i think it'd be good to combine the change proposals
hober: does my proposal not address everything
frankolivier: i think keyboard
navigation, or overlapping hit regions
... but if you combine the two...
hober: can we take that offline and do that
richardschwerdtfe: where in the
proposal do you address clearing
... paths
... talking w/ Devs @ SXSW
... they need to be able to remove them
richardschwerdtfe: it describes
the process
... is there a method that does it?
hober: addHitRegion -- step 18
richardschwerdtfe: addHitRegion, clearRect are the "3 ways"?
hober: off by one error
richardschwerdtfe: you put a new
path
... you can put an empty path to remove it?
frankolivier: how do you store the hit regions?
hober: there's a concept of a hit region list
richardschwerdtfe: lightweight
paths
... do you have text associated with the objects?
hober: just role and label
richardschwerdtfe: is the label rendered?
hober: no
shepazu: it's like alt
... any visible rendered text
... would still be rendered through the "text api"
frankolivier: what about ATs that go to the DOM itself?
s/frankolivier/richardschwerdtfe/
scribe: for Firefox, AAs go to
the AT tree
... but for IE to be backwards compat, they go to the DOM
s/ATs/AAs/
frankolivier: we might have to
tell the AAs to go to the AT
... do you have concern about aria roles for lightweight
objects?
richardschwerdtfe: i'm concerned
that we can't put other properties beside label
... if we start working on SVG
... and we start introducing new properties pertinent to
graphics
... a drawing is a drawing
hober: this proposal allows you to use the DOM elements
richardschwerdtfe: why don't we add that capability when we merge it?
mjs: in the whatwg spec
... HitRegion takes a dictionary
... so you could add more properties
richardschwerdtfe: aside from
ellipses, text, and paths
... does anyone want to talk about them?
hober: there have been many
changes relevant to the canvas part of the spec
... the revisions in my detailed proposal
... are limited to this
paulc: they were added in the
same week
... but there was a distinct dividing line
frankolivier: i think it would be worthwhile to focus on the Accessibility features first
sam: it sounds like everyone
agrees
... i haven't heard objections
paulc: i can find you another room
frankolivier: i can suggest edits to the other change proposal
hober: just go change it
richardschwerdtfe: i can work w/ frankolivier on it next week
sam: hober can watch it
... and work on it in his spare time
... are we done with this topic, for now, at least?
[ RESOLVED ]
trackbot, issue-194?
<trackbot> Sorry, timeless, I don't understand 'trackbot, issue-194?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
issue-194?
<trackbot> ISSUE-194 -- Provide a mechanism for associating a full transcript with an audio or video element. -- open
<trackbot> http://www.w3.org/html/wg/tracker/issues/194
issue-183?
<trackbot> ISSUE-183 -- Enhance and simplify the time element -- open
<trackbot> http://www.w3.org/html/wg/tracker/issues/183
issue-184?
<trackbot> ISSUE-184 -- Add a data element -- open
<trackbot> http://www.w3.org/html/wg/tracker/issues/184
sam: i know tantek wanted time
for time+data
... any other interest
adrianba: you, tantek, were
proposing rather than a specific topic of time+data
... but "how do we decide when we work on a new element?"
tantek_: it might be useful to
split the discussion into two pieces
... time+data
... and then methodology for HTML.next
... if that's acceptable
adrianba: either way works
i/i know tantek/Topic: Time and Data element/
tantek_: this is a follow
on
... for an online discussion
... it came up @TPAC
... we reached a consensus in the room
... which was fairly solid
... and then we made progresssome made their way through
s/progresssome made their way through/progress/
scribe: some made their way
through
... and some are working their way through
... the counter proposal to drop the time element
... and instead enhance the data element with a time
attribute
... which i think is harder to use
sam: i thought there was a CfC to accept the time element
tantek_: there was, and it was accepted
sam: there was a counter proposal
to add to data
... but it didn't have sufficient justification put
forward
... and i haven't seen that
tantek_: ok
... i'd like to propose, as a way of moving forward
... is that the group decide that adding the time-type to data
is a new feature
... and we don't add it to html5
sam: i'm reticent to make a
decision today in this room
... STRAW PROPOSAL
... is that if there was a type= attribute added to the
<data> element, it would be done post HTML5
... STRAW POLL: is there anyone in the room who would object to
that?
paulc: typically, when you design
something like this
... what's the default value
... in the case you don't have the attribute and it doesn't
occur
... what's the equivalent without a value?
mjs: i don't think the proposal makes it clear
paulc: looking into the
future
... what would it do if it's optional
mjs: i'm saying the person isn't in the room
sam: if this type attribute were
added and no one in the room is advocating
... how would we address it?
... i understand your point
... people who propose such things should define such
things
... we as cochairs did indicate it was deficient
... i don't believe we've timed it out yet
s/your/your, paulc's,/
paulc: you sent your proposal on the 18th
sam: we accepted tantek_'s
proposal for data + time
... there are remaining sub proposals that haven't made
coherent arguments
tantek_: i'm claiming the proposals are feature additions that we can postpone
paulc: the change proposal was
Mar 27
... "enhance the data element with a type system
proposal"
... this hasn't been touched since Feb 9
sam: in that case, we should mark
as defered
... it looks like it's quite likely we have consensus on 183
and 184
tantek_: and the broader discussion we can have in HTML.next
sam: we're missing a participant on 194
cyns: i haven't reached him
JF: we'd like to get Shawn Hayes,
Microsoft, to dial in to join us
... if we postpone to tomorrow
paulc: where's he based?
JF: UK
<adrianba> s/Shawn/Sean/
paulc: so proposing to do this
now was a bad idea
... we should do this @9am tomorrow
eric_carlson: I won't be here tomorrow
tantek_: on the previous subject
ISSUE-185?
<trackbot> ISSUE-185 -- Drop the pubdate attribute -- open
<trackbot> http://www.w3.org/html/wg/tracker/issues/185
tantek_: ... drop the pubdata
attribute
... the summary of the proposal
... is we can drop pubdata
s/pubdata/pubdate/
scribe: because it lacks
nontrivial use outside of hatom usage
... which provides a superset of the functionality
<paulc> http://lists.w3.org/Archives/Public/public-html/2012Mar/0738.html
i/previous subject/Topic: Pubdate/
paulc: you, sam, on tantek_ 's proposal
tantek_: wordpress templates use in hatom
sam: it's not in dispute that
it's used
... we could update the change proposal and say it's
defficient
... or do a survey
... if you point out that
... it's not in dispute that it's in use
... but it's in dispute that it's necessary
tantek_: the other proposal is to
add a MODDATE attribute
... and i claim that's a new feature and say that's for
HTML.next
sam: all valid things to put in a
survey
... so if it becomes a formal objection, we can point to the
survey
... "everyone had an opportunity to comment"
paulc: i'm suggesting that the
chair's review of the revised change proposal
... will ask you to review that additional change
proposal
... if we get that out of the way, it's very likely that if the
review doesn't turn up anything else
... we can go to survey ASAP
ISSUE-194?
<trackbot> ISSUE-194 -- Provide a mechanism for associating a full transcript with an audio or video element. -- open
<trackbot> http://www.w3.org/html/wg/tracker/issues/194
paulc: JF sent a link
... and there was a request for a change proposal update
<paulc> Review of ISSUE-194: As such, we will not accept the @transcript proposal until it is updated to contain a set of edit instructions, specific enough that they can be applied without ambiguity, and contains answers to the questions posed in the counter change proposal.
JF: I have not done that
... we require a programmatic means of finding an associable
element
... one is an attribute
... the other is a no change proposal
<paulc> http://dev.w3.org/html5/status/issue-status.html#ISSUE-194
JF: the other proposal is to
defer to HTML.next
... that's a bit of a non-starter
... it leaves a gaping hole from the Accessibility
perspective
... hober had done a review of a couple of different
patterns
... we looked at the patterns and found a couple that were
viable/workable for us
... if we could talk them through/find a common ground
... i'd rather get the engineers involved a little more
<paulc> John: Could we look at the patterns in http://www.w3.org/html/wg/wiki/ISSUE-194/NoChange and discuss if there is a solution we can agree on.
janina: ...
[ Break ]
<eliot> thank you
<tantek_> rubys, paulc, othermaciej, as requested, I've updated my change proposal for issue 185 - http://www.w3.org/wiki/User:Tantekelik/drop_pubdate - to rebut "keep pubdate / add moddate".
<glenn> ISSUE-194?
<trackbot> ISSUE-194 -- Provide a mechanism for associating a full transcript with an audio or video element. -- open
<trackbot> http://www.w3.org/html/wg/tracker/issues/194
<glenn> go ahead
JF: hober did a good review of different patterns
s/go ahead//
scribe: and the accessibility TF
looked through it
... and was thrilled
... a half dozen or so that would meet our User
Requirements
<paulc> Alternatives in http://www.w3.org/html/wg/wiki/ISSUE-194/NoChange
scribe: the one we're leaning toward
<hober> research in http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194/Research
scribe: is the <track>
element
... an untimed file
... there were a couple of others
... using an indirect transcript reference
... or reuse the for/rel attributes
sam: if you've got your preference, let's start with that one
JF: the preference is to reuse
the <track> element
... it can be used for CC and subtitles
... and subtitles in multiple languages
... although to my knowledge we don't have an implementation
now
... that would produce a menu to choose a caption they
want
... so the user would be in control
<hober> http://www.w3.org/html/wg/wiki/ISSUE-194/Research
JF: adding a transcript in the
menu items would be an elegant UI pattern
... there's been a concern that there's been a concern that it
abuses the semantics of track
... the idea is do we add an attribute to <video> or a
child element
... an attribute on video would be easier to do
... do we introduce an attribute or do we reuse something
... i don't want to go into CR with this hole
... at some point there will be regulatory requirements
... with why did you miss this?
... when we captured user requirements
sam: a viable answer is "HTML5
has a bunch of holes"
... it sounds like you're saying there are several
... i'd like you to narrow it down to one
eric_carlson: <track> right
now is used to provide
... time stamped text to the video element
... a transcript isn't time aligned at all
... it would change the semantics
... i don't think that method would have advantages over an
attribute
hober: the fallback story for
<track>
... is particularly bad in a UA that doesn't support
<video> or <track transcript>
... using a track= to point out an <element. on the page
s/<element./<element>/
eric_carlson: every shipping browser on the planet
hober: we've provided a fallback for every new feature
cyns: there are a couple of
reasons i like track better
... having an attribute that points to another place on the
page
... is the discussion we had about longdesc=
... having an attribute like longdesc
anne: how is <track> different from longdesc=
cyns: no
... you have a track
... all interchangable
anne: i don't see the difference
cyns: you're not saying this url
goes to this image
... you're saying these things are interchangable
... <source> is a child element
anne: there's also a src= attribute
cyns: it seems e
anne: <track> is the same as longdesc=
cyns: child elements are easier
to understand
... this one is special, why?
BobLund: when you consider
... out of band tracks
... there's a similarity between out of band attributes
... and in band tracks
... i don't think in band tracks work very well
<hober> We're looking Option 4A "reuse the <track> element" v. Option 2B "mint an indirect transcript attribute which takes many IDREFs"
BobLund: i don't think an author
wants the transcript available
... i don't think <track> works very well for inband
tracks
... <track> works fine for inband tracks
... but transcript= would work better for the inband transcript
case
... if i have an mpeg4 file
BobLund: it isn't likely i'd have the transcript internal to the resource
<hober> http://www.w3.org/html/wg/wiki/ISSUE-194/Research#4A_-_reuse_the_track_element
cyns: and the <track> element allows for
BobLund: not for inband
tracks
... you don't have individual urls to the component tracks
cyns: can't you have mixed?
janina: can't you have inband subtiles
s/subtiles/subtitles/
scribe: and out of band
mark: that works
glenn: timed text
... VTML
... has a role= attribute
... defining arbitrary values
... and one of the values is Transcription
... and you as an author can choose what you're timing
... if you're timing
<yosuke> s/VTML/TTML/
JF: so you could put your
Transcript into TTML
... with no timing
janina: even if there's no timing
glenn: yes
... you have control over granularity
... about 10 different levels
... mapping to EI608/708
... roles
... you might take a look at that
sam: does that require no change to html5?
JF: we'd have to put in a proposal to do a
eric_carlson: the Spec text assume the contents of the file are associated with timestamps
glenn: I think that Text refers to VTT
frankolivier: no
hober: it does require the format to be timed
glenn: but the timing could be the entired time
eric_carlson: if you wanted to present the entire text at the initial time
sam: so, some spec work to be
done
... glenn is willing to parcipate?
s/parcipate/participate/
glenn: no
anne: I don't think it's going to
work
... most browsers aren't going to implement TTML
glenn: it's a safe harbor format
eric_carlson: ... for content delivery providers
mjs: i think we're reaching topics where people wouldn't like to speak without attorneys present
cyns: we don't have enough brownies for the lawyers
eric_carlson: i could see
... i'm still not convinced that it makes sense to make sense
to change the semantics of <track>
... i think it could work to use an attribute on the media
element
... with ID refs
hober: that design as many advantages
<Zakim> chaals, you wanted to say asking web designers to add a link somewhere and a pointer to it is a horrid design approach - and that track, apart from being an element instead of
chaals: it has many technical
advantages
... but you have to get the URLs into the page
... the drawback is that you need to get URLs to do that
... it's a horrible design pattern for a document
... pointing to urls is analogous to longdesc=
... there are differences
... but
sam: 'it'/'that'?
chaals: it= "The IDref
pattern"
... the thing about track
<krisk> * ping test
chaals: it may change the semantics
s/* ping test//
scribe: a zero timing
... it doesn't seem to be a semantic shift
... getting everything in one pile
... i don't see why that's a problem
... you cross out 'timing' in the spec
... you say "that may be timed"
... most of them will be timed
... someone of them might not
... that argument doesn't seem like a meaningful
distinction
... "the spec says it's timed, and that means it must have at
least two time points"
... that doesn't seem to be a reasonable requirement
... cyns 's suggestion that it be a <track> seems
reasonable
... "except for the one that doesn't have timing"
... seems to not make sense
mjs: i can't remember when i
added myself to this queue
... timed v. untimed
... is an important distinction for media
... for synchronizing timelines
... the <video> element does have support for pointing to
one untimed element
... the poster image
... it's associated with the video element
... but it doesn't need to be synchronized
... second
... a distinction between <track> and IDref
... chaals mentioned one
<chaals> s/synchronized/synchronized and is an attribute/
mjs: IDref forces the designer to
include something visible
... it makes something visible
... but it isn't necessarily true
... you could have a video
... and then a link to a transcript
... if i don't have half an hour to watch something
... i'd often like to read through the transcrpit
s/transcrpit/transcript/
scribe: it seems to be more
successful
... than linking to a visible way
[scribe-garbled-mjs]
mjs: IDref also accounts for
having things visible in the page
... you want to programmatically associate that
... i think people should keep this in mind
... that's more salient than the logical meaning of the
<track> element
frankolivier: 2 questions
... is there a requirement to link multiple transcripts to a
video or just one
<plh> example of a page with a video that links to a transcript
JF: the requirement isn't that
specific
... we could need one or more
hober: both proposals support multiple
frankolivier: what's the difference between transcripts and a timed text file?
JF: traditionally a transcript
captures more than just the dialog
... it's sort of an amalgamation of CC and Descriptive
Text
... it's almost like a Book
... it's an alt-ernative presentation
cyns: think of it as a Script for a Play
janina: it might also have timing data
<plh> transcript that spells out text display in the video
cyns: I could live with either
attribute or <track>
... getting developers to understand and live with this
... poster= seems like a different thing
... it isn't a description of the whole content of the
video
... <track> comprise the content of the entire
<video>
... and so does <transcript>
hober: requiring developers to do
any of this at all
... it makes sense to piggyback on what they're doing
... people are adding links in prose
... IDrefs is pixydust to link up existing videos with existing
content
... in terms of encouraging author adoption, "keep doing what
you're doing"
cyns: in the short term, that
will be true
... but in the long term, when they're adding tracks to
videos
... why would that be true?
richardschwerdtfe: why are you forcing developers to force the full transcript on this page?
<Mark_Vic_> If a transcript can having timing info, how is it then different than a caption text track?
hober: an IDref could point to an <a> linking off the page
[ chaals waves hand ]
richardschwerdtfe: why make person put another link on the page
hober: people already put links
in the page
... one of those links will bitrot faster than the other
... visible link v. link in video
richardschwerdtfe: show a visual
indicator
... transcript attribute
... UA vendor shows that
hober: any method allows that
richardschwerdtfe: why make the author put the link on the page
hober: we're paving cowpaths
cyns: we're doing that because we asked them to do that
sam: i'd like to flush the queue
<Zakim> Josh_Soref, you wanted to say that you want non Accessible requiring users to review transcripts
Josh_Soref: If there's a CC or
Transcript available
... I, as a non accessibility needing user am likely to try to
use it
... and like it
... but if it doesn't work, I will complain
... I and people like me (mjs)
... and we will help clean the cowpaths
JF: sam you asked about
options
... I'm happy to only look at two options
... and to discard the others
sam: ok
JF: points...
... cyns mentioned the authoring pattern
... there's an assumption of people authoring content using a
text editor
... many people create content using WYSIWYG editors
... the Dialog comes up
... for a video
... and you click on files
... the pattern for linking for a <video>
... seems very simple
... if you add an IDref
... that seems more cumbersome
... we've talked about C+P
... everything remains self contained
... if you copy an IDref
... but not that ref'd content
... then you lose that
... when you paste
... nothing precludes an author from adding a transcript as a
<track> kind
... and later including an <a href>
... and you don't put the <a href>, we still have the
reference
janina: 2 points around UCs
... mjs 's point of accessibility
... you just want to read the transcript
... we really want to solve this now
... and not HTML.next
... the curb-cut effect
... i'm not hearing when talking about IDref
... sometimes untimed, and sometimes also timed
... maybe TTML covers that
... i don't know how you cover that
JF: TTML is a timestamping format
sam: is it IDref or <track>
cyns: it's a possible src= for a <track>
JF: if the desire to preserve the
timing notion of track
... then make the <track> a full length
richardschwerdtfe: we spent a lot
of time looking at this
... we need a visual association with this thing
hober: you'd get a visual association
richardschwerdtfe: you'd have a
link somewhere else in the page
... and you assume the person doing this relative to the
video
... basically take transcript
... and put the visual indicator next to the video
... what we're doing for Described Video
... this is what we're looking at
... put an icon of your choice
... I see no reason for another link to be on the page
sam: you prefer <track>, ok
cyns: I agree w/ Josh_Soref,
mjs
... about wanting to have access to that
... i don't think it should be something to be responsible
for
... i think an IDref and a link is two things for an author to
make a mistake
... and I agree with JF about C+P
... more ways to mess up
... same way I don't like the longdesc= replacement
proposals
mjs: some transcripts may not
just be a flat text transcript of the video
... possibly a machine readable timing
... possibly including captions and descriptive text
... it seems those are different things
... sometimes you want a transcript of the video
... and sometimes you want an HTML file
... other times you want it to be timed with the video
... in some cases you want it timed
... for timed w. the video v. flat
... it may not be the same UC
... and maybe we're doing a disservice
JF: mjs, i don't disagree with
you
... and it may be a PDF or a DOC
sam: ouch
JF: i'd prefer HTML
... putting that aside
... the reason we're saying TTML
... if there's a huge desire not to pollute the purity of
<track>
... we can make the guidance
... "make it TTML"
... chaals mentioned that semantic purity isn't a huge
advantage
... we've got this stuff that augments, supplements, or
replaces for disabled people
... we're just looking for an elegant way of doing that
... <track> is an elegant way of doing that
mjs: a TTML file isn't something
you could link to in a browser
... all transcripts linked today would not work if they were
TTML
... so that seems like a downside
chaals: that's also true of
VTT
... and various other formats
... in practice, they damn well read them
... it's not pretty, but it's a transcript, that's readable,
and it's a step forward
... occasionally, they put them in the web page
richardschwerdtfe: can <video> controllers handle <track>s with no timings ?
cyns: you just put full length for it
hober: i saw this when i prepared
the wiki page
... i encourage people to read it
... i came up with a list
... between these two
<JF> hober's research page: http://www.w3.org/html/wg/wiki/ISSUE-194/Research#2B_-_mint_an_indirect_transcript_attribute_which_takes_many_IDREFs
hober: they each fulfill
some
... fail to fulfill others
... the attribute with IDrefs did come out on top in terms of
requirements
... we could walk through that
s|hober's research page: http://www.w3.org/html/wg/wiki/ISSUE-194/Research#2B_-_mint_an_indirect_transcript_attribute_which_takes_many_IDREFs|-> http://www.w3.org/html/wg/wiki/ISSUE-194/Research#2B_-_mint_an_indirect_transcript_attribute_which_takes_many_IDREFs hober's research page|
BobLund: how would transcript work with continuous media?
eric_carlson: how would anything work with continuous?
BobLund: with <track> you could produce something
janina: we have UCs for both experiences
eric_carlson: unless you have timestamps, that won't help you much
BobLund: right, you'd have to have timestamps
eric_carlson: in the same
way
... it's a url to a resource on a server
... it doesn't make a difference where the url is on the
server
... it doesn't make any difference
sam: we started with two change
proposals
... one which said defer
... now we have two more concrete proposals
... we can't hold HTML5 forever
... are people committed to writing down the <track> and
IDref ones?
... if people are willing to do both, we're going to
survey
... if they don't, the one that goes, will be the one that will
win
JF: I'm happy to propose
<track>
... but it's fast and loose with your timeline
hober: will you withdraw your existing proposal?
JF: i'm likely to
sam: we'd ask you to update
JF: updating would be a rewrite
paulc: this conversation started
with an assertion that we can't finish HTML5 without this
feature
... Web+TV IG came to us with a whole bunch of Addon proposals
for HTML5
... can this be an addon for html5?
... does it have to be on our critical path?i
issue-204?
<trackbot> ISSUE-204 -- Exempt ARIA attributes from the rule that prohibits reference to hidden elements -- open
<trackbot> http://www.w3.org/html/wg/tracker/issues/204
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
s/path?i/path?/
scribe: this could be the long
pole for getting out of LC
... i'm not saying is it important
... i'm saying could it be a separate spec
sam: our motivation is to exit LC
JF: i can't answer that
question
... part of the problem
... is that this issue will be muddied by compliance
issues
... that are not technical
... to get HTML5 past CR would be blocked
paulc: CR is where W3C calls for
Implementations
... nothing about quality or completeness
... it's just asking implementers "can you implement"
... "can a third party, not in the working group use the spec
to drive implementation"
... a feature missing doesn't hurt that
chaals: when HTML5 goes to
PR
... if this feature isn't terribly complicated
... and a number of members are asked to vote for it
... you'll find a number of members of W3C that are fairly
upset
... the answer to "can you put it in a separate spec"
... is "sure you can"
... is it an elegant solution?
... no
... it's an ugly solution, it will probably solve the
problem
... it would be nice to avoid going there
sam: it's my opinion that the
question isn't whether it's complicated
... it's whether it's controversial
... link to a link isn't about hard to implement
... it's hard to get users to do
... it's a matter of whether it's controversial
... would you hold up HTML5 for your pet feature
... or do you want to get HTML5 out?
... we're closing out features for HTML5
... but we're close
... I want hard dates
JF: you want it by next
friday?
... i'll get it to you by next friday
ACTION JF to deliver a proposal by next friday
<trackbot> Sorry, couldn't find user - JF
ACTION sam to get JF to deliver a proposal by next friday
<trackbot> Created ACTION-210 - Get JF to deliver a proposal by next friday [on Sam Ruby - due 2012-05-10].
JF: i'll commit to next friday
sam: it sounds like given a choice between <track> and IDref would like to write a proposal for IDref?
hober: I'm happy to write up
IDref
... but i'm not withdrawing proposal to defer
ACTION hober to write up a video-transcript IDref proposal by next friday
<trackbot> Sorry, couldn't find user - hober
ACTION sam to get hober to write up a video-transcript IDref proposal by next friday
<trackbot> Created ACTION-211 - Get hober to write up a video-transcript IDref proposal by next friday [on Sam Ruby - due 2012-05-10].
paulc: hober, you're now signed up for 3 items
ISSUE-199?
<trackbot> ISSUE-199 -- Define complete processing requirements for ARIA attributes -- open
<trackbot> http://www.w3.org/html/wg/tracker/issues/199
paulc: I recognize you have a commitment to CSS-WG
ISSUE-201?
<trackbot> ISSUE-201 -- Provide canvas location and hit testing capability to fallback content -- open
<trackbot> http://www.w3.org/html/wg/tracker/issues/201
paulc: maybe offline you should work with the chairs
sam: is it about extracting this portion from the wiki
hober: it's not new work
eric_carlson: you might be able to talk me into helping
mjs: seems like if the research
is done
... someone could copy it
sam: a proposal could have people
throw darts at
... and that's the discussion i'd rather have
<Zakim> tantek__, you wanted to note that microformats have been adopted just fine as additional separate specifications to HTML4/HTML5.
tantek__: experience has shown
separate specs can do just fine
... multiple specs, ranging from a single attribute, to
multiple attributes
... that have been adopted just fine
... based on the component nature of the web
... and a broader trend in w3c of modularizing
... you need folks who can do it well
chaals: i didn't mean to say it wasn't possible
tantek__: you said it was
ugly
... and i'm saying there's data that disputes
... HTML5 is a huge spec
... if something CAN be done, it SHOULD be done
... not even MAY be done
sam: ultimately, that's a 4th proposal
<adrianba> +1 to everything tantek just said
sam: saying "someone else SHOULD
do something" isn't going to fly
... it's a viable .next discussion
... unless someone proposes doing that for HTML5
tantek__: i didn't propose
that
... just to dispute chaals
richardschwerdtfe: to hober
... i'm concerned about IDref
... could you make it a url?
hober: when i did the
research
... i considered lots of designs
... i think URL is worse than IDref in a variety of ways
richardschwerdtfe: i haven't seen your justification
hober: go look at it
... i believe it's 1A on the wiki page
<hober> http://www.w3.org/html/wg/wiki/ISSUE-194/Research
[ hober describes 1A which is projected on the screen ]
janina: Links doesn't know video
chaals: there's a time
hober: i've only pressed play,
pause, scrubbers
... i might not know what all those things mean
... but text that says "transcript"
<tantek__> video element was designed with fallback / existing UAs in mind.
JF: hober, you were saying
... controls
... one question i'd ask you
... you'd hit play/pause/stop
... and the rest would be "unlearnable"?
... if you saw a button in a video player that had [CC]
... you'd quickly learn what those did
... one observation we're seeing
... is that people script their own controls
... the fact that we're having programmatic
... controls that they can associate
... works
... it goes to the point that
... moving forward
... if there was a consistent way that controls could expose a
button
... or an equivalent features
s/features/feature/
<chaals> s/there's a time/the argument about back-compat is not untrue. But paving that cowpath is like implementing video by having an a href link to the video and then importing it because existing browsers didn't support <video> elements. There is a time to work on adding functionality./
scribe: if there was a control
panel that had a consistent behavior
... that would make the requirement for a text link
... to be embedded in the document to be less important
... there's this week, next month, 3 years from now
... i appreciate we may not have it all today, next month, or
by the end of 2012
... but the train keeps rolling
... yes you want to pave cowpaths
... but sometimes you want to steer cows in the right
directoin
s/directoin/direction/
glenn: it's a lot harder to get
things in once you've gone to CR
... you can mark things as AT RISK
... but getting something in later is harder
richardschwerdtfe: it seems
like
... we're sacrificing usability of the page
... just so we can support older browsers
... looking at the justification that hober had
... for not using a url
... it's just for backwards compat
... by the time <video> is done
... probably a year or two out
... why would we do that
... we had the same discussion with <canvas>
... we found they were supporting this on mobile devices
ddorwin: David Dorwin
... there was a link, or display alongside the page
... or timed
... maybe it's listed
... what are the desired requirements that a browser would
do?
... should the browser be able display this as a window next to
the page?
... a point about reference is maybe that links you
... if we want to keep these together
... today you could do this with <track> as timed or
not
... but it would require JS
... it should be easy
... and that might affect the design
richardschwerdtfe: UAs can detect
the browser that made the request
... i don't see the need to have this fallback
ddorwin: it wasn't a
response
... just a general input
... if you wanted to correlate in some way
richardschwerdtfe: i would much
rather have the browser say look
... what's the best usable experience?
... an indication that there's a transcript
... and provide the ability to view it
... a separate window, in the same context, i don't know
... there are so many differences between IE7 and today's
browsers
... i don't see the point in going back to support them
... i'd rather get them to move to IE10 or the latest
Chrome
janina: i was going to suggest on
the same lines
... the media elements are some of the most persuasive reasons
to get users to update their browsers
... even before we start designing really good interfaces
... thinking about railroad gauge being the way they are --
roman chariots
... and here's why the reason to do it is a good idea
... protecting the past. the past disappears fairly quickly
mjs: has anyone here heard from a content author unwilling to add a visible transcript link?
chaals: i've never asked
... but as anne said
... this is the same stylistic design decision about
longdesc=
... boatloads of designers unwilling to do it
cyns: i haven't had examples of
refusing
... but when i talk about it
... i get pushback
... two hours of complaining
mjs: if they had to do a custom video control
cyns: i'm not encountering custom
JF: we're looking to browsers to add it
mjs: majority of <video> on the web is using custom control
JF: if they have Transcripts, and
are using custom control, they'll build it
... the native controls will build it
mjs: clicking on a link below a
video doesn't seem like a bad UE
... there are people asserting it would be
cyns: i'm asserting it's a bad
Developer Experience
... talking to developers, they don't like it
... i don't want email for the next 10 years
sam: put in concrete feedback to your proposal
mjs: for videos using custom
controls
... folks mentioned they can put in their own button
... but that same use case can be served just as well with an
<a href>
... it doesn't lock out
... a link with a text link or a button in controls
... doesn't lock in
... point 3
... [of 3]
... folks say: who cares about old browsers?
... we should push users to new browsers
... in my experience, web developers are reluctant to use
things that require new browsers
... if you give them something that requires that, they'll hold
off until adoption
richardschwerdtfe: developers are
having to deal with more frequent release cycles than they've
ever had before
... every 3 or 4 months
... they're more conditioned to things coming out on that
schedule
... the transition to new browsers isn't a 2 year anything
anymore
... In terms of developers/end users
<mjs> http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2&qpcustomd=0
richardschwerdtfe: end
users/developers like done by default
... ARIA Live Regions
... oh, it already speaks for me w/ ATs
<plh> on mobile, the release cycle aren't 3/4 months...
richardschwerdtfe: if you want to
show a link for Safari
... that's ok, but then you have to decide where to put it on
my page
... we had this problem w/ longdesc=
... it's like "skip to main content" links
... it detracts from what they do
s/do/want to do/
scribe: maybe providing a way to
override it
... but getting something from the browser for free is
something they aren't going to complain about
cyns: especially if they don't have to do something
mjs: I pasted a link to marketshare study
s|http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2&qpcustomd=0|-> http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2&qpcustomd=0 Market Share study|
JF: developers are starting to
race to the latest
... gobbling up new CSS stuff
sam: stuff that gracefully degrades
JF: <video> in a page, using a page
sam: <track> element in on a browser that supports <video> but not <track transcript>
chaals: browser that supports <video> but not <track>, those exist as well
JF: same problem, different
bucket
... browsers today not supporting Track, not supporting
Subtitles, same poor UX
mjs: Browser adoption, developer
adoption
... mobile content is driven differently
... mobile focused developers using latest stuff
... but on desktop site they care about older browsers
sam: will there be desktops in 3 years?
paulc: what will happen for this issue?
sam: JF will have a proposal by a
week from friday
... "in 8 days"
... hober will extract from the wiki in the same time frame
paulc: chairs will try to review those ASAP and see where they stand
sam: there will be a survey
... and i can see there'd be a discussion for a couple of
weeks
JF: i'm thankful to everyone for participating
sam: we have plenty of things in
the queue
... if we can get 1-3 proposals mashed out
... improved/merged
... getting them in concrete
... i'm happy with that
... and hober isn't withdrawing his third one
paulc: i'd like to thank
richardschwerdtfe for breaking out the schedule and money
... it applies to everyone in the room
... myself and the accessibility coordinators attempted to get
the right people in the room
... so thank you richardschwerdtfe
[ Recessed until tomorrow @9am ]
trackbot, end meeting
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/accomidate/accommodate/ Succeeded: s/open issue/open issues/ Succeeded: s/Stabization/Stabilization/ Succeeded: s/Shoudl/Should/ Succeeded: s/let's to/let's do/ WARNING: Bad s/// command: s/http://lists.w3.org/Archives/Public/public-html/2012Apr/0204.html/-> http://lists.w3.org/Archives/Public/public-html/2012Apr/0204.html HTML Working Group Changes email, April 2012/ Succeeded: s|FAQ: http://dev.w3.org/html5/decision-policy/html5-stabilization-plan.html|-> http://dev.w3.org/html5/decision-policy/html5-stabilization-plan.html FAQ (Draft HTML5 Stabilization Plan)| Succeeded: s/msj/mjs/g Succeeded: s/here/hear/ Succeeded: s/narrow/narrowing/ Succeeded: s/tanek/tantek/ Succeeded: i/choosing topics for F2F/Topic: Choosing topics for F2F Succeeded: s/for the WG/from the WG/ Succeeded: i/Let's move into the stabilization topic/Topic: Stabilization Succeeded: s|s/http://lists.w3.org/Archives/Public/public-html/2012Apr/0204.html/-> http://lists.w3.org/Archives/Public/public-html/2012Apr/0204.html HTML Working Group Changes email, April 2012/|| Succeeded: s|http://www.w3.org/html/wg/tracker/issues/199|-> http://www.w3.org/html/wg/tracker/issues/199 ISSUE-199 -- Define complete processing requirements for ARIA attributes| Succeeded: s/shouldbe/should be/ Succeeded: s|http://www.w3.org/WAI/PF/aria-implementation/#mapping_role|-> http://www.w3.org/WAI/PF/aria-implementation/#mapping_role aria ua implementation guide| Succeeded: s/table/role-mapping table/ Succeeded: s/DOM/eg DOM/ Succeeded: s/than HTML/than HTML - on the other hand, more people might read HTML.../ Succeeded: s/ach richardschwerdtfe// Succeeded: s/MichaelC: can you expand on the "clarifying forward compatibility" issue?// Succeeded: s/thanks hober// Succeeded: s/skipped/skipped in my change proposal/ Succeeded: s/charcacterisation/characterization/ Succeeded: s/this/processing this way/ Succeeded: s/abtracgt/abstract/ Succeeded: s/...two specs"// FAILED: s/yes, you should be// FAILED: s/what are you doing?// FAILED: s/lunch?// Succeeded: s/yes// Succeeded: s/ok// FAILED: s|http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035239.html|-> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035239.html Canvas v5 API additions| FAILED: s/frankolivier/richardschwerdtfe/ FAILED: s/ATs/AAs/ FAILED: i/i know tantek/Topic: Time and Data element FAILED: s/progresssome made their way through/progress/ FAILED: s/your/your, paulc's,/ FAILED: s/Shawn/Sean/ FAILED: s/pubdata/pubdate/ FAILED: i/previous subject/Topic: Pubdate FAILED: s/go ahead// FAILED: s/<element./<element>/ Succeeded: s/e// FAILED: s/subtiles/subtitles/ FAILED: s/VTML/TTML/ FAILED: s/parcipate/participate/ FAILED: s/* ping test// FAILED: s/synchronized/synchronized and is an attribute/ FAILED: s/transcrpit/transcript/ FAILED: s|hober's research page: http://www.w3.org/html/wg/wiki/ISSUE-194/Research#2B_-_mint_an_indirect_transcript_attribute_which_takes_many_IDREFs|-> http://www.w3.org/html/wg/wiki/ISSUE-194/Research#2B_-_mint_an_indirect_transcript_attribute_which_takes_many_IDREFs hober's research page| FAILED: s/path?i/path?/ Succeeded: s/+Q//g FAILED: s/features/feature/ FAILED: s/there's a time/the argument about back-compat is not untrue. But paving that cowpath is like implementing video by having an a href link to the video and then importing it because existing browsers didn't support <video> elements. There is a time to work on adding functionality./ FAILED: s/directoin/direction/ FAILED: s/do/want to do/ FAILED: s|http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2&qpcustomd=0|-> http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2&qpcustomd=0 Market Share study| Found Scribe: krisk Inferring ScribeNick: krisk WARNING: No scribe lines found matching previous ScribeNick pattern: <timeless> ... Found Scribe: chaals Inferring ScribeNick: chaals Found Scribe: MikeSmith Inferring ScribeNick: MikeSmith Found Scribe: chaals Inferring ScribeNick: chaals Found Scribe: Josh_Soref Found ScribeNick: timeless Scribes: krisk, chaals, MikeSmith, Josh_Soref ScribeNicks: timeless, krisk, chaals, MikeSmith WARNING: Replacing list of attendees. Old list: Radhika_Roy tantek eliot Clarke +1.650.693.aaaa hober Cooper New list: Clarke +1.650.693.aaaa eliot F2F MichaelC Default Present: Clarke, +1.650.693.aaaa, eliot, F2F, MichaelC Present: Clarke +1.650.693.aaaa eliot F2F MichaelC Odin_Horthe_Omdal plh Magnus_Olsson Wonsuk_Lee Bryan_Sullivan Art_Barstow krisk Soonbo_Han Glenn_Adams_(glenn) Yosuke_Funahashi Josh_Soref Russell_Berkoff(Samsung) Agenda: http://www.w3.org/html/wg/wiki/May2012Agenda Found Date: 03 May 2012 Guessing minutes URL: http://www.w3.org/2012/05/03-html-wg-minutes.html People with action items: ted WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]