trackbot, start meeting

<trackbot> Date: 04 May 2012

<glenn> +Present Glenn_Adams_(glenn)

Introduction

paulc: This is the agenda for today
... we lost the whiteboard
... we said we'd do the two media topics
... and a CfC
... after coffee, we'd do charter for V.next
... after lunch is open issues (ISSUE-204) and test suite
... chairs did a discussion last night
... and noted that while we don't have all the proponents of 204
... whether it'd be worth discussing it
... we have one proposal from cynthia
... and one from sicking and "Matthew"
... do we expect cynthia to be here today?

janina: we expect her today

paulc: we'd need someone to speak to sicking's side of the issue
... i don't know if hober could look at sicking's proposal
... at lunch
... and be an animateur of sicking
... after our successful use of F2F discussion yesterday

<odinho> 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

paulc: the chairs realized maybe we should tackle ISSUE-204 while we're here
... we're open to discussion of other issues if people want to give us an ISSUE- number
... we can also look at a page sam has that gives us a table
... it might be useful for the WG to actually review that
... these are topics we failed to cover yesterday
... we discussed stabalization and had a bullet item for a CG
... the other was a decision to defer ISSUE-184
... we can do it under "Open Issues"
... my notes indicate we, the chairs, could defer it
... got everything, scribe?

[ scribe nods ]

<odinho> ISSUE-184?

<trackbot> ISSUE-184 -- Add a data element -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/184

Media Proposals

paulc: which proposal do we want to do first?
... Encrypted
... there was a suggestion to do Media Source first
... do we have someone to walk us through

<acolwell> colwell

paulc: plh, welcome

acolwell: should I project?

paulc: yes

[ Technical break ]

<acolwell> Media Source specification

<Petr> are any presentations available online?

acolwell: its main purpose is to allow JS to create a presentation
... the spec is split into parts

<plh> Petr, the document itself is being displayed in the room

acolwell: the html media element
... append data to the tag
... examples of supporting different formats
... we have a byte-stream format for WebM and ISO based media format
... and there's a way to add streams of your choice, like ogg
... this picture describes how to think about it
... the media element is a model of

[ acolwell points to part of the picture ]

acolwell: it introduces the concept of the element
... and a source buffer
... and the Media Engine will pull stuff out of the source buffer
... and this is associated with splicing behavior
... especially for elements close to the current playback time
... questions?

[ None ]

acolwell: this is the theoretical model
... to agree on what the media engine looks like
... this covers Splicing
... Media Segments
... to start you give it an initialization segment
... and then you do appending
... multiple implementations can append over an area
... how does the media engine decide to take that in
... here is how the api looks
... you can use a single source id and use multiplexed
... and then switch on things
... Activating the "media source mode" on the html media element
... currently you assign the mode to the media source element
... and that's what causes it to be active
... there's an open issue on that
... for instance integrating with the <source> tag
... currently the only way to activate this mode is with JS
... there's add/remove-id
... to create/destroy media buffers
... so you can create a new source buffer during the presentation
... the sourceBuffered property allows you to see what the browser is holding
... so a js app can understand what the browser has
... so it can decide what to append next
... currently there's sourceAppend() which takes a Uint8Array (of bytes)
... this is how you get media data in
... sourceAbort() is a way to
... we have Segments, initialization segments, media segments
... if someone requests a seek
... you may want to abort
... and start appending a segment for the new seek point
... sourceEndOfStream() to signal you're done with the presentation
... and provides a way for JS app to signal other types of errors
... Network Errors, Decode Errors, ...

joesteele: is the network error
... only an I'm out of data error

acolwell: the intent is to signal the same errors as you would normally
... so an XHR error could trigger end of stream
... a common one is to signal network errors/...
... this is a way to route an error code from the JS app running the API
... to the player's hooks for error handling
... sourceState keeps track of state
... SOURCE_CLOSED/...
... when you activate it, it changes to SOURCE_OPEN
... and sourceEndOfStream() switches to SOURCE_ENDED
... and then a seek could switch back to SOURCE_OPEN

<plh> the WebIDL in the spec needs a refresh btw. doesn't match latest WebIDL spec

glenn: i noticed you added this to HTMLMediaElement

acolwell: implementationwise

<anne> plh: looks like WebKit IDL

acolwell: it made side,
... things are closely tied to the <media> element

glenn: could you add it to MediaController?

acolwell: it'd be kind of confusing, since that's tied to multiple tags
... what would that mean?
... i could understand it if you had it on multiple tags
... think of this as "having a url"
... and JS is the source

glenn: for things ...

acolwell: there's an open question about making this a separate object
... relating to sourceURL
... say you attach it to the <media> element
... as with WebRTC
... for this interface
... with a special media-source-url
... i could have on-source-open
... on-source-closed
... on-source-buffered
... i wouldn't need extra stuff to hook this up
... but that's an open item

glenn: is a declarative interface wanted?

acolwell: i need to define that as an open issue
... you could define this and then non-adaptive as fallback

glenn: events...
... i didn't see functions

<adrianba> Events

acolwell: they aren't declared here
... when I was working on this for Chrome
... yeah i need to add this

paulc: do the authors of this proposal have a place tracking open issues?

adrianba: not yet
... we talked to MikeSmith about that this morning

paulc: having a bugzilla component would be the easiest way

adrianba: we have for the other proposal a bugzilla component
... and bugs filed
... today, we have issues highlighted in the document

paulc: is your general plan to get a bugzilla component
... and transfer them
... and is what glenn identified a new item?

acolwell: yes
... i'll look at the transcript

<MikeSmith> Media Source Extensions bugzilla component

Josh_Soref: the transcript is incomplete
... glenn will need to help out

paulc: there's a goal of creating components
... and moving things in ASAP
... and the item glenn raised on callbacks would be moved there

acolwell: any other questions?

[ None ]

<adrianba> Byte Stream Formats

acolwell: Byte Stream formats
... so you can take your format (ISO, WebM, ...) to the bytestream
... and to make it concrete
... we've described how WebM maps to the bytestream
... what elements that could appear in the stream that you can ignore
... certain elements needed in WebM aren't needed in <media>source
... we've done the same thing for ISO
... the intent is to describe stuff enough to implement DASH using MPEG fragment files
... in both cases, the spec isn't saying you should support them
... it's saying "if you do it", "you should do it this way" for interop

adrianba: we tried to make the introduction descriptive enough
... so you could walk up with a new media format
... and just make it work
... but at the same time, we wanted to avoid
... for common formats
... that you don't have multiple slightly different versions
... because people just took the description and applied it slightly differently in each implementation
... that's why we mixed them together
... the specific examples are (non-)normative / not-required

acolwell: the bytestream sort of touches with Encrypted stuff
... we need definitions for initialization and intermediate sections
... while they don't depend on eachother
... they need to cover the Encryption use cases
... there's a need for them to interoperate

<glenn> ack

<adrianba> Open issues

acolwell: there's a buffer, and there's no limit on how much you can append into the browser
... there's discussion about having a callback for when you can append more data
... that's because we hadn't decided how to make certain things asynchronous
... another issue is Splicing behavior
... there might be a limit on Buffer count
... or adding buffers midplayback
... there's a mechanism needed to detect constraints on an implementation
... looking at splicing details
... there may be cases where an implementation can't do the splice immediately
... it might need to wait for a keyframe
... and js may need to do something based on the capabilities of the browser
... maybe we'd use mime type parameters
... we might reuse canPlay()
... another is changing sourceAppend to accept urls with byte-range parameters
... some reasons for this
... to avoid pulling bytes from XHR and then push back in
... saving the browser from copying out into a js context and then back down
... to make things more asynchronous
... and to add progress events
... so you could make switching decisions
... it would be useful in an adaptive streaming scenario
... that's an important area to me
... it would allow us to reduce the JS code that we have
... timestamp offset
... i have a bunch of files and need to insert them at a point in the timeline
... the files have internal timestamps of 0
... but i want to map them to another timeline point (2 minutes)
... so you could dynamically append these things in with adjusted timelines
... we think this is useful for ondemand
... and also in live
... timed text
... the spec only discusses audio/video
... but we want to enable timed text as well
... i don't think it'll be too difficult, but we need to look at it
... WebAudio
... WebRTC's MediaStreams
... we need to have discussions about how these proposals work together
... it would be nice to be able to take stuff from <media>stream and do post processing using WebAudio
... or start with <media>source and map that to WebRTC
... we need to see if things are similar enough to make them work
... Tracks
... how to identify them
... using <media>source with a track
... when data appears, you need to know which source buffer to append it
... there are track properties
... Dash manifests specify "kind of language" and "kind of track"
... and we need a way to bubble that up
... they won't be part of the initial append
... that's it

glenn: timed text tracks, are you considering it?

acolwell: yes, BobLund brought it up

glenn: Timing
... is this a HTML.next feature?

acolwell: yes
... definitely HTML.next
... I have a demo

[ Local Demo ]

acolwell: this is an older api
... what you're seeing here are different bitrates in a dash manifest
... JS is downloading chunks via XHR and appending them
... i'll simulate congestion
... now it'll switch
... this isn't just a thought experiment
... we actually have this working
... Chrome is planning on getting the proposed version implemented by the end of the Quarter
... it should be in Chrome 21 behind a flag
... what we're really interested in is AppendURL

