See also: IRC log
<trackbot> Date: 29 April 2015
<janina_> agenda: this
<scribe> scribeNick: jamesn
JS: have edits from GV
... worked hard to make sure the minutes were very accurate. Will be a nice resource if it comes up again
... are there any further edits
... objection to posting?
RESOLUTION: post 04/08 minutes to public list
... post 04/22 minutes to public list
ACTION-1615?
<trackbot> ACTION-1615 -- Janina Sajka to Review media capture and streams http://www.w3.org/tr/mediacapture-streams/ -- due 2015-04-29 -- OPEN
<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1615
JS: another week
<MichaelC> action-1615 due 1 week
<trackbot> Set action-1615 Review media capture and streams http://www.w3.org/tr/mediacapture-streams/ due date to 2015-05-06.
MC: that is it for recent spec actions
... have some ancient ones we can give up on
ACTION-1616?
<trackbot> ACTION-1616 -- Fred Esch to Review gamepad http://www.w3.org/tr/gamepad/ -- due 2015-04-22 -- PENDINGREVIEW
<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1616
FE: waiting to be closed
<MichaelC> close action-1616
<trackbot> Closed action-1616.
<MichaelC> W3C DOM4
DOM defines a platform-neutral model for events and node trees.
SM: no need to review as a minor change
<MichaelC> UI Events (formerly DOM Level 3 Events)
JS: think we should look to see if the issues we care about have been tweaked in any way
<ShaneM> DOM4 spec at http://www.w3.org/TR/2015/WD-dom-20150428/ has a WARNING in the status section
JS: propose come back to this at another time
... lets record an action
<MichaelC> ACTION: janina to get group to look at UI Events (formerly DOM Level 3 Events) http://www.w3.org/TR/uievents/ - due 30 June [recorded in http://www.w3.org/2015/04/29-pf-minutes.html#action01]
<trackbot> Created ACTION-1627 - Get group to look at ui events (formerly dom level 3 events) http://www.w3.org/tr/uievents/ [on Janina Sajka - due 2015-06-30].
<MichaelC> DOM Level 3 KeyboardEvent key Values
<MichaelC> DOM Level 3 KeyboardEvent code Values
<MichaelC> ACTION: nurthen to review DOM Level 3 KeyboardEvent code Values http://www.w3.org/TR/DOM-Level-3-Events-code/ and DOM Level 3 KeyboardEvent key Values http://www.w3.org/TR/DOM-Level-3-Events-key/ [recorded in http://www.w3.org/2015/04/29-pf-minutes.html#action02]
<trackbot> Created ACTION-1628 - Review dom level 3 keyboardevent code values http://www.w3.org/tr/dom-level-3-events-code/ and dom level 3 keyboardevent key values http://www.w3.org/tr/dom-level-3-events-key/ [on James Nurthen - due 2015-05-06].
JS: relative to audio controls would be suprised if there a way to direct it to multiple audio devices
<MichaelC> action-1628 due 1 month
<trackbot> Set action-1628 Review dom level 3 keyboardevent code values http://www.w3.org/tr/dom-level-3-events-code/ and dom level 3 keyboardevent key values http://www.w3.org/tr/dom-level-3-events-key/ due date to 2015-05-29.
<MichaelC> Privileged Contexts
This specification provides guidelines for user agent implementors and spec authors for implementing features whose properties dictate that they be exposed to the web only within a trustworthy environment.
MC: looks to be guidelines. Maybe we can pass on it
<MichaelC> Upgrade Insecure Requests
This document defines a new Content Security Policy directive, upgrade-insecure-requests, through which authors can make this assertion. Note: Delivering the policy as a header allows an administrator to easily opt a set of pages into the upgrade mechanism without touching their source code individually. The legacy content examples above would not be feasible with an approach that inlined the policy into HTML, for example.
MC: defines switching to HTTPS etc.
... can let this pass
<MichaelC> Manifest for a web application
tz: we reviewed this.... if icon is the only issue you have with this then great
<MichaelC> ACTION: nurthen to review Manifest for a web application http://www.w3.org/TR/appmanifest/ - due 1 month [recorded in http://www.w3.org/2015/04/29-pf-minutes.html#action03]
<trackbot> Created ACTION-1629 - Review manifest for a web application http://www.w3.org/tr/appmanifest/ [on James Nurthen - due 2015-05-29].
<tzviya> http://w3ctag.github.io/packaging-on-the-web/
tz: the concept of a manifest is pretty broad. Recommend looking at packaging too
... then you get into service workers
<MichaelC> action-1629: will need to look at previous threads on this, see https://lists.w3.org/Archives/Member/wai-liaison/
<trackbot> Notes added to action-1629 Review manifest for a web application http://www.w3.org/tr/appmanifest/.
jn: may have gone through a rename
MC: no "new" groups
SM: there is a schema.org CG now which is super active. I am monitoring it. When talking about dpub role semantics is that we might want to find a way to promote role values as meaningful semantics to the schema.org community
... want to loop in somebody else from this group at some point
... I think there is a lot of value here to content developers
MC: will add to list of groups
RS: can loop me in when you think it is time
tz: Matt Garish oversaw the a11y stuff and submitted the testing classes
... can you mention this at the TF meeting.
rs: roles used to be NameSpaced
JS: should i be putting out a 48hr consensus
tz: hold off until meeting tomorrow
... debate is going way beyond dpub and aria
... will have a conversation at the tf meeting. need a discussion as to what an aria module is etc.
js: may not get full agreement but only need consensus depending on what the issues are
rs: we had a lot of additional roles called into question
<tzviya> https://rawgit.com/w3c/aria/master/aria/dpub.html
rs: lets put a link to the rawgit draft
... regarding modularization. the hypens is what we were planning for graphics.
... we worry about this in the accessibility api mappings guide.
... need to figure out how we address it
tz: the prefixing issue - we understand why it is a concern
... the hypen spacing had a concern in general. If that is the way the modules are going forward we need to look at it
js: some challenges that the terms seem unnecessary
tz: epub 3.1 may need to be cleaned up some terms
js: I don't think we will make it b4 the moratorium around the AC meeting but as soon as it expires on the 11th we could be ready
rs: this discussion is getting dispruptive
mc: this is a FPWD have to have ready and approved a week b4 publication. Need to publish by may 14 at latest
need WG decision b4 may 7
rs: we have things in the spec that we have issues on. Making it so onerous for the dpub group is a bit over the top.
JS: can we create an editors draft for call for consensus
... can still make our deadline
ls: cascading semantics
<Zakim> joanie, you wanted to ask if "not make it before the moratorium" includes ARIA core.
jn: asked about multiple vocabs etc.
<Lisa_Seeman> here it is... http://www.w3.org/WAI/PF/natural-lang-20030326.html
<Zakim> ShaneM, you wanted to ask about publication
jd: wanted to check that was specifically about dpub
js: yes
sm: a pull request with JS fix which hasn't been merged.
... i want to merge it. will do this PM
JD: if you are cool with the JS then ok. I just want to check the child script and then merge it
... will do it now
<Zakim> MichaelC, you wanted to say I have urgent charter stuff to discuss
MC: there are 3 things i need answers on
... did a quick survey
... 2nd question is would there be concerns if a public group
... 3rd are there objections or support for splitting spec review and aria
... 2 respondants with potential IP concerns
... is it enough reason to tell the group we can't do that
... the plan is for CSS to take the parts they want to.
RS: at the very least there should be a TF working with CSS
MC: not sure indieUI will be rechartered - there may be no home in WAI if APA doesnt take it
... no formal conversation but a few have been taken up
JN: could it move to a CG until someone wants to do something with it
MC: I can't spend time in a CG.
RS: I like the TF thing
CS: maybe there are people who would want to do this in a CG
... People involved in GPII might want to be involved
MC: IndieUI will be discussing a CG. The question is would be take it. There maybe concerns from some
RESOLUTION: we have a lukewarm yes on IndieUI contexts in APA
MC: splitting spec review vs aria
... if we are willing to split should it happen
RESOLUTION: The PFWG accepts splitting the functions so long as the spec review remains a WG function and does not move to the IG
MC: public vs member space
RS: my take is public space
CS: MSFT wants public
<richardschwerdtfeger> IBM wants public
<joanie> Igalia wants public
MC: any objection to the group going public?
RESOLUTION: PF will move to public space