chaals-o: thinks no one will remember anyone's name
... please speak slowly.
<xfq> https://github.com/w3c/html/issues/845
chaals-o: We say UA must validate all email addresses and must use ASCII only
r12a: Spec may say domain part may be Unicode?
chaals-o: user name must be ASCII, the other part can be validated against punycode.
r12a: universal acceptance program at ICANN, I hear folks are using the non-ascii in the user-name
... some apps don't allow this... it's a bit of chicken-and-egg problem.
... one part of the cycle is HTML spec only allows ASCII on user-name, but folks want to use full Unicode.
chaals-o: (channeling Sangwhan) input type=email is an anti-pattern. We should just burn it with fire and purge it from spec.
... 3/4 courses of action
... 1. delete it
... 2. leave it, cause it's perfect
... 3. change to allow non-ascii in email address
... 4. change to allow non-ascii in email + say it's obsolete and shouldn't be used.
... Is one of these options better than the others?
... I suggest striking option 2 (leave it)
... seeing some nods... (are you all asleep)?
... should we keep it (input type=email); should it stil b ein the spec?
Shwetank: still see some value in it; if we can specify it more explicitly. Server-side checking of email is still necesary
... but still value in having some validation on the client.
jsbell: not as implementer, but as user... I appreciate it when my device provides an email-oriented soft keyboard
JakeA: I don't have a strong opinion.. but keyboard affordance could be done using `autocomplete=email` attribute
chaals-o: My device might also offer suggestions from a list, which helps me.
... since you all agreed (quietly) to not leave it as ASCII...
... and I agree with Sangwhan, we should not make another one of these...
... I think we should update the validation rules to allow use of Unicode.
Toshihiko_Yamakami: : Want to ask about where we have to protect? Protect the implementation? I'm curious about the decision context.
... Older gateways shouldn't validate, just carry out the operation.
chaals-o: summarizing: what are our criteria when we make decisions regarding the spec. Should it match implementations, should it be aspirational to what the web should do...
... question about criteria is a good one.
... I think we should be allowed to write Unicode in user name. Sounds like the feature should stay.
... Here in #webplat, any decision we make must be published for wide-review to allows others to comment.
... Our decisions are provisional.
... given that, proposed resolution is to change input type=email to use Unicode.
... [Gavel comes down]
chaals-o: We now have new editors
... Thanks to Travis, AlexD, arronei for their contributions.
... so, practically, how are we going to make this change to the spec?
<tink> +1 on thanks to Travis Arron and Alex.
chaals-o: process: by and large we try to match implementations, though we've not been super-rigorous
... its been suggested that each change require a test.
... its been suggested not to add any features until it works in practice.
... where should we draw the line. Are folks happy to have a working draft full of good ideas, but they might not work?
... or do we lock the document until the thing you want to add actually works.
tink: I think we should have a test for all changes; but if the tests don't show interop, then we should look for evidence that it may be implemented later.
chaals-o: I mostly agree; slight tweak--even if you put it in the spec and it does work--it should still have a test.
plh: I'm PLH
... Was talking to Philip J about this...
... what happens when the tests are fine, the spec is fine, but the implementaitons don't want to change?
... it was the right decision for the time, but then what?
... Implementers (-ors)? can still not implement for a variety of reason. Something to consider how to respond.
chaals-o: <sarcasm>don't everyone leap up at once</sarcasm>
... thoughts?
... I think we may adopt an approach that allows us to accept proposals with some LGTM's (and if it has tests), we would accept into the spec.
... It wouldn't get into CR though. (If we don't think it's going to be implemented soon)
... We can keep speculative stuff in WD's that never make it to REC
JakeA: For submitting tests... how do we manage tests for WHATWG things now in W3C?
chaals-o: We put it in the repo. Might not be a big deal?
patrickkettner: All tests are in WPT... so no real other place....
... There are some tests that are marked as tentative. That could work.
plh: The core of WPT is to test the web, not necessarily test specifications.
... If we merge tests that are in the WHATWG, that's good. If there are problems we should talk about it.
... I'd rather have the discussion around tests to resolve the disagreement.
chaals-o: to the editors: does this sound like it works?
tink: Here's are new timeline.
... FPWD - 14th of Dec, 2017
... Update every 4-6 weeks
... CR - Aug 23rd, 2018
... PR - Oct 4th, 2018
... REC - Nov 15th, 2018
Michael_champion: when does the charter run out?
... Found it interesting that the schedule goes past the charter expired date.
tink: fair point.
chaals-o: we could pull the date forward... timeline was done by experience.
... doesn't seem like W3C is going to "kill it with fire" so plan is to do this "next year"
... we can beg forgiveness to finish the spec.
... if folks say, you should finish this work, but then kill it, we can extend to finish.
tink: we could also just drop a few WD updates to bring the timeline in.
chaals-o: anyone care about the ship date? Specific reason to move the date?
... default opinion: probably shouldn't plan work outside of charter...
... though WebPlat has lots of bits of work, so there's low risk to the group disappearing.
... end date on the charter is a checkpoint for W3C members
... cites: editing meeting where new work was suggested that needs to be added to the charter.
tink: If we decide to stick with Nov date, assuming we can get an extension to the charter.. we might miss our date.
... thinking about pulling in the date.
chaals-o: Don't think this impacts the editors (charter work)
... secret reason: rechartering is long and painful, and work would start much earlier (June/July)
tink: point is if people object to the new charter. It's not unreasonable to assume we'll get another FO.
chaals-o: notes level of interest in the topic...
... I propose we ship to timeline. Yes, prposed rythmn seems reasonable. Don't have strong opinions in the room.
... any other burning issues?
r12a: Was looking at minutes... can we can a summary of the type=email discussion?
... want to point to something saying the group has agreed (vs. just chaals)
RESOLUTION: the group agrees that the points noted in the minutes above should be adopted.
chaals-o: would like to discuss Workers.
... sangwhan is editing workers. He knows it's not going fast.
... he wants to make sure the spec matches reality.
... that's about all I've heard.
mikewest: we've had an issue open for some time #187...
... not a big deal.
... single feature added for CSP.
... was eventually pulled from WHATWG to HTML.
... but I didn't notice that HTML @ W3C didn't include workers.
... discussion ensued.
... I'm not sure what needs to happen in order to get changes into W3C's Workers doc.
... I only care because for various reasons, we need to have changes needed for WebAppSec put into W3C specs.
... this is a particular problem that's been happening for at least a year.
... I don't see more than an ad-hoc plan.
... I ping the bug, then there's some activity, then it dies.
... I don't see a dependable process to get this work done.
chaals-o: it's difficult. If we paid editors, and could fire them...
... then things might be different.
... we could motivate the editors that way, but we don't have that.
... (ah volunteers)
... when an editor's employer is invested, then there is some movement.
... Yelling at the chairs hasn't worked really well.
... Looking for help on workers.. anyone?
jeff: Hi I'm Jeff Jaffe
... I think chaals answer is accurate, but insufficient.
... would like to suggest that someone take an action to start a dialog between team and chairs to answer mike's question.
chaals-o: I'll take that.
... I think the answer is 'yes there's a problem, sorry we haven't solved it. we'll try to solve it with our meager resources.`
stevef: Seems reasonable to say: if you have a minor change, just file a PR.
... There's a lot of waste of time sending emails...
<jeff> ACTION: chaals to work with the team in resourcing Mike's question about responsiveness to issues.
chaals-o: if you want a change, do send a pull request.
... for Sangwhan, I can chat with him...
mikewest: the original PR was against the WHATWG spec. Wasn't worth my time to migrate a patch from WHATWG to W3C's bikeshed structure.
... that imposes a cost, and this group needs to pay it for having made the decision (to have a different format)
chaals-o: Not entirely unreasonable to file the bug (and not do the work)
... we're sorry we're causing your group pain.
... W3C process describes ad-hoc way of getting stuff done.
... we COULD drop all of our work and hand it over to WHATWG, but they also have an ad-hoc process.
tink: should we look at re-integrating workers?
mikewest: we at least wouldn't have missed it.
tink: should we still consider this?
mikewest: not clear to me why it was pulled out before--the two are quite intertwined.
tink: what do others think?
chaals-o: I have an opinion on that.
... HTML work adopted some principles, making things easier for spec editors was not a priority, but making it easer for folks to consume the spec.
... so if there's some very good reason why workers were split out, then that's probably still the right decision.
... There was a big push (back in the mists of time) to Modularize the spec.
... we've backed off of that in the charter.
... should we re-unify, re-modularize?
Stefan Zager_Google: I've found discovery to be a problem--having monolithic spec is helpful.
chaals-o: for those interacting with the "wider-world" how are they seeing this? How are they finding it difficult (or not).
stevef: what appears to be the case, the more specs they are modularized... the harder to keep up to date. Specs should reflect reality, so...
chaals-o: I'm leaning that way too now, given the discussion.
tink: modularized spec is harder to maintain, seems like a reasonable change.
chaals-o: Looks like the current temperature in the room is to find benefits in unifying.
Michael_champion: can you elaborate on what history you're referring to...?
chaals-o: I won't elaborate; the meetings were confidential.
... but our charter says we would modularize HTML.
... some things we did, didn't match that.
... charter now is not mentioning modularizing...
... So, this is not a decision, but the current direction I'm thinking...
xiaoqian: For CR, we went through all the issues, but some were still there; we want a new label to mark the high-priority issues.
chaals-o: we should just do this; don't really require a WG decision. We shouldn't be more of a blocker to other groups than we already are...
stevef: I have tried to be more responsive.. thinking back to when mike's issue came up; but my area of expertise is limited and we need editors with that expertise.
chaals-o: there were editors who were doing their best to accomplish these tasks; thanks again.
... Propose a break till 11am.
<jsbell> https://github.com/wicg/entries-api
<jsbell> https://wicg.github.io/entries-api/
Josh: history of this: many years ago, Google proposed a file system api
... the same API was reused
... worked with directories
... things lingered for many years, but there was demand
... other browsers started implementing, following Chrome’s model
... also Safari (yay)
... The spec was marked obsolete, do not implement
... currently sitting as a WICG spec, awaiting feedback
... Given that we have implementations now, do we still need it to be webkit prefixed
... Good discussion at the web platform test meeting earlier this week
... test results pretty good
<pwnall> Entries API tests: https://github.com/w3c/web-platform-tests/tree/master/entries-api
Josh: some failures around IDL tests, Edge missing some interfaces
... Any additional feedback? Not a priority to move out of incubation
chaas: meta comment:
... we have interoperable implmentations and you can do the core stuff
... what kind of comment is going to make a change?
josh: if any browser implementar wants to go unprefixed?
... browsers use callbacks, some examples given to wrap with promises
... not a high priority, people got used to it or it’s being wrapped in libraries
... if any implementer wants to push forward, please do
... last comment from the chrome side: more feedback around interop with native file system, file system type can be exposed
... given security and permissions are right
chaals: yes please, something i always wanted
josh: next topic around cookie access
... folks from google and microsoft who have thoughts
<pwnall> async cookies api from google: https://github.com/WICG/async-cookies-api/blob/gh-pages/explainer.md
victor_google: proposal is three laysers
... first layer: reading and writing
... second layer: observing changes from doc context
... third layer: observing cookie changes from service worker
... based on feedback from google-internal properties
... some of it may not be fully documented, feedback welcome
... nothing is cast in stone, we welcome feedback
... both from web dev and browser vendors
nolanlawson: we looked over it
... we also have a cookie change events api proposal, posted to github
<jsbell> https://patrickkettner.github.io/cookie-change-events/
nolanlawson: apis are pretty similar
... might be interesting to start to think
... full featured api has sw support and promosing, granular listening, utf8
... thinking in different stages to find common things
josh_google: we’re obvisoulsy happy for other implementors, sw piece is elementary
... not a secondary feature
... key scenario is having cookie involved in authentication
... one of the reasons is using cookies from a service worker, as it’s async
... wouldn’t strat w/o sw support
patrick_microsoft: sw support is essential
... secondary proposal is to add an event listener to document.cookie
josh: which requires having an active client
jake_google: in the sw meeting one of the requests from facebook and google was to query the state of cookies from the sw
... for change events, have you heard that request? is it more important to have pull vs. push?
victor: what we are aware of is developers want change events in sw
... in an async way that doesn’t block
jake: we’ve heard from facebook that they want read access, a getter
nolan: our perspective is that this can be fixed with cookies
... essentially, we’re seeing the same sort of problems being attacked
... cookies should be accessed async and promise-based
... no one wants to parse/stringify cookies
... we see perf issues with polling
... especially for polling for changes
... concept of a listener/observer is common to both specs, both agree on that
... looking at the shape of the two apis, don’t see conflict, but pending spec work
... around the async parts
jake: async stuff and promise api: are there implementaiton concerns?
patrick: detail pls?
jake: is there an implemtnation concern?
patrick: two separate issues
... the main thing is we look at these two specs, 14 pages, very ambitious spec
... it’s a lot
... we wannt to solve the immediate performance problem
... one of the pieces of feedback: the observer pattern, not sure that’s the right pattern
... there’s only one cookie store
... seems more adequate to use an event listener
... that’s just one example
victor: glad you brought that up
... it seems like our observer layer matches ours
... if there’s a concern for observers vs. events
... you already mentioned observer not the right api because there’s just a single cookie store
... we went for observer because we don’t want to see all changes
... but just the events you’re interested in
... if there’s a concern, that’s an argument to look at event listeners
<JakeA> https://github.com/w3ctag/design-principles/issues/78
victor: based on your feedback, we can look at it
patrick: when in your current explainer there is no reference to multiple cookie stores
... something you are considering?
victor: sorry, think i was unclear. there’s one cookie store
... if you have an observer, you can say what you’re interested in to observe
... you can select, e.g., certain prefixes
... that’s something google people want
... with an event listener it’s unclear how one would do that
jake: posted a link to a discussion
... when to use observers vs event lsiteners
... observers miust be motivated, event listeners are the default
victor: if event listeners are better than observer for that, we are happy to iplement
nolan: a filtered listener could be added
... when we start talkking about filtering, it’s already a complex spec
... just saying observe all cookies is the simplest
... it’s true we need a way to wake up the sw, maybe with a push
... the api would eb different for document vs. sw
victor: we want the layers back where you can only implement the layers you want
... implement the filter later and increase performance
patrick: please rephrase
victor: if you want to implement a part of the spec only, we want that to be possible
patrick: we’re not against filtering at all
... we do a lot of perf analysis like you
... we want the simplest proposal possible
... we’re not against it, but need to figure out the right shapoe
... cookies as objects inside the event
... that you could filter
... event listeners could be added to individual cookies
... part of a far more ambitous idea, we just want to fix perf now
victor: having the api spec with filters, but having the spec say the event listener could be ignored at first, and later be implemente
patrick: great idea, we can start speccing
stefan: recap a couple of points
... on the issue of filtering
... for most event types, the rate would be low
... but scroll events come very fast, making it hard to keep up
... another point was the cost of bubbling events
... just the cost of computing acestor chains is expensive enough for frequent events
... so a good argument for observers
patrick: no ancestor chain currently
chaals: do there need to be different shapes? my feedback is, unpleasnt situation
patrick: there doesn’t nned to be, it could be added to window obj
bell_google: for sw, we want to avoid waking up the sw for nothing
... need to leave time for a11y folks
... any last, q?
alice_boxhall: we talk about AOM
... who has heard of it?
... about half
... express the semantics of an element to accessibility model
... currently needs to be done with aria attributes
... some things can’t be done
<aboxhall> https://github.com/WICG/aom/blob/gh-pages/explainer.md <-- explainer
jcraig_apple: probably more of you know aria than AOM
... where aria falls short is id refs
... they need to be in the same document
... the shadow root is different root-wise
dominic_google: some gaps in aria
... only way to express relationships is via id refs
... with labeldby
... this doesn’t work for different tree scopes, maybe in an iframe
... very inconvenient
... next gap is: input events that can’t be captured
... you can make an accessible slider or a map control
... on desktop this works fine b/o keyboard shortcuts
... on mobile, there are different gestures that indiciate different behavior like scroll
... can’t be caputered
... there is no equivalent on the web for that
... the accessibility tree has the correspondance with the dom
... where the dom doesn’t correspond with what’s conceptually exposed to the user, you have to create fake dom elements and decorate them with aria
... there is no way to know if you spelled things correctly w/o using an external tool
... you are not sure if you’re using it correctly
... you need to use a lot of getattribute/setattribute
... annoying'
<jcraig> s/james (apple)/jcraig/
dominic_google: sprouts a bunch of extra attributes that are just implementaiton details that should be hidden
... the context here is: we’ve divided the AOM into phases
... they can be implemnted incremewntally
... first phase makes all the exisitng aria attributes avail from js
... now you can take any elemnt and via js assign the aria attribute
... instead of creating ids, you can reference elements directly
... this frees up the authors to get elements they want ot reference
[brings up demo]
dominic_google: link?
... now looking for demos, feedback, examples from the broader community
... next part is accessible inpout events
... explicit events that can be sent from assistant devices
<aboxhall> https://tink.uk/playing-with-the-accessibility-object-model-aom/ explains how to enable the flag
dominic_google: developers can directly listen for events
... like increment, decrement, dismiss, they might not have correspinding dom events
... this raises a privacy concern:
<aboxhall> http://wicg.github.io/aom/demos/#21 these demos
dominic_google: for the moment the plan is to require explicit opt-in by users
... a dialog will pop up when such an event wants to be captured
... third topic is virtual nodes
... virtual nodes
... that don’t correspond to actual dom elements
... if the user should interact with those, you could create them, and have the user interact with them w/o needing to create actual dom elements
... on all platforms you get a11y for free with native controls
... with custom elements you lose this
... requires hacking
... with virtual nodes you have the same flexibility without the pain
... you have extra apis like bounding boxes
... last part of the spec is introspection
... is like computedstyle, can get the computed accessibility tree
... stopping here, any deep dive?
chaals: sounds good, let’s get it
... do you want us to pick this up in a charter?
... or just for chatting?
craig: mostly for informing
... mainly seeking comment
... jump on github issues, give us feedback
... want to make clear what this is and why it’s necessary
name?: if there is feedback for the use cases, please let us know
shwetan: looks good to me
... are you looking for test cases or prototypes?
alice: all of the above :-)
... having people try out the chrome implemntation
... we will link to the slides and demos
... if you have use cases, let us know
shwetan: haven’t looked at the apis in detail
... should be similar in syntax to actual dom elements (for virtual nodes)
alice: my concern is: we do it, and everyone likes it, but not sure how much detail people have looked at
... no pushback yet, afraid everyone just nods it off
... please try it out
... we have the cure of knowledge
james: [shows demo]
... application, browser creates a11y tree
... assistive tech then uses this tree
... interfaces on behalf of the user
... when a user wants to click a button, the button can be interpreted by the browser
... the assistive tech can read this from the browser and convey it to the user
... user knows how to “press” a button
... browser then handles that
... where this falls apart is custom elements with custom interaction
... a div that represents a slider
... with aria you can say the div is a slider
... assistive tech can tell the information to the user
... user can then “increment”
... but it falls apart then
... the div has no increment
dominic: [shows google docs]
... the dom looks nothing like the semantics of the actual word processor doc
[shows the calcuator app]
dominic: accessible with voice over
... toy web app that streams the calcuator to the web app
... imagine the calculator is visual studio or something
... maybe patrially rendered on the server, on the screen it’s just pixels w/o meaning
... even though it’s just an image, voice over works
... buttons labeled
... everything comes from the a11y tree
... exposed via the AOM
... driving the native app
... pixels are entirely differently generated than the a11y tree
... receives events from the user
... it’s not mouse clickable, just via voice over for the purpose of this demo
chaals: yes :-)
james: most major document suites have complex underlying custom views. Google Docs uses a canvas view for example. iWork for iCloud (Apple’s document suite) is a custom svg view, the dom structure has nothing to do with conveyed semantics
... could be made work , but way too complex to use fake dom elements to fix a11y
chaals: time is passed
... make it happen, ship it
dominic: thanks for giving us time, at 2:30 we detail the idea more
chaals: screen orientation api skipped in marcos cazeres absence
josh: indexeddb 2 update
<jsbell> https://www.w3.org/TR/IndexedDB-2/
josh: on track to exit CR
<jsbell> https://github.com/w3c/IndexedDB/issues/213
<jsbell> http://w3c.github.io/test-results/IndexedDB/less-than-2.html
josh: implementation report ready
... tests new with very obscure edge cases
... moving from dom error to dom exception
... backwards compatible and widely agreed
... no active work on new functionality
... some agrement from implementors to add an api to enumerate databases
... not been added yet
... could be added
... other active work: on the chrome side: experimenting with an observers api, looking for feedback
... this would allow web apps to observe changes coming from within a sw
... no broadcast channel would be needed
... not far away from pushing this into the spec
... next iteration of indexeddb: firefox had this, bubbling errors up to window
... we ran into perf issues when implementing this in chrome
... otherwise, not much going on
... questions? none
chaals: thank you
<cpn> /join #wicg
SZ_google: I have done the bulk of the work on the spec.
... It's now an FPWD.
... Chromium shipped IO in May 2016.
... It's since shipped in Firefox and Edge, and is on it's way in Webkit Safari.
... With a bias to mobile, it's used on about 10% of page loads already.
... IO eliminitated a popular use of Flash.
... I have a proposal for IO 2.0 if people are interested?
... Ok, IO 1.0 has overflow clipping and CSS clipping, but doesn't tell you about visibility.
... It has utility for things like infinite scroll.
... but doesn't give you iron clad guarantee of visibility to the user.
... IO 2.0 will introduce a feature that will change this.
... It will eliminate a common use of fraud on the web.
... This will be harder to implement/compute.
... I hae an idea how it could be done in Chromium, and possibly WebKit.
... Not sure about Firefox or Edge.
... We have to be certain that an invisible element is never reported as visible, and vice-versa.
NL: Another use case is element timing AKA hero timing.
... But it gets tricky with the question of the default route.
SZ: The default behaviour is to report within the viewport layout.
... My understanding is that element timing is about time taken to get to first meaningful paint.
... As soon as a target element is visible to IO, whether scrolled off-screen or not, a notification is generated.
... I think the difficulty is that IO timing, the timestamp, doesn't account for time taken to raster.
... NL: If that's our conclusion, then we can't define element timing in terms of IO I think.
PW: To add to this, the WebPerf discussion was to expose an entry with multiple timestamps.
SZ: This poses more of a problem for the spec than implementation.
... There isn't a way/room in the spec for measuring time between the intersection observer being generated and pixels rendering.
... Would need help to spec that.
PW: Is there a link to IO 2.0?
SZ: Yes.
PW: If visibility changed would it trigger a notification?
SZ: Yes
<szager> Proposed V2: https://szager-chromium.github.io/io-v2/
SZ: Want to acknowledge Philip's work on IO.
<szager> https://github.com/w3c/IntersectionObserver/issues/124
SZ: There is an open issue about elements taller than the viewport.
VS: We have a few open issues.
... One is a future request "Pointer clip".
... Also some boilerplate issues.
... PL 1.0 reached Rec last year, and 2.0 was opened up for maintainance and enhancements.
... So far only editorial updates.
... We're not ready to publish a WD update.
... We specify mouse events have an attribute movementx/y
... It's based on changes in screen x/y.
<dtapuska> Issue #24 https://github.com/w3c/pointerlock/issues/24
VS: The CS WG has a spec that modifies screen x/y to become double values.
... If this is released, we'll also need to change the movement x/y to use doubles because they're linked.
... I have an open issue in CSS to ask about this.
... If anyone has suggestions/opinions I'd like to hear.
... Otherwise I'll just wait for CSS to get back to me.
... PL was initially specified without reference to high DPI and/or zoom.
... Multiple display pixels can be mapped to an OS level pixel.
... Queston is what co-ordinates space should the PL values be in?
<dtapuska> Issue #23 https://github.com/w3c/pointerlock/issues/23
VS: The use cases - there is no obvious single solution, so we just have to pick one.
... Like be aware when a zoom is happening and correct for it.
... A use case is a 3D environment for a game, using the mouse to move.
... You move your mouse 6" on the desktop and turn 180 degrees in the game.
... if the view is zoomed, that relationship changes.
... Conversely, you could attempt to render a synthetic cursor/pointer.
... you could choose to use PL to hide the actual cursor, and control the software cursor with additional constraints.
... in a real-time strategy game for example, where the cursor is constrained to a specific area.
... you then want the synthetic cursor to move in the same way the OS cursor would.
... if you have a high DPI screen or if you zoom, you still expect the cursor to move in the same way.
... that's the problem space.
... There isn't yet consistency in defining how CSS pixels for screen x/y respond to zoom or high DPI.
... There have been attempts to resolve this, but no solution AFAIK.
... Here are the issue links.
<dtapuska> UIEvents Issue #150 https://github.com/w3c/uievents/issues/150
<scheib> UIEvents Issue #150 https://github.com/w3c/uievents/issues/150
VS: Until it's resolved at CSS I don't think we can update PL.
<scheib> Issue #21 https://github.com/w3c/pointerlock/issues/21
VS: Another change request is changing the target where events are dispatched.
... Full-screen has a change to where we dispatch events, indicating exclusive access to ful-screen has been entered/exited.
... Want to go back to the pointer clip issue now.
<scheib> Pointer Clip https://github.com/w3c/pointerlock/issues/27
VS: Pointer clip is a concept raised during the original PL.
... Use case is mostly real-time gaming, with an overview map of the world.
... The mouse cursor is moved quickly, to pan the view, and select things.
... So if you push on the left of the map, the expectation is that the view will reveal more of the left side content on the map.
... It takes a cursor and leaves it visible, but constrains the area in which it can move on screen.
... In the browser you may not want to play in full-screen mode, and have your cursor otherwise available.
... This is possible in PL.
... Because it's possible, this is why this use case did not ave a special API added in PL 1.0
... Developers have complained there is a performance impact.
... There are noticeable delays between moving the mose and it responding on-screen.
... OS for a long time have had dedicated solutions to make sure the mouse cursor is as responsive as possible.
... Request is to add a new API or a variation or parameter to PL 2.0 to constrain the mouse cursor.
... Not aware of any implementors willing to implement this though.
... All four major browsers now support PL 1.0
... I'm hesitant to add new features unless there is interest. Would like to ask if there is any from implementors in the room?
SZ: Whats the expectation in the non-full-screen case?
VS: In this proposal it would be implemented using low level OS APIs.
SZ: There would be no way to guarantee that the app would release the pointer lock?
VS: Yes.
... There is an escape gesture - the escape key on a desktop for example.
... You get a notification when you enter this mode.
... Chrome has a timer for the exit instruction for example.
... In Windows pressing the Windows key, or Alt Tab has the same effect on Windows.
Xidorn_Mozilla: The API is interesting.
... As far as OS providing the functionality, I think the request is reasonable.
... We should probably have this feature.
... But I can't comment on our priority to implement.
VS: My opinion is that it's a reasonable request.
... My concern is that in 7 years I've heard this request from perhaps 5 companies.
... It seems like a very niche use case.
... also if we continue to do performance work, we benefit many things.
... Then this problem also becomes less.
... So I think I'm opposed to adding the API, but I'm aware the request is there.
... artillery.io wanted to bring Star Craft style gaming to the web.
... They haven't been able to achieve it, because of the lack of this feature.
... That's a shame.
... So that's why it's still worth having the conversation about this feature.
Xidorn: Maybe because there aren't many people implementing games?
VS: Yes. If I saw more game developers bringing games to the web, I think the priority of this would change.
GK: Don't have much to talk about.
... Léonie gets credit for pushing two specs forward to CR (Key Values and Code Values).
... Want to do some significant rewriting in the UI Events spec.
... Want to try to identify and document what browsers to and put it into better format.
... It'll give us better integration opportunities with other specs, like Keyboard Lock for example.
... If anyone has a spec that was previous lacking this, let me know.
... So I want to do this before we push UI Events to CR.
DT: We skipped over event dispatch, and would like to see it resolved in the next year.
... Not sure which spec that belongs in?
... Relevant to the event lifecycle.
... Not sure if HTML5.2 covers it?
CMN: This will be addressed by writing out the alogrithms?
GK: Yes.
<chaals-o> LJW: Where are we at in terms of interop for key code values?
GK: Thought I'd sent something out.
... We have about 2.5/3 implementations.
XW: Is there a timeline for Intersection Observer?
SZ: 1.0 or 2.0?
XW: 1.0
SZ: FPWD came out a couple of months ago.
... we had lots of revisions in incubation.
... We have abou 20 issues we need to deal with.
... Perhaps a week of editing time.
CMN: When the editing is done we can go to CR, though that's typically not less than 90 days from the FPWD being published.
SZ: Early next year then I guess.
<garykac_> Leonie, I have the implementation report for uievents-key at: https://w3c.github.io/uievents-key/impl-report.html
<garykac_> and uievents-code is at: https://w3c.github.io/uievents-code/impl-report.html
<garykac_> But I haven't updated them yet for recent updates to Safari.
Marcos: Update on WebManifests -- getting implemented on all browsers
... Has shipped in Gecko and Chrome for a while
... Not yet in Edge
... Now considering V2.
... V2 will be web-IDL-ish
... Google crawling stats suggest V2 won't cause impact.
... Seeking feedback from Apple/WebKit
... Spec now feature-complete, working on tests
chaals-o: Perhaps overlap with browser extension manifest?
Kenneth: Moving to WebIDL will enable this.
Marcos: Cry for help! Struggling with spec terminology.
... blah blah blah environment client settings object blah blah blah
[chirp]
chaals-o: Interested parties not present, so maybe punt
<tink> https://github.com/w3c/WebPlatformWG/issues/88
Leonie: Maybe FPWD soon?
... Repo needs to move to w3c
Leonie: What to do with Gamepad spec? Mostly dormant this year, no response from maintainers.
chaals-o: Looking for new editors.
sLéonie: Current editors are Brandon Jones, Scott Graham, Ted Mielczarek.
[Brandon Jones arrives]
scheib: Need to find a way forward with editing
... Chrome has proposal for adding vibration outputs
... Would use "rumble" feature from gamepad controllers
... Common feature of gamepads; feature requested many times
... Feedback on proposal is lukewarm; Microsoft says looks good.
... MS not sure what priority should be.
... VR controllers is dealing with similar controller issues.
... Looking for more input from gamepad makers.
Theresa O'Conner (Apple): looks good, no major problems
Marcos: There's now a repo to get standards positions from Mozilla
NellWaliczek_Microsoft: Need to consider differences in haptic motors
Kelvin_Sony: Newer controllers have some common functionality
Kelvin: e.g. Touch support, which doesn't have support in current Gamepad API
<marcosc> MC: standards positions from Mozilla, https://github.com/mozilla/standards-positions
kelvin: At a minimum, need X and Y
... How to handle multi-touch surfaces?
... Also need width/height and touchID
<scheib> related issue https://github.com/w3c/gamepad/27
kelvin: to distinguish separate touch events
... Light indicator present on many controllers
scheib: Google supportive of adding these features
... Flash deprecation makes this more useful
... Time is right for extending Gamepad API
NellWaliczek: Also want to re-energize Gamepad development
mattreynolds_Chrome: Make sure we're not duplicating efforts with WebVR
NellWaliczek: Definitely overlap, and also distinguishing features
<scheib> Some related issues -> https://github.com/w3c/webvr/issues/297 https://github.com/w3c/webvr/issues/298
mattreynolds: re button/axis primitives -- would be nice to be able to use VR controllers via Gamepad
NellWaliczek: Device drivers/controllers an issue
... VR hardware is pretty fundamentally different
bajones_chrome: Many current VR implementations use Gamepad currently
bajones: Inaccurate feature mapping has caused many problems
... Control mappings are free-for-all
... Plus, capability profiles of VR inputs are still in development
<chaals-o> [some head-shaking at the idea we might do this by finding and mapping every controller ourselves]
NellWaliczek: Gamepad input not event-based
scheib: Gamepad input should be a user gesture
... If gamepad is polling during rAF, maybe it can consume user gesture?
chaals-o: Yes, should be able to generate events
scheib: mouse move event is not considered user engagement gesture
... button press *is* user engagement gesture
... These issues are tractable
... Generating events may exacerbate event spam
NellWaliczek: Maybe only events for button press?
... Still, let's look for overlap with motion input from VR controllers
bajones: Gamepads have lots of buttons. Browser shouldn't have to map every variety.
... But still, maybe helpful to identify "significant" buttons that qualify as user engagement gesture
Steve_Sony: Regionalizing primary button controller: what's up with that?
bajones: Browsers could do more to apply localization data.
... But usually "primary button" is hard to determine
NellWaliczek: Non-standardization is getting worse with new hardware
... Would like to work with other vendors towards better standardization
chaals-o: When evaluating whether gamepad gesture is a genuine gesture, the browser gets to determine it
bajones: In chromium, e.g., must have a "button up" event before accepting any more button events.
... Chromium already doing intelligent evaluation of user gestures
chaals-o: Not necessary to solve this problem to make standards process
Thomas_Wisniewski: Would be good to standardize what a user gesture is
scheib: Mainly, user gestures used for fullscreen, pointer lock. Separate issue from button mapping.
... App will determine whether to go fullscreen, but UA will make its own determination whether to allow it.
NellWaliczek: Agreed that these are separate issues
scheib: Moderately positive feels on adding vibration
... Good to see Sony take interested in Gamepad
... Still need more editing
[Brandon is on the spot]
bajones: I feel bad.
... This is not the first time Gamepad spec editing has stalled
chaals-o: Drop the "Gamepad"; it's cleaner
bajones: I bravely volunteer to stop editing
scheib: VR hardware desperately needs an abstraction layer, and Gamepad API is not it.
... However, apps will want more Gamepad-like access to new VR hardware
... Would be a big mistake to develop competing/overlapping interfaces for new hardware
... Gamepad has enough success that it shouldn't be allowed to languish
... WebVR should interact/cooperate with other Web API's
Evil_Alex: WebVR needs very low-latency input, compared to main document events
... WebVR event rate might be much higher than rAF.
NellWaliczek: WebVR input work is very early stage
... Now is the right time to figure this out
bajones: New spec from Kronos (sp?) for VR input will be wildly mismatched to Gamepad API
... (OpenXR)
Steve_Sony: Gamepad input needs low latency too.
NellWaliczek: Low latency needed for curve-fitting
... Need synchronization between headset events and controller events
scheib: Maybe need time-aligned event data to work with VR
NellWaliczek: Nope, prior work showed this didn't really work
... VR input is basically two types: "gaze and commit" and "point and commit" (also "tap and commit")
... Gaze and commit -- use position of user's head for targeting
... "Commit" can be button press, mouse click, key press, or even head-steady
Nell: point and commit -- direction comes from controller
... tap and commit -- tapping on screen
... Modality not as important as targeting ray
... At a high level, input is direction+commit
scheib: Gamepad API still useful for more low-level control
... High-level interpretations may have to happen in user code
Nell: Feedback is that low-level interface didn't work well
bajones: Recycling Gamepad data structures for new VR hardware inputs is probably OK
... Concern is that there's a lot of static string checking in existing apps that won't recognize events from newer hardwrae
... The mapping problem is key to adapting Gamepad to VR hardware
Nell: Need to be forward-looking, forward compatible
... Must avoid known anti-patterns
chaals: Maybe schedule future meeting
bajones: Maybe discuss during bi-weekly (yes, that's right) WebVR call
... Maybe November 28?