<acolwell> acolwell's Demo

acolwell: we actually had to interleave the audio and video chunks
... in JavaScript
... which is why source id was created
... so you wouldn't have to do crazy media stream parsing in JS

<acolwell> Content creation guide

acolwell: our goal is to make as much of this as possible Open Source
... the benefit is that people can adapt this and modify this
... to their own CDN ...

odinho: I would have filed a bug if there was a bugzilla component
... the API is using Numeric constants
... and that's an anti pattern lately
... WebWorkers don't use constants
... IndexedDB changed to string constants

acolwell: are there plans to do that with ready state?
... we did it to match enums in media element

odinho: it's hard to change when it's already there

Josh_Soref: some readyState properties were moving to strings

acolwell: i'm fine with it

paulc: is there a spec that you can point to
... that says "these specs are inconsistent, but you should use this pattern"

hober: at this point, it's mostly folklore

anne: i'm not sure we quite decided
... for consistency

http://lists.w3.org/Archives/Public/public-webrtc/2012Jan/0038.html

Josh_Soref: WebRTC was looking to move to that

acolwell: documenting this intent so people creating new apis would know this
... it would be helpful

mark_vickers: we are using a lot of adaptive streaming
... there's this dash spec
... which is good because everyone is moving to it
... but it's early days
... but this is better
... since it makes dash soft
... you can adapt something else
... i think this is the right kind of approach

acolwell: the feedback we got
... each deployment was different
... "we have multiple CDNs with different cost
... ... and if we're getting bad perf, we want to switch"

paulc: tbl said that he wished vendors would bring things less baked
... on a scale of 0 to 1.0
... is this spec 0.5, 0.6, 0.9?
... you've talked about internal issues
... does this handle the scope you wanted?

acolwell: even as we're implementing the source buffer model
... we're running into things about splicing
... there will be issues
... and a number of things will be big

adrianba: rather than assuming a single dimensional scale
... i'd say, the proposal as it stands today
... is a good encapsulation of the scope
... with the current proposed api+buffer model + open issues
... represents a good scope of functionality
... thinking back to earlier in the week in WebApps
... a good idea for FPWD
... is to be clear on Scope
... for IP exclusions
... "is this the set of IP i'm going to care about?"
... or "are you going to add/remove things?"
... i wouldn't expect we're going to all of a sudden add a new chapter

paulc: as mark_vickers said, you're setting the scope that it's extensible by using JS

adrianba: the Use of it is extensible

paulc: ... rather than being locked into a format

mark: this is sufficient to base a commercial service
... it's very well scoped
... the service could be improved
... you could get better with candwidth estimation

Encrypted Media Extensions

<ddorwin> Encrypted Media Extensions

i/aaron_colwell: should I project/Topic: Media Source Extensions/

ddorwin: David Dorwin, Google
... The goal is to let us have commercial content, that's protected, in the HTML5 video tags
... today most of this is a proprietary stack
... where the entire player is involved
... we'd like to have the entire player with html5
... we're looking for the minimal changes
... to accomplish a wide range of UCs
... on how baked is this
... we spent a lot of time going through the UCs
... there are still Open Questions
... and we filed those
... and there are other things we'd like to consider
... start with the overview picture
... download the media
... playback stack
... oh, the application is in control

<adrianba> Overview

ddorwin: we make no assumptions about the CDM having network access
... when encrypted media is seen, it will fire a needkey event
... and it can use canPlayType() to see what's supported
... application picks one
... calls generateKeyRequest() to the CDM
... we defined a term "CDM", - Content Decryption Model
... to separate what's in the W3C spec
... for the Media element
... to something that's possibly platform/hardware specific
... that's behind the scenes
... essentially a request is forwarded to CDM
... send a request to License Server
... and send a key back down
... application uses addKey()
... you can have multiple keys
... the media stack when it detects an encrypted frame
... can ask CDM to decrypt
... that's just one option
... you could support a Secure Media Pipeline

adrianba: the way i think about this
... this diagram already represents the conceptual model
... for how to think about which parts are done by Media Stack and which by CDM
... we've had feedback about this on the list
... we're not saying this api requires exposing the decoded frame to another component
... the implementation of how the frame gets to the frame is an implementation detail

chaals: in a real system
... instead of frames going back to the media stack
... the CDM will display the frame without passing it back to the browser
... in the current deployed and likely to be deployed stuff
... it won't be pushed back to the browser

mark: there is a class of content
... if the browser wants to push it back

mark_vickers: another way to look at that
... is to say that the media stack and the content decryption module
... are abstract
... and some parts are handled separately from the browser

chaals: one of the things that could happen
... the requirement is "don't expose an unencrypted frame stream"
... that causes encrypted the content to not happen
... it's up to the platforms that use this
... that could be handled by the browser
... in some agreement
... where the browser will not expose encrypted frames
... or it could be handled by a plugin

acolwell: the Media Stack and CDM could be combined
... and the browser has two playback engines

chaals: what do things do today?
... or in stuff you could ship some time this year
... is it all, the CDM will handle everything?
... is there anything you could deploy that would not match that model?

joesteele: for Flash
... where we have access to DRM
... it's essentially where you describe
... part of the media stack is all combined
... we're not using the <media> element, it's an <object> tag
... we're not passing bytes back to the JS layer
... you can't modify the bytes

plh: you wouldn't be able to apply CSS transforms to a video?

ddorwin: you should in some cases be able to do a transform
... if it comes back to the browser

chaals: that won't arrise
... Opera doesn't think that you should not have content protection
... but we should recognize that the limitation we're having
... you won't have the power of the web
... until frames go up into the browser rendering pipeline
... or pass the browser into to the media rendering pipeline

mark: there's a class of content where it would be ok to pass the content to the browser
... there's a class of content where it really needs to be handled in the rendering pipeline
... there are hundreds of thousands
... where there's a media pipeline
... that render pipeline is there
... they don't provide browsers the power to do what browsers can do
... maybe you can pick a region of the screen
... there'd be work to do to enable what you have in html

adrianba: two comments
... 1. thinking about whether/how we could apply parts of the web platform
... are good requirements to gather
... so we could feedback it into the discussion
... in IE when we're
... developing these new graphics capabilities
... we're trying to push them down through the stack
... in IE
... one of the things we're doing is pushing those things
... so we can have a secure graphics pipeline
... where you can push transformations down into the hardware
... so it's possible to do this, without removing large parts of the platform

chaals: an issue for a company like opera
... is doing that on Windows platform devices is one thing
... doing that on a pile of different platforms is another
... the situation where Flash is defacto
... is great, until you get to a device where flash doesn't actually work
... that's a trick problem
... knowing the kind of distribution
... being aware of the requirement
... to make this feasible on all platforms
... to handle open-WebM decoder
... on the OLPC

paulc: we have an ogg theora decoder, and it can handle a calculator
... being able to put things on a platform is important
... mozilla has wondered if they could implement this in practice
... on the one hand, we're their competition
... and we'd like to eat their lunch
... but it's important to us that mozilla can make this work

mark_vickers: i believe and others can tell me if i'm wrong
... there are 3 models for how this can be chunked
... 1. all in browser (CDM in browser)
... 2. software talks to external software API
... 3. browser talks to system api
... there could be combinations of those
... a lot of the discussion is about that api
... there's embedded security on chips
... i think system apis will become more common
... in a sense, it will be outside w3c
... on the other hand, maybe it's a joint effort
... in the same way that HTTP is a joint effort with IETF
... maybe the web could drive those apis
... I think we have all the players, both on the CDM and Browser side at W3C

ddorwin: there's opportunity to do this outside the W3C
... the major players are represented and outside
... there may be devices without a secure pipeline

paulc: i get really nervous when plh starts to pace
... it's one thing to read someone's body language
... it's another when our Domain Lead starts to walk the floor
... an chaals is up too

bryan: I understand the idea of pushing the content to be rendered in a protected box
... how do you integrate
... from UCs i see in the doc
... how do I do captions?
... do i have access to this display box?
... can i overlay it?
... are there limitations?

ddorwin: i don't know about in band captions
... certainly for just a tracks file

bryan: i'm talking about things
... a UC in Web and TV is i can find captions anywhere
... crowd sourced

chaals: we'd expect in any of these scenarios
... that has a composite over screen region
... even in the worst possible scenario
... in terms of losing Transforms
... we expect to always be able to add captions

ddorwin: the most basic is 2 layers

adrianba: that's QoI
... if you have a media pipeline that doesn't allow composition
... that would be a problem
... most services we see today
... support the basic ability to overlay something onto part of a screen
... which is how you'd do captions

Mark_Vickers: accessibility access in a standard way
... is the number one goal for why we're interested in this
... we've put a lot of effort into making this api open
... we have a standard api for getting embedded caption data
... and standard controls
... the notion is that these standard things would work
... which they do not through a plugin api
... that's the major driving goal
... we'll have to work through all of these cases

ddorwin: there may be platforms of hardware with limitations
... and we may need to work through that

mark: this is very much an implementation issue
... we're not proposing to specify restrictions
... as far as the spec is concerned, everything is possible
... similar to how OpenGL works
... application restrictions
... you might want to expose
... but i don't think we'll know that until we get further along the path

