See also: IRC log
trackbot, start meeting
<trackbot> Date: 04 May 2012
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 rubys 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 stabilization 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
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
... 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: implementation-wise
<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 each other
... they need to cover the Encryption use cases
... there's a need for them to interoperate
<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 mid-playback
... 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 on-demand
... 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 bandwidth estimation
<ddorwin> Encrypted Media 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 sometime 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 arise
... 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
... 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
... and 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 signaling
... you have something playing
... the browser Open Media Stack
... and browser with Closed Media Stack
... and running your captions through the Open Media Stack
... you need signaling between the two
adrianba: you mean for timelines?
chaals: yes
adrianba: I think timelines work the same way it does generally for the media stack
... 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 seamlessly 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 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 system
... 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 growth
... 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 reconcile
... any remaining questions
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: Web and TV IG and Protocols and Formats WG met at TPAC
... and we're pretty satisfied
paulc: and you're a co-chair of PF?
janina: I'm a co-chair of PF
mark_vickers: I'm a co-chair of Web and TV
... as is yosuke
ddorwin: what's added are 3 methods and
... we've extended canPlayType
... example code can be this much
<adrianba> Extension APIs
ddorwin: fairly simple
... for the demo
... an official Chrome build with flags enabled
<adrianba> Code Examples
ddorwin: 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
... 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
<chaals> [clearKey is a demo DRM that you can look inside...]
<ddorwin> Encrypted Adaptive Demo
<rubys> CfC Create Media Task Force
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
... 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
... 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 Co-chairs + 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 - noting particularly the "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
paulc: 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 uncontroversial
... 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 Gothenburg
... 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 coast
... 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.
paulc: for TPAC
... the general model is that Web Apps would meet Mon Tue
<tantek> woohoo - TPAC during Halloween again!
paulc: 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
paulc: 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 was 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 Morocco
paulc: rubys, do you think we have enough feedback from the WG?
rubys: I think so
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
... Dewey - 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 earnest?
paulc: I'm not hearing dissent at all
... I'd like to agree on the order for after lunch
... 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 segue doing charter after lunch
[ Lunch ]
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 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 Hixie wanted to add http+aes/https+aes schemes
... 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 anti-pattern
... new person comes to web platform
... with new feature, requests new element
... I'd request the opposite
... we should be very conservative
paulc: why is that an anti-pattern
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
... new types/rels?
... 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 anti-pattern 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?
... 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
... new elements and attributes
... 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
... 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
... new elements/attributes, different people will disagree
... 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 Liaison 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?
<anne> "classic HTML" really?
Josh_Soref: 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> HTML to Platform Accessibility APIs Implementation Guide
paulc: you're saying the high level deliverables don't cover that deliverable
... 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 co-chairs
... 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 Microsoft 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
... co-chairs 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 that?
plh: MikeSmith ?
MikeSmith: next month?
chaals: the first or second?
MikeSmith: not likely I can do it by the end of this month
plh: 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 ]
[ Cookie Break ]
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?
<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
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 structure
... 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 similar 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 off-screen
cyns: you have off-screen content?
Josh_Soref: "skip to content" is off-screen
JF: the more complex the tabable off-screen element is
... if you tab through off-screen elements
... it's a horrible 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> 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 semantics
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 off-screen as a good thing for accessibility
... is an anti-pattern
mjs: how do you handle off-screen?
cyns: keyboard focus goes off-screen
... 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 off-screen
... 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 Tree
paulc: is that the second difference?
hober: it's the same 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 erupt
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 Microsoft 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 co-chairs 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
... 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 survey
... 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
<krisk> Testing Status Update
paulc: we have a meeting next Week
... 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