W3C

- DRAFT -

HTML Weekly Teleconference

03 May 2012

Agenda

Attendees

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)
Regrets
Chair
Sam Ruby
Scribe
krisk, chaals, MikeSmith, Josh_Soref

Contents


<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

Choosing topics for F2F

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

Stabilization

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!

ISSUE-199

<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

Canvas Hit Testing

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

<hober> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#clear-regions-that-cover-the-pixels

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

Transcript with Audio/Video Element - Part 1

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

Issue-194

<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

<hober> http://www.w3.org/html/wg/wiki/ISSUE-194/Research#2B_-_mint_an_indirect_transcript_attribute_which_takes_many_IDREFs

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

Summary of Action Items

[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/05/03 23:35:00 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]