bryan: does that mean we won't know it's possible to overlay captions until we have implementations

adrianba: no
... we're saying there's no reason why this will be a problem
... the spec is designed to allow that
... we know there are implementations that support overlaying captions
... but we don't know how common it will be for implementers to hit restrictions in devices
... if that's a problem, then we need to look at that
... but we don't know that will be a problem

chaals: what makes we confident
... is that TV has crap accessibility
... but they've done this quite well with a lot less
... we need to have requirements
... i wanted to pick back up on Mark_Vickers 's point
... on standardizing apis
... i think it's valuable to get that convergence
... so when someone wants come along and build a browser that can play video content
... if a significant amount of video content on the web is protected
... then standardizing that is good
... whether that's entirely in W3C or somewhere else
... we'd like to ensure it's done w/ W3C well in the loop

paulc: chaals, you've said it's possible to do it with someone else
... can you enumerate that other side?

chaals: no

paulc: that's fine

chaals: how do you handle signalling
... you have some thing playing
... the browser Open Media Stack
... and browser with Closed Media Stack
... and running your captions through the Open Media Stack
... you need signalling between the two

adrianba: you mean for timelines?

chaals: yes

adrianba: i think timelines work the same way it does generally for the media stak

s/stak/stack/

scribe: an advantage of this approach is you still manipulate an element on the page the same way
... events get fired should be the same

chaals: i.e. "yes"

ddorwin: there's already cases where hardware is decoding/demuxing

JF: you were talking about captions as text overlays
... what about supplemental audio?
... same principal?

adrianba: yes,

joesteele: along the same lines
... if i wanted to do ad insertion, that should work seemlessly with this proposal?

adrianba: right
... we've tried to ensure that the media-source proposal and media-encryption proposal are orthogonal and compatible
... we've tried to ensure you can control the timeline
... as that data gets processed
... if it's encrypted, the encrypted part needs to fire
... one of the things we need to think through
... and acolwell mentioned
... around segments
... another is understanding where in the pipeline decryption happens
... is this something decryption from a transport
... or when you're about to render it
... there are nuances there
... and i think implementation experience will help

acolwell: Media Source says that
... for Text Tracks
... they're implemented in chrome independent of the pipeline
... using CurrentTime
... as long as you have CurrentTime
... you can do it

chaals: you're getting CurrentTime out of the stack
... alright
... glenn 's timeline question, this is slated for HTML4.1?

mark: encrypted stuff?
... this is high priority for the media stack in chrome

ddorwin: we're working on it in webkit
... we know there are open options
... seeking feedback
... talked to DRM providers
... still lots of opportunity for feedback
... this is the first roun

s/roun/round/

paulc: i want to watch the clock
... we were planning on a coffee break

acolwell: as we progress on this
... DRM providers and Content owners will be motivated to integrate with this
... Content providers will leverage against DRM providers
... we don't have to solve that
... Content wants to be on the web

adrianba: a scope comment
... similar to media source
... proposal
... we've collaborated on what we think is a good model for enabling encrypted media in the web platform
... as with the other proposal, we've called out open issues
... i think the scope of the proposal is fairly complete
... and is a good indication of what we think needs to be built
... i wanted to point to Mark_Vickers 's email to the list indicating we'd be open to alternative proposals
... but we think this is a good model

mark: as acolwell noted
... as a content provider
... we want it to be available everywhere
... while we can't dictate apis to people
... the incentives are there

Mark_Vickers: in the past
... the practice was
... content was made available encrypted
... and paired to a single system
... obviously an issue of leverage
... there's a new model innovated by UltraViolet
... they support multiple decryption models, maybe 6-10
... and the service supports multiple
... the client chooses one
... maybe baked into OS
... or based on costs/models
... and that leaves a bit of burden on providers

chaals: i hope so
... having seen these things played out
... "in the best possible world, you're right"
... to Mark_Vickers, mark, yeah
... places where i tend to go, it isn't quite as smooth as that
... there are big lumps in how that plays out
... there are real pressures to make it happen
... what i said before
... it's important this stuff is available on the platforms people have
... multiple mechanism ecosystem is important
... if it doesn't work,

Mark_Vickers: UltraViolet is deployed and proven to work in the field

adrianba: as we went through
... we tried to make sure this API supports the common encryption model
... the way negotiation works for key sysem

s/sysem/system/

scribe: the 3 places key system touches
... media file supports multiple
... UA supports multiple
... UA+media has choice
... JS can decide
... so web app can build in cost preference

johnsim: John Simmons, Microsoft
... commenting on UltraViolet, PlayReady
... UltraViolet's mechanism was developed by PlayReady at Microsoft and proposed by them in 2009
... originally they weren't going down that road
... Microsoft + PlayReady team at MS
... sought a stack that supports interoperable encoding/playback
... speaks to our philosophy
... of not creating vertical stack
... but promoting online video and interoperability
... one of the reasons we're Bullish about participating in this
... it's part of our vision of DRM interoperability
... throughout the stack will enable large growt

s/growt/growth/

scribe: to address chaals 's concern
... our vision is the interoperability you're talking about

chaals: my vision is World Domination for Opera

[ Break ]

paulc: we want to wrap up
... and we need to decide how to reconicile
... any remaining questions

s/reconicile/reconcile/

janina: what we're hearing is good from the accessibility point of view
... accessibility, ability to overlay
... what were flash points in the past
... sound very workable

paulc: i know the TF had high level concerns
... but what you're hearing is very positive

janina: XX and YY met at TPAC
... and we're pretty satisfied

s/XX and YY/Web and TV IG and Protocols and Formats WG/

paulc: and you're a cochair of PF?

janina: i'm a cochair of PF

Mark_Vickers: I'm a cochair of Web and TV
... as is yosuke

Encrypted Demo

UNKNOWN_SPEAKER: what's added are 3 methods and
... we've extended canPlayType
... example code ban be this much

<adrianba> Extension APIs

UNKNOWN_SPEAKER: fairly simple
... for the demo
... an official Chrome build with flags enabled

<adrianba> Code Examples

UNKNOWN_SPEAKER: an extension of what acolwell showed
... you try to play an encrypted video

[ Error dialog ]

ddorwin: same page
... you can see the track element is working in this demo
... and it's adaptive

s/... what's/ddorwin: what's/

scribe: what you missed is key needed
... and key exchange

plh: you know you, you don't need encryption to see this video

[ Laughter ]

ddorwin: yes, it's also using ClearKey

CfC Create Media Task Force

<rubys> http://lists.w3.org/Archives/Public/public-html/2012Apr/0007.html

paulc: i want to point out, when this was sent out, we only had one of these proposals, the second one we did today
... if people want to work on this, but don't want to disrupt this WG
... maybe we should have a TF

<chaals> [clearKey is a demo DRM that you can look inside...]

s|http://lists.w3.org/Archives/Public/public-html/2012Apr/0007.html|-> http://lists.w3.org/Archives/Public/public-html/2012Apr/0007.html CfC Create Media Task Force|

paulc: since the request came out of Web and TV IG
... we wanted to note they had to join this WG
... there's be a new ML
... while we create a TF, decisions are still made by the WG

<ddorwin> Encrypted Adaptive Demo (from previous topic)

paulc: we'll have facilitators, for Accessibility, that's janina, and MikeSmith
... an initial point of contact
... report back every 2 weeks
... TF could draft scope, initial work plan
... in this case, Encrypted and probably also media source
... feedback we got
... some people didn't like the direction on Encryption
... and some people didn't like the name
... I chose it for the short email: public-html-media@w3.org
... i think we're in an interesting point in the Timeline of the WG
... maybe we just keep these proposals at the WG level
... we have bugzilla components for both
... we could morph Thursday meetings from just status on the HTML5 document
... to having discussions about the Media items at the meetings
... i'm open to other suggestions
... we got pushback on CfC
... chairs view it's in our domain on how to go forward
... looking for feedback

chaals: i don't think we need another TV+Web IG within HTML WG
... they've done a good job
... we'd like the work done at the level of the WG
... if we get back to the flame storm when this was first presented
... then a TF is probably an administrative necessity to make it work
... that would be unfortunate
... just because you have most of the people
... for encryption and media stream
... shouldn't be that you put them together in a TF
... that would be administration over sense
... TFs should be scoped on tasks
... just because they interact/interrelate are separate

Mark_Vickers: i don't want to limit participation
... everything should be above board and visible
... there are people who may want to get involved
... who have media expertise
... who won't have expertise in HTML
... we'll need a F2F on this subject
... w/o causing an HTML WG F2F
... on media source
... it can go either way
... but again, i think there's some in common
... there will be conversations where we'll be talking about both proposals
... no matter how we go

adrianba: i agree with what Mark_Vickers said
... i proposed the TF on a WG call
... after we saw the discussion on the encrypted media proposal
... it appeared some people wanted to not work on it
... there are others who wanted to work on this
... but didn't want to contribute on other areas
... i'm not wedded to a TF/no TF
... i'd like to see the work proceed in the WG
... i'd like people to be able to focus on this area
... we want to make sure there's machinery to have discussion on this

