See also: IRC log
<MikeSmith> trackbot, start meeting
<trackbot> Date: 03 May 2012
<krisk> scribe: krisk
paulc: choosing topics for F2F
... Potential Topics...
time/date OR how/when we add semantic elements to HTML
Issue 183
<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
media extensions/Encrypted media
HTMLG WG charter
If people have specific timeslots for an agenda then we will accommodate
#1 Time/Date
#2 Media Extensions +Task Force
#3 HTML Charter (V.NEXT)
#4 Test Suite
#5 Issue 199
Issue-199?
<trackbot> ISSUE-199 -- Define complete processing requirements for ARIA attributes -- open
<trackbot> http://www.w3.org/html/wg/tracker/issues/199
#6 Issue 201 (canvas hit testing)
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: 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 occurred 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?
[ no agreement ]
paulc: let's do stabilization first?
... 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, hober 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 happened 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 implement 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
adrianba: the goal of overtime narrowing comments, is a good goal
... we should implement these changes and if they don't work then we can revisit
ArtB: Q6 seems reasonable, though I could see an 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..
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
... bug 16674
... 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: would 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
cynthia: we at the point in 'shipping' that adding new stuff will be painful
... 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 stabilization 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 fundamentally opposed
... 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 chaals 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..
<chaals> scribe: chaals
<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, hober 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 about how we express things in the spec rather than technical difference - it is still important to ensure we all understand 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
hober: 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 encountered.
... 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.
hober: 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.
hober: Which issue is this?
Rich: Did you use what was here when you defined role mapping?
hober: 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?
anne: 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. changing the processing rules to deal with custom roles
anne: Will the change be compatible
Rich: Not clear. How would we handle sub-roles available in the mac platform?
cynthia: Haven't started discussion on that
anne: If changes are made, we change the specs.
hober: 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.
anne: 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 e.g. DOM specs...
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...
mjs: might make sense for role to be in ARIA rather than host, but ARIA chose not to do that - doesn't give a sufficient 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 hober's text, worried about looking forward.
mjs: First issue - should role be single token or list of tokens? hober isn't sure we disagree.
hober: It's a list in both proposals.
cynthia: Was Hixie's critique listing a single one?
hober: 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 tokenlist
mjs: second - clarifying forward compatibility.
<tantek> btw, how can things be different in SVG? Isn't SVG just part of HTML now?
MichaelC: Forward compat model. You can provide multiple roles - newer better one first, followed by old one that is better known. UA takes the first role it recognises.
<shepazu> tantek, what does that mean, functionally?
MichaelC: think that was not clear enough in the change proposal that led to 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
hober: 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.]
hober: 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 hober'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.
MichaelC: Yes. This issue answer Ian's critique.
anne: 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 "yes, 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)
MichaelC: 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.
MichaelC: 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.
hober: There is a distinction between processing and author-conformance requirements. Would prefer leaving author conformance to aria spec to define.
mjs: Do the proposals defer this point as written?
hober: MichaelC proposal has text where each properties is defined and text saying where they can be used.
Rich: I think HTML5 spec is clear on where you can apply roles or not. Tried in user agent implement guide not to do the error correct - leave it to authoring to deal with that.
... i.e. 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 hober/MichaelC 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.
hober: We are reflecting what the author wrote. It would be weird to have markup that did not get to the DOM.
chaals: Think we need to define in the processing model that error 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
hober: 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
MichaelC: Do we want to document the intersection and specify it, or point to the two sets of rules and tell implementers to figure it out?
mjs: Is there a part of the proposal that addresses this question?
MichaelC: 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: MichaelC 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.
hober: sure
[general agreement that we aren't facing a disagreement to resolve]
mjs: Should aria 'stuff' be defined in HTML or in ARIA specs?
MichaelC: In my proposal I defined all state and property attributes. Concern was that redefining these in HTML leads 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. Counter-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?
hober: 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 think we need to incur.
... you already have to read the referenced specs to implement HTML so not sure what is different here.
Rich: Think the ARIA spec should define values for role, state, property. We also have to address other host languages. So I agree with hober.
... 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.
MichaelC: 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
MichaelC: 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?
MichaelC: how much should be included even if only in an informative manner (if any).
<anne> tantek: no because that takes CSS
hober: 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 hober did it different consensus follows hober, it sounds like you guys could align a single proposal.
... MichaelC, hober, can you do that?
hober: 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
<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> Canvas v5 API additions
hober: the proposed changes
... allow drawing ellipses
... paths
... text alignment paths
... and define a cursor
... for each accessible region
... new text metrics
... 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
cynthia: 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
cynthia: 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?
cynthia: 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"
richardschwerdtfe: what about AAs that go to the DOM itself?
... for Firefox, AAs go to the AT tree
... but for IE to be backwards compat, they go to the DOM
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
rubys: 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
rubys: hober can watch it
... and work on it in his spare time
... are we done with this topic, for now, at least?
[ RESOLVED ]
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
rubys: 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
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 progress
... 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
rubys: I thought there was a CfC to accept the time element
tantek: there was, and it was accepted
rubys: 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
rubys: 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
rubys: if this type attribute were added and no one in the room is advocating
... how would we address it?
... I understand your, paulc's, point
... people who propose such things should define such things
... we as co-chairs did indicate it was deficient
... I don't believe we've timed it out yet
paulc: you sent your proposal on the 18th
rubys: 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
rubys: in that case, we should mark as deferred
... 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
rubys: we're missing a participant on 194
cynthia: I haven't reached him
JF: we'd like to get Sean Hayes, Microsoft, to dial in to join us
... if we postpone to tomorrow
paulc: where's he based?
JF: UK
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 pubdate
... because it lacks nontrivial use outside of hAtom usage
... which provides a superset of the functionality
<paulc> Chair review of the issue-185 change proposals
paulc: you, rubys, on tantek 's proposal
tantek: wordpress templates use in hAtom
rubys: it's not in dispute that it's used
... we could update the change proposal and say it's deficient
... 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
rubys: 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
JF: hober did a good review of different patterns
... 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
JF: the one we're leaning toward
<hober> research in http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194/Research
JF: is the <track> element
... an untimed file
... there were a couple of others
... using an indirect transcript reference
... or reuse the for/rel attributes
rubys: 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
rubys: 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
eric_carlson: every shipping browser on the planet
hober: we've provided a fallback for every new feature
cynthia: 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=
cynthia: no
... you have a track
... all interchangeable
anne: I don't see the difference
cynthia: you're not saying this url goes to this image
... you're saying these things are interchangeable
... <source> is a child element
anne: there's also a src= attribute
cynthia: it seems
anne: <track> is the same as longdesc=
cynthia: 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 in-band tracks
... <track> works fine for in-band tracks
... but transcript= would work better for the in-band transcript case
... if I have an mpeg4 file
<hober> 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> ISSUE-194 Research 4A - reuse the track element
cynthia: and the <track> element allows for
BobLund: not for in-band tracks
... you don't have individual URLs to the component tracks
cynthia: can't you have mixed?
janina: can't you have in-band subtitles
... and out of band
mark: that works
glenn: timed text
... TTML
... 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
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
rubys: 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 entire time
eric_carlson: if you wanted to present the entire text at the initial time
rubys: so, some spec work to be done
... glenn is willing to 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
cynthia: 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
rubys: 'it'/'that'?
chaals: it= "The IDref pattern"
... the thing about track
... it may change the semantics
... 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
... cynthia'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 and is an attribute
... second
... a distinction between <track> and IDref
... chaals mentioned one
... 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 transcript
... 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
cynthia: 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
cynthia: 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"
cynthia: 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_Vickers> 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
cynthia: we're doing that because we asked them to do that
rubys: 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: rubys you asked about options
... I'm happy to only look at two options
... and to discard the others
rubys: ok
JF: points...
... cynthia 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
rubys: is it IDref or <track>
cynthia: 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
rubys: you prefer <track>, ok
cynthia: 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
rubys: 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 ?
cynthia: 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
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
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
rubys: 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
rubys: 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?
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
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
rubys: 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
rubys: 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
<scribe> ACTION: rubys to get JF to deliver a proposal by next Friday [recorded in http://www.w3.org/2012/05/03-html-wg-minutes.html#action02]
<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
rubys: 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
<scribe> ACTION: rubys to get hober to write up a video-transcript IDref proposal by next Friday [recorded in http://www.w3.org/2012/05/03-html-wg-minutes.html#action03]
<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
rubys: 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
rubys: 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
rubys: ultimately, that's a 4th proposal
<adrianba> +1 to everything tantek just said
rubys: 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: 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.
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 feature
... 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 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
cynthia: 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
cynthia: 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
cynthia: 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
rubys: 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> Market Share study
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 want to do
... maybe providing a way to override it
... but getting something from the browser for free is something they aren't going to complain about
cynthia: especially if they don't have to do something
mjs: I pasted a link to marketshare study
JF: developers are starting to race to the latest
... gobbling up new CSS stuff
rubys: stuff that gracefully degrades
JF: <video> in a page, using a page
rubys: <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
rubys: will there be desktops in 3 years?
paulc: what will happen for this issue?
rubys: 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
rubys: 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
rubys: 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