<richardschwerdtfe> silvia:
so this is a build of Chromium which is a build of webkit
code

Silvia Demo on chromium

<richardschwerdtfe> silvia:
this is a build by one of the people in Google (not myself)
doing text track on chromium

<richardschwerdtfe> silvia:
it is implemented in the browser

<richardschwerdtfe> silvia:
it's been built into the framework of how video works

<richardschwerdtfe> eric: so
what she has done is add a generic track element to webkit and
a number of classes to read the data from the track to decode
it. The whole thing is done in a very generic way and it is not
a big deal to put in a generic parser

<richardschwerdtfe> eric: it
was done as a text track. Binaries would be more work. Basic
plumbing is in webkit 4

<richardschwerdtfe> eric: we
just got code from the person doing this on Friday

<richardschwerdtfe> eric: it
is a simple matter of finishing this on Safari

<richardschwerdtfe> silvia:
there is a lot more to do

<richardschwerdtfe> silvia:
we are on the way and we are getting there. It fits with the
other stuff in video. That basically states what we have
designed so far can be implemented.

<richardschwerdtfe> sean: the
styling you had on that caption, where did that come from ...
so you are not hooked up to the CSS

<richardschwerdtfe> silvia:
this is a very, very early pre-release thing but the first
thing is done

<richardschwerdtfe> mike: is
the build available publicly

<richardschwerdtfe> silvia:
no

<richardschwerdtfe> eric: I
am working with her but she is a new webkit contributor. The
plan is to get it into shape to get it into the tree

<richardschwerdtfe> eric: the
point is it will be in there to play around with

<richardschwerdtfe> frank:
what was the trickiest thing to implement so far?

<richardschwerdtfe> eric: the
architecture

<richardschwerdtfe> silvia:
one thing to note the styling ...

<richardschwerdtfe> eric: it
is done with an element in the shadow dom

<richardschwerdtfe> frank: we
are considering doing a similar thing

<richardschwerdtfe> silvia:
how do you do the controls?

<richardschwerdtfe> frank:
custom draw them

<richardschwerdtfe> silvia:
cool

<richardschwerdtfe> eric:
hooking this up to CSS is no work at all as it is in the shadow
DOM. ... hours of work

<richardschwerdtfe> eric:
Since Webkit is open source. We have to get the architecture
and the code submitted. I don't know how far off it is. It will
take a week or so to get it all checked in. As it is an early
draft it will take 3-5 weeks

<richardschwerdtfe> silvia: I
would say at least a month. soonish

<richardschwerdtfe> silvia:
the spacial markup for WebVTT

<richardschwerdtfe> silvia:
deciding if to use generic HTML markup in queues

<richardschwerdtfe> frank: we
would like that. CSS ...

<richardschwerdtfe> silvia:
pseudo selector support to get to the shadow DOM

<richardschwerdtfe> Mike:
running a little bit over. The next thing we want to do is do a
review of yesterday's minutes

<richardschwerdtfe> frank: It
seems prudent that you know where you are in live streaming
such as if you are behind. It also seems prudent to tell the
author if there are issues with playing back at a certain
rate.

<richardschwerdtfe> frank: we
want to have something that does not change and ship what we
have today in the spec.

<richardschwerdtfe> silvia:
the playback rate tells you the rate it is playing back. If
playing backwards it is negative. That is what playback rate
does and you can adjust it in JavaScript

<richardschwerdtfe> eric:
this is a javascript API. The text in the spec. says the user
sets it and the browser plays it

<richardschwerdtfe> mike:
where we are at is we have a bug and Hixie says won't fix.

<richardschwerdtfe> mike: we
are going to adopt this unless someone introduces a counter
proposal

<richardschwerdtfe> silvia:
it is overloaded as the browser can tell you what it has
done.

<richardschwerdtfe> silvia: I
introduced a change proposal

<richardschwerdtfe> mike: the
next thing to do is put out a survey

<richardschwerdtfe> mike: the
bug triage team said this does not have any relation to
accessiblity concerns

<richardschwerdtfe> silvia: I
would think Janina might be concerned about a playback rate

<richardschwerdtfe> eric: the
spec. tells you play at the rate the browser told to play

<oedipus> "All HTML elements
may have the dropzone content attribute set. When specified,
its value must be an unordered set of unique space-separated
tokens that are ASCII case-insensitive. The allowed values are
the following:"

<oedipus> "copy: Indicates
that dropping an accepted item on the element will result in a
copy of the dragged data."

<oedipus> "move: Indicates
that dropping an accepted item on the element will result in
the dragged data being moved to the new location."

<oedipus> "link: Indicates
that dropping an accepted item on the element will result in a
link to the original data