paulc: we're looking for input on how to process the encrypted media proposal
... and the media stream proposals
... chairs are looking for feedback on how to process these two
... looking for as wide as possible

tantek: has anyone suggested a CG instead of a TF?
... to be more nimble

paulc: no, they submitted it directly to the HTML WG

<Zakim> chaals, you wanted to say HTML can hold f2f meetings on specific parts of what it is doing...

chaals: in webapps, we don't have any formal TFs
... but DOM3 events was done on a separate ML
... with their own Teleconfs
... dedicated to DOM3 events
... weekly
... when the WG wasn't having calls at all
... process is what we create when we behave badly
... if we behave sufficiently nicely without having to create formal process
... it's good

paulc: alright
... to be transparent, chairs had dinner last night
... do you want to know what we had or what we talked about?

[ Laughter ]

paulc: mjs took us to a place that was a favorite dinnertime spot in the Netscape days
... in true browser tradition
... La Fiesta, we went back to our roots
... chairs agree whole-heartedly
... wanting to change the culture and mode/mood
... and we want to encourage exactly that on those items
... i was going to ask chaals if you had an opinion on a separate ML
... other opinions here?
... a. in WG
... b. in WG w/ separate meetings/F2F
... ironic because Cochairs+plh were talking about more regular F2F meetings
... possibly a meeting between now and TPAC
... plh + paulc: took the suggestion from chaals and myself
... the hoops we had to go through to find meeting space were difficult
... six months in advance is easy, 3 months is quite difficult
... c. separate email list
... d. separate telconf
... we have bugzilla components
... WG members could opt in
... principal: they're WG meetings, anyone from outside
... Josh_Soref is an observer

Josh_Soref: I stopped scribing Web and TV because i couldn't call in w/o being a member

janina: Mark_Vickers mentioned
... some people would be coming w/ expertise not based on processing markup

paulc: chairs always have the scope to bring in experts to bleed ideas/items off
... the place we have to be careful is when people make contributions from a WG perspective
... if we have this dialog, we'd want to make sure existing issues, raised points
... if we'd want to invite experts
... on other options of feasibility

Mark_Vickers: I wasn't suggesting invited experts/non members
... people should be members
... WG or TF, there should be clear meeting times
... so people with interest in these areas
... could only spend time on this

chaals: +1 on "these people should be members"

paulc: always useful to have the club decide whether it wants to have guests
... or force people to join the club
... taking silence as affirmation
... we should look to create a ML

Mark_Vickers: separate ML

JF: as an accessibility TF
... we have a public-html-a11y@
... that's worked for us

BobLund: +1

joesteele: clarification
... I agree a separate ML
... it would still be public

<chaals> s/+1 on "these/+1 - noting particularly the "these/

joesteele: we switched away from prefix: www-*@ to public-*

anne: "This discussion"

paulc: we were talking about Encrypted Media and Media Sources
... and topical F2F meeting
... where we could make progress
... if we tried to schedule a F2F in Aug or Sep
... would people be interested in trying to advance the work

<joesteele> +1

chaals: we don't really like the blending of all the media stuff as one thing
... separate audiences
... we can live with separate lists
... we can live with separate meetings
... expect us to join for what we care about
... and leaving things we don't care about ourselves
... and similar for others

anne: in particular, streaming seems far less controversial

paulc: what do you mean by separate?
... group doesn't seem interested in TF
... do you want 2 new email lists
... or tagged messages

chaals: if we behave nicely
... if it's easy to figure out
... so long as that works nicely, that's ok

paulc: if we had a F2F
... 2 days
... encrypted on day 1
... sources on day 2
... would that work?

chaals: yes

paulc: you're asking for work allocation split
... for phone calls, which call for which item

chaals: i don't think it was just us

tantek: i want to echo what chaals is saying
... i think mozilla is also interested in media source streaming
... and what anne says, that seems fairly uncontroverisal

s/uncontroverisal/uncontroversial/

scribe: i'd say media stream source should be a core part of HTML.next
... the other part i don't think we could get consensus on

adrianba: I want to support what chaals was asking for
... we want to enable people to participate in the things they're interested in
... as a general work practice, having that discipline makes life easier for everyone

Mark_Vickers: listening to chaals and tantek , i'm more convinced
... of handling the two things differently
... source has been out for about a year
... it's not as much of controversy
... as level of development
... i don't think it needs as much intense meetings
... for encryption, i think we need meetings much sooner
... and another one shortly after
... i think they may need to be handled differently
... i hope we can have this soon

acolwell: i agree with adrianba
... we want to be as inclusive for both proposals
... we, google, want to get this done
... we wanted to keep them separate so we could evolve them separately

mark: i don't have an opinion on process
... but decide soon
... what does it mean for something to be a core part of HTML.next?

paulc: i put this item on agenda before charter discussion
... chairs and team would like to go down the wiki items and say
... should these things be covered by scope of the charter for the WG

mark: if it isn't in the Charter, it isn't worked on the WG?

paulc: not without ReChartering
... back to Mark_Vickers about sooner
... the reason i suggested Sep was splitting the difference between now and TPAC
... what about a F2F at the end of june?
... and plh's blood is boiling

<tantek> there really seems to be different constraints, interests, urgency for Media src/streams vs. DRM.

paulc: talking about something for which we don't have a host?
... especially for Europeans who take August off
... where North Americans lose the first week
... of September to vacation
... but I want to make it clear we need a host

Mark_Vickers: there are 3 authors to this proposal
... we'd like to be part of a more intense group
... but i don't want to form a more exclusionary group
... i'd like to create more high bandwidth involvement
... but not forced to wait

chaals: i understand 2 weeks
... we flew 3 people from Europe to the meeting
... that was expensive
... if you want Soon, we could do Beijing
... or we could do Guteborg
... and we wouldn't object to short notice
... but this is W3C
... and part of this is dealing with the world

paulc: we're on the west cosat

s/cosat/coast/

scribe: we intentionally picked this
... for good attendance
... we're tentatively in Europe Oct 31-Nov 3

<tantek> I think decoupling Media src/streams vs. DRM would benefit *both*, i.e. permit the folks that want to urgently meet quickly on DRM to go ahead and do so in a more agile fashion, and reduce the number of folks to coordinate with for meeting time/place preferences etc.

scribe: for TPAC
... the general model is that Web Apps would meet Mon Tue

<tantek> woohoo - TPAC during Halloween again!

scribe: and HTML would meet Thu Fri
... the pattern since 2009
... Plenary on Wed
... some have W3C process in cache
... usual process in W3C is 8 weeks notice
... that doesn't preclude us

<adrianba> TPAC 2012

scribe: from having separate topical meetings by phone
... plh: anything to add about a F2F

plh: everything has been said
... would be concern about meeting F2F every two weeks
... a lot of work on participants

<glenn> won't be present at afternoon's session, but cox votes +1 for including Encrypted Media Extension in "core html.next" deliverables

Josh_Soref: this meeting painful for me to get to

acolwell: trying to schedule F2F now may be premature
... does it make sense to see where it goes before?

chaals: Josh_Soref isn't the only person
... there are people not in this room
... for the same reason it was painful for him
... you need to plan with a pile of lead time
... and you'll hit Summer
... two months of misery
... Americans don't work in July
... Europeans don't work in August
... from a practical perspective
... we should figure it out in the next week
... if you want to do it before you get buried in summer

paulc: it was strictly getting rooms
... which was the problem
... which is why we had to change dates
... as the person paying the bills
... it isn't cheap
... i even have to pay for security
... it's less expensive doing it here than in a hotel

chaals: i can get dirt cheap meeting space in Morocco

<joesteele> +1 for Morrocco

paulc: rubys, do you think we have enough feedback from the WG?

rubys: I think so

<joesteele> s/Morrocco/Morocco/

s/sam:/rubys:/g

paulc: the rest of you, please corner us 1-on-1
... if anyone wants to host, please let us know directly

glenn: presumably this wouldn't be the whole

paulc: at least one company indicated a willingness to divide focus
... i wouldn't be surprised if we divided the time
... if we needed a room for at least 30 people
... especially if Mark_Vickers indicated others might get engaged
... Duey - Truman phenomena

glenn: Cox can volunteer meeting space in Atlanta

BobLund: CableLabs can offer space in Denver

Mark_Vickers: Comcast can offer space in Philadelphia

mark: are the chairs saying we're going to work on these two items in ernest?

paulc: I'm not hearing dissent at all
... i'd like to agree on the order for after lunch

<joesteele> s/ernest/earnest/

paulc: everyone put up your hands if you'll be hear at 5pm
... raise your hand if you'll be here at 4pm
... raise your hand if you'll be here at 3pm
... looks like we're losing people at lunch
... chaals can scribe
... proposal: we move agenda down
... nice segway doing charter after lunch

s/segway/segue/

[ Lunch ]

Charter v.Next

plh: some of you are lucky enough not to be familiar with how we work
... when people look to joining the group
... you're committing to RF agreements
... so you go to the lawyers
... if i put a charter that said "you can do whatever you want"
... your lawyers will kill me right away

<rubys> http://www.w3.org/2007/03/HTML-WG-charter

plh: i put a list of things in the wiki
... of things we could put in the charter
... i'm only interested in In-Scope or Out-Of-Scope for the WG
... it doesn't affect how many Specs
... of course, we try to draw the charter to give freedom for the WG to, e.g. add a new html element
... this morning we had a discussion on Media Source and Encrypted Media extensions
... and you guys agreed to make a TF

No!

plh: oh, a ML
... can we assume you're ok with adding that to the charter

tantek: is there a methodology for what is in HTML WG v. Web Apps?

plh: i don't think there's a clear methodology
... sometimes it's historically

s/historically/for historical reasons/

tantek: let me put forth a straw proposal
... if something makes sense in a more focused WG
... maybe it can be in that WG

plh: I don't think anything in the proposal...
... except for Web Intents

tantek: sure

plh: I know hiro_away wanted to add http+aes/https+aes schemes

s/hiro_away/Hixie/

scribe: any objection to that?

paulc: you have that under media

ddorwin: I think it's generic

anne: it was in the proposals for Encrypted Media extensions

plh: i didn't hear someone say "we want it out-of-scope"

anne: that would seem kind of lame

paulc: why?

anne: it was a proposal in context for Encrypted Media

<ddorwin> to clarify, it was proposed as an alternative, not "in the proposals"

anne: so why exclude?

plh: then there was MikeSmith 's list
... one of the problems we're having is that we have other WGs extending HTML
... is there anything in that list that we'd rather do in the HTML WG?
... e.g., we rejected the ping= attribute for HTML5
... people should be free to bring it up for .Next
... two things to consider now:
... Web Components
... Web Intents
... they're currently in Web Apps
... at some point, Web Apps, was like "it seems outside our area, more into HTML than into Web Apps"
... should we add Web Components into scope for this WG
... or should we let Web Apps deal with it?

anne: HTML Parser will most likely change for Web Components
... if you want to keep defining HTML Parser, then you should add Web Components to Scope

chaals: The Web Apps charter says that
... ~ a "low barrier process to move stuff from one group to the other"
... the fact that you have to change the parser should be severable from defining Web Components
... HTML WG defines the Parsing
... i'm not sure you need a tight joint deliverable

plh: the Parser is already in Scope

chaals: we should ensure that the Parser is in Scope

anne: Web Components would tie into certain specific elements of the Parser

plh: does the deliverable need to be listed in the HTML spec?

anne: I, personally, think all HTML elements should be listed in the HTML spec

paulc: let's put it in the HTML WG charter

anne: it's unclear how we'd organize it

plh: i'd like to avoid the HTML WG later saying "let's put it in the HTML spec"
... and someone says "it's not in Charter"

chaals: let's put it in the charter

mjs: for specific elements
... it might be debatable where things should be developed
... but perhaps we should have a catchall item in charter
... to say anything that involves changes to the parser
... could be in scope either as a joint deliverable or sole deliverable

plh: i'm fine with something
... that says elements or attributes

paulc: "it's in the scope of the HTML WG to define the syntax of elements and attributes within the HTML elements"

mjs: as long as it says "this is a non exhaustive list of items"

paulc: "The following is a set of examples"

plh: would web intents fall into that?

MikeSmith: Web Intents is only one element
... and it wouldn't involve parser changes

paulc: who does that require coordination with?

Josh_Soref: DAP+WebApps

paulc: as a general principle, should the charter indicate who is currently working on items?

plh: yes

paulc: so we should include references to the other group's + deliverables

plh: i gather it's the same for the others
... we'd use this catch all sentence as well

paulc: this list
... has been accessible for quite some time
... is there any reason we wouldn't include the entire list?

tantek: more of a meta comment on the list
... there's an antipattern

<scribe> ... new person comes to web platform

UNKNOWN_SPEAKER: with new feature, requests new element
... i'd request the opposite
... we should be very conservative

paulc: why is that an antipattern

tantek: it's what every new person does
... and it's most often the wrong answer
... we have CSS, we have rel= attributes
... there are various other ways to do it
... that Browser devs know to do instead

mjs: do we have lists that proposed

<scribe> ... new types/rels?

UNKNOWN_SPEAKER: are there new attributes?

MikeSmith: this list doesn't cover new attribute values/apis

mjs: we shouldn't presume they'll be added in the form proposed
... i agree with not wanting to favor new elements
... "here are some examples of elements and features"

tantek: i'm for examples
... but not as elements

rubys: MikeSmith, "not for new attributes?"

MikeSmith: not new attribute _values_

plh: I don't think we should put that text
... it would be too descriptive
... i'd be fine with a generic statement from mjs

mjs: how about a generic statement and a link to a list of examples
... tantek: should features include "no elements", or does he object to an "exclusive list of elements"

tantek: I'm ok with a list of functionality
... "Web Intents is functionality"
... but <intent> is picking a specific solution

mjs: you want a list of Functional Areas
... but not to describe Syntax

tantek: right
... Syntax is inappropriate for a charter

paulc: i understand the point you're making
... the fact that the bad practice that you want to eliminate/avoid
... is that people view the HTML WG as owning the syntax/language
... the charter has to say that
... if someone does want to follow the antipattern of adding the new element
... but they should come to the HTML WG

tantek: that if you want a new element, you can come to the HTML WG

s/WG/WG?/

scribe: No. I'd rather it not say, and they be confused
... and have them ask, and be told, "no, do something else"

mjs: if people are confused, they won't know to whom to ask
... and they'll get the wrong answer
... and they'll decide it's ok to do

paulc: mjs stole my next question
... do you want the charter should say "no one else in w3c should be creating new elements in the html language"

tantek: no

cyns: Aria is a good example

tantek: +1 to cyns
... even the style attribute

<Zakim> MikeSmith, you wanted to speak

MikeSmith: ARIA is a good example of an extension developed outside HTML WG
... but which came back
... the idea of extensions being developed
... but never being folded back
... i think having new elements being created and not folded back
... i don't think that's a good idea
... let me talk about a specific example
... look at <speech> stuff
... there still isn't consensus
... on new features for speech/tts
... that there needs to be markup at all
... i'd argue if there doesn't need to be markup,
... then there's no need to coordinate
... "for these features, if new elements/attributes seem to be necessary/desirable
... ... then that work is in scope for the HTML WG"
... i'd further assert, that the group should consider
... whether it should restrict itself more to Markup features
... an example of this is WebGL
... <canvas> work was done before it came to HTML WG
... work continues to be done in HTML WG
... but it could be done somewhere else
... it was done somewhere else
... hypothetically, it could be bound to another element
... there are other APIs under discussion, today and in the future
... where the WG does not necessarily have to do the work on the APIs
... the work could be done ... elsewhere ... in a more efficient way
... WebGL is an existence proof
... there was no coordination with khronos about WebGL
... and it seems to have worked out fairly well

Josh_Soref: WebApps should have been more in that coordination

MikeSmith: The spec defines HTML as having an implied Namespace

<scribe> ... new elements and attributes

UNKNOWN_SPEAKER: APIs, if they aren't tied to elements/attributes
... we have interfaces in DOM
... for HTML elements
... and they have to be somewhere
... but we have things that aren't as tightly bound

mjs: it seems like there are two interesting dimensions to the charter
... we should mention both
... one is subject matter areas that the group can work on
... charters are not totally care on whether they're minimum or maximum scope
... if not working on them, they're considered to have failed
... there's also a technological area of focus
... CSS WG
... most acknowledge that if you want to introduce a new CSS attribute
... you should do it in CSS WG, or in conjunction with CSS WG
... I don't know if the charter says so
... but for HTML
... it should probably say that you should probably talk to the HTML WG
... if you want an Element, Attribute, Value, or Parser Change
... I think the charter should cover both the low level functional domain
... as well as subject matter areas open to work
... the second for IPR review
... and member companies may not sign off if you don't make reasonably clear
... I agree with tantek 's concern about not predefining the solution for an area

rubys: I agree we can make a stronger statement for parser changes

<scribe> ... new elements/attributes, different people will disagree

UNKNOWN_SPEAKER: anne made a point about Web Components
... parser changes should get HTML WG involved

plh: i don't say parser is in scope of HTML WG
... but i'm uncomfortable about saying "no one else can work on parser"
... we assert rights by coordination

rubys: can't you say as a positive statement "This is the group that defines the parser"

paulc: and you can put in the Liason section, "This is the group of possible offenders"
... WebApps for Web Components
... PF for ARIA
... etc.
... I agree the upper part of charter should say "we own this backyard, and no one else comes here"

plh: Canvas 2D additions
... i'm assuming no one will argue against doing those additions in the WG

[ No objections ]

plh: MikeSmith, the bugzilla component has other items

MikeSmith: the list was proposals that were Markup features

<MikeSmith> eh?

paulc: should the charter say
... "items deferred from HTML5 including the following"
... you have more experience than anyone in the room
... i've only listed 9 or 10

plh: in general, we try not to list

paulc: it's not uncommon to have
... deliverables that are requirements for the next version

plh: i'm under the impression the group would like more flexibility

paulc: the extremes are "leave the trap door open
... causing IPR pain"
... or you close the trap door, and cause the
... -- Make the charter vague enough that you fail AC review
... -- Make an interim charter causing the WG to deliver a set of features
... put that out to get feedback and do an explicit revised charter

plh: tantek would like to work on a <decompress> element

[ Laughter ]