<richardschwerdtfe>
MikeSmith: we had a break scheduled at 10:30

<richardschwerdtfe> Judy: I
think it was back at 10:03 your time I saw Rich Schwerdtfeger
minute that Laura was not in full agreement with the task force
discussion on the taskforce discussion on longdesc, but in the
communication i saw, she said it looked like the group made
good progress.

<richardschwerdtfe> Judy: it
looks like she further tweeked her proposal on longdesc.

keyboard access

<oedipus> how is user to
decide what accesskeys to use: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10775
status: the HTML Accessibility Task Force needs to review the
following quotes from the 18 March 2011 Editor's Draft which
follow to ensure that this bug has been adequately addressed;
of pariticular concern is that there is no stipulation that
when a UA or user chooses a set of accesskeys, that...

<oedipus> ...that set of
accesskeys will be uniformly applied (no mixing of accesskey
strings: once a set of accesskeys is chosen, the user agent
must them limit the accesskey values to those that match the
position of the initially chosen accesskey)

GR: bug 10775. you can have a space-delimited
list of accesskeys. how can user figure out what to use.
... my proposal was to make that a cascade.
... what's currently in the spec is examples that use multiple
access keys. There's nothing in the spec that says which to
use
... Say I have a search field. accesskey="S 0". you can get
that accesskey by typing alt+S or alt+0, but if you have each
accesskey assigned more than one value, that you have a
cascade.
... so if you have S used somewhere else, it would fall back to
0. Otherwise, you can only use S, not both
... how do you get to that second key of accesskeys.

MS: Ian says that you don't expose those to
users. UA makes the selection, and only exposes the selected
key to the user. multiple values are not exposed to the
user.

GR: i have an inherent distrust of UA chosing
for me. I want to choose if I want to use alpha or other user
accesskeys

MS: so bug should say that if there are
multiple accekeys exposed to the user, so the user can choose.
The current spec assumes that's not something users need. Need
to provide a use case.
... looking at the status on this, hixie moved it to rejected,
but you commented, then hixie made a spec change, to add
informative text to give an explaination and posted a dif, bug
triage said in January that the change addressed the original
issue.
... if that's not the case, you need to re-open the bug or make
a new one.

M

GR: I guess I do.

MS: new bug should challenge assumption in the
spec that users don't need to have the full list of accesskeys
exposed to the user.

GR: discoverability is a problem. author
proposes user disposes.

MS: create a use case.

GR: what hixie wrote is very nebulous. UA will
decide what to do based on capabilities of device.
... UA might pic numberic keyboard on a phone or alpha on a
full keyboard. User should be able choose.

CS: would configurability be enough? could
make for very complex UI

GR: how many accesskeys are likely?

MS: this is a problem in earlier versions of
HTML
... previous spec for accesskey only allowed one value,
right?

GR: right

MS: there were other ways, such as through
scripting

CS: sort of. not declaratively

MS: previous spec was less precise on what UA
behavior should be.

GR: right. so if we're paving the cow path,
let's do a good job. make sure that it's discoverable.

MS: frame the discusision instead as... great,
now we have a standard way to define multiple access keys, and
now we need to refine that for the case where someone might
want to choose which key
... better to close this bug, and create a new one that refines
the behavior

RS: is teh behaivor on a non-alpha keybaord
defined?

CS: yes.

RS: so waht is that you are looking for?

GR: user should be able to choose whether they
want the first token for every value, second token, etc.

MS: this is a bigger issue, or needs to be
framed differently. describe the use case and go from there.
you don't have anything in the use case. need to explain why
the user wants to do this

GR: ok

<oedipus> HTML WG Bug 10773
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10773
- accesskey should chosen from document's declared charset
marked RESOLVED WONTFIX status: the HTML A11y TF must decide if
this is an important point of clarification; this reviewer
thinks it is and needs to be added to the current text

GR: accesskey should be chosen from documents
declared character set. for example, if I'm using a doc that's
english, I shouldn't have a character that's not english

CS: aren't most web pages UTF-8 now?

MS: no, lots of Japanese and Korean are
not
... TF bug team thought Ian's fix was ok

GR: don't agree

MS: write an email to TF to discuss, put on
telecon agenda.

GR: I will prepare 2-3 a week to work
thoruhg

MC: TF bug team may have said that because we
thought the whole team doesn't need to be invovled. Gregory can
do it himslef.

MS: Need use cases.

GR: I will bring them to task force, and they
can decide if we will address it or if Gregory should do it on
his own.

MS: TF may need to work on that. Bring use
cases, and what should change.

breaking for lunch

<oedipus> ok, thaniks

<MikeSmith> janina_lurker:
big thanks to Microsoft and to Cynthia in particular for
sponsoring the meeting