chaals: where's the Line element?

plh: Fullscreen is being taken care of

paulc: does video enhancements

ddorwin: next frame is squishy

paulc: following mjs's request for a high level
... does this mean "additional forms functionality"?
... or "additional functionality based on existing language constructs"?
... tantek, don't throw your chair at me
... something that says "new elements and attributes", but "extensions to the existing language"

plh: looking at the existing charter

Josh_Soref: is there anything wrong with the current scope

s/scope/scope?/

<anne> "classic HTML" really?

scribe: there's a thing about workshops

<anne> that text is hilarious

plh: in general, we don't do that normally for charters

adrianba: I wanted to talk about 2.1
... this has things that are in scope
... it seems like a reasonable compromise
... maybe we can look at the other proposals

plh: do you think the media items are within scope for the existing charter?

adrianba: I've said before that i believe they are

cyns: second bullet from the bottom seems to cover it

plh: alright, if it's already in scope, we can already work on it as much as we want

paulc: is there anything we want to throw away

cyns: probably "evolved from html4"

rubys: still a true statement

Josh_Soref: do you want to move that thing about meetings?

plh: we can move that to another section

paulc: there are 7 bullets there

> A language evolved from HTML4 for describing the semantics of documents and applications on the World Wide Web. This will be a complete specification, not a delta specification.

plh: HTML4 => HTML5
... maybe remove the second sentence
... i'd suggest to remove it

mjs: +1

adrianba: +1

chaals: +1

[ General agreement ]

> An extensible, serialized form of such a language, using XML.

plh: during Web Apps
... the Web Components will only be applicable to one syntax, HTML, not XHTML
... to be allowed to do this thing...

paulc: is this particular bullet met and satisfied by the polyglot spec?

plh: you need the xhtml syntax to do polyglot

paulc: where is xhtml in our deliverables?

plh: it's in section 9

paulc: polyglot came in
... i'm wondering what words were in the original charter
... other than the director

adrianba: > This group will maintain and produce incremental revisions to the HTML specification, which includes the series of specifications previously published as XHTML version 1. Both XML and 'classic HTML' syntaxes will be produced.

chaals: what does this commit us to do
... and what does it except?

plh: as is the case anyway

chaals: here, it's reasonable to assume you can do html5 in xml
... we should make it clearer that you can't

plh: that there are differences between the two syntaxes?

chaals: yes
... there are semantic and capability differences

> A serialized form of such a language using a defined, non-XML syntax compatible with the 'classic HTML' parsers of existing Web browsers.

anne: why "classic"

adrianba: that's why it's classic

cyns: "classic is good"

anne: "classic" seems alien

chaals: "it sounds better than the moronist/crappy html"

anne: or the TAG call it "tag soup"

plh: i'm fine with s/'classic HTML'/HTML/

paulc: do you get rid of 'existing' if you get rid of 'classic'?

cyns: yes

paulc: it seems to imply if you had a new browser that came along

anne: HTML language with HTML an XHTML syntaxes

chaals: it's in this charter, because it was a big shift from what we had
... but now we have it

> Document Object Model (DOM) interfaces providing APIs for such a language.

Josh_Soref: wasn't there a DOM WG?

cyns: there was

chaals: Web Apps took over DOM Core

<MikeSmith> "An abstract language for describing documents and applications, with HTML an XHTML syntaxes, and some APIs for interacting with in-memory representations of resources that use this language."

chaals: the rest of DOM are belong to us

cyns: there's a piece missing
... about how the UA maps DOM to existing OSs

MikeSmith: does that need to be in the HTML WG?

cyns: I'm not sure who else would do it
... we have overlap

paulc: what's the deliverable

cyns: a document mapping how HTML constructs map to Accessibility constructs in a variety of platforms

<plh> http://dvcs.w3.org/hg/html-api-map/raw-file/default/Overview.html

paulc: you're saying the high level deliverables don't cover that deliverable

s|http://dvcs.w3.org/hg/html-api-map/raw-file/default/Overview.html|-> http://dvcs.w3.org/hg/html-api-map/raw-file/default/Overview.html HTML to Platform Accessibility APIs Implementation Guide|

paulc: a specification mapping HTML elements and attributes to accessibility API Roles
... States and Properties on a variety of platforms
... that would let this document map to that requirement

janina: this is important
... because there will be an HTML.next and an ARIA.next

cyns: and the platforms are evolving

> Forms and common UI widgets such as progress bars, datagrids, menus, and other controls.

cyns: we need more of those
... i don't think those are the right ones

rubys: the examples should be updated

cyns: chaals is bored, he wants a soap opera to watch

> APIs for the manipulation of linked media.

> Editing APIs and user-driven WYSIWYG editing features.

cyns: those still need work

paulc: is there anything we want to add?
... in general, are the things we've talked about adequately covered by the evolving bullets we have here?

cyns: which bullets covers canvas?

plh: interesting point

[ Uh ]

mjs: Man, I never thought we'd get to have this conversation

plh: maybe i should put some wording for the <canvas> element

mjs: at some point there was an addition for canvas

paulc: was that in a note to AC or in the charter?

> Data and canvas are reasonable areas of work for the group. On the one hand, they elaborate areas touched on in HTML4. On the other hand, these elaborations are much deeper than the features of HTML4, but also they form separate subsystems, and these subsystems have strong overlaps with other design areas.

plh: so, we should make sure microdata is in scope as well?

paulc: update the bullets
... and then reverse engineer the bullets from the deliverables
... Accessibility Document
... Canvas
... Polyglot (covered, but obscurely)

MikeSmith: why does Canvas 2d need to be in HTML WG
... where WebGL isn't?
... is it historical?
... assuming it's the right place is maybe not the right assumption

plh: do you want to create another?
... anyone want to do it outside the WG?

MikeSmith: alright, let's resolve then

rubys: if someone actually proposed that
... i think we should consider it

paulc: are we done?

plh: there was DOM Parsing and Serialization

ISSUE-184?

<trackbot> ISSUE-184 -- Add a data element -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/184

ISSUE-198?

<trackbot> ISSUE-198 -- Ensure innerHTML and related APIs are subject to the W3C patent policy -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/198

rubys: ISSUE-198 failed for lack of an editor
... microsoft identified an editor
... it's now in scope of chairs
... proposal to change
... assumption in W3C
... this came up during web apps charter

plh: it's in Web Apps charter atm

chaals: that charter has been finished and approved
... does HTML want to fight us for it?

paulc: i sent an email to the cochairs
... didn't this material come out of html spec?

anne: yes

paulc: straw man, doesn't it make sense to do it here, since it's from here?

hober: a number of things have been spread out

anne: html spec is too big
... and once spun out, it's also wrong

mjs: there was an individual from ms who volunteered to do the work
... would he object to do it if it were a webapps deliverable instead of in html?

paulc: we'll pass on your question

rubys: shouldn't we get the editor's input?

paulc: yes
... cochairs should discuss this
... given we have a volunteer to do the work
... and we'll get back to both WGs with a proposed solution

plh: it's in scope of Web Apps

paulc: that's a likely solution

<anne> (my "too big" was a quote)

paulc: plh, on Apr 24
... you sent out a proposal to have a charter
... are you going to take our input today and go directly to AC?

plh: no, i'd like to write a charter
... to ask MikeSmith to do it
... and circulate it to the WG

paulc: can we have a time table for tha?

s/tha/that/

plh: MikeSmith ?

MikeSmith: next month?

chaals: the first or second?

MikeSmith: not likely i can do it by the end of this month

ACTION MikeSmith to draft revised HTML WG charter for May 31

<trackbot> Created ACTION-212 - Draft revised HTML WG charter for May 31 [on Michael[tm] Smith - due 2012-05-11].

<MikeSmith> action-212 due May 312

<trackbot> ACTION-212 Draft revised HTML WG charter for May 31 due date now May 312

<MikeSmith> action-212 due May 31

<trackbot> ACTION-212 Draft revised HTML WG charter for May 31 due date now May 31

paulc: plh, are we done?

plh: i believe so

[ Time check ]

[ Short Break ]

s/Short/Cookie/

paulc: sometimes the HTML WG doesn't have good notes from meetings
... i suspect this will be an exception
... on behalf of the HTML WG

[ paulc presents a bottle of Red Wine to Josh_Soref, scribe ]

[ Applause ]

ISSUE-204

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

s/Topic: ISSUE-204/Topic: ISSUE-204 ARIA-Hidden/

hober: there have been several proposals
... the major point of disagreement
... is whether or not
... the spec should mandate that the content of the individual
... element should be flattened in the Accessibility tree

cyns: as far as i can tell
... the diff is hard to read
... you deleted almost the same things i deleted
... the options
... and we can go into which are feasible
... later
... aria-described-by/aria-labeled-by
... you could flatten it and do the name calculation
... which puts a strain
... or you could create a subtree
... out of what it's pointing to

mjs: i think the other proposal doesn't specify how to do it
... which leaves it to the Aria implementer's guide

hober: which avoids baking in flattening

cyns: the reason flattening is called out explicitly
... what happens now for similar calculations
... is it goes into a string field
... with a certain length
... markup stripped out
... if what you point to is a complex marked up tree
... that's problematic
... but sometimes what's in there is text
... and it works well enough
... what i tried to do in my proposal
... is make clear that's how the api works
... and how it fits into the api strucutre

s/strucutre/structure

scribe: and make it clear to authors what you want in there

mjs: are you saying Aria spec requires it
... or all implementations do it
... or it's fundamentally impossible to do

cyns: 1 and 2 yes
... not sure about 3

mjs: 3 i know it's false

hober: good to know

mjs: anything in dom, it's possible to expose with full semantics
... it's possible to put into the accessibility tree

cyns: it seems like a very
... i agree it's technically possible
... it seems a strange implementation

hober: my understanding is that the accessibility tree is based on the content of the render tree
... but we don't create things for elements that aren't displayed

cyns: i don't think we do that for native applications
... i don't think we do that for nodes not part of the ui
... it isn't how UIA works
... it seems strange from how ATs
... and how users are used to things
... what we do now with similar constructs is "you may grab text"
... or you may do nothing

hober: for us, we may grab text

cyns: what does VoiceOver do with that
... is it similiar with that

mjs: we don't have anything like that
... but it could work like:
... when you're on an element
... it could work the same way as if it were directly
... whether content was visible to sighted users or not
... often we're faced with content that's offscreen

cyns: you have offscreen content?

Josh_Soref: "skip to content" is offscreen

JF: the more complex the tabable offscreen element is
... if you tab through offscreen elements
... it's a horrible UE

s/UE/UX/

mjs: when I mean keyboard navigation
... i do not mean tab navigation
... VoiceOver has special navigation
... for character by character
... word by word
... etc
... when VoiceOver does this
... it has a box so sighted users can see what the user is hearing
... it's possible to structure stuff so it's visible on screen
... i agree focusable controls may be a separate issue
... tables, rope commands
... may be doable
... i'm not claiming we have it implemented now
... but based on my understanding of what we have
... i'd be sad if we couldn't do this

<cyns> http://www.w3.org/html/wg/wiki/Correct_Hidden_Attribute_Section_v2

s|http://www.w3.org/html/wg/wiki/Correct_Hidden_Attribute_Section_v2|-> http://www.w3.org/html/wg/wiki/Correct_Hidden_Attribute_Section_v2 Correct Hidden Attribute Section v2|

> User agents should not create accessible objects in the platform accessibility API tree for elements that have the hidden attribute specified.

mjs: what's the justification around SHOULD NOT

cyns: I don't know how to create a reasonable UI

mjs: for tables
... what's the reason not to?

cyns: it doesn't fit with how things work now
... it's a documenting how things work now

mjs: documenting is ok
... as a warning
... but a 'should'

cyns: it was focusable elements

paulc: "SHOULD NOT" means "you shouldn't do it unless you have a good reason"

rubys: can you flip it to
... "Authors should not presume"

cyns: maybe we could make it tighter
... I'm not sure how to build the tree in UIA

mjs: i'm not sure
... i could see how it's fair to create a warning to authors
... that requires to be understandable
... users have to understand the scemantics

cyns: i think we may want to be more careful with focusable elements

hober: if a couple years from now
... they did think of a good way to do it

cyns: i could see that
... but i'm worried that people would think that's a good idea
... there's a worry that people spend all their time
... thinking about visual readers
... putting things offscreen as a good thing for accessibility
... is an antipattern

mjs: how do you handle offscreen?

cyns: keyboard focus goes offscreen
... if i find that on a microsoft site, i try to shop it from shipping

mjs: it seems that if a user tabs to something offscreen
... you should temporarily show it
... if a UA can give a better experience
... i think they should be encouraged to try
... i can see the argument for not encouraging authors to try
... while they do not exist

cyns: would you be comfortable with a
... "browsers may flatten, they may create a subtree"

mjs: by may, that'd be fine

cyns: I meant MAY

mjs: it seems that should be in the aria-implementers-guide
... it seems weird to be in the html spec

cyns: so if we shortened this significantly
... so hidden was exempted from
... aria-described|labeled-by
... from no-render
... and then put the rest of it in aria-implementation-guide

hober: if we did that, it would be substantially closer to the other proposal

cyns: what do you guys think about that?

janina: i'm having trouble understanding hober

chaals: hober said that gets us closer to agreement

hober: i think sicking wants us to require the full semantics to the AT

s/AT/AT Tree/

paulc: is that the second difference?

hober: it's the same different

s/different/difference/

mjs: is that opinion in the change proposal?

hober: the change proposals on the table do not capture sicking's desire

mjs: probably because that's an ARIA requirement

cyns: and no one i've spoken to would support

JF: something we've said can't and won't work
... that isn't really feasible

<paulc> Jonas CP: http://www.w3.org/html/wg/wiki/ChangeProposals/AllowAriaReferHidden

cyns: looking at the two change proposals
... we could get consensus by moving controversy to a new document

JF: that just moves the rub somewhere else
... we need to clearly communicate to content authors the limitation of doing this
... we have no evidence of seeing this behavior from other browsers/OSs
... not saying this to be dismissive
... when content authors are creating content
... it's for all browsers on all platforms
... but without commitment from everyone

cyns: or have UIs for how it would work

mjs: a proposal
... remove the restriction from html5 on linking to hidden content
... and include a warning that many implementations may give a limited version
... including flattening text
... and the actual hard requirements on what UAs are allowed to do
... would be deferred to the ARIA specification/implementers guide

JF: the change proposal that cyns presented
... was a collaboration of the ARIA members
... it'd be unfair to give a definitive answer

mjs: acknowledging that different people may have different opinions

cyns: i'm having a hard time channeling people
... with whom i don't agree
... personally... moving the discussion of flattening
... into ARIA/accessibility implementation guide
... is probably fine
... but when i suggest anything close to that, flame wars errupt

janina: i think it would further delay us
... we're already 13 months delayed

JF: we're often told, we want to get this guidance into the HTML5 spec
... authors want one point of reference
... so in html5 you'd say "it's ok, but go to aria to make sure it's ok"
... it's kind of like punting it to a document that will have less readership

mjs: i'm suggesting the warning to authors would be in the html 5 spec
... and then a bit to the implementers in the other document

JF: and that's down to the strength of the warning
... if it's sufficiently foreboding enough
... paulc's SHOULD
... "you really shouldn't"
... there has to be a strong justification
... if we could invoke this is a warning
... or make it a SHOULD NOT
... then i think some of the more problematic responses within the larger group could be addressed

chaals: how you put it is important
... and how you put it depends on where the platform goes

<mjs> Current warning to authors => "This technique should not be used for longer content that has structured text (e.g., headings, anchors, list markup, table markup, etc.), as accessible name and description calculation [WAI-ARIA] will flatten the referenced elements to plain text, losing interactivity and semantic structure."

chaals: if MS holds a significant share of the platform for users
... then trying to drive them around by misleading authors
... is wrong
... by the same token, i'd expect and hope that ms won't sit with no flattening for 140 years
... a warning that matches a reasonable sense of expectations
... points to the aria documentation
... where it gets defined

<mjs> Proposed warning to authors => "This technique should not be used for longer content that has structured text (e.g., headings, anchors, list markup, table markup, etc.), because the content may be presented only as flattened plaintext. Authors should not assume that full semantics will be preserved."

chaals: and not putting an explicit requirement that you can't do anything better
... does put a modicum of pressure on people to upgrade

cyns: what i'm hearing is
... removing a UA SHOULD NOT
... and adding an Authors SHOULD NOT

mjs: there is an Authors SHOULD NOT
... in cyns's proposal
... "This technique should not be used for longer content that has structured text (e.g., headings, anchors, list markup, table markup, etc.), as accessible name and description calculation [WAI-ARIA] will flatten the referenced elements to plain text, losing interactivity and semantic structure."
... I suggested an alternative
... "This technique should not be used for longer content that has structured text (e.g., headings, anchors, list markup, table markup, etc.), because the content may be presented only as flattened plaintext. Authors should not assume that full semantics will be preserved."

cyns: that seems good
... it seems like we should add something about focusable stuff

<chaals> [+1 to mjs' proposed text as written by mjs above.]

janina: that suggests it may be ok in many circumstances
... i don't think you have that much marketshare yet
... i'm disagreeing
... there will be more breakage
... the warning is too weak
... make it stronger, that's fine

cyns: did you have a suggestion?

paulc: this is the chair
... in sicking's proposal
... he gives as credible evidence
... the position of Apple + Mozilla
... of what Firefox can do
... does the counter proposal discredit that as not sufficient

cyns: I quoted that as well
... the quotes
... say "apple doesn't have a strong feeling either way"
... i didn't hear "we plan to do this in 18 months"

JF: it's easy to say "browser can solve world peace"

mjs: we don't have a strong view on author's conformance
... everyone seems to agree that it's ok to point to hidden content
... the issue is what authors should be aware of when they use the technique
... the original point to which we didn't have strong feelings is no longer a controversy

<chaals> [I still think pointing to hidden text is an anti-pattern, but I'm not dying on that hill]

cyns: an Authors SHOULD NOT as a validation warning with appropriate text
... because it doesn't work now
... and no one thinks it will work anytime soon

paulc: part of the concern is implementation plans
... if we came down to a survey
... whether cochairs would be comfortable making a decision around that grounds alone
... we'd be more comfortable making a decision on caution signs

janina: something quantitative would help

chaals: you can't quantify this against when we might have something in the future

rubys: we're talking about modifying one or both proposals
... chairs will not craft a mix+match proposal when we go to survey
... cyns, you might expect a very strong objection
... to your proposal

cyns: i'm not tied to it

rubys: we might pick the other one

cyns: i'm comfortable with it
... but others may take convincing

paulc: maybe for HTML5 you can get an Authors MUST NOT

cyns: it's the UA requirements that people object to
... do you think sicking would be ok with that

hober: i'd assume he's less concerned w/ Authoring requirements

JF: i hear this as reducing the implementation sticking point

cyns: this is machine testable, and a violation

JF: it can be author guidance in the spec
... and WAICAG

cyns: so, remove the UA requirement
... and add an Author MUST NOT
... not machine testable doesn't seem like a good must

hober: we have lots of none machine testable

mjs: MUST NOT USE v. MUST NOT RELY ON
... you aren't letting Authors

cyns: that sounds like a SHOULD NOT

janina: I'd be ok with that

JF: We'll get there
... it won't be a walk in the park

cyns: we can put the stronger text in ARIA

JF: and WAICAG
... authors are going to see this as some magic token thing that will make things disappear
... today there are significant problems
... maybe down the road someday, things may get better
... we don't want to restrict browsers from getting better
... the more you can do to make the UX better

s/..../.../

scribe: there's been discussion about making things better

janina: otoh, today, there's an unmet need

paulc: actions today?

cyns: for me to redraft the details section of the proposal

JF: i'll help

hober: and i'll try to run it by sicking
... and maybe we'll drop the other proposal

paulc: we split 204 off 30

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

paulc: if we get consensus on 204
... it unblocks ISSUE-30
... do we need to make changes to proposals on ISSUE-30

cyns: i'm not sure what the proposals are on ISSUE-30
... but this is less rich than this
... since LONGDESC links to a structured document

mjs: the authors of those proposals may want time to redraft those proposals

rubys: if sicking's proposal were done
... i can see proposals for don't use LONGDESC being enhanced

paulc: if we get consensus on cyns 's proposal
... (modified)
... if we don't get consensus
... go to survye

s/survye/survey/

scribe: and sicking's is the winner
... then it's possible the 30

hober: i don't think cyns's modified is much different from sicking's

cyns: sicking's proposal
... suggested a structured hidden thing
... but unicorns

paulc: LONGDESC does point to a structured HTML file
... but hidden with aria-described-by for a year would not

<tantek> what if LONGDESC pointed to data URL text/plain?

JF: the issue with 30 is: no exit strategy

cyns: to be fair, impl of longdesc in browsers is spotty today
... a flat string today everywhere
... is better than spotty longdesc today
... what we're talking about here is easier to implement

paulc: i heard cyns and JF to do a proposal

hober: I'll work with sicking to review the revised proposal

paulc: to make a decision of "can you live with the modified proposal"

rubys: will sicking be at the CSS WG?

hober: no

JF: i'd like it done soon
... i can do some drafting

ISSUE-184?

<trackbot> ISSUE-184 -- Add a data element -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/184

JF: accessibility team will mean Tue+Thu of next week
... cyns and i will work together
... i'll take driver's position
... to tech team before sicking
... by the 15th of may

paulc: janina, can judy invite me to the meeting
... hober late next week in your hands

ISSUE-203?

<trackbot> ISSUE-203 -- All Media Elements should have the ability to have both short and longer textual descriptions associated to the element -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/203

paulc: on behalf of the WG, Josh_Soref, thanks very much
... i understand the french wine is much better than the California wine
... we have a meeting next week

<krisk> Testing Status Update -> http://www.w3c-test.org/html/tests/reporting/HTML5_Status_5_4_2012.pdf

paulc: 8am for accessibility, and WG at 9am
... mjs: who's chairing?

mjs: i can do another

krisk: i can help

paulc: thanks everyone
... chairs will have a proposal for media soon
... see many of you at TPAC
... thanks very much

janina: thanks to MS for hosting

[ Applause ]

[ Adjourned ]

trackbot, end telcon

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/presentzajkim, Paul_Cotton has entered F2F//
Succeeded: s/aaron_colwell:/acolwell:/
Succeeded: s|http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html|-> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html Media Source specification|
Succeeded: s/elemnt/element/
Succeeded: s/a media/an initialization/
Succeeded: s/elemnt/element/
Succeeded: s/single/signal/
Succeeded: s/.. and/... and/
Succeeded: s|Events -> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#event-summary|-> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#event-summary Events|
Succeeded: s|Byte Stream Formats -> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#byte-stream-formats|-> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#byte-stream-formats Byte Stream Formats|
Succeeded: s/each impl/each implementation/
Succeeded: s|http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#open-issues Open issues|-> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#open-issues Open issues|
Succeeded: s/... i/... i'll simulate congestion/
Succeeded: s/+q/q+/
Succeeded: s|http://git.chromium.org/gitweb/?p=webm/webm-dash-javascript.git|-> http://git.chromium.org/gitweb/?p=webm/webm-dash-javascript.git acolwell's Demo|
Succeeded: s|content creation guide: https://sites.google.com/a/webmproject.org/wiki/adaptive-streaming/instructions-to-playback-a-webm-dash-presentation|-> https://sites.google.com/a/webmproject.org/wiki/adaptive-streaming/instructions-to-playback-a-webm-dash-presentation Content creation guide|
Succeeded: s/you're/as mark_vickers said, you're/
FAILED: i/aaron_colwell: should I project/Topic: Media Source Extensions
Succeeded: s/Topic: Encrypted Media Extensions//
Succeeded: i/Encrypted Media Extensions -/Topic: Encrypted Media Extensions
Succeeded: s|Encrypted Media Extensions - http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html|-> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html Encrypted Media Extensions|
Succeeded: s/Dowin/Dorwin/
Succeeded: s/mark:/acolwell:/
Succeeded: s/pipleine/pipeline/
Succeeded: s/...being/... being/
FAILED: s/stak/stack/
FAILED: s/roun/round/
FAILED: s/sysem/system/
FAILED: s/growt/growth/
FAILED: s/reconicile/reconcile/
FAILED: s/XX and YY/Web and TV IG and Protocols and Formats WG/
Succeeded: s/ban/can/
FAILED: s/... what's/ddorwin: what's/
FAILED: s|http://lists.w3.org/Archives/Public/public-html/2012Apr/0007.html|-> http://lists.w3.org/Archives/Public/public-html/2012Apr/0007.html CfC Create Media Task Force|
FAILED: s/+1 on "these/+1 - noting particularly the "these/
Succeeded: s/... we/paulc: we/
FAILED: s/uncontroverisal/uncontroversial/
FAILED: s/cosat/coast/
FAILED: s/Morrocco/Morocco/
FAILED: s/sam:/rubys:/g
FAILED: s/ernest/earnest/
FAILED: s/segway/segue/
FAILED: s/historically/for historical reasons/
FAILED: s/hiro_away/Hixie/
FAILED: s/WG/WG?/
FAILED: s/scope/scope?/
FAILED: s|http://dvcs.w3.org/hg/html-api-map/raw-file/default/Overview.html|-> http://dvcs.w3.org/hg/html-api-map/raw-file/default/Overview.html HTML to Platform Accessibility APIs Implementation Guide|
FAILED: s/tha/that/
FAILED: s/Short/Cookie/
FAILED: s/Topic: ISSUE-204/Topic: ISSUE-204 ARIA-Hidden/
FAILED: s/strucutre/structure/
FAILED: s/UE/UX/
FAILED: s|http://www.w3.org/html/wg/wiki/Correct_Hidden_Attribute_Section_v2|-> http://www.w3.org/html/wg/wiki/Correct_Hidden_Attribute_Section_v2 Correct Hidden Attribute Section v2|
FAILED: s/AT/AT Tree/
FAILED: s/different/difference/
FAILED: s/..../.../
FAILED: s/survye/survey/
No ScribeNick specified.  Guessing ScribeNick: timeless
Inferring Scribes: timeless
Default Present: F2F, Josh_Soref, MikeSmith, +1.858.677.aaaa, paulc, JF, janina, bryan, sam, Arno_, glenn, Arnaud_Braud, Paul_Cotton, Adrian_Bateman, Russell_Berkoff, Peter_Peterka, Odin_Horthe_Omdal, plh, Aaron_Colwell, frankolivier, anne, hober, Wonsuk, +1.650.576.aabb, BobLund
Present: F2F Josh_Soref MikeSmith +1.858.677.aaaa paulc JF janina bryan sam Arno_ glenn Arnaud_Braud Paul_Cotton Adrian_Bateman Russell_Berkoff Peter_Peterka Odin_Horthe_Omdal plh Aaron_Colwell frankolivier anne hober Wonsuk +1.650.576.aabb BobLund Yosuke_Funahashi Magnus_Olsson Soonbo_Han David_Dorwin Russell_Berkoff(Samsung) Bryan_Sullivan Wonsuk_Lee
Agenda: http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 04 May 2012
Guessing minutes URL: http://www.w3.org/2012/05/04-html-wg-minutes.html
People with